287879 - Toggling from HTML to Plain-Text composition should disable "Insert" and "Format" Menus instead of hiding them (irritating change of UI)

Status: NEW

(Thunderbird :: Message Compose Window, enhancement)

Description

[Rishi Chopra]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Changing the message format from 'plain-text' to 'HTML' or vice-versa causes the
application to commit a cardinal sin of UI usability: the menus for the
application change!

Changing the message format from HTML to plain-text or vice-versa should NOT
cause inapplicable menu items to disappear; instead they should be greyed out.

Reproducible: Always

Steps to Reproduce:
1. Change the message format.
2.
3.

Actual Results:  
The menus for the message compose interface changed!

Expected Results:  
The menu items that were no longer applicable should have been greyed out.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Rishi Chopra]

This is still relevant...

Comment 3

[Rachel]

(In reply to comment #2)
> This is still relevant...
> 

Yes, I agree. UI is always important!

Steps to Reproduce:
1. Higlight a message you have recieved that was sent in html.
2. Hit the "Reply" button.
3. From the Reply message, go to Options>Format>Plain Text Only

Actual Results:  
The text edit toolbar (containing text format, font, color, styles, etc.) for the compose message disappear!

Comment 4

[Tony Mechelynck [:tonymec]]

I believe the disappearance of the HTML toolbar and of the HTML-only menus when selecting plaintext format is "intended behaviour" and that the lack of a "Format => HTML" menuitem belongs in a separate bug, by itself.

=> INVALID.

Comment 5

[Rishi Chopra]

(In reply to comment #4)
> I believe the disappearance of the HTML toolbar and of the HTML-only menus when
> selecting plaintext format is "intended behaviour" and that the lack of a
> "Format => HTML" menuitem belongs in a separate bug, by itself.
> 
> => INVALID.

Intended?  Perhaps.. but correct? No...  It's been more than forty months and this bug is still present and still as embarrassing as it was the day I documented it in Bugzilla; also, please reference the "separate bug" as part of 287879 before marking 287879 as "INVALID" (the contention that the composition interface should not radically change but rather grey-out invalid options should also be addressed in kind).

Comment 6

[Magnus Melin [:mkmelin]]

Why would you want a lot of grayed out menus and other UI taking up space if you bothered to set the composer to plain text compose? (I agree it's per designed, and a good design.)

Comment 7

[andré]

If someone uses html messages sometimes, and plain text other times, greying out the html fields not available in text mode provides a coherent interface.
Suppressing the display of these fields is, in my view, bad design.

The solution of suppressing display is only useful if one _never_ uses html format.

Comment 8

[Thomas D. (:thomas8)]

I think this deserves to be reconsidered (albeit the priority is certainly low).

I tend to agree that it would be a more coherent UX if "Insert" and "Format" menus would not entirely go away when choosing "Options > Format > Plain Text Only", but just be greyed out.

It *is* confusing when menus change their position and regular order. I think it's a habit formation thing: After using those menus a few dozen times (in default HTML mode), you subconsciously know where they are (Options is the 6th menu from the left, and it comes after Format menu...) and it's irritating if that changes.

In support of that view, I think we can safely assume that the regular mode of composition is now HTML (it's also TB default), so plain-text is more likely to be the exception.

I don't agree that the formatting toolbar should stay in plaintext mode, that's just wasting screen real estate and disabling an entire toolbar doesn't make sense. Not showing the toolbar also helps users to realize they are working in plain-text mode, and it's not some sort of flaw that formatting can't be applied.

Comment 9

[Thomas D. (:thomas8)]

Bug 253017 might even require *enabling* the "Insert" menu in plaintext mode...

Comment 10

[deadrat]

I think that the current UI is good. Why would anyone want to format the message if they are composing in plain text. Even if they want, they can't. If they want to format the message, it should be in html. 

But I wouldn't want the grayed out icons there when I am writing a message in plain text. I think it is better if they disappear when composing in plain text.

Comment 11

[andré]

So an email is in text mode, and the user wants to change it.
Now the interface is confusing.
Much better design would be moving the "options/format" sub-menu to the top of the format menu (as format/mode) and *never* greying out the top-level format menu.

So instead of

- format menu (sometimes greyed out, often unpredictably, from tests with sm2.32)
- - character_fonts submenu
- - ...

and
- options menu (just to the right)
- - ...
- - format sub-menu
- - - () automatic detection
- - - () text only
- - - () html only
- - - () text and html

we have the more coherent
- format menu (never greyed out)
- - mode sub-menu --- transferred from "options/format" 
- - - () automatic detection
- - - () text only
- - - () html only
- - - () text and html
- - character_fonts submenu -- which would be greyed out (or hidden) if "text only" selected
- - ...

I would strongly favour greying out instead of hiding, as it intuitively shows that the options are sometimes available.
Note that in many other parts of the Mozilla menus, including the "format" menu itself, options not currently available are greyed out.
This is common in many other applications.

So *in sum* :
1) never hide or grey out the "format" menu.
2) instead
 a) transfer "options/format" submenu to top of "format" menu as "format/mode" submenu, and
 b) grey out submenus below when mode = "text_only" is selected.

Comment 12

[andré]

Note that most of the many comments have confirmed the noted behaviour.
So the status should be upgraded to "new".

Comment 13

[Thomas D. (:thomas8)]

André, thanks for your comments.

(In reply to andré from comment #11)
> So an email is in text mode, and the user wants to change it.

Toggling between from text mode to HTML mode is currently not possible, and poorly implemented the other way round. Which is bug 140800 / bug 216132 territory, not this bug.

> Now the interface is confusing.
> Much better design would be moving the "options/format" sub-menu to the top
> of the format menu (as format/mode) and *never* greying out the top-level
> format menu.

I don't think moving the "Options > delivery format" menu into HTML's Format menu is good UI, and it seems outside the scope of this bug.

The Format menu in HTML mode is exclusively for formatting the text.
Setting the composition/delivery mode is on a completely different (meta) level, hence correctly located in Options menu.

> I would strongly favour greying out instead of hiding, as it intuitively
> shows that the options are sometimes available.

As long as we don't even have a way of toggling between plaintext and HTML composition (bug 140800 / bug 216132), there's not much point of looking into this little detail.
The current implementation has plaintext and HTML mode as 2 different animals with almost no bridges (apart from the delivery-format: Auto-detect nonsense), and users are much more likely remain with one mode, so fine-tuning the transition doesn't help much at this stage.
Accordingly, with only 3 votes, no dupes, 9 CCs, and only 12 comments, users don't seem to care much about this because it's kinda trivial compared to the real issues.

> Note that in many other parts of the Mozilla menus, including the "format"
> menu itself, options not currently available are greyed out.
> This is common in many other applications.

Well, until Microsoft decided to dump menus and replace them with ribbons, which are now very much contextual and strictly NOT showing any options which can't be used in the current context.
So if we like it or not, stable menus have long ceased to be the only UI concept out there.

I think this really depends on bug 140800 / bug 216132 and if we ever get round to that, we could revisit this bug again and make the call.

Comment 14

[Thomas D. (:thomas8)]

I spoke to soon.

Notwithstanding the general triviality of this, I'll make the UX-call and confirm this for now:

1) When changing from HTML to plaintext mode (via Options > delivery format > Plaintext), it feels really weird that the menu I have just clicked on moves away from under my mouse, and two entire menus disappear. This does not convey the fact that this formatting decision is easily revertible, by just going back to the Options menu and choosing Options > delivery format > HTML [and plain]. In the current traditional menu setup (and with all the bugs we have in this corner), hiding menus for a simple and fully reversible format decision seems ux-inconsistent and over-dramatic. (But we should hide the toolbar if it cannot be used in plaintext mode; in fact that's arguable, too, because some formatting commands might actually have their plaintext equivalents).

2) Removing "Insert" and "Format" menus unnecessarily changes the position of "Options" menu which in turn makes it harder to undo the formatting decision. To this day, I somehow subconsciously assumed it couldn't even be undone.

3) Temporarily having two disabled main menus (Insert and Format) does NOT seem disturbing, distracting, nor eating up space that would be useful if freed. Instead, it's an intuitive indiciation of the current modus operandi, namely that available formatting options are temporarily (and reversably) disabled by Options > delivery mode > plaintext. More so as HTML is clearly the default mode, so for the majority of users, plaintext will really be an exceptional / temporary choice.

Comment 15

[andré]

Thanks for responding to my comments.

(In reply to Thomas D. from comment #13)
> > Now the interface is confusing.
> > Much better design would be moving the "options/format" sub-menu to the top
> > of the format menu (as format/mode) and *never* greying out the top-level
> > format menu.
> 
> I don't think moving the "Options > delivery format" menu into HTML's Format
> menu is good UI, and it seems outside the scope of this bug.
> 
> The Format menu in HTML mode is exclusively for formatting the text.
> Setting the composition/delivery mode is on a completely different (meta)
> level, hence correctly located in Options menu.

But as you note further on, the availability of formatting depends on the delivery mode.
BTW, your term "delivery mode" is probably much better than just "mode".
It is logical to put options just after other options that they depend on, which is what I proposed.  It could be all put under the "options" menu, but I think that formatting is important enough to have its' own menu, as it does now.

> > Note that in many other parts of the Mozilla menus, including the "format"
> > menu itself, options not currently available are greyed out.
> > This is common in many other applications.
> 
> Well, until Microsoft decided to dump menus and replace them with ribbons,
> which are now very much contextual and strictly NOT showing any options
> which can't be used in the current context.
> So if we like it or not, stable menus have long ceased to be the only UI
> concept out there.

The world isn't necessarily Microsoft-centric (I use Linux), and even Microsoft was forced to come out with 8.1 so users can bring back the menu.
Note also that Microsoft menus generally contain a very large number of elements, unlike Mozilla menus (which has its' roots in the Unix world).  So hiding unused elements could make more sense in that context.


(In reply to Thomas D. from comment #14)
> I spoke to soon.
> 
> Notwithstanding the general triviality of this, I'll make the UX-call and
> confirm this for now:
> 
> 1) When changing from HTML to plaintext mode (via Options > delivery format
> > Plaintext), it feels really weird that the menu I have just clicked on
> moves away from under my mouse, and two entire menus disappear. This does
> not convey the fact that this formatting decision is easily revertible, by
> just going back to the Options menu and choosing Options > delivery format >
> HTML [and plain]. In the current traditional menu setup (and with all the
> bugs we have in this corner), hiding menus for a simple and fully reversible
> format decision seems ux-inconsistent and over-dramatic.

Agree totally.

> 2) Removing "Insert" and "Format" menus unnecessarily changes the position
> of "Options" menu which in turn makes it harder to undo the formatting
> decision. To this day, I somehow subconsciously assumed it couldn't even be
> undone.

Understandable.  I prefer using plain text most of the time, and it took me a while to discover that I could do that without a separate email account.

> 3) Temporarily having two disabled main menus (Insert and Format) does NOT
> seem disturbing, distracting, nor eating up space that would be useful if
> freed. Instead, it's an intuitive indiciation of the current modus operandi,
> namely that available formatting options are temporarily (and reversably)
> disabled by Options > delivery mode > plaintext. More so as HTML is clearly
> the default mode, so for the majority of users, plaintext will really be an
> exceptional / temporary choice.

Absolutely.

Since the delivery mode is so closely linked to the formatting, it really would make a lot of sense to put them in the same menu.  The relation would then become very obvious.
Although one could argue that it is a separate issue, in my view it is intrinsically related to the heart of this bug.
As well, the solution to this bug would change :
When the text-only delivery mode is selected, the format menu itself would never be greyed out, but rather the existing sub-menus.

Comment 16

[:aceman]

I would agree with just disabling the 2 menus (+ hiding the formatting toolbar).

But I assume when the compose window is opened in plain text mode, the menus will be hidden, as there is no way yet to enable HTML mode. Also it would clutter the menu bar for users that always compose in plain text only.

Magnus, would you accept such a solution?

Comment 17

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #16)
> I would agree with just disabling the 2 menus (+ hiding the formatting
> toolbar).

Yes, as I pointed out above, that's good and required UX when (reversibly) toggling from HTML composition mode into plaintext composition mode via Options > Delivery format (this bug).

> But I assume when the compose window is opened in plain text mode, the menus
> will be hidden, as there is no way yet to enable HTML mode. Also it would
> clutter the menu bar for users that always compose in plain text only.

Yes, for status quo, that's reasonable when going *directly* into plaintext composition mode, where there's currently no way of toggling/upgrading into HTML composition mode.

That said, how hard can it really be to enable toggling from plaintext composition mode into HTML composition mode?
Jorg once pointed out that the plaintext compose window is just a reduced HTML compose window. We don't need bells and whistles like automatic conversion of *bold* into HTML-bold, so can it be much harder than just re-enabling menus and toolbar and setting some internal flags? Given that Plaintext<->HTML toggle is one of our bugs with most votes (historically, at least), I'd think it might be worth having another look into a minimal solution for bug 140800.

That said, looking into bug 140800 first will probably delay us here, so:
From my POV, Aceman, please go ahead with your proposal exactly as described. Thanks a lot for having mercy on this little bug.

> Magnus, would you accept such a solution?

I don't see on what grounds he wouldn't. We are not making anything worse. This is a useful and correct representation of the status quo where we have two flavors of plaintext composition:

a) reversible plaintext "light" mode coming from HTML
-> hide HTML toolbar, *disable* HTML menus (as it's reversible)

b) irreversible plaintext "hardcore" mode going directly into plaintext
-> hide HTML toolbar, *hide* HTML menus (as it's currently irreversible)

It's actually a very helpful minimal visual hint which even helps to distinguish the two.

Comment 18

[Magnus Melin [:mkmelin]]

What's the steps to reproduce this? Comment 3 doesn't change the menus in any way (at least on ubuntu)

Comment 19

[Thomas D. (:thomas8)]

(In reply to Magnus Melin from comment #18)
> What's the steps to reproduce this? Comment 3 doesn't change the menus in
> any way (at least on ubuntu)

Indeed. This has become even worse than before.

STR

1) Compose HTML message with some formatting (mental note: inline images to be tried, too), like "Hello bold italic" (apply formatting)
2) Options > Delivery Format > Plain Text Only

Actual Result

1) No warning that HTML formatting will be lost
2) No immediate down-conversion of formatting to ensure wysiwyg (losing format upon sending is a nonsensical UX concept to begin with!!!)
3) NO change of UI at all, i.e. the full palette of HTML formatting is still available, but all formatting will silently go away upon sending
4) OT: note weird bugs when double-clicking on last word to select, and when double-clicking on "bold" after bolding, unrelated dialogues popping up - hope that's not in the release?

Expected result

1) Immediate warning that HTML formatting will be removed if confirmed
2) If confirmed, immediate down-conversion of message to ensure wysiwyg, and saving of down-converted msg to drafts folder (we could also have a checkbox for saving a backup of the HTML message)
3) Per Aceman's comment 16, disable Insert and Format menus, hide HTML toolbar to reflect reality that HTML formatting is not available atm bc msg will be sent in plaintext. I guess that still won't stop all the HTML formatting and image insertion patterns (drag and drop?), but it's better than the status quo. Maybe we should just downconvert and open the msg in the "real" plaintext mode where there's no return to HTML mode.
We'll forever suffer with these things until we address bug 140800 and its associated conversion issues; or maybe fixing this here is part of the solution also needed for bug 140800...

Comment 20

[david]

I think an item is being overlooked here that would support keeping the menu and greying out inappropriate options. The 'Characters and Symbols' option applies equally to HTML messages and to plain text messages. By greying out only the HTML-related options, you preserve the Insert entry on menu. The value of seeing greyed-out options while in plain text mode is a gentle reminder of Thunderbird's full Insert features. To me, that is the purpose of the user interface, keeping all relevant options, many for HTML and one for plain text.