What happened to hiring an architect?

The Wanderer wanderer at fastmail.fm
Fri Dec 16 04:07:24 UTC 2016

On 2016-12-15 at 11:35, R Kent James wrote:

> On 12/15/2016 5:55 AM, Mark Rousell wrote:

>> For what it's worth, I've introduced many people to Thunderbird,
>> most of them non-technical end users. Here are my observations of
>> their needs:
>> (1) Above all else, stability. Don't break it. New UI or
>> functionality changes must be either optional for existing users
>> or must be easy to back out of for existing users. Note that this
>> does not prevent innovation or changes: New or changed UI and/or
>> functionality can be enabled by default for new users. Remember
>> that success means not only that you attract new users but that
>> you retain existing users.
>> (2) Flexibility. In a way, this is a feature that appeals to me
>> but it is also why I recommend TB to my clients. Apart from TB's
>> own settings, "flexibility" means addons. I cannot over-emphasise
>> the importance of addons. This also feeds back to point 1 above:
>> Don't break addons. Stability in addon compatibility matters as
>> much as stability in Thunderbird's own UI and features.
>> Non-technical users don't know the difference and don't care -- it
>> just has to work. Thunderbird is to a great extent its addons.
> My answer to both of these points is what I call first-class addons.
> These are addons that follow certain rules, but are considered as
> important as the core program. New features could be added as addons
> rather than complicating the core. Certain third-party addons that
> are recognized as critical to our user base would be somehow tested
> and maintained with new releases.

For what it's worth, I approve of all of this.

> For this to work, there needs to be a well-defined path for 
> monetization of third-party addons.

I'm not particularly happy about this, but I agree that it will probably
be necessary for the rest to be workable.

> But at the same time, you really can't have a policy of no changes, 
> ever, that change the user interactions.

I don't think you need to.

What you need is a policy that all changes to user interactions must be
backwards compatible, and able to be "switched off" in some way -
whether by config option, or by add-on, or by userChrome changes
(preferably documented somewhere!), or almost any other method. (The
idea of "first-class addons" could easily help with this; if you
introduce the change to user interactions as a new add-on which is
present by default, and pull "the way it used to work" out as a new
add-on which can be swapped in for those who want to switch back, that
would seem to address the issue entirely.)

My go-to example of a change "done right" in this way is the
introduction of tabs to Netscape/Mozilla, back in the day. They were
available for those who wanted them, and they were on by default, but if
you happened to dislike them it was easy to avoid them entirely: just
turn off all the "open in new tab automatically" options, turn on "hide
the tab bar when only one tab is open", and never hit the "new tab"
keyboard shortcut or use the "open link in new tab" middle-click.

The introduction of tabs to Thunderbird was not done quite as well;
TTBOMK it is not, and AFAIK never has been, possible to avoid tabs
entirely in a tab-supporting version of Thunderbird except by avoiding
parts of Thunderbird's other functionality.

Firefox itself eventually dropped the "can do anything you want without
ever seeing a second tab in the same window" possibility, IIRC around
the time they moved the add-on manager into a tab instead of having it
as a separate dialog. IMO that was a wrong move.

Doing things this way would quite likely involve considerably more
complexity, and require supporting more code paths, than would the
alternative - but IMO it is the best alternative.

   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161215/c769f5fe/attachment.sig>

More information about the tb-planning mailing list