Google Summer of Code 2014 - Proposal to Improve Composer UI

John Crisp jcrisp at
Sat Feb 15 00:55:34 UTC 2014

On 14/02/14 22:03, Axel Grude (Axel) wrote:
>> Gets my vote (or ckeditor ?) - can't stand the ribbon mess.
> Maybe you should have hung in there... Messy or not people HTML mail
> users want an intuitive interface where they can easily use and define
> styles without having to know CSS. And you can only do this if you offer
> an interface that defines styles and is easily extendable. It is a
> typical thing to say "I do not like X" and "I like the look of that,
> because I know it" without looking at the actual requirements people have.
> In the corporate sector people take this pretty much for granted. Click
> a style, define it, use it everywhere. Whether you call it Ribbon or
> have separate toolbars / areas / for the various styles is just a design
> detail, and can be maybe solved in a better way. however what we have
> now on the formatting bar is not good enough. And the markup it creates
> is not up to date, we do not want to create endless cascades of <font>
> <big> <small> etc, and put a lot of pain into making an email layout.

Having seen so many users of numerous applications struggle and be
overwhelmed with developers trying to give them more options they don't
use, I'm kind of glad I didn't 'hang in' there.

As I personally use text email almost exclusively (your original mail
with all the images rendered very nicely in plain text - just no glossy
pictures to look at !) I don't worry about the mess that is created by
the vagaries of differing html viewers and 'standards'. Your fancy HTML
is invisible to me :-)

For those that do, I agree that KISS should always apply. I don't work
in the big corporate world so in my own experience most users I know
wouldn't know a style if it fell on them.

At my own company the current html toolbar rarely ever gets used and I
can't say I'm upset - I want my own workers to work, not sit and faff
about for hours tweaking their 'styles'.

These are the same people who don't understand that they can't open an
image with a spreadsheet application. Don't get me wrong, I'm not for
dumbing down in this respect, just better education of users. But there
are still a huge swathe out there who really know nothing about
computers whatsoever and any new toy is an excuse to play, and not work.

If you work for a corporate I would have thought that the company would
lock down styles anyway ? Why on earth would  you want individually
tailored emails looking like they came from different companies ? And if
you are doing fancy markup, why bother doing it in an email ?

> In its most minimal form imagine you can define <h1> with a default look
> (could be based on the tag or on a class) and you are able to reuse that
> on any email you write. The interface just has to be easy to use and
> enticing enough so people start using it and panels with preview styles
> are the most intuitive way to offer this to the users.

As I said above, if I am honest, anything beyond Bold and Italic is
beyond most of them. H1 & H2 are another language. Styling them as well ?

Ironically more and more people use web based systems which usually only
have basic formatting, and portable devices, again with simple
formatting. Are they clamouring for fancier formatting tools I wonder ?
Even if they do all that formatting, can the receiver actually see it ?
Ironically at my place we reject most html email anyway...... most of it
is spam. If I had my way I would ban the lot !

So if you are going to do it (and that depends on who Thunderbird is
really targeted at and why), it has to work, be simple to use, and
produce good, simple, clean code and reproduce accurately across a
multitude of differing platforms and applications. That's a major
challenge in its own right.

For now I'll stick to text - I know everyone can read it :-)

I think there are better things to be done than worry about the composer
interface for now. Fix some of the old bugs perhaps ?

B. Rgds

More information about the tb-planning mailing list