Hi friend of Thunderbird,

Back in 2010 there was a discussion about how to restructure preferences
and AM, the thread started here[1].

Then in 2014 some dedicated volunteers started developing "AM in pref
tab" in [2] since the options were moved into a tab like in Firefox for
TB 38. Options in a tab were always hidden behind a pref and never
enabled until de-XBL forced us to move the options out of their
stand-alone window and into a tab.

I personally thought that moving the "AM into (some sort) of tab" was a
good idea and wanted that feature in TB 68. Strings were already
approved by the TB module owner and landed for TB 38. As soon as "AM in
pref tab" landed, everyone started to scream: The TB module owner who
surely must have had a look at the WIP back when he approved the
strings, BenB, one of the major stake holders in account creation, and
finally Alex, our new UX lead who is the only one who can't be blamed
since he came very late to the party.

Having a feature that no one wants on trunk 69 shortly after the branch
to 68 is an absolute maintenance nightmare since patches can only be
backported with manual and error-prone intervention. Therefore I backed
the entire lot out.

This is a fine example of how UX is done, or not done, in TB and how it
shouldn't be done unless one wants to waste large amounts of developer
time. Any development, and particularly UX development, should be done
in the way I learned when I was working in the software industry:

1. You analyse the problem and come up with a bunch of requirement the
   new thing needs to fulfil.
2. You design the new thing and write a detailed spec.
3. You get agreement on what is to be implemented.
4. You implement against that spec.
5. You unit test against that spec.
6. There is sign-off against the requirements you collected.

Jörg.

[1] https://mail.mozilla.org/pipermail/tb-planning/2010-December/000632.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1096006

Hey Jörg,

thanks for bringing this up.

Code:

Jörg Knobloch wrote on 24.06.19 23:00:

Having a feature that no one wants on trunk 69 shortly after the branch to 68 is an absolute maintenance nightmare since patches can only be backported with manual and error-prone intervention. Therefore I backed the entire lot out.

Ah, that explains why you backed it out. That makes sense. Thanks for explaining it.

FWIW, I think the work of aceman was a step in the right direction. I always found the split between TB global prefs and per-account prefs arbitrary, implementation specific (where you find a pref just depends on whether we allowed to change it per-account or not, and the decision is semi-random for each pref) and confusing.

We should put them at least in the same dialog and in the exactly same UI structure, so if somebody doesn't find the pref in the per-account prefs, he can look in the global prefs easily, and vise versa, without bending his brain and adapting to a different UI, and without opening a completely different dialog.

I think the code from aceman was a very good start. I was surprised how easy it was to re-structure it and put the accounts list on the left. This speaks to the good work of the original patch of aceman. I think later work could build on aceman's patch in Bug 1560344.
Method:

UX development, should be done in the way I learned when I was working in the software industry:

1. You analyse the problem and come up with a bunch of requirement the new thing needs to fulfil.
2. You design the new thing and write a detailed spec.
3. You get agreement on what is to be implemented.
4. You implement against that spec.
5. You unit test against that spec.
6. There is sign-off against the requirements you collected.

Yes, agree.

Our bad methods came from the fact that we did not have a proper professional UX designer, so each developer was just doing what he felt was right. Now that we have Aleca, we can go back to a proper method of Design first, Implement later.

However, we have to pay attention not to design by committee. We developers have to agree that Aleca has the final word. We can give arguments, and Aleca would be well-advised to at least consider them, because developers often add a certain point of view. But most developers are horrible UX designers, and we should respect the role of Aleca to make the decision.

Account manager UX:

So, to add my 2 cents to the discussion, here is what I see as requirements for the UI:

• The account manager should be merged with the global prefs, because a user cannot know which pref is per-account and which is only global. For the user, everything are "settings", and they should all be found in the same place.
• The sub-sections of the account prefs should be identical in UX to the sub-sections of the global prefs.
• Do NOT use tabs. We already use tabs for content tabs. Top-level content tabs are something that users understand from browsers. Tabs are the uppermost top level, right below window level. Tabs are like a OS-level window. Do NOT use tabs for lower-order organization. Specifically, do not use tabs to sub-sections below other higher level sections. And never have 2 levels of tabs.
• If you have several levels of organization (i.e. sections and sub-sections), we could use the same UX method of organizing them. Do not use a list for one level and tabs for another. That must be confusing. Instead, use a tree structure to show sections and sub-sections in the same list.
• Alternatively, what we could do, however, is use a list on the left for top-level sections, and then use a page structure (like on dead-tree paper) with headings for sub-sections, all in the same scrolling page.

In other words, for an end user:

• Tabs are the highest level, like an OS-level window. (Like a paper folder/binder on a shelf)
• Lists on the left or top organize the main sections. Lists may be hierarchical to represent complex structures. (Like the sections and separators within the paper binder.)
• Page headings are the lowest level of organization. (Like headings on a paper.)

Jörg Knobloch wrote on 25.06.19 16:06:

it was unclear how long it would ride the trains

You explained why you backed out, and I understand. Given that it's not ripe for TB 68 and a large change, I think that was technically a good decision to back out until TB 68 ships, to make backports easier. It's not a reflection on the merits of the patch itself.

we need to carefully plan UI/UX changes and get broad agreement before implementing or landing anything.

Plan yes. That UX plan has to be make by Aleca. With input from others, but he makes the plan. That's his role.

You cannot design UI by committee. Our communication forums (bugzilla, mailing lists) are developer- and power user-heavy, and they tend to be nerdy and geeky and consequently very bad UX designers. We need to avoid that power reflex. Attention: That applies to reviewers and module owners, too: A good supervisor knows to listen to others. If we listen to developers in UX questions, we'll end up with a UI that only power users understand. So: hands off!

So, the final decision needs to be made by Aleca. Sure, with input from others like aceman and Richard and you and me, but eventually, Aleca makes the call and should not be pressured by any developers to any particular solution.

Ben