Worthwhile Thunderbird projects/addons?

Bryan Clark clarkbw at gnome.org
Tue Dec 21 09:58:44 UTC 2010

On 10-12-20 9:56 PM, Jim wrote:
> On Mon, Dec 20, 2010 at 7:10 PM, Bryan Clark<clarkbw at gnome.org>  wrote:
>> Dragons!  But if you were to start on something like this I would give my
>> (new) standard recommendation.  Start with a tab and a browser element and
>> HTML.  We could then flatten all the preferences and account settings into a
>> single page with some accordion like expand collapse trickery.  This would
>> be slightly difficult work because it's full of crazy edge cases but you
>> could also transition the existing UI over as you implemented different
>> pieces.
> The only thing that concerns me about this plan is the "HTML" part.
> One of the things that always bothered me a little about the Gloda
> search UI was that it looked more like a webpage than something native
> to the OS. I suppose using HTML instead of XUL doesn't technically
> restrict how it looks, though it would make it more difficult to use
> XUL-only controls.
> There are some places where this works out (e.g. the ill-fated updates
> to account central and folders), but in general, I prefer UI that
> looks OS-native, since (in my non-scientific opinion), it has lower
> mental overhead and makes everything look like it fits together.
Right, much of it is a matter of CSS.  The thing that isn't CSS and 
where you really want to make decisions is on the widgets used.  The OS 
look often means using the tree or list widgets, which are the clunkers 
of UI design when it comes to visualizing information; like trying to 
use spreadsheets to visualize all your information.

> Instinctively, I'd also keep the prefs and account settings separate,
> but that may just be because that's what I'm used to.
They might want to remain separate, I'm not sure as I haven't tried some 
real prototypes yet.  The designs I have break everything down by 
behavior first and then account specific differences within that.

Right now we have a "Composition" preference in the main preferences 
which is mostly about behaviour and then we have "Composition & 
Addressing" in your account settings which is about similar behaviors 
but specific to that account.  It's awkward designing which pieces go 
where and so it's very awkward for people to find where we put it.  e.g. 
'Compose messages in HTML format' is in the Account Settings but 
choosing your default HTML formatting is in the 'Composition -> General' 
settings. :)

Instead I think with a single compose behavior category we would have 
people choose the default behavior of HTML or Plain Text and then select 
accounts which are exceptions to that rule.  Something like:

[x] Compose messages in HTML format
      ( All Accounts | v )

[x] Compose messages in HTML format
     ( Only some accounts | v )
     [x] Account 1  [ ] Account 2 [x] Account 3

But that's a pretty rough sketch right now.
>> * Update address book backend to support SQLite (may be a big project)
>> * Update address book UI
>> I think these two are one in the same because you really need to start with
>> a new storage system to have more than two email addresses, etc.
> That's what I was afraid of. Updating the address books is pretty
> important to me, but it's also big enough that I don't know if I'd
> have time to finish it before I got sick of it. ;) In more general
> terms, this is probably one of the things keeping people from doing
> some of the bigger projects, like implementing Sieve. I'm not sure of
> a good way to fix this, though.
Agreed, there are a lot more things that could be done if we had a new 
version of the address book.  Even if you just wanted to try an 
experiment that would be really worthwhile.  I'm kind of wondering how 
hard it would be to get the base extension done such that it replaces 
all the pieces that require the address book in Thunderbird.  With that 
alone we could at least start getting more experiments into what is 

I know Mark (s8) is interested in the address book stuff as well so you 
wouldn't be alone. :)

~ Bryan

More information about the tb-planning mailing list