Google Summer of Code 2014 - Proposal to Improve Composer UI

JoeS joesab2005 at gmail.com
Sat Feb 8 01:32:26 UTC 2014


On 2/7/2014 4:06 PM, Axel Grude (Axel) wrote:
>
> All,
>
> I think some UI work on composer would be great. Maybe a Ribbon-Style 
> / extended Formatting Bar interface, plus fixing the bugs around 
> [Enter], so that writing paragraphs would be more consistent.
>
> So I am following up here to ask if this would be a good project to 
> mentor. If I had time I would write this as an Addon, but sadly...
>
>
>   Rationale
>
> To make it easier to compose great looking emails and encourage users 
> to use semantic tags for formatting.
>

I totally agree, we have needed this for a long time.
>
>
>   User Definable Styles
>
> in particular I like these widgets as they are very easy to use (1 
> click) and show that styles can be expandable:
>
> "normal" this is actually the style that is assigned to<p> and adds a 
> <p> mark if the text is pure body. [Enter] should split the paragraph 
> into 2. I would like to design an easy to use interface for defining 
> the styles which would inject the css styles (either on class level or 
> inline on send). The implementation should allow for some downwards 
> compatibility but not too much (since we are using semantic styles 
> such as p h1 h2 etc style deterioration on lesser mail clients would 
> be something expected anyway. I would aim for being at least "Broad 
> strokes" compatible with capable HTML clients such as outlook, so that 
> largely font sizes, colors, and very important formats in quoted mails 
> stay largely persistent. (This is not easy)
>
> Each style should have a "follow on" rule, e.g. <h1> => <p> , <p> => 
> <p> , etc. and a broad selection of typographical attributes, e.g.
>
Are the widgets you refer to theoretical, or are they part of 
smarttemplates extension, or something
I agree on the enter=paragraph break issue
A lot of trouble pasting in </p><p>
so i didn't bother with that here.
>
> Font specific
>
>   * font family
>   * font size
>   * font weight
>   * font decoration / formatting
>   * color
>   * background color
>   * text shadow
>
> Block specific
>
>   * alignment
>   * line distance
>   * Spacing before & after (padding)
>   * indentation
>   * line width
>   * border styles
>   * box-shadow
>   * gradients
>
> Inline / Character Styles
>
>   * these would be injected via <span> and would allow stuff like the
>     html entities in this mail (I am using <tt> blocks which are
>     defined as inline-block). the hardest thing with these is to come
>     up with a non-technical description (or does one ues CSS terms). I
>     think the benefit is pretty much visible instantly once you come
>     up with some examples.
>
I'm not quite sure how you got those <tt> blocks in there, or is that a 
feature of your extension
>
>  *
>
>
> Most rich text editing users are familiar with the concept of user 
> defined styles. One thing to solve would how to persist the style 
> definitions, would the be only stored in the email and / or globally. 
> It should also be extendable in the form of a style template so that a 
> bunch of style definitions can be stored together under a common name. 
> I wouldn't attempt to implement the template management as part of 
> this project but make it extendable so that the overarching template 
> structure already exists.
>
>
>   A panel for table styles
>
> ..at the moment the inclusion of tables in Composer is also somewhat 
> lackluster (if you ever try to paste an Excel formatted table into a 
> html mail you can see the sorry effects of this). So at least we 
> should provide a tool to quickly format the table with a colored style 
> and a heading.
>
Shouldn't we  use divs rather than tables or at least offer that as an 
alternative.
>
> As you can see there is support for odd and even rows (also columns) 
> and especially the header row and first column, I think this pretty 
> basic stuff and should be implementable via nth-row etc.
>
>
>   List styles
>
> should they be separate?
>
>
>   Style Persistence
>
> There are 3 levels of style persistance: In the mail client / profile, 
> in the individual email and after sending on the recipient's system. 
> With persistence I mean the answer to the question "where and how are 
> these styles stored".
>
> On the program level, of course we can (and probably should) persist 
> the styles in the config database, so that they can be used again and 
> again (Similar to Word's "Default template"). Then these styles could 
> be copied into the composed emails using CSS classes, e.g. by 
> injection into the <head> section. Of course the epxectation of the 
> users is that if I modify my style while composing the email, it will 
> automatically be updated (and stored) in my composed email. Likewise, 
> if I re-open the email from my drafts folder (or via "Edit as New") i 
> would expect my style selections to reflect these styles (provided I 
> have created the mail with the same system = current Thunderbird); if 
> I have chosen to make my headings blue, I want them to be blue again 
> when I continue editing.
>
> The next question is whether changes to for example the <p> style will 
> then atuomatically affect all following emails, or how to create an 
> easy to understand interface
>
I think we should just rely on templates for persistence I don't think 
anything developed in the scope of GSOC can do better.
>
> There should be an option to persist these styles down to the inline 
> level for "lesser" mail clients. We need to have some clever way of 
> optionally pushing down styles from the class level (maybe on send or 
> save) but we should also be able to change the style on class level 
> later. This means, in this mode, that inline styles must somehow be 
> marked for deletion (or ignored) while composing.
>
> I think using inline styles this is the biggest challenge for actually 
> implementing a proper styling system, therefore I would be happy if we 
> could implement CSS class (or element level) styling first so at least 
> non mail-mangling clients display the html content in "Hi-Fidelity".
>
>
>   Clipboard and Format Painter
>
> a more helpful panel when dealing with pasting and can support things like
>
>   * Paste
>   * Paste without Formatting
>   * Paste as Quote
>     ---------------------
>   * Paste as Code Snippet  (if we can select a quickStyle when pasting
>     this will be very handy for developers and other specialists)
>   * Paste as <User defined Style 1>
>
> Format Painter: can be used to transfer<span> or <block> level style 
> depending on what is selected
>
What is "Format Painter", a separate program, or another proposed 
included feature.
>
> .
>
> To make it easier for the user to understand the style application I 
> would suggest a "x-ray" mode which shows paragraph and spanned 
> outlines of the currently active element.
>
> Also an Fx inspector style breadcrumb panel might be helpful:
>
> interestingly in a standard email the nesting would typically not be 
> very deep (maybe 3 to 5 levels), clicking trhe container would tightly 
> outline it on screen - also an advantage when troubleshooting 
> <spanned> font attributes. do you think this might be a helpful tool 
> for formatting HTML mail?
>
>
>   Scope
>
> Well that's the one I am worried about. Might all be a bit much for a 
> 3 months project...
>
>
Yes, I think it's way too much for a 3 month project and won't these 
proposed enhancements require changes to the 'core editor'
That's a task in itself
unless you are proposing forking the editor,
I think that will eventually be the only answer

>>
>>
>>
>>
>> [1] 
>> http://blog.queze.net/post/2014/01/24/Project-ideas-for-Summer-of-Code-2014 
>>
>> [2] https://wiki.mozilla.org/Community:SummerOfCode14:Brainstorming
>>
>>
>
>
Please read this in HTML. 90% of the email world does.
-- JoeS/1/2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140207/2615ac63/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8807 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140207/2615ac63/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8155 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140207/2615ac63/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 19507 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140207/2615ac63/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4962 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140207/2615ac63/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11489 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140207/2615ac63/attachment-0004.png>


More information about the tb-planning mailing list