ESC: (possible) conflict resolution #1 - bug 690644, was: Engineering Council or Engineering Steering Committee (ESC) - where art thou?
On 31-08-2018 12:29, Jörg Knobloch wrote:
On 31/08/2018 10:14, Magnus Melin wrote:
I think we have a responsibility to our users to make them look as
good as possible in their communication. Letting them by default
compose mails with font-size=+3 and body bgcolor=red doesn't seem
like a good idea. (They want to zoom instead.)
No. The proposed new default value is not to send any colours. Yes,
the UI allows them to select an ugly background for all their e-mail,
but the UI also allows them to select a font for all their e-mails
which will in 50% of cases not display correctly at the recipients
end.
I'm not against hiding default font selection away even further.
The UI also allows users to accept any remote content by default, send
outgoing mail encrypted in "Korean (EUC-KR)" and view stored passwords
in plaintext.
Remote content by default is ok if the user wants it. In fact the
average user probably even wants that. (You realize Gmail does have it
on by default, right? And there's no significant outcry about it.)
Encoding for outgoing could be forced to UTF-8 only, if we can get Japan
on board. We should try to find out if we can do that. Converting
encodings back and forth creates a bunch of extra work for us.
100% fool-proof software doesn't exist and there are far worse traps
than an ugly background, which, BTW, under the latest proposal would
come with a warning unlike other dangerous options. The fact of the
matter is: Blocking an improvement or compromise is just cementing-in
the existing undesirable state. And that's not in anyone's interest.
Seems like a strange argument that since we can't get 100% we should do
nothing at all to improve the situation. I'm interested in fixing all
footguns we have. Just file bugs and upload a patch.
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.
Eh, no, just in theory. Like I said, doing certain things without enough
key people buy-in would be a disaster.
Besides, the Thunderbird Council also have their right to influence the
product.
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.
TB next is not being discussed here. As stated that intended as
completely separate code base. As a different code base it would have
had it's own decision making process. In any case, that would have been
a political decision for the Thunderbird Council to take.
-Magnus
On 31/08/2018 12:38, Magnus Melin wrote:
(You realize Gmail does have it on by default, right? And there's no significant outcry about it.)
Not quite.
https://www.lifewire.com/how-to-have-gmail-display-remote-images-for-trusted-senders-1171909
Second, even the images in emails from reputable senders are not downloaded directly from the sender's server to your computer. Instead, Gmail inserts itself as an image proxy: it requests the image, saves it and then shows its own copy to you. All the sender learns is that Gmail downloaded the image.
Of course if the image is index by recipient, that's still enough to know that the recipient viewed the e-mail.
Jörg.
On 31-08-2018 13:48, Jörg Knobloch wrote:
On 31/08/2018 12:38, Magnus Melin wrote:
(You realize Gmail does have it on by default, right? And there's no
significant outcry about it.)
Not quite.
Yes quite, the show images is on by default :)
That article seems outdated, and yes they proxy the images. Anyway, off
topic.
-Magnus
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[1]. 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
somewhere.
(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
feature."
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
email client.
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
another question).
Footnote:-
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
detail implementation.
--
Mark Rousell
On 31/08/2018 16:30, Mark Rousell wrote:
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?
I'm not aware of one. For the hotly contested add-ons issue for example,
this is all we've come up with so far:
https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63
But we hired Magnus as a technical manager
(https://mail.mozilla.org/pipermail/tb-planning/2018-August/006127.html),
so we can look forward to some planning now.
As for the colour issue, the current suggestion looks like this:
https://bug690644.bmoattachments.org/attachment.cgi?id=9003086
I think adding tooltips explaining the dangers is a good idea. The UI
for the "per message" setting is rather poor (compose window, Format >
Page Colors and Background), and there isn't an option to make the
individual setting global, which is also a good idea.
Jörg.
P.S.: Thanks Mark for you long contribution, it was very interesting to
read fully ;-)
On 31/08/2018 16:21, Jörg Knobloch wrote:
On 31/08/2018 16:30, Mark Rousell wrote:
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?
I'm not aware of one. For the hotly contested add-ons issue for example,
this is all we've come up with so far:
Ah yes. Well, that's much better information than nothing of course and
it's a good thing that the current knowledge is documented somewhere.
But of course I think it also highlights the lack of a firm overall
roadmap. So much is dependent on what the Firefox project does that it
makes it difficult for Thunderbird to develop a firm, consistent
roadmap, not just on extensions but on anything. (But this is a
different problem again to the ones under discussion here).
But we hired Magnus as a technical manager
(https://mail.mozilla.org/pipermail/tb-planning/2018-August/006127.html),
so we can look forward to some planning now.
Oh yes, indeed. Well in that case it could be argued that Magnus is
fulfilling his role by taking the position that he is on this issue...
except that the lack of agreed and documented strategic direction means
that his decisions could be seen as simply reflecting his preferences
rather than the preferences of the project as a whole.
As for the colour issue, the current suggestion looks like this:
https://bug690644.bmoattachments.org/attachment.cgi?id=9003086
I think adding tooltips explaining the dangers is a good idea.
I like the screenshot in the context of the main program preferences
area. It makes sense.
I just have two caveats:
(1) Use of the phrase "non-default" always causes me to ask: "Hang on,
what are the defaults? It doesn't say. But I don't want to lose my
current settings by clicking Restore Defaults just to find out." And so
rather than using "non-default", might I suggest that the warning text
is something like this: "Warning: Removing the tick from 'Use reader's
default colors' may cause incorrect message display when viewed by the
recipient".
(2) The use of "recipient" and "reader" to refer to essentially the same
entity is I think inconsistent. Furthermore, the word "reader" is often
used to refer to particular software or parts of software and so I don't
think it is necessarily clear that "reader" refers to the recipient's
mail client in this context. For this reason I suggest changing "Use
reader's default colors" to "Use the recipient's default colors" or even
"Do not set colors (allow recipient to view using their own color scheme)".
And two comments about context:
(1) If this is the look for the main program preferences area then it
does of course need to be matched by the UI in the compose window. I.e.
When 'Use reader's default colours' option is selected, the per-message
colour picker in the compose window needs to be disabled (not removed!)
and the user needs to be told why this is (as per items (i) and (j) in
my previous message).
(2) Ideally in my opinion there would be a per-message option in the
compose window to enable/disable setting text and background colours
(using similar language to whatever is decided for the program
preferences area under discussion here) but as I mentioned in item (h)
before I think it can be on a menu or in a dialog by default rather than
being immediately exposed on a toolbar.
( I'll add a comment on Bugzilla with these comments. )
The UI
for the "per message" setting is rather poor (compose window, Format >
Page Colors and Background)
It is a bit unobvious, isn't it, but making it more obvious is perhaps
part of a wider issue with discoverability and editing workflow in the
compose window (especially in HTML mode). I don't think I'm saying
anything radical when I say that the compose window could do with some
serious updating, especially the HTML editor.
And wouldn't a Markdown editor be nice. I rather suspect that Markdown
is going to become popular as a native email format (maybe).
But, again, these particular issues are probably out of scope for the
particular issue at hand here.
and there isn't an option to make the
individual setting global, which is also a good idea.
I agree.
I just want to add that I realise that I am sticking my oar in as a user
whilst not offering direct coding contributions. I feel guilty about
that but, for the time being, I'm not in a position to offer more.
Nevertheless, I hope that what I can contribute has some value.
--
Mark Rousell
On 31/08/2018 18:45, Mark Rousell wrote:
It is a bit unobvious, isn't it, but making it more obvious is perhaps
part of a wider issue with discoverability and editing workflow in the
compose window (especially in HTML mode). I don't think I'm saying
anything radical when I say that the compose window could do with some
serious updating, especially the HTML editor.
Well, you realise that Magnus wants to get rid of the colour options and
you want to make them even more discoverable ;-) - That said, the
current colour pickers aren't really good since the only offer the
limited basic HTML colours. None of them are actually really suitable as
a background, I've tried. You want something more subtle, like some very
light colour, and the colour picker doesn't allow that. But you can
enter it as the preference and at least the picker will show it. The
problem is that some mail services don't or only partly honour those
colours, so using a template with CSS is certainly a more sophisticated
approach.
As for HTML editing: Yes, that's sadly missed, that's why I offer the
add-on ThunderHTMLedit (mostly forked from Stationery, with improvements
and bug fixes) and Stationery also has a HTML editor, these days even
more modern by switching to Ace (https://ace.c9.io/).
Our friends from Postbox have an inbuilt HTML editor, they use "Code
View" (https://www.postbox-inc.com/features/html-editor).
I just want to add that I realise that I am sticking my oar in as a
user whilst not offering direct coding contributions. I feel guilty
about that but, for the time being, I'm not in a position to offer
more. Nevertheless, I hope that what I can contribute has some value.
I think it has :-)
Jörg.
On 31 Aug 2018, at 10:14, Magnus Melin mkmelin+mozilla@iki.fi wrote:
On 31-08-2018 09:55, Jörg Knobloch wrote:
On 31/08/2018 01:30, Ben Bucksch wrote:
The ESC is not in charge of the UI, only of technical aspects.
The larger technical aspect is: How much of an HTML editor do we want Thunderbird to be.
Yes there are larger technical aspects that can be discussed.
Thunderbird is an email client, and aspiring personal information manager supporting various communication protocols. It is not, and was never designed to be used as an HTML editor though it has HTML email editing capabilities.
There appear to be tendencies to deconstruct HTML capabilities for no apparent reason, or perhaps with the argument, that you can do stupid things with it.
I think you should look at these capabilities from the other side. If you were to design it from scratch, is this feature something you would include, and are there use cases where the feature comes in handy. If you establish there's a use case, think about what the best way of achieving it is.
Now, for bug 690644, you already acknowledged yourself you think the feature is a footgun with few use good use cases, but you want to keep it for the sake of... not knowing if anybody would be upset?
I think we have a responsibility to our users to make them look as good as possible in their communication. Letting them by default compose mails with font-size=+3 and body bgcolor=red doesn't seem like a good idea. (They want to zoom instead.)
In general I don't think there is any point in trying to encourage users to use extensive html formatting in their mails. Chances are pretty high the recipients will see something fairly different from what the sender expected. To have something that looks good, you need to put significant time (and have the knowledge) into the composition. You can do that, but if you put in the time, what you want is to make a fancy template that you can reuse and improve over time. Doing it time and time again is just not something to recommend to anyone.
Adding one-off formatting to emphasize certain information in your mails is not what this discussion is about. That's a worth while use case. We're discussing default values that apply to all the mails you send out.
So as I see it: During the course of the year we have achieved nothing except the creation of the Maildev mailing list, and steps of getting more people involved in the decision making, not only the discussion, are even being wound back. So much for governance changes :-(
By being part of the discussion people are part of the decision making process and can voice their opinions or alternative solutions. The idea was to present ideas to a wider audience for feedback before going all out. Now, the group of people is not easily definable... Clearly certain ideas would be hard to pull through without buy-in from key people, and that would be part of the decision on which direction to go (or not).
-Magnus
What I miss every timr when people say that recipients don’t see formatting is that a lot of (company) users use Outlook and they /do/ see formatting! I’m not in favor of html mail myself, but I think that if you deny this and strip formatting options from Thunderbird, you’ll only lose more users to other clients.
Onno
Colors are not part of HTML. (they were at one point in time, but they were neither originally, nor are now)
HTML is about structure, not presentation. the reader software can present the structure in a way that is pleasant to the reader user.
i think this is very appropriate for the email context.
Am 31. August 2018 08:55:11 MESZ schrieb "Jörg Knobloch" jorgk@jorgk.com:
On 31/08/2018 01:30, Ben Bucksch wrote:
The ESC is not in charge of the UI, only of technical aspects.
The larger technical aspect is: How much of an HTML editor do we want
Thunderbird to be.
There appear to be tendencies to deconstruct HTML capabilities for no
apparent reason, or perhaps with the argument, that you can do stupid
things with it. Some recent quotes:
https://bugzilla.mozilla.org/show_bug.cgi?id=690644#c44:
Yack (sic) - too many things inherited from Editor :(
https://bugzilla.mozilla.org/show_bug.cgi?id=1486051#c3
Falls into the category we-have-it-because-we-inherited-editor -
there's
fairly little reason to have something like this in an email client.
So I just wanted to present the (perceived) tendency of the module
owner
to a wider audience. However, since we follow the Mozilla module owner
system, the module owner makes the final call and all discussion is
more
or less futile.
I reiterate that the so-called ESC as a larger group of developers, see
http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2018-August/001254.html
for a proposed list of members, has not been established and even the
group of "technical directors" of Magnus, BenB, Kent and myself as per
Thunderbird Council decision of 2017-06-23 as decision makers is under
discussion of being abolished again. Certainly not all people in the
group are still available or their membership has been questioned
otherwise, see
https://mail.mozilla.org/pipermail/tb-planning/2018-August/006142.html.
So as I see it: During the course of the year we have achieved nothing
except the creation of the Maildev mailing list, and steps of getting
more people involved in the decision making, not only the discussion,
are even being wound back. So much for governance changes :-(
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
--
Sent from my phone. Please excuse the brevity.
Man, this thread has a lot going on! I think having the two issues being
discussed in this thread doesn't make either single discussion as
effective as it could be. It makes sense to bring up the HTML editor
issue insofar as you are pointing out a decision that the module owner
could make in opposition to what some contributors may want.
But I think it would be worthwhile to focus on just one of these issues
in the thread. I'd like to see the conversation around the HTML editor
play out and see what Magnus, as the module's owner, ultimately makes as
a decision (if he hasn't already made it). And then move on to a thread
focused on the ESC and whether or not it is necessary. I think the
former helps inform the latter conversation.
Ryan Sipes
Community Manager
Thunderbird
On 8/31/18 11:37 AM, Jörg Knobloch wrote:
On 31/08/2018 18:45, Mark Rousell wrote:
It is a bit unobvious, isn't it, but making it more obvious is perhaps
part of a wider issue with discoverability and editing workflow in the
compose window (especially in HTML mode). I don't think I'm saying
anything radical when I say that the compose window could do with some
serious updating, especially the HTML editor.
Well, you realise that Magnus wants to get rid of the colour options and
you want to make them even more discoverable ;-) - That said, the
current colour pickers aren't really good since the only offer the
limited basic HTML colours. None of them are actually really suitable as
a background, I've tried. You want something more subtle, like some very
light colour, and the colour picker doesn't allow that. But you can
enter it as the preference and at least the picker will show it. The
problem is that some mail services don't or only partly honour those
colours, so using a template with CSS is certainly a more sophisticated
approach.
As for HTML editing: Yes, that's sadly missed, that's why I offer the
add-on ThunderHTMLedit (mostly forked from Stationery, with improvements
and bug fixes) and Stationery also has a HTML editor, these days even
more modern by switching to Ace (https://ace.c9.io/).
Our friends from Postbox have an inbuilt HTML editor, they use "Code
View" (https://www.postbox-inc.com/features/html-editor).
I just want to add that I realise that I am sticking my oar in as a
user whilst not offering direct coding contributions. I feel guilty
about that but, for the time being, I'm not in a position to offer
more. Nevertheless, I hope that what I can contribute has some value.
I think it has :-)
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net