Role of addons

Patrick Cloke clokep at
Fri Sep 14 18:23:59 UTC 2012

On Fri, Sep 14, 2012 at 1:06 PM, Kent James <kent at> wrote:

>  One of the results of that is well stated in a review of Thunderbird by
> Linux Magazine <> :
> "*One of the problems with Thunderbird is that it doesn’t seem to fit
> with most users’ needs for email. That is, it doesn’t work well for
> business users who need features like calendaring and groupware
> connectivity, and it doesn’t work well for casual mail users who have
> mostly adopted Webmail or whatever ships on their computer. ... It’s too
> complex for casual users, and not full-featured enough for business users."
> *
Ironically I find that most "casual" users I know think Outlook is easy
enough to use, so...I'm a bit confused by this.  If "casual" users can use
Outlook, it would imply it's both "full featured" and "simple" to use

> * *In terms of positioning of the product, I think that we should push at
> both of these boundaries, at the same time realizing that we will probably
> never be able to displace webmail for the most casual user, or Outlook for
> the most complex enterprise.
I agree here.

> To push at the simplicity boundary, we must be willing to reduce the
> complexity of the user interface. One of the main ways that we have to do
> that is through addons. The user interface for features that are only going
> to be used by a tiny fraction of our users should be pushed to addons, and
> not included in the core code.
To be clear here, you're talking about the user interface, but not the
actual core code?  That seems a bit wonky.  Maybe it's time to revise the
UI that touches these features to add "advanced" options?

> In the long run I would like to see us do this more explicitly by adding a
> category of addon that is maintained along with the core product, and
> shipped with the core product. So these addons would have the same
> commitment to support as any core feature, but are included as addons to
> reduce the overall complexity of the product.
This sounds more complicated to maintain to me.  You have to figure out
what add-ons are installed (or enabled at least) and check various
combinations of those to ensure everything still works.  Plus, when writing
code, it might be harder to understand all the consumers of a certain API.

This might also be pretty hard since various aspects of Thunderbird don't
seem to have good APIs to them, meaning you'd have to create the API as
well as rip out bits of code.

> Good candidates for that in the long run would be chat, calendaring, RSS
> feeds, bayesian junk processing, advanced security models, and advanced
> search and filter functionality.
Is this list actually based on anything?  I use most of these on a daily
basis, as do most people I know of who use Thunderbird.  How do you decide
what stays in and what goes?  Can things be prompted/demoted?  There's
political as well as technical questions in there, mind you.  It would be
great to have hard data about what features are used and what ones aren't

> In the short run, I would encourage us to be selective about adding new
> features that complicate an already overwhelming user interface. Just
> because a developer is motivated should not be a good reason to add new
> user interface items for rarely needed features.
I think it's reasonable to add the user interface, but it needs to be done
in a clean way to clearly separates what a normal user and "power" user.
It's also good to have sane default values so it will "just work" for most

I also wonder if some options don't necessary need UI and "about:config" is
a good enough UI for them.  We've been using this in Instantbird (and in
some of the chat code as well) and it seems to work fairly well for options
that the basic user won't need to tweak and an advanced user "gets" how to
change it pretty instantaneously.

> Comments?
I think the major issue here is that the UI of Thunderbird is old and
creaky and likes to display a lot to the user...much of which the user
might not care about.  Instead of ripping things out to fix this, the UI
could be made "simpler" by default with advanced options hidden in other
tabs, windows, dialogs, etc.

I don't think it makes sense to talk about this in overall terms.  I think
it would be more useful to take a look at each feature individually and see
whether it can be simplified / removed / etc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list