Google Summer of Code 2014 - Proposal to Improve Composer UI

Nikolay Shopik shopik at inblock.ru
Sat Feb 8 09:55:56 UTC 2014


some OT

Joe, email quoting not showing at all while at plain text mode, anyone
know bug for this? I seen this multiply times.
Last time I investigated it was related to multipart messages.

On 08.02.2014 5:32, JoeS wrote:
> 
> 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
> 
> 
> 
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
> 



More information about the tb-planning mailing list