Google Summer of Code 2014 - Proposal to Improve Composer UI

John Crisp jcrisp at
Mon Feb 17 13:57:05 UTC 2014

On 15/02/14 11:48, Axel Grude (Axel) wrote:
> Just to show that I can do this as well (and the mail doesn't end up in
> John's spam folder) I am replying in plain text; I excuse in advance
> that I am little controversial in the following but I am very
> enthusiastic on this topic, and formatted email is something that is
> near and dear to my heart:

LOL :-)

I can read HTML perfectly well if I need too - after all I use my
favourite email program :-)

I just prefer not to use it to compose, and generally ignore most that
is received.

>> 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.
> The trick is to offer the options the users need in a way that they can
> find them. It may be true that 90 % only use 5% of the features, but it
> is impossible to say which 5% these are and it would we foolish to
> describe the other 95% of  features as superfluous. Also it is often
> fringe features that can draw in new users - you would be suprised at
> the amount of people who praise certain features of my extensions
> because they miss Eudora.

My comments were merely based on the fact that if you have limited
resources then they should be dedicated to the majority. An awful lot of
time could be wasted on a bunch of features most do not use. A bit of
research may be necessary to show what features are used. How do you
know what to develop if you don't know what is really required ?

I suggested that were other things that may be more important.

There have been continual comments for as long as I remember that old
bugs frequently don't get fixed, and yet the discussion here is about
adding a new bunch of features that will probably not get used by most.

How about this one :
Nearly 7 years now.

I am not against having a better editor for those who wish to use one.
But prioritise the importance of such things in context with other
issues. That one bug has my users doing backflips. If I could code this
in I'd be happy to try and fix it, but it's not my language.

>> 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'.
> Apart from screenshots and mockups there is another very important thing
> that often gets sent around in companies, and this is tabular data. It
> should be very easily possible to insert a table and style it so it has
> a proper heading and maybe alternating rows. If it is just an excerpt or
> a couple of rows I infinitely prefer this to having to open attachment
> after attachment after attachment. To offer the tools that I described
> in the original email exactly _avoids_ the faffing around (as it only
> takes one click). There is a lot more faffing around going on when you
> do not have the proper tools at hand and try to create something
> readable. Just saying.

I don't disagree about eternal attachments  - I actively discourage
users doing that here.

But if you have shared documents (you mention you use SharePoint and I
guess this is what it does ?) then why not work on those instead of
trying to build a new tool to do the same job ?

Why write it in an email and the paste it later when you can just do it
in a document designed for the purpose ?

>> 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 ?
> Are they the _only_ users Thunderbird wants to cater for I wonder?
> Excuse me but I do not see the irony here. I think Thunderbird should
> precisely show this difference and show that it is easy to be awesome.

The irony is your argument for a fancier html editor when the move to
webmail means people are using simpler formatting tools. I haven't seen
people clamouring for fancier formatting tools. They seem to accept the
simple ones that exists, assuming they use them at all. That tends to
indicate they haven't missed anything. I know for all the users I have
ever helped install (admittedly a very small sample, though quite
diverse) none of them have asked me about having a better html editor.

> Yes you can write text only email too. By the way you shouldn't leave a
> space before your question marks. ;-)

Ah, you caught me out..... Yes, if I write English correctly (and being
British I am relatively conversant with my own language) then I
shouldn't. It's just my little bit of 'style' :-)

> And your slighting of "fancier" tools is a bit of a diversion, it is not
> about the *tools*; it is about making the already inherent functionality
> (full expressive freedom on styles) (yes you can have *fancy*
> *formatting*) easier accessible. So it doesn't mean to confuse users (or
> earn bragging rights) it is about giving the users who want something an
> easy way to get that; preferably with a single click.

Did you mean 'more easily accessible' ? :-)

No, it is not a diversion. It is the reality of coding something more
complex. To use more 'styles' etc , you are going to need a better set
of tools to access all that functionality. Your original mail, pretty
pix & all, suggested a much more involved system.

>> 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 !
> Which in my eyes immediately disqualifies you from the discussion of
> html editors. You should be honest and vote for abolishing the html
> portion of Thunderbird altogether and not vote for "yet another online
> html editor clone" just to keep html as inaccessible as possible. Do you
> see my problem with this argumentation?

I don't think it disqualifies me from commenting. I do not use HTML, but
I appreciate others do. I am not saying ban HTML altogether (even if
that is my personal choice). My argument was about how many resources
you devote to it, and for what return. The more time and effort spent on
that may affect something else that does affect me.

Your original thread suggested that time should be spent developing a
better html editor. I have merely asked if that is what is
wanted/needed/required/best use of resources.

As I have mentioned before, sometimes developers get carried away with
fancy new ideas before they consider who they are actually building
things for, and whether the users either want or use them.

>> I think there are better things to be done than worry about the composer
>> interface for now. Fix some of the old bugs perhaps ?
> I think not, but feel free to fix bugs as you see fit. In my proposal,
> the big untapped potential of users that I would like to entice using
> Thunderbird are the ones who ask themselves whether Thunderbird is dead
> and why there is so little innovation happening. And why it is oh so, oh
> so hard to write properly formatted emails.

I would disagree - most people want stability and to know that problems
are fixed and not ignored in the rush to bring out new features that may
themselves be broken, and then never fixed. There are plenty of comments
to that effect on the bug tracker. Those comments are detrimental as
they make it look like no one is listening or cares.

>From my own experience with a small distro, people want to know that it
is being maintained, and that where possible, old problems are being fixed.

The question that I have been trying to ask is will a great new HTML
editor really entice a myriad of new users ? The big problem, and I have
same with the distro, is finding out what the majority of users really
want. If I saw overwhelming evidence to show that this is what the
majority of users want then I have no problems with that at all. I just
don't see any at the minute.

How about a survey on the download page ? What would users like to see ?

B. Rgds

More information about the tb-planning mailing list