Google Summer of Code 2014 - Proposal to Improve Composer UI
shopik at inblock.ru
Sat Feb 8 09:55:56 UTC 2014
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:
>> 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...
>> 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?
>> Well that's the one I am worried about. Might all be a bit much for a 3 months
> 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
>>>  http://blog.queze.net/post/2014/01/24/Project-ideas-for-Summer-of-Code-2014
>>>  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
More information about the tb-planning