Worthwhile Thunderbird projects/addons?

John Hopkins john.hopkins at mozillamessaging.com
Wed Dec 22 16:48:17 UTC 2010



On 10-12-21 01:58 AM, Bryan Clark wrote:
> 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

I agree - that would be a nice improvement.

John

>
>
> 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
> possible.
>
> I know Mark (s8) is interested in the address book stuff as well so you
> wouldn't be alone. :)
>
> Cheers,
> ~ Bryan
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning



More information about the tb-planning mailing list