Google Summer of Code 2014 - Proposal to Improve Composer UI

Axel Grude (Axel) axel.grude at gmail.com
Sat Feb 8 11:37:57 UTC 2014



*Subject:* Re: Google Summer of Code 2014 - Proposal to Improve Composer UI *To:* 
tb-planning at mozilla.org - tb-planning [tb-planning at mozilla.org]
*From:* JoeS <joesab2005 at gmail.com> - JoeS joesab2005 at gmail.com 
<mailto:joesab2005 at gmail.com>
*Sent: *Saturday, 08/02/2014 01:32:26 01:32 GMT Standard Time {GMT ST} +0000 [Week 6]
*Subject:* Re: Google Summer of Code 2014 - Proposal to Improve Composer UI
>
> On 2/7/2014 4:06 PM, Axel Grude (Axel) wrote:
>> ...
>>
>>
>>   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
They are meant as part of a long needed overhaul to make the Composer as awesome as 
the rest of Thunderbird. I would not propose to add them to smartTemplate4 (which I 
own), they are really needed in the core code. However this should be discussed here 
first before even looking into it. If the consensus was that an Addon would be better 
suited, this should definitely be done in its own dedicated Extension.

I have been thinking about these features with this functionality for a long time. And 
this gestated the more concrete wish to create an Addon, but the problem with Addons 
is that they have a very small audience and so wouldn't help Thunderbird as much as a 
core change. Also I wouldn't have enough time to write such an Addon by myself alone 
as I already have too many Addons to maintain. I would however offer to mentor and UX 
design lead such a project.
> I agree on the enter=paragraph break issue
> A lot of trouble pasting in </p><p>
> so i didn't bother with that here.

With current Thunderbird, you can simply use the format menu:


As you just demonstrated, this is not easily discovered by most users, with this 
minimal UI, imo Paragraph should be the default (like it is in Outlook). Body Text is 
actually not a style at all it just meant "no container" and makes it much harder to 
persist a style (especially when you are quoting). I am not sure what the official 
method of transferring styles from <body> is - what I see in this email is that the 
<style> tag that I placed in the <head> section was transferred into the <blockquote> 
and all rules were prefixed with a unique id #mid_52F54AC8_8080408_gmail_com.

>> 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

In Thunderbird, after highlighting the word I want to style, I simply used the font 
drop-down:


I then manually injected the following code into the <head> tag (I am using the 
Stationery Addon for editing the Source code):

p tt, li tt {
   background-image: linear-gradient(to bottom, rgb(230, 240, 163) 0%, rgb(210, 230, 56) 50%,
                     rgb(195, 216, 37) 51%, rgb(219, 240, 67) 100%);
   border-radius: 0.3em;
   display: inline-block;
   border: 1px solid rgb(187, 187, 187);
   padding: 2px 4px; font-size: 10pt ! important;
}

Note that I use this only for tt blocks contained within paragraphs or lists; of 
course I could also have added a class but I am lazy :-).

In order to avoid this affecting quoted material I would have preferred to use: body > 
p > tt but unfortunately due to [Bug 964024 
<https://bugzilla.mozilla.org/show_bug.cgi?id=964024>], Thunderbird replaces  the 
child selector > with >  (we should teach it not to mess with <style> sections like 
that).

The other question is whether such inline level styles should also be within the same 
widget (I think this is what Outlook does) or should they be separate?

The whole point of my suggestion to give the users a possibility to do the above 
without having to edit the message source or necessarily understanding CSS2.1.


>> 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.
No, you use *Tables *for/Tabular data/. The main examples for tabular data on the Web are:

  * actual tables. So you have a bunch of records that have fields (columns) and data
    (row)
  * forms. Yes these are tabular as well, usually only having 2 columns, that is label
    and input.

These table styles are not a replacement for divs as they are very obviously designed 
for handling the former (tabular data).

>>
>>   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.
Can you elaborate what you mean when you use the word "template", maybe with an example.

Where do you store these? Are the template names also injected into the mail body (so 
you can recall them when you reply to the email chain or re-open the mail in drafts or 
Edit as New?


>>   Clipboard and Format Painter
>>
>> 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.

It is a special widget from Microsoft which lets you transfer the formatting rules of 
a highlighted text section or paragraph to another place in the document. You can 
single click to do this once or make it sticky by double-clicking it. In that case you 
can transfer your _/*beautiful style*/_ that you created to many other places, by 
simply clicking on them once. Likewise you could just highlight a <h2> and turn other 
paragraphs into <h2> as well, or turn <body> text into <p> or <ul><li>.

It is a very intuitive tool, but due to that many different styling methods, I would 
say the implementation of this is something quite complicated. So maybe something for 
formatting bar version 2.0.


>>   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
Yeah maybe branching it off for a half year or so, but you want to make sure there is 
some consensus and a small team of people working on it. Alternatively we could create 
a mini Team to write a "proof-of-concept" addon to see how that would be accepted by 
the users.

>>> [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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140208/4a21a07f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iacjjidj.png
Type: image/png
Size: 4664 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140208/4a21a07f/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bgbbaaee.png
Type: image/png
Size: 6986 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140208/4a21a07f/attachment-0001.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/20140208/4a21a07f/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/20140208/4a21a07f/attachment-0003.png>


More information about the tb-planning mailing list