Thunderbird prefs redesign (aka mega-prefs)

Bryan Clark clarkbw at gnome.org
Tue Dec 28 21:28:05 UTC 2010


Awesome!  I'm really glad you're looking into this.  I'll make some 
notes below to each point because I think there are good questions here 
about how the UI should work.  But I think the overall general goal of 
starting with the behavior and then breaking down into account specifics 
afterward is a good goal.


On 10-12-26 1:10 PM, Jim wrote:
> One project I've been thinking about for Thunderbird is reorganizing
> the prefs windows. clarkbw has done some work on this too and put up a
> proof-of-concept of a "mega-prefs" page that holds the
> application-wide prefs and the account-specific prefs:
> <http://clarkbw.net/designs/mega-prefs/>. Here are some of my thoughts
> on the matter.
>
> * Per-account prefs
>
> Since the plan is to put all the prefs in one spot, we need a way to
> handle options that can be set per-account. There are really two types
> of per-account prefs: account-specific details (e.g. incoming server,
> drafts folder location) and common prefs (e.g. compose in HTML). For
> the former, it's going to be rare that the details are the same across
> accounts, but for the latter, they may well be the same. (The former
> might also work better in their own dialog.)
Right so we might need some further separation of the first type of 
setting either by grouping them or just handling it differently.  For 
server settings I'm thinking it might make more sense to have an 
"Network Settings" tab that has all the different server related 
settings which aren't really linked to behavior in the client.

* clarkbw at example.com

    Incoming
   / mail.example.com / 993 / clarkbw at example.com /  SSL / Normal Password /

   Outgoing
   / smtp.example.com / 465 / clarkbw at example.com / SSL / Normal Password /

* bryan at example.com

    Incoming
   / mail.example.com / 993 / bryan at example.com /  SSL / Normal Password /

   Outgoing
   / smtp.example.com / 465 / clarkbw at example.com / SSL / Normal Password /


And it could also take on the Network connection settings stuck in the 
Advanced Preferences.  Still just ideas at this point.

>
> For the common prefs, we probably want a way of selecting the behavior
> for all accounts and then drill down to individual accounts, like in
> clarkbw's example. This will probably need some experimentation to get
> it right. Here's what I think would work well:
>
> Collapsed:
>    [ ] Compose in HTML [>]
>
> Expanded:
>     [-] Compose in HTML [v]
>         [x] one at example.org
>         [ ] two at example.org
>         [ ] three at example.org
>
> The little button on the right should probably have some kind of a
> useful icon and a tooltip like "Configure each account individually".
> To make things simple for developers (there are going to be a lot of
> prefs like this), we could maybe implement an XBL binding that wraps
> around the control to automatically generate the per-account
> drilldown.
Agreed, this looks like a good start.  The one you have above is a good 
example of boolean pref with account specific exceptions.

I think the Signature provides a good example of a non-boolean pref 
where the widgets get a little more complex or copied, depending on how 
you look at it.

Collapsed:

[x] Include Signature in Messages [>]

     [x] Use HTML (e.g.<b>bold</b>)
     +-----------------------------------------------+
     |                                               |
     |                                               |
     |                                               |
     |                                               |
     +-----------------------------------------------+


Expanded:

[x] Include Signature in Messages [v]

     [x] clarkbw at example.com
         [ ] Use HTML (e.g.<b>bold</b>)
         +-----------------------------------------------+
         |                                               |
         |                                               |
         |                                               |
         |                                               |
         +-----------------------------------------------+

     [ ] bryan at example.com

     [x] sales at example.com
         [x] Use HTML (e.g.<b>bold</b>)
         +-----------------------------------------------+
         |                                               |
         |                                               |
         |                                               |
         |                                               |
         +-----------------------------------------------+


This is just one way to solve the problem and I don't think this is 
correct yet.  I would like to keep the original signature as the 
*Default* value and allow the accounts to use the default, none, or a 
custom signature.  However the issue of injecting a copy of the 
signature editor per account remains either way.

>
> * Meta-controls
>
> Since there are bound to be a lot of prefs on one page with this
> design, one way to help people find what they're looking for would be
> a search bar that filters out the prefs to show only the relevant
> ones. We could also get rid of the "advanced" category entirely by
> adding a checkbox at the top that says "Show advanced options", which
> would display the advanced options in the relevant categories.
This is a really good point, I'll add something like this to the search 
mockup.  A quick filter that expands the sections which match and 
collapses the sections that don't should work fairly well for now.
>
> * Extensibility
>
> Add-ons (e.g. Lightning) will probably want to put stuff in the
> mega-prefs window, so we should make it easy to hook into. Not too
> much to say here, really.
I updated the mockup earlier to show how an extension could append a new 
tab piece onto the existing system with Lightning as an example.  This 
is similar to how many larger extension pieces append themselves into 
the preferences.  This piece is a little worrisome because we would be 
encouraging add-on authors to clutter up the preferences space with a 
whole new tab.

Because of the above I also added another example of an "Add-ons" tab 
which would pull in the preferences from add-ons into a single place; 
we'd just make it easier to find and open their existing dialogs.  This 
was just added as a proof of concept and to show we could provide a 
place for add-ons such that they don't all add themselves as new tabs.
>
> * HTML vs. XUL and OS-integration
>
> Whether we do this in HTML or XUL, I think we should try to make
> everything look OS-native if at all possible. This is at least partly
> for selfish reasons, since I just prefer that everything looks like it
> fits together with the OS.
>
> I'm not sure if you can use XBL or XUL from inside HTML, so that might
> make a difference in what we decide. There are lots of useful
> controls, (folder-picker, dual-buttons, menu-buttons) that would
> probably be useful, and if we can't use them from HTML, I'd probably
> vote for using XUL.
>
> Using XUL would also probably make it easier to gradually migrate to
> the new prefs system by just dropping the old prefs windows in
> unchanged until they get updated.
Agreed that we don't want to have this page bring in a new or different 
look or theme.  In the HTML that exists inside Thunderbird already we're 
converging on a platform neutral look that you see in the search results 
and thread / multiple selection summary pages; still more work to be 
done.  Also I think we came fairly close to an interesting and OS native 
look [1] in the new Account Central Bug [2] where we reworked the 
existing page.

I'm usually not one to choose tech but I wanted to say that I'm for the 
HTML version for a couple of reasons.  It's easier to get contributors 
(designers too) to work with HTML because it's a tech they already 
know.  While the HTML5 type controls are still young somewhat they are 
gaining ground quickly and I believe will overtake XUL in most areas 
with the current desktop/mobile browser competition happening.

There are definitely downsides to the HTML version.  The major downside 
I see is the extensibility of HTML pages which has been a problem for 
the search results page and other HTML pages within TB.  I think the 
solution that protz used in Thunderbird Conversations has worked really 
well to allow for extensions to inject themselves into the template but 
there may be downsides I'm not aware of.

* Final Thought! *

Something I'd like people to think about and I'll try include this in my 
next rev of the mockup is creating a preference system that isn't just 
static controls.  For example the Screenshot of New Account Central [1] 
uses simple graphs to help people understand the information presented.  
One tab I'm trying to work on right now is a "Disk Space" tab which 
helps people understand what accounts are using what kind of disk space 
and allows them to turn off sync inside those accounts.  Things like 
this are a bit more work inside XUL than they are in HTML just because 
most of the javascript graphing systems are expecting HTML and not XUL; 
it's not impossible just awkward.

[1] Screenshot of New Account Central
https://bug489999.bugzilla.mozilla.org/attachment.cgi?id=378744

[2] New Account Central Bug
https://bugzilla.mozilla.org/show_bug.cgi?id=489999

> * Netbooks
>
> Hopefully this will just fall out automatically from the redesign, but
> we should make sure the UI works for netbooks. I suppose just adding a
> scrollbar would be sufficient for this.
Yes, we should make sure this is a design goal.  By using a scrolling 
page and making sure the width doesn't require more than something like 
960px (that's a lot of space and most netbooks are 1024) wide we should 
be very netbook friendly.

> That's about all I've got for now. Ideas/comments?
>
I've got some more comments but I'll try to respond to other messages 
for now.

Thanks,
~ Bryan



More information about the tb-planning mailing list