What happened to hiring an architect?

Mark Rousell mark.rousell at signal100.com
Thu Dec 15 13:55:21 UTC 2016


On 12/12/2016 21:29, R Kent James wrote:

> Another thing that scares me is that we really don't have a good idea
> why our existing users choose Thunderbird. With the direction that FF
> is moving, TB is going to have to change in some ways, and there is a
> serious risk that we will change in ways that alienate our users if we
> don't understand them that well.
>

I agree that understanding what users really need and/or want is
critical. It's never easy to get this kind of feedback, not least
because many people cannot express what they really want.

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.

(3) Simplicity. When people mention "simplicity" they often think about
UIs but simplicity in overall structure and design is important too. For
example, keeping the main data in easily parsable text files is a key
benefit. In a way this is a feature I want but it also feeds into how
much I am likely to recommend TB. Note that this kind of simplicity does
not mean that one could not use a database for indexes and so on (and
there's no reason to not use a database for fts, as at present). But
plain text files from which the entire data structure can be rebuilt are
a key benefit.

On 12/12/2016 08:28, R Kent James wrote:
> I do see that Thunderbird though has three fundamental options to
> consider. 1) Continue our traditional path of being a binary rebuild of
> Firefox, which means probably moving toward Rust and custom
> WebExtensions or WebIDL features, 2) Move Thunderbird clearly into the
> an app category using web technologies, or 3) pick an entirely different
> binary platform to run on, like QT or .NET core. Of these three choices,
> I think that 2) is the path we are mostly looking at.

It seems to me that none of these options is a good option stability. Is
forking Gecko and sticking with a XUL/XPCOM base any more work than
options 2 or 3 would be anyway? I am quite certain that Thunderbird dies
if its existing addon infrastructure dies, at least not without there
being an equally capable migration path (which, I admit, does seem least
difficult with option 2).

-- 
Mark Rousell
 
 
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161215/944a2f9c/attachment.html>


More information about the tb-planning mailing list