[Maildev] Engineering Council or Engineering Steering Committee (ESC) - where art thou?
mark.rousell at signal100.com
Fri Aug 31 10:30:14 EDT 2018
This is a long message. Sorry. I think it needs to be long.
It strikes me that there are two separate issues here: The specific bug
under discussion and the issue of leadership and strategy that this the
situation seems to expose. Certain aspects of the bug under discussion
reflect what should, to my mind, be previously decided strategic issues
of usability and UI/UX style. I'll explain how and why below.
On 31/08/2018 10:29, Jörg Knobloch wrote:
> Sadly you're ignoring the fact that an attempt was made by Kent and
> others to move away from Mozilla's despotic module owner model to a
> more, dare I say, "democratic" or community-involved model where key
> contributors not only have a voice but also a vote. That effort has
> gone nowhere and it even being rolled back as I see it.
> If you look at https://wiki.mozilla.org/Modules/All you can see the
> Mozilla have heaps of modules, Firefox, Toolkit and dozens of Core
> modules. Thunderbird appears to have four modules: TB itself, Mailnews
> (practically unowned), Chat and Calendar, and the TB module owner can
> *decide *the future of the product at their (in this case, his) sole
> discretion. As I mentioned before: A while ago "Thunderbird
> NextGeneration" was discussed. Due to lack of funds this didn't go
> ahead. But had there been funds, the TB module owner should not have
> had the power alone to decide to stick with the approach of TB as a
> desktop-centred stand-alone binary.
> Given the feedback received in this thread, after Kent's departure, I
> seem to be the only person interested in a re-structure, so I might as
> well just shut up.
First of all I'll address the strategy issues:-
But who wants to give up power without being made to? Surely for an
organisation like this and an application like this to make progress,
there must be a roadmap or program strategy document to which everyone
can contribute but, when it is decided, it is decided. Read on for
more on what such a roadmap/strategy document should include.
I have to say that, as a longstanding user of TB, I despair about this
situation -- not specifically about the bug under discussion but about
the lack of leadership and direction issues that it seems to me to
expose. The lack of a clear roadmap for Thunderbird (both at a strategic
level and, where possible, at a detailed level or detail /guidance/
level) seems counter-productive to me.
A question to everyone here: Is there a strategic roadmap anywhere? I'm
very sorry if I haven't noticed one! Please do tell me where it is. Or
are things that contribute to or reflect what should be strategy still
being decided on an ad hoc issue by issue basis by those who are in de
facto control of implementation?
Now for my thoughts on the specific bug/proposal under discussion and
then about how resolving issues like this specific bug can (and probably
should in my opinion) be guided by strategy:-
I'm not going to take sides on the exact bug under discussion; I'll just
offer my own view (broken down into what I see as units of UI/UX
interactivity which could and should all be largely guided by
already-decided UI/UX strategy):
(a) It seems to me that most users expect program defaults to be set in
the main program preferences area.
(b) As part of the defaults for an email program, most users expect
defaults for message foreground text colour and background colour to be
visually set in the main program preferences area. This is an HTML email
client, after all, and setting foreground and background colours is a
basic part of HTML.
(c) Most users expect per-message overrides of the default message text
and background colours to be pickable in the compose window.
(d) Having message text and background colour pickers in the compose
window is obvious, natural and expected for an HTML email client. They
should be present. If they need to be disabled for any reason, see items
i and j below.
(e) Per-message overrides of any option should not permanently set
defaults that are normally set in the main program preferences area,
unless this is made clear with a "Set this as program default for future
use (you can later change this in the program preferences area)" tick
box or similar.
(f) Where there needs to be an option to explicitly *not* set foreground
and background colours so that the recipient's mail client can decide
what colours to show, then the program default for this should be set in
the main program preferences area. It should not be hidden.
(g) Complex options (such as not setting foreground/background colours)
need text explanation that either appears in the UI or in a tooltip or
explanation box that is easily accessible in the UI (such as by hovering
or clicking on an 'explanation' icon). There should also be a link to
further discussion and explanation in a help file.
(h) The option to *not* set foreground and background colours on a
per-message basis should also be exposed in the compose window
somewhere. Probably not normally as a toolbar icon but perhaps in a menu
(i) Where the currently selected option (whether it be due to program
default or via a per-message override) is to *not* set message
foreground and background colours and where this logically requires the
compose window's colour pickers to be disabled, this must be explained
to the user. Having a disabled colour picker is on the face of it
counter-intuitive (and so needs explanation) but removing the colour
picker entirely from the compose window would be more confusing.
(j) The disabled colour pickers in the compose window should be
explained in a tooltip (for toolbar icon versions) or directly in the UI
or perhaps in a tooltip available by hovering or clicking on an
'explanation' icon (if looking at a dialog version of the colour
pickers). I.e. In all such cases, the explanation should be somewhere
visually close the the visually disabled option. The explanatory text
would read something like: "Colour selection for text and background is
disabled because you have 'Allow recipient to select their own text and
background colours' selected. Disable 'Allow recipient to select their
own text and background colours' to be able to select text and
background colours. Click <somewhere> for additional explanation of this
I think that the specific issue under discussion does highlight where
there is a difference between strategy and tactics, as well as strategic
guidance needed for implementation. In general, the exact details of a
specific UI feature probably would not be a strategic issue BUT, as in
this case, where a proposed UI change affects the look, feel and exposed
feature set of the program then this most certainly is a strategic
issue. Furthermore, part and parcel of the strategy should be usability
guidelines, of the sort that I have hinted at in my points a to j above,
that provide clear guidance of how UI changes should be made to provide
a consistent and predictable experience to the user whilst providing
features that they might reasonably expect to see in an HTML-capable
Getting this right is something that needs not only discussion (which it
is certainly getting) but also guidance from a strategy document and,
ultimately, leadership decision making to enforce the strategy (whether
that decision making be by an individual or a council or committee is
1: Yes, I know, such documents need to be updated. But this does not
mean that each and every point should be re-debated at the point of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Maildev