641527 - "Download Messages" dialogue needs a "Cancel" option

Status: NEW

(Thunderbird :: Mail Window Front End, enhancement)

Description

[WBT]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9

In the "Download Messages" dialogue, which (in English) reads "Do you want to download messages for offline use before going offline?  [CHECK] Always ask me when I go offline [BUTTON: Yes] [Button: No]"
we should add a button to "Cancel" or "Stay online."

Reproducible: Always

Steps to Reproduce:
Use case:  I am running Thunderbird maximized on the main screen of my Windows OS.  
Extra config info: My OS is Vista with the "Classic" Windows display settings, and the taskbar is two rows high, with the start button floating to the top left corner of the taskbar (though all that shouldn't matter much).

Action:
1.  I move the mouse to the lower left corner of the screen in order to click on the Start button.
2.  I miss by a few pixels and click the Online/Offline toggle in Thunderbird.
3.  I get this dialogue about downloading messages for offline use, even though I don't intend to go offline.
4.  I want to cancel the action, to stay online, but I can't do it.  Clicking the "X" in that dialog is equivalent to clicking "No" (don't download messages, but still go offline).


Expected Results:  
I want to be able to cancel the action of going offline.  Presenting this dialog doesn't make sense to me as the user, I don't want to do EITHER of the options that it's presenting, and I can't exit it out.  The main issue is that the offline toggle is so close to the Start button (in the maximized window), but there's nothing wrong with making full use of window space and the easiest/most user-friendly solution seems to be adding that cancel button.

Comment 1

[geniassmchlachla]

Applies to 3.1.13 on Ubuntu 11.04 as well

Comment 2

[Nigel Babu [:nigelb]]

Picking this up for fixing.  I have a preliminary patch, once tested, I'll attach for review.

Comment 3

[Nigel Babu [:nigelb]]

Attachment: patch-v1

First effort. Almost everything works. The only thing I couldn't figure out is, if I click File -> Offline -> Work Offline and then press Cancel, the checkbox is ticked.  This is undesirable; however, I couldn't find how to fix that behavior.

Comment 4

[Nigel Babu [:nigelb]]

Attachment: screenshot

Screenshot with the new dialog box.

Comment 5

[Magnus Melin [:mkmelin]]

I think there used to be a button like this back in tb1.something, but it was removed to simplify things. 

I didn't check in detail but I expect adding that button would be very confusing esp. regarding going online/offline from startup and the pref for what to do then.

Comment 6

[Nigel Babu [:nigelb]]

I would argue that having a button that can be accidentally clicked and then having no way to "undo" that click is also bad UX.  I'm happy to make any changes that would make it less confusing.  I've already changed the prompt to be "Download Messages" and "Don't Download" instead of "Yes" and "No", which should be much less confusing.

Comment 7

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 577176 [details] [diff] [review]
patch-v1

Review of attachment 577176 [details] [diff] [review]:
-----------------------------------------------------------------

So, I think the first thing I'ld suggest is that the Cancel button be positioned on the right side, not in the middle.
Secondly, now that we have Cancel, I think hitting the "esc" key should be the same as clicking Cancel, which it appears not to be.

To address Magnus's concerns, this dialog doesn't show during startup, so the pref will be whatever it was the last time the user chose it.  (i.e. I don't think we're adding any complexity here.)
And the "Download"/"Don't Download" buttons seem clear enough.

Thanks,
Blake.

Comment 8

[Nigel Babu [:nigelb]]

Attachment: patch-v2

> So, I think the first thing I'ld suggest is that the Cancel button be
> positioned on the right side, not in the middle.

This was probably an OS-specific implementation difference.  I looked further and it seems that POS_1 is the standard position for Cancel button.  Fixed that this time.

> Secondly, now that we have Cancel, I think hitting the "esc" key should be
> the same as clicking Cancel, which it appears not to be.

This was fun tracking down.  confirmEx always returns 1 when the Esc button is pressed or the [X] on the dialog button is clicked. The solution was to put the Cancel button in position 1, and now it works.

Comment 9

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 578829 [details] [diff] [review]
patch-v2

Looks good to me!

Thanks,
Blake.

Comment 10

[Nigel Babu [:nigelb]]

Comment on attachment 578829 [details] [diff] [review]
patch-v2

Mark, are there any changes you'd like me to make?

Comment 11

[Mark Banner (:standard8)]

Comment on attachment 578829 [details] [diff] [review]
patch-v2

Review of attachment 578829 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay. Generally looks good and almost ready for review - you just need to correct the logic slightly.

::: mail/base/content/mail-offline.js
@@ +91,5 @@
>        ioService.manageOfflineStatus = gPrefBranch.getBoolPref("offline.autoDetect");
>      }
>      else // going offline
>      {
> +      var confirmDownload = this.confirmDownloadMessagesForOfflineUse();

This is going to cause us to always prompt for confirmation, even in the case where the pref is set to 1.

You could probably do something like this:

if (prefDownloadMessages == 0) {
  confirmDownload = this.confirmDownloadMessagesForOfflineUse();
  if (downloadButtonValue != 2)
    this._goOffline(...);
}
else
  this._goOffline(prefDownloadMessages);

This should keep it relatively simple. Of course, you'll need to move some of this into the new _goOffline function.

@@ +207,5 @@
>    {
>      const nsIPS = Components.interfaces.nsIPromptService;
>      var promptService = Components.classes["@mozilla.org/embedcomp/prompt-service;1"].getService(nsIPS);
>      var alwaysAsk = {value: true};
> +    var yes_no_cancel = (nsIPS.BUTTON_POS_0 * nsIPS.BUTTON_TITLE_IS_STRING) + 

This should be a const.

@@ +214,1 @@
>      var downloadMessages = promptService.confirmEx(window, 

Whilst you're touching this, lets re-format this to be:

var downloadMessages =
  promptService.confirmEx(window,
                          this.offline.getString .... etc

@@ +221,2 @@
>                                                     this.offlineBundle.getString('downloadMessagesCheckboxLabel1'), 
> +                                                   alwaysAsk);

The fact you've removed the == 0, makes me think you should be more explicit about what you're expecting the return values to be, and then why it is acceptable to do downloadMessages ? <values> in the setIntPref call below - i.e. just add a comment.

Comment 12

[Mark Banner (:standard8)]

Comment on attachment 578829 [details] [diff] [review]
patch-v2

Actually, this is along the right lines, so let me make that feedback+, but it'd be review- without the logic fixed ;-)

Comment 13

[Magnus Melin [:mkmelin]]

Nigel, still working on this?

Comment 14

[Nigel Babu [:nigelb]]

I haven't worked on this in a while. Thanks for the ping. I'll get an environment setup and work on the feedback.

Comment 15

[Nigel Babu [:nigelb]]

I haven't managed to find time and I don't think I will.

Comment 16

[Blake Winton (:bwinton) (:☕️)]

Thank you very much for the work you've done on it so far!
I would offer you a Whimsycorn sticker, but I'm pretty sure you already have one.  ;)

Comment 17

[Pavel Černý]

Hi, I would like to fix this thing.

Comment 18

[Pavel Černý]

Attachment: screen - improved dialog

I suggest to change the dialog to the one attached. And also to change the behavior of clicking on "X" button and "Esc" key to do nothing - stay online.
The new dialog tells user what's happening now and offers all the following steps.
Only downside it slightly increases the cognitive load on the user because it adds the third button.

To keep the cognitive load low it could be possible to remove the checkbox "always ask me when I go offline". I suppose 90% of users will never uncheck this checkbox, because they are not sure where to change this setting in future.

Comment 19

[Magnus Melin [:mkmelin]]

Comment on attachment 8571108 [details]
screen - improved dialog

I think what the dialog should look like was already decided. We just need someone to finish off the patch that is already almost done.

You're proposing a dialog with 7 words "offline", that is way too much. Also, "Offline" is not a verb.

Comment 20

[Thomas D. (:thomas8)]

Pavel, thanks for picking this up.

I tend to agree with Magnus that your proposal is somewhat over-explicit and not grammatically correct.

I understand/suppose we really just want the existing current dialogue, with an added cancel button (whose position depends on OS):

Download Messages

Do you want to download messages for offline use before going offline?
[ ] Always ask me when I go offline

[Cancel]    [Download Now] [Later]

This is ux-consistent e.g. with the UX of the "Save Message" dialogue when closing a draft which has unsaved changes. We focus on the action the user needs to decide on (save or dump the draft), assuming that the triggering action (closing of msg) is known because it was triggered by explicit user action (Alt+F4 or clicking [X]). Cancel aborts the original user action (don't close message window).

By analogy, we could assume here that user deliberately clicked on "Offline" button, so we focus on the decision that needs to be taken before going offline (Download messages now, or later). Cancel aborts the original user action (don't go offline).

That ux is desirable because we do NOT want to explicitly confirm going offline ("Do you really wont to go offline after you have clicked offline button!?"), which is not dangerous or anything, but we're just trying to assist by avoiding potentially negative consequences of that action (not having all messages available for offline use).

FTR: Imo we cannot use [Don't download] because it might be misunderstood as a final decision for those messages, whereas the decision is really between "Download Now" vs. "Download Later (after going online again)".

Comment 21

[Thomas D. (:thomas8)]

Pavel, so you could just start from the existing patch attachment 578829 [details] [diff] [review], and implement the code changes requested by review of comment 11 above (change the code logic).

Comment 22

[Pavel Černý]

Magnus and Thomas, I agree there is too much "offline" in my suggestion. I also agree on the three button logic and behaviour. The only point where we differ is the exact text of the dialog and labels of the buttons. But it can be easily changed later if needed. So I'll look on the code of patch-v2 and fix it as you propose.

For future thinking I left:
Thomas you are right, when the user want to go offline and triggers it, your dialog makes perfect sense.
But consider this case: 

Your work flow was interrupted by something. Then you came back. You only see the dialog. Can you quickly see "what action is happening right now?"
The same applies if you accidentally clicked the button - you need to quickly now what's happening and not to decode it from "...before going offline?" in the dialog's text. You are first interested in thinking about the process of going offline and after that you can start caring about downloading the messages or not.

So I suggest:

Download Messages

You are going offline. Do you want to download messages for offline use?
[ ] Always ask me when I go offline

[Cancel]    [Download Now] [Later]

I think it tells me better what's happening. It also helps me to easier mentally link [Cancel] to "You are going offline." and link [Download Now] [Later] to "Do you want to download messages for offline use?"

Comment 23

[Pavel Černý]

Hi, can you please suggest me which revision from mercurial repository should I download and use for fixing this bug?

I followed this guide https://developer.mozilla.org/en-US/docs/Simple_Thunderbird_build
But I am not able to find a suitable revision on https://treeherder.mozilla.org/#/jobs?repo=comm-central, which will build on my computer correctly. I've tried 94adb5945ec3 with all green Bs,Xs,Zs and also many other revisions including the latest. But still I am not able to build anything. I tried it on Ubuntu x64 and Win 8 x32 with no difference. Which revision are using you? Thank you in advance

Comment 24

[Thomas D. (:thomas8)]

Richard, can you assist?

(In reply to Pavel Černý from comment #23)
> Hi, can you please suggest me which revision from mercurial repository
> should I download and use for fixing this bug?
> 
> I followed this guide
> https://developer.mozilla.org/en-US/docs/Simple_Thunderbird_build
> But I am not able to find a suitable revision on
> https://treeherder.mozilla.org/#/jobs?repo=comm-central, which will build on
> my computer correctly. I've tried 94adb5945ec3 with all green Bs,Xs,Zs and
> also many other revisions including the latest. But still I am not able to
> build anything. I tried it on Ubuntu x64 and Win 8 x32 with no difference.
> Which revision are using you? Thank you in advance

Comment 25

[Kent James (:rkent)]

Hi Pavel,

You should check https://treeherder.mozilla.org/#/jobs?repo=comm-central to see if the current revision of comm-central is building successfully. But keep in mind that you only see changes there in comm-central, while most of our breakages come from mozilla-central.

If you have never built before, you might try first building with the current repo for Thunderbird 38, which is a lot more stable than trunk. You should only use that to confirm that you build environment is working, your patch needs to be against comm-central.

Current beta is at http://hg.mozilla.org/releases/comm-beta/

Comment 26

[Thomas D. (:thomas8)]

Thanks Kent!

Comment 27

[Richard Marti (:Paenglab)]

Pavel, you need also the corresponding mozilla-central revision. In treeherder, when clicking a build, you see on bottom left a link looking like 'moz:7723b15ea695'. This is the m-c revision you should use with your c-c revision.

Comment 28

[Pavel Černý]

Thank you very much, but again I am not able to build it. I reported it as a new bug https://bugzilla.mozilla.org/show_bug.cgi?id=1160751.
And special thanks to Richard, I've never noticed the possibility I can click on the "B" on treeherder so I've never saw this info before.

Comment 29

[Pavel Černý]

Attachment: patch-v3

I finally added the cancel button. Any feedback is wellcome :)

Comment 30

[Richard Marti (:Paenglab)]

Attachment: dialogs.png

Great you fixed your build issues.

Only tested on Windows:
- The order of the buttons is not the same as the order of the save message dialog (see attachmnent). The Cancel button should be on the right. Maybe comment 8 could help:

> > So, I think the first thing I'ld suggest is that the Cancel button be
> > positioned on the right side, not in the middle.
> 
> This was probably an OS-specific implementation difference.  I looked
> further and it seems that POS_1 is the standard position for Cancel button. 
> Fixed that this time.

- The "Later" button is ambiguous. Does it mean 'go offline later' or 'download later'? I propose to change it to "Download Later" (see also the save message dialog).

- When I'm pressing the X or ESC it still goes offline. It should stay online. Maybe again comment 8 could help:

> > Secondly, now that we have Cancel, I think hitting the "esc" key should be
> > the same as clicking Cancel, which it appears not to be.
> 
> This was fun tracking down.  confirmEx always returns 1 when the Esc button
> is pressed or the [X] on the dialog button is clicked. The solution was to
> put the Cancel button in position 1, and now it works.

I can't say anything about the code as I'm not a good programmer but I propose for the next iteration to ask for feedback aceman and/or mkmelin (when you attach a new patch set the feedback flag to ? and enter the names).

Comment 31

[Pavel Černý]

Attachment: patch-v4 (corrected Esc and close[x] behaviour + button labels)

Thanks for feedback. The buttons indexes are not consistent cross-platform and are from left to right
> win:    0, 2, 1 :: Return 1 when closing the dialog
> linux:  2, 1, 0 :: Return 1 when closing the dialog
Maybe it could be reported as a bug.

For my patch:
Fixed the Esc and [x] behvior.
Changed part of the dialog text to "Download messages for offline use?". I am not 100% sure if it is grammatically or stylistically correct, but it is more lightweight and straightforward than using "Do you want to ...". It's just a dialog not a fiction literature. I am curious what do you think about it.

Comment 32

[Pavel Černý]

Attachment: dialog-v4 (version from my patch on Linux)

Comment 33

[Magnus Melin [:mkmelin]]

Comment on attachment 8606719 [details] [diff] [review]
patch-v4 (corrected Esc and close[x] behaviour + button labels)

Review of attachment 8606719 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not thrilled about the extra button. It's just too many choices that people have a hard time finding out what they actually click. Can we get by by cancelling offline mode only with Esc?

::: mail/base/content/mail-offline.js
@@ +67,5 @@
> +        // 0 == Download, 1 == Cancel offline, 2 == Don't download
> +        if (decision == 1)
> +          goOffline = false;
> +        else
> +          downloadForOfflineUse = (decision == 0);  // 0 == Download, 2 == Don't download

i don't think this really is an if-else

or rather, you don't need the else. it could just be

goOffline = (decision == 1);
downloadForOfflineUse = (decision == 0);

@@ +194,4 @@
>        this.offlineBundle.getString('downloadMessagesWindowTitle1'),
>        this.offlineBundle.getString('downloadMessagesLabel1'),
>        (Services.prompt.BUTTON_TITLE_IS_STRING * Services.prompt.BUTTON_POS_0) +
> +      (Services.prompt.BUTTON_TITLE_IS_STRING * Services.prompt.BUTTON_POS_1) +

the cancel one would be BUTTON_TITLE_CANCEL

@@ +204,5 @@
>  
>      // if the user changed the ask me setting then update the global pref based on their yes / no answer
> +    // and if user didn't cancel going offline (idx 1)
> +    if (!alwaysAsk.value && buttonPressed != 1)
> +      Services.prefs.setIntPref("offline.download.download_messages", (buttonPressed == 0)? 1 : 2);

nit: space after 0)

::: mail/locales/en-US/chrome/messenger/offline.properties
@@ +3,5 @@
>  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
>  
>  # Download Messages Prompt
>  downloadMessagesWindowTitle1=Download Messages
> +downloadMessagesLabel1=Switching to offline. Download messages for offline use?

I'd suggest.

Going offline. Do you want to download messages for offline use first?

@@ +8,2 @@
>  downloadMessagesCheckboxLabel1=Always ask me when I go offline
> +downloadMessagesNow2=&Download

I wouldn't change this, but it would have to update the localization key (to e.g. downloadMessagesButton)

@@ +8,4 @@
>  downloadMessagesCheckboxLabel1=Always ask me when I go offline
> +downloadMessagesNow2=&Download
> +downloadMessagesLater2=Download &Later
> +downloadMessagesCancelOffline2=&Cancel offline

offline should be capizalized (if we used that)

but it probably should just be "Cancel" (for which there's a standard button text). 
Otherwise it'd have to be "Cancel Going Offline" which is too long.

Comment 34

[Richard Marti (:Paenglab)]

Comment on attachment 8606719 [details] [diff] [review]
patch-v4 (corrected Esc and close[x] behaviour + button labels)

r+ with the strings changed.

(In reply to Magnus Melin from comment #33)
> Comment on attachment 8606719 [details] [diff] [review]
> patch-v4 (corrected Esc and close[x] behaviour + button labels)
> 
> Review of attachment 8606719 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I'm not thrilled about the extra button. It's just too many choices that
> people have a hard time finding out what they actually click. Can we get by
> by cancelling offline mode only with Esc?

I think the Cancel button isn't too much, it should only, as Magnus wrote below, be "Cancel" without the "offline". Not every user knows the possibility of ESC.

> ::: mail/locales/en-US/chrome/messenger/offline.properties
> @@ +3,5 @@
> >  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
> >  
> >  # Download Messages Prompt
> >  downloadMessagesWindowTitle1=Download Messages
> > +downloadMessagesLabel1=Switching to offline. Download messages for offline use?
> 
> I'd suggest.
> 
> Going offline. Do you want to download messages for offline use first?

I was also on proposing something like this, but this one is better. 

> @@ +8,4 @@
> >  downloadMessagesCheckboxLabel1=Always ask me when I go offline
> > +downloadMessagesNow2=&Download
> > +downloadMessagesLater2=Download &Later
> > +downloadMessagesCancelOffline2=&Cancel offline
> 
> offline should be capizalized (if we used that)
> 
> but it probably should just be "Cancel" (for which there's a standard button
> text). 
> Otherwise it'd have to be "Cancel Going Offline" which is too long.

I'm for "Cancel" only.

Comment 35

[Thomas D. (:thomas8)]

Comment on attachment 8606720 [details]
dialog-v4 (version from my patch on Linux)

(In reply to Richard Marti (:Paenglab) from comment #34)
> Comment on attachment 8606719 [details] [diff] [review]
> patch-v4 (corrected Esc and close[x] behaviour + button labels)
> 
> r+ with the strings changed.

+1

> (In reply to Magnus Melin from comment #33)
> > Going offline. Do you want to download messages for offline use first?
> 
> I was also on proposing something like this, but this one is better.

+1. Magnus wording provides an excellent, concise and consistent compromise between saying what we're about to do (going offline), and what the dialogue is about (download messages for offline use first).

Pavel, we've picked your idea of keeping things short for the first half, because that's the less significant part of this dialogue (but it's good to make it explicit so that Cancel will be easier to understand). For the main question, we'd want the full grammatical sentence because we already have the short version in the dialogue title (Download Messages), so by design this is the more elaborate variant, which sounds friendlier, is easier to understand (natural English), and we're using the same style in other dialogues (ux-consistency).

> > @@ +8,4 @@
> > >  downloadMessagesCheckboxLabel1=Always ask me when I go offline
> > > +downloadMessagesNow2=&Download

To this, Magnus said:
> I wouldn't change this

+1. Please keep the original label of "Download Now", because the "Now" is actually the significant part as the difference is NOT between 'Download' or 'Not download' (as in 'never download') but only between 'Download Now' or 'Download Later'. Also, the 'Now' is important because user will actually have to wait for that before his original request for 'Going offline' can happen.

> > > +downloadMessagesLater2=Download &Later
> > > +downloadMessagesCancelOffline2=&Cancel offline
> > 
> > offline should be capizalized (if we used that)
> > 
> > but it probably should just be "Cancel" (for which there's a standard button
> > text). 
> > Otherwise it'd have to be "Cancel Going Offline" which is too long.
> 
> I'm for "Cancel" only.

+1. Cancel only is sufficient and ux-consistent with other dialogues, more so that we now have 'Going offline' as part of the explanation, which can easily be linked to Cancel. Btw Cancel effectively cancels BOTH the 'Going Offline' and the 'Download Now' actions, so there's really no need to clarify this.

Now iiuc we have (by OS design, I assume, to be externally consistent) two different button sequences on Windows vs. Linux. So this is the result of current patch v4 (pls correct me if wrong), after re-adding 'Now' as we had it before:

> win:    0, 2, 1 :: Return 1 when closing the dialog
[Download Now][Download Later][Cancel]

> linux:  2, 1, 0 :: Return 1 when closing the dialog
[Download Later]      [Cancel][Download Now]

For Linux, we're probably fine (although if they are used to having 'the alternative answer button' on the left, we might still ask the same question as below for Windows).
For Windows, it's odd, because there's too much 'download' in the dialogue, especially this duplication: [Download Now][Download Later].

In the current dialogue, we're using a less clumsy, concatenated variant:
[Download Now][Later]

I think that original design looks much better and is still sufficiently clear.
I can hear Pavel saying, but then it's not clear if it's 'Going offline later' or 'Download messages later'... Well, no. In spite of the slight deviation of 'Going offline', there's a clear question in this dialogue:
Title: Download Messages
Icon:  [?]
Text:  Going offline. Do you want to download messages for offline use first?

So any buttons are generally answers to that question. So from contextual reading of the buttons in left-to-right sequence (on Windows), as well as from the dialogue context, imo there's still sufficient clarity if we just have:

Windows: [Download Now][Later][Cancel]    <- My proposal, as in current design

Pls comment if we can use that more elegant version on Windows as in the current dialogue. Linux guys please comment if we could do the same for Linux (I suspect yes, because of the standardized internal logic of such dialogues where the alternative answer occurs on the left):

Linux: [Later]                   [Cancel][Download Now]

If we keep the current patch approach for Linux, this requires an ifdef to have one separate string for Windows and Linux.

Comment 36

[Pavel Černý]

Attachment: dialogs.png

Thanks for your feedback. I've improved the code as you both suggested.

>Can we get by by cancelling offline mode only with Esc?

I thought about this solution before. 

Consider the version without any CANCEL: 
The user made a mistake, now he sees the dialog and tries to not choose either Download Now nor Later. User testing with people would prove it, but I am sure almost everybody would try clicking [x] for closing the dialog or hitting Esc.
BUT! The dialog window for Esc and [x] returns value 1 (which is the same as for button on position 1). And therefore the button on position 1 has to match the desired behaviour of [x] and Esc for the dialog.

Consider the version with some CANCEL:
Thanks to the grouping buttons in linux variant. There will be [Cancel] and [Download Now] nearby. Based on Gestalt Principle of proximity
> http://en.wikipedia.org/wiki/Principles_of_grouping#Proximity
the people will suppose Cancel is opposition to Download now and won't notice the Download Later on the left. Therefore there could be label only "Cancel" just in case we are able to re-arrange buttons order and their grouping. 
See the attachment, you will see what I mean

Comment 37

[Thomas D. (:thomas8)]

(In reply to Pavel Černý from comment #36)
> Created attachment 8607399 [details]
> dialogs.png
> 
> Thanks for your feedback. I've improved the code as you both suggested.

Thanks Pavel for fast iterations!

> Consider the version with some CANCEL:

(variant with only "Cancel" as a button label)

> Thanks to the grouping buttons in linux variant. There will be [Cancel] and
> [Download Now] nearby. Based on Gestalt Principle of proximity
> > http://en.wikipedia.org/wiki/Principles_of_grouping#Proximity
> the people will suppose Cancel is opposition to Download now and won't
> notice the Download Later on the left. Therefore there could be label only
> "Cancel" just in case we are able to re-arrange buttons order and their
> grouping. 

I think Pavel is trying to say this:
On Linux, having "Cancel" just next to "Download Now" would suggest that Cancel is the opposite of "Download Now" so perhaps it would just cancel the download. We could only use just "Cancel" (w/o offline) if we find a way to rearrange the buttons like in on Windows, so that Download Now + Later are together.

I wouldn't agree with that position, because the Linux UI logic presupposes that alternative answers can be found on the left, and just Cancel and Default answer on the right. Cancel traditionally implies go back to where I started from without changing anything, and that's exactly what's the case here. (Compare: close message, get "Save draft?", press Cancel: will not just cancel the "save draft", but also cancel the initial action so that 'close draft' is NOT done). And, as mentioned before, effectively Cancel *does* cancel BOTH the downloads AND the offline action.

So let's summarize what we've got:

Windows: [Download Now][Later][Cancel] <- I think we have all agreed on this, everything's quite clear from the context

Linux:
a) [Download Later]      [Cancel Offline][Download Now] <- Pavel's suggestion, fully explicit
b) [Download Later]      [Cancel][Download Now]         <- Normalize Cancel, keep Download Later
c) [Later]               [Cancel][Download Now]         <- Minimalist

I could live with all of these, they all have pros and cons.
Perhaps a) is over-explicit, but there's nothing wrong with it (needs a bit more parsing cause Cancel is longer than expected).
b) makes a nice compromise between explicit and ux-minimalist.
c) is ux-minimalist, and following the Linux logic of distributed answer buttons I'd think it would also be sufficient.

My preference is between b) and c), and I think I'm leaning slightly in favor of minimalist solution c).

Comment 38

[Richard Marti (:Paenglab)]

On Linux the dialog UI is default: [Option]     [Cancel][OK]
And so a normal Linux user would know that the Cancel button with his position is for canceling the whole action.

I'm for b) because "Later" only is not clear enough if it's "Download Later" or "Offline Later".

Comment 39

[:aceman]

The order of the buttons is determined by the platform code and differs between Windows, Linux and OS X. We should not fight with it. You just have to properly mark which button is the "accept" one, which is "cancel" and which button is the "additional button". You do that using the BUTTON_POS_X constants. I think the POS_0 is the "accept", the POS_1 is "cancel" (that is why you get 1 when you close the dialog) and POS_2+ are the "others". And you just can affect what is the label on each of those buttons. But let the platform lay them out.

Comment 40

[Thomas D. (:thomas8)]

Pavel, it looks like we've heard everyone and the following has become consensus wrt UI labels:

Windows: [Download Now][Later][Cancel]

Linux:b) [Download Later]      [Cancel][Download Now]

Which means that that there are two different labels between Windows and Linux for the one button with 'download later' action:
Windows:             [Later]
Linux and MAC OSX:   [Download Later]

OS X seems to have the same button layout like Linux.
So please branch the code between those platforms. You'll need an ifdef condition for that, see https://developer.mozilla.org/en-US/docs/When_To_Use_ifdefs
Probably just create the special condition with short button text for windows, and otherwise use the full button text.
Pls request needinfo from aceman or mkmelin to find out more if you need help.

Comment 41

[:aceman]

Yes, it is possible to have different labels for different platforms.
But have we really agreed to that?

If yes, please do not use #ifdef and preprocessing! In Javascript you can determine the platform at runtime. Use Services.appinfo.OS which returns the current OS. The useful return values are "WINNT", "Linux", "Darwin".

Comment 42

[Richard Marti (:Paenglab)]

(In reply to :aceman from comment #41)
> Yes, it is possible to have different labels for different platforms.
> But have we really agreed to that?

Not really. Let it on all platforms the same (Download Later), also when we have then a double Download... on Windows. It makes it also easier for support with only one string.

Comment 43

[Pavel Černý]

Yes, I am also for platform-consistent solution. There are people using two OS i.e. Win and Linux with Thunderbird on both (as I am).

So the proposal is:
Going offline. Do you want to download messages for offline use first?
linux: [Download Later]                      [Cancel][Download Now]
win:   [Download Now] [Download Later] [Cancel]

Is anyone who strongly does not agree?

Comment 44

[Magnus Melin [:mkmelin]]

Well, I still think the whole button is problematic in that it is confusing as there's too much choice. We can't seem to find a good because dialogs aren't supposed to have you choose between this many things in one go. 

The best way IMHO (though more code of course) would be not to have a cancel button but a notification after you went online. That would allow going online again if it was a mistake, and auto-hide after a few moments.

Comment 45

[Magnus Melin [:mkmelin]]

s/went online/went offline

Comment 46

[WBT]

(In reply to Pavel Černý from comment #43)
> So the proposal is:
> Going offline. Do you want to download messages for offline use first?
> linux: [Download Later]                      [Cancel][Download Now]
> win:   [Download Now] [Download Later] [Cancel]
> 
> Is anyone who strongly does not agree?

From just that text, I'm still not sure what exactly the "Cancel" would do.  
The verb in the question is "download messages," so Cancel seems to apply most directly to that.  
Would it skip downloading messages (in which case, what's the difference between that and Download Later?  Does it mean Download Never?  It also raises the question: How is Download Later possible if you're offline?) 
Or, would it cancel the action of "go offline?" In the latter case, that's not obvious because the question does not seem to indicate that going offline is any longer in question. 

What about: [Download Now] [Download Later] [Stay Online]
perhaps with some added clarity about what exactly "Download Later" means?

Comment 47

[:aceman]

(In reply to WBT from comment #46)
> What about: [Download Now] [Download Later] [Stay Online]
> perhaps with some added clarity about what exactly "Download Later" means?

Yes, I think these labels are the most telling.

Comment 48

[Richard Marti (:Paenglab)]

(In reply to :aceman from comment #47)
> (In reply to WBT from comment #46)
> > What about: [Download Now] [Download Later] [Stay Online]
> > perhaps with some added clarity about what exactly "Download Later" means?
> 
> Yes, I think these labels are the most telling.

+1

Comment 49

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #47)
> (In reply to WBT from comment #46)
> > What about: [Download Now] [Download Later] [Stay Online]
> > perhaps with some added clarity about what exactly "Download Later" means?
> 
> Yes, I think these labels are the most telling.

I disagree. The "Stay Online" label is 'most telling' to the extent of being over-verbose and complicating things even more for all scenarios because it requires more brain processing time to be parsed and understood.

So Magnus is sceptical about having the button *at all*. I don't share that scepticism, because having just one alternate choice of actions plus a simple [Cancel] button is expected, standard, and necessary layout for such dialogues. But with [Stay Online], we're making it even bigger and even more complex/non-standard.

So what are the scenarios?

Scenario A) (Most frequent scenario)
User wants to go offline and has just deliberately clicked the button on status bar (or File > Offline > Work Offline).

So the "Download Messages" dialogue is directly and obviously triggered by "Go offline" command which user himself has just initiated. No doubts at all that "Cancel" will cancel that command as it does in any other dialogue of that sort (e.g. when closing draft: Save, Don't Save, Cancel). And yes, cancel really cancels everything, so it won't save, or it won't download messages at this time, either. Nothing surprising here.

Offering "Stay Online" is not helpful for that scenario because user doesn't want it, but we make him waste more time to read and parse the meaning of that unexpected button (whereas [Cancel] is standardized and expected so it'll take near-zero time to process and ignore).

Scenario A2) (very unlikely, rare scenario)
In the rare event that user wants to cancel the action of going offline which he just deliberately triggered, CANCEL is still the faster and more intuitive choice, as explained in A).

Scenario B) (less frequent, probably rare scenario)
User has accidentally clicked the button on the status bar (while trying to click Windows Start Button below, or a TB folder above).

So the user has no idea why this dialogue is suddenly occuring, because he never intended to download anything or go offline. User is irritated because his original action was unexpectedly interrupted, and he doesn't know nor care what the dialogue is about at this time. So that's the classic no-brainer "Cancel!" case of "I don't want this! Just get me outta here without touching anything". Imagine how hard it will be for this user to analyse/understand all of these buttons with actions he doesn't know nor care about:
> [Download Now] [Download Later] [Stay Online]
Wtf?? I just want to CANCEL this because I've never wanted this in the first place!!!
Again, we're making such users waste time to figure out that [Stay Online] is the non-damaging action. Whereas plain [Cancel] is a milli-second no-brainer because it's universally known to, well, just cancel whatever we don't want to deal with, and return to where we started.

And fwiw, Cancel *cannot* mean "Abort download" as in "will I lose my messages?" because you can't abort a progress which hasn't even started (and there's no progress bar to indicate a progressing process which could be aborted). Words are slippery but I think you get me.

Bottom line: For both scenarios, [Stay Online] makes it harder and wastes time, compared to sweet, simple, and standardized [Cancel]. 

I'm really irritated how easily we lose track of basic UX design principles just because someone throws in some idea. More specifically:

1) Per bug summary, we're here to add an option for "Cancel". The natural incarnation of that is a simple [Cancel] button. Imagine all Cancel buttons saying explicitly WHAT they cancel...
> [Cancel exiting Thunderbird] [Cancel closing draft] [Cancel Changing Options]... 
In fact, [Stay Online] is worse because it doesn't even have the word [Cancel] so the recognition effect is zero because we're positively stating what "Cancel" will do. Which is worse:
> [Return to TB main screen] [Return to draft] [Don't Change Options]...
That's the stuff from which UX nightmares are made.

2) There's a long-established, cross-application, cross-OS meaning of "Cancel" as part of standardized application dialogues:
"No, I don't want to do this. Close this dialogue box, ignore any settings I changed, and abort whatever we were doing... If the dialogue was displayed by a command to collect information it needed to execute, the command should be aborted."[1]
I acknowledge that UX design patterns can change over time (OK buttons have been replaced by action buttons), but I don't see "Cancel" to be one of them, because it's still a very simple, elegant, intuitive and universal way of saying "Get me outa here without changing anything"

3) As shown in the detailed scenario analysis above, it follows that unnecessary deviations from standardized dialogue design make the decision more difficult and time-consuming for the user. More specifically, re-labelling [Cancel] as [Stay Online] would violate internal and external ux-consistency, and ux-efficiency.

Fwiw, other people have had this discussion before us, and I think this sums it up well:

> Cancel should do just that… Cancel, no more, no less. Labeling it anything else would not be
> beneficial, and could possibly even result in confusion. Regardless of why the dialog box has been
> presented, the cancel button ensures the dialog box goes away and nothing is at risk of being lost or
> changed. Generally the user knows why the box is on the screen so this is not an issue anyways, but
> what if my cat walked across my keyboard or I mistyped or pressed something I didn’t mean to and a
> dialog popped up. I don’t want to have to analyze buttons to make sure I don’t lose any work, I just
> want to cancel. [2]

+1 :)

WAY FORWARD:

If people agree on the slightly clumsy duplication on Windows proposed by paenglab's comment 42 (supported by Pavel, probably supported by aceman's comment 41, and I can live with that...), I think we should be able to agree on Pavel's proposal of comment 43:

> Yes, I am also for platform-consistent solution. There are people using two
> OS i.e. Win and Linux with Thunderbird on both (as I am).
> 
> So the proposal is:
> Going offline. Do you want to download messages for offline use first?
> linux: [Download Later]                      [Cancel][Download Now]
> win:   [Download Now] [Download Later] [Cancel]
> 
> Is there anyone who strongly does not agree?

Unless we want to spend more time discussing and implementing the button-less notification bar solution of comment 44... (which might be worthwile, but it'll definitely take longer so perhaps we can do the simple thing now and try more sophisticated solutions later?).

[1] GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers https://books.google.de/books?id=-kcKpqzbBR0C&pg=PA328&lpg=PA328&dq=gui+cancel+button&source=bl&ots=rR7HhU9UUK&sig=ajX8knSCazfvL2EP_x8lTZLhoTY&hl=de&sa=X&ei=1XhdVazXMsTlUfb6gcAC&ved=0CHAQ6AEwCQ#v=onepage&q=gui%20cancel%20button&f=false
[2] http://uxmovement.com/buttons/why-the-ok-button-is-no-longer-okay/

Comment 50

[Thomas D. (:thomas8)]

Btw, can we have tooltips on any of these buttons? Perhaps we could explain ourselves more clearly in the tooltips?

Comment 51

[WBT]

(In reply to Thomas D. from comment #49)
> The "Stay Online" label is 'most telling' to the extent of being
> over-verbose and complicating things even more for all scenarios because it
> requires more brain processing time to be parsed and understood.
I don't think so.  To figure out what pressing "cancel" will do, your brain has to figure out what is on the table that is eligible to be cancelled.  The declarative statement "Going offline." and the assumption in the question which follows indicate that the action "going offline" is no longer in question.  

A user who wants to click "cancel" is probably not a user who just acted intentionally to go offline.  

> 2) There's a long-established, cross-application, cross-OS meaning of
> "Cancel" as part of standardized application dialogues:
> "No, I don't want to do this. Close this dialogue box, ignore any settings I
> changed, and abort whatever we were doing... If the dialogue was displayed
> by a command to collect information it needed to execute, the command should
> be aborted."[1]
If "cancel" means this or "Just get me outta here without touching anything" or "cancel whatever we don't want to deal with, and return to where we started," a user reading this dialog would assume that "cancel" would return to a starting point that is AFTER the action to "go offline" has been irreversibly started, and that from the state "cancel" gets to, further action will be needed to go back online.  Most probably, this would take the user to just before the "download messages" action that is prompting the question.

My experience-based estimates of frequency for A and B are very different from yours, and I think that making things easier for the confused user who most needs that button far outweighs the difference in time it takes to read one word instead of two (and then try to figure out what verb Cancel applies to).  My experience is just another data point, but I would definitely challenge your assumptions.  

The action "stay online" make it crystal clear what the effect of clicking that button will be, without requiring the user to try to remember or understand the state of the software, which may include actions and steps that they are not aware of or do not understand, and then have to negate that.  

> 1) Per bug summary, we're here to add an option for "Cancel". The natural
> incarnation of that is a simple [Cancel] button. Imagine all Cancel buttons
> saying explicitly WHAT they cancel...
Imagine all buttons making it very clear what clicking on them will do, and what state you will be in after you click.  That's a great vision.  That's a whole lot better than users having to understand and negate implied technical terms.  

I wrote that bug summary and was just about to change it to reflect the greater clarity, but wanted to first see the community feedback, and not mess up any subject-line-based inbox threading for those who are following the currently-high level of activity on this bug. 

> I acknowledge that UX design patterns can change over time (OK buttons have
> been replaced by action buttons), but I don't see "Cancel" to be one of
> them, because it's still a very simple, elegant, intuitive and universal way
> of saying "Get me outa here without changing anything"
I do see "cancel" as possibly changing, in instances where the base-point for "not changing anything" is unclear.  Things change a whole lot faster now than they used to, so it's easier to get from state A to M without realizing it and then when a Cancel button comes up in the M->N transition, would that take you back to M or back to A or back to any of the states in between?  The word Cancel by itself isn't clear.  

> > Cancel should do just that… Cancel, no more, no less. Labeling it anything else would not be
> > beneficial, and could possibly even result in confusion. Regardless of why the dialog box has been
> > presented, the cancel button ensures the dialog box goes away and nothing is at risk of being lost or changed. 
Again, the base-point for "nothing lost or changed" is not clear - a parsing of what's above the buttons indicates that at the very least you'll be offline, and the action of downloading messages (which is the action in question) is what would most likely be cancelled by the cancel button. Given that the other two options involve downloading messages, it's very reasonable to assume that Cancel will just cancel the "download messages" action but not the "go offline" action which it's already too late change.

> > Generally the user knows why the box is on the screen so this is not an issue anyways, but
> > what if my cat walked across my keyboard or I mistyped or pressed something I didn’t mean to and a
> > dialog popped up. I don’t want to have to analyze buttons to make sure I don’t lose any work, I just
> > want to cancel. 
The bug report is prompted by those cases where the user doesn't know why the box is on the screen and wants to stay in the online state.  

Let's make it clear what the effect of clicking on each button will be, without requiring much thought or understanding from the user.

Comment 52

[WBT]

(In reply to WBT from comment #51)
> Things change a whole lot faster
> now than they used to, so it's easier to get from state A to M without
> realizing it and then when a Cancel button comes up in the M->N transition,
> would that take you back to M or back to A or back to any of the states in
> between?  The word Cancel by itself isn't clear.  

As a TB example of that, I just went to do something in TB. While doing so, I noticed another bug and went to see if it had already been reported.  It had been reported, and fixed, but in a later version than what I was running.  After learning my current version number from the Help->About window, I clicked to check for updates, and one was available.  It was downloaded. In the process of restarting TB to apply the update, I got a popup dialog saying "Message has not been sent.  Do you want to save the message in your drafts folder (Drafts)?  [Save] [Don't Save] [Cancel]"
This was prompted by a draft message I had left in the taskbar, reporting completion of the higher-level job that this TB task I was trying to do would support. 

The first two buttons, it's pretty clear what they would do.  The third?  Not so much.  If I click on that, what am I canceling?   Since Save and Don't Save seem to pretty thoroughly cover the entire set of possibilities (A || !A = true), I have to rack my brain trying to figure out what possibility is not covered by one of those first two buttons, to be left for the third.   What action is it cancelling? 

Would it cancel the pending update, and restore everything to the version of thunderbird I'd been running?  Would it cancel the task I was trying to do when I noticed the bug?  
Neither of these nor most other alternatives. It would cancel the "close draft message" substep in the "restart Thunderbird" substep in the "update Thunderbird" substep in the "overcome bug" substep in the "perform task in TB" substep of the job that I am working on.  Clicking Cancel would NOT cancel the pending update; there's apparently no easy way to go back (even if some add-ons that I regard as core functionality don't work with the new version - but that's a separate discussion).  

This is one of those M->N transitions in my example.  Confusion around what Cancel means in that dialog might be a subject for a separate bug discussion, but when we're adding a new button to "stay online" here, we should make it clear to the user exactly what clicking on it will do.

Comment 53

[Thomas D. (:thomas8)]

(In reply to WBT from comment #51)
> (In reply to Thomas D. from comment #49)
> > The "Stay Online" label is 'most telling' to the extent of being
> > over-verbose and complicating things even more for all scenarios because it
> > requires more brain processing time to be parsed and understood.
> I don't think so.  To figure out what pressing "cancel" will do, your brain
> has to figure out what is on the table that is eligible to be cancelled.

No. The sweetness of "Cancel" is that instead of figuring out what exactly it will do, I will just rely on my age-old ux that "Cancel" just "gets me out of here without changing anything".

> The declarative statement "Going offline." and the assumption in the
> question which follows indicate that the action "going offline" is no longer
> in question.  

No. "Going offline" is still in process, as indicated by the present progressive form "going". And "Cancel" ALWAYS cancels whichever first user action triggered the dialogue. So there's no reason to assume "Going offline" couldn't be cancelled. But I don't care, because I can just cancel this without exactly figuring out what it's about, and trust my application to ask me if that'll lose any data.

> A user who wants to click "cancel" is probably not a user who just acted
> intentionally to go offline.  
> 
> > 2) There's a long-established, cross-application, cross-OS meaning of
> > "Cancel" as part of standardized application dialogues:
> > "No, I don't want to do this. Close this dialogue box, ignore any settings I
> > changed, and abort whatever we were doing... If the dialogue was displayed
> > by a command to collect information it needed to execute, the command should
> > be aborted."[1]
> If "cancel" means this or "Just get me outta here without touching anything"
> or "cancel whatever we don't want to deal with, and return to where we
> started," a user reading this dialog would assume that "cancel" would return
> to a starting point that is AFTER the action to "go offline" has been
> irreversibly started, and that from the state "cancel" gets to, further
> action will be needed to go back online.  Most probably, this would take the
> user to just before the "download messages" action that is prompting the
> question.

No, as explained above. No indication of "irreversible", just an ongoing process of going offline. If I cancel that, it won't happen. Plus if I'm in this dialogue by accident, I just want to get it out of the way without thinking about any content of the action. So it's CANCEL. Simple, and trained a thousand times in other similar dialogues.

> My experience-based estimates of frequency for A and B are very different
> from yours, and I think that making things easier for the confused user who
> most needs that button far outweighs the difference in time it takes to read
> one word instead of two (and then try to figure out what verb Cancel applies
> to).  My experience is just another data point, but I would definitely
> challenge your assumptions.

I said: number of users clicking "Offline" accidentally < number of users clicking "Offline" deliberately. Are you suggesting that there are MORE users who click "Offline" in the status bar *accidentally* than users who click it *deliberately*? Then we'd have to think about ux-error prevention...

> The action "stay online" make it crystal clear what the effect of clicking
> that button will be, without requiring the user to try to remember or
> understand the state of the software, which may include actions and steps
> that they are not aware of or do not understand, and then have to negate
> that.  

Huh? You are producing the very problem you are trying to avoid.
If user never intended to go offline, but ends up in this dialogue, what's "crystal clear" about having as many as *three* different buttons with actions I've never requested? And how should it be easy to figure out that "Stay Online" means "Cancel" (what I know from thousands of other such dialogues), while to my own knowledge I haven't done anything about "online/offline" because I just misclicked? User doesn't want to affirm *any* positive action at this time, he just wants to "get out", and you're making it harder to find the exit button. Having "Stay Online" button is exactly what will force the user to read and understand the whole dialogue, including all *three* buttons, instead of quickly and simply click "Cancel" without caring much what it does.

> > 1) Per bug summary, we're here to add an option for "Cancel". The natural
> > incarnation of that is a simple [Cancel] button. Imagine all Cancel buttons
> > saying explicitly WHAT they cancel...
> Imagine all buttons making it very clear what clicking on them will do, and
> what state you will be in after you click.  That's a great vision.  That's a
> whole lot better than users having to understand and negate implied
> technical terms.

I'm challenging that, and I see it exactly the other way round. "Stay Online" is a technical term which is much harder to understand than just "Cancel". We all know that many users will just click on that "[x]" button for unwanted things even *without* trying to understand any bit of such dialogues. Iow, especially for things that just get in their way, they don't even WANT to go deep and understand. Why do you think is it that while "OK" buttons went away (to be replaced by "action" buttons), "Cancel" has still survived? It's because "Cancel is a universal no-brainer which reduces the cognitive burden of explaining the details of the fact that we'll just go back to where we came from. It might be "fuzzy" sometimes, but that's exactly what's makes it simple.

> I wrote that bug summary and was just about to change it to reflect the
> greater clarity, but wanted to first see the community feedback, and not
> mess up any subject-line-based inbox threading for those who are following
> the currently-high level of activity on this bug. 
> 
> > I acknowledge that UX design patterns can change over time (OK buttons have
> > been replaced by action buttons), but I don't see "Cancel" to be one of
> > them, because it's still a very simple, elegant, intuitive and universal way
> > of saying "Get me outa here without changing anything"
> I do see "cancel" as possibly changing, in instances where the base-point
> for "not changing anything" is unclear.  Things change a whole lot faster
> now than they used to, so it's easier to get from state A to M without
> realizing it and then when a Cancel button comes up in the M->N transition,
> would that take you back to M or back to A or back to any of the states in
> between?  The word Cancel by itself isn't clear.  

You might be right, although we've had affirmative action buttons for quite a long time and "Cancel" is still around. I suspect that if there's a doubt wether "Cancel" will take you back to A or back to M, there's something else which is wrong in the workflow or interaction design.

> > > Cancel should do just that… Cancel, no more, no less. Labeling it anything else would not be
> > > beneficial, and could possibly even result in confusion. Regardless of why the dialog box has been
> > > presented, the cancel button ensures the dialog box goes away and nothing is at risk of being lost or changed. 
> Again, the base-point for "nothing lost or changed" is not clear - a parsing
> of what's above the buttons indicates that at the very least you'll be
> offline, and the action of downloading messages (which is the action in
> question) is what would most likely be cancelled by the cancel button. Given
> that the other two options involve downloading messages, it's very
> reasonable to assume that Cancel will just cancel the "download messages"
> action but not the "go offline" action which it's already too late change.

Not really, as explained above.

> > > Generally the user knows why the box is on the screen so this is not an issue anyways, but
> > > what if my cat walked across my keyboard or I mistyped or pressed something I didn’t mean to and a
> > > dialog popped up. I don’t want to have to analyze buttons to make sure I don’t lose any work, I just
> > > want to cancel. 
> The bug report is prompted by those cases where the user doesn't know why
> the box is on the screen...

Indeed!

> ...and wants to stay in the online state.  

NO. User does NOT WANT to stay in online state because he's not even thinking about online/offline if he just ended up in the dialogue by accident. That's exactly the point.

> Let's make it clear what the effect of clicking on each button will be,
> without requiring much thought or understanding from the user.

I maintain that having to chose between three positive action buttons of actions I don't care about because I never deliberately requested them is harder than just using universal swiss-knife "Cancel"...

Comment 54

[Thomas D. (:thomas8)]

(In reply to WBT from comment #52)
> (In reply to WBT from comment #51)
> Would it cancel the pending update, and restore everything to the version of
> thunderbird I'd been running?  Would it cancel the task I was trying to do
> when I noticed the bug?  
> Neither of these nor most other alternatives. It would cancel the "close
> draft message" substep in the "restart Thunderbird" substep in the "update
> Thunderbird" substep in the "overcome bug" substep in the "perform task in
> TB" substep of the job that I am working on.  Clicking Cancel would NOT
> cancel the pending update; there's apparently no easy way to go back (even
> if some add-ons that I regard as core functionality don't work with the new
> version - but that's a separate discussion).  
> 
> This is one of those M->N transitions in my example.

Yeah, that's more tricky IF you think about it. Most users just wont think that far.
And "overcome bug" substep in the "perform task in TB" substeps are just in your head so they are not technically part of TB's current set of actions.

> Confusion around what
> Cancel means in that dialog might be a subject for a separate bug
> discussion

I strongly doubt that we could ever provide perfect clarity for such scenarios. What do you want to put? "Cancel closing draft, postpone updating TB until next restart"?
I believe there's still life for good old fuzzy "Cancel" :)

Comment 55

[WBT]

(In reply to Thomas D. from comment #53)
> No. The sweetness of "Cancel" is that instead of figuring out what exactly
> it will do, I will just rely on my age-old ux that "Cancel" just "gets me
> out of here without changing anything".
But where exactly is "out of here?"  That might not be clear to the user.
With "Stay online," it's very clear where that gets you: staying online.

> No. "Going offline" is still in process, as indicated by the present
> progressive form "going". 
Just because something is happening, doesn't mean it's possible to cancel that.  Whomever makes that assumption has a high degree of control over their environment and over what happens to them (and/or a limited perspective); not everybody has that kind of agency.  The question itself assumes that this is already a settled question that it's happening, and the only choice is about how to prepare "for offline use."

Also, the CURRENT BEHAVIOR OF TB, as reported in comment 0, is that once this dialog shows up, going offline *IS* inevitable.  Maybe it's a reversible action in the sense that you can take explicit action to go back online (assuming you know how), but by this dialog in current TB there *will* be at least a moment in the very near future when you are in the "offline" state.  Anyone who's already learned that will reasonably expect this to continue to be the case.  TB has previously used this dialog and language to indicate that going offline is now unstoppable; why should a user have to assume that TB is suddenly meaning something different with the same dialog and words? 

> And "Cancel" ALWAYS cancels whichever first user action triggered the dialogue. 
You are making the assumption that the user will always be able to figure out what action that is.
This assumed ability is not always present. 

Also, "cancel" *DOES NOT* ALWAYS cancel the user action that triggered the dialogue.  In comment 52, the user action was "Update Thunderbird" and the Cancel button in the triggered dialogue DOES NOT CANCEL that action.  It cancels a different action, delaying (BUT NOT CANCELLING) the (now-unstoppable) user action that triggered the dialog.  

> But I don't care, because I can just cancel
> this without exactly figuring out what it's about, and trust my application
> to ask me if that'll lose any data.

After a lot of experience with TB, I definitely *don't* trust it to ask or warn me before it loses data or important functionality.  

> I said: number of users clicking "Offline" accidentally < number of users
> clicking "Offline" deliberately. Are you suggesting that there are MORE
> users who click "Offline" in the status bar *accidentally* than users who
> click it *deliberately*? Then we'd have to think about ux-error prevention...

In my experience, I have clicked "Offline" *at least hundreds* of times accidentally, and maybe *once* on purpose, excluding tests to try to figure out what was happening or what that feature did.  My final solution was to move the start menu to a different corner of the screen.  Ux-error prevention may be worth considering, but that's a different discussion for a different bug.  Also, that would at best reduce but not eliminate such errors.  Having an easy button that lets me stay online, without having to figure out where that dialog came from, solves the problem *when* those errors happen. 
 
> If user never intended to go offline, but ends up in this dialogue, what's
> "crystal clear" about having as many as *three* different buttons with
> actions I've never requested? 
There's one easily labeled with where I want to go.  That's what's crystal clear.  
As an example, when a traveler who doesn't speak the local language, finds himself at a crossroads with labeled signs pointing in different directions, he might not be able to understand what all the labels mean.  But if he recognizes one as clearly matching where he wants to be, he knows exactly what to do.  

> And how should it be easy to figure out that
> "Stay Online" means "Cancel" (what I know from thousands of other such
> dialogues), while to my own knowledge I haven't done anything about
> "online/offline" because I just misclicked? User doesn't want to affirm
> *any* positive action at this time, he just wants to "get out", and you're
> making it harder to find the exit button. 
There's an X in the upper left.  Users who want an exit familiar from all the other windows they've used before will click the X.  Personally, I would be confused about what X would do: does it mean I still go offline, per current behavior, (see comment 0 step 4), which is NOT what I want?  That's the current behavior, so clearly TB designers thought it would be logical.  Having a button labeled with exactly what I want is much more attractive.  But if you want the familiar "close this dialogue," click the X.   

> Having "Stay Online" button is
> exactly what will force the user to read and understand the whole dialogue,
> including all *three* buttons, instead of quickly and simply click "Cancel"
> without caring much what it does.
If their mindset is to dismiss this dialog quickly, they will click the X.
If they want to be able to understand the options clearly, they should be able to do so.

> Why do you think is it that while "OK"
> buttons went away (to be replaced by "action" buttons), "Cancel" has still
> survived? It's because "Cancel is a universal no-brainer which reduces the
> cognitive burden of explaining the details of the fact that we'll just go
> back to where we came from. 

I think it's mainly because designers haven't come up with something much better, and/or because it's being used in dialogues where "back to where we came from" is clearly and specifically obvious.

> I suspect that if there's a doubt
> wether "Cancel" will take you back to A or back to M, there's something else
> which is wrong in the workflow or interaction design.

Yep, well, there are plenty of wrong things in the workflow or interaction design of software we (at least I) use every day.  Check out my Comment 52 for an example *in TB.* 

> Most users just wont think that far.
They might just assume one of the other options, which does not match the actual software behavior.  Then, they're just confused when the software does something different than expected.

Some of us do think that far.  Not requiring it by telling me clearly what the button will do, would be appreciated.  https://books.google.com/books?id=qahpAgAAQBAJ

> And "overcome bug" substep in the "perform task in TB" substeps are just in your head 
> so they are not technically part of TB's current set of actions.

Having to think about which of my workflow actions are explicitly part of TB's set of valid actions adds cognitive load.

> I strongly doubt that we could ever provide perfect clarity for such scenarios. 
> What do you want to put? "Cancel closing draft, postpone updating TB until next restart"?

Now that you ask, "Cancel closing draft" would be clearer than the status quo about what action that button cancels. I don't anticipate that one changing anytime soon, for other reasons, but if you're just asking on the specific point of providing greater clarity about the action of that button, I do believe there's room for improvement, as illustrated by the example. 

> I maintain that having to chose between three positive action buttons of
> actions I don't care about because I never deliberately requested them is
> harder than just using universal swiss-knife "Cancel"...
I think you would just click X without wondering where that would take you, to dismiss the dialog whack-a-mole style (just to get it out of the way as quickly as possible).  Users who think "oh, the software is presenting a dialogue, it's asking me a question, maybe this is important and I should try to understand what my option are" would benefit from more clarity.

Comment 56

[Thomas D. (:thomas8)]

(In reply to WBT from comment #55)
> (In reply to Thomas D. from comment #53)
> > No. The sweetness of "Cancel" is that instead of figuring out what exactly
> > it will do, I will just rely on my age-old ux that "Cancel" just "gets me
> > out of here without changing anything".
> But where exactly is "out of here?"  That might not be clear to the user.
> With "Stay online," it's very clear where that gets you: staying online.

If I never intended to "go offline" because I just misclicked, I'll have no interest and it will be far from "crystal-clear" to figure out between three explicit action buttons that "Stay online" is actually "out of here". I'll have to parse and understand more or less the entire dialogue to find my best option. Given that since I misclicked, the original action I intended (like Windows Start Menu) did NOT happen, and I get another dialogue instead in the very same second, it doesn't take too much to figure out that it was my misclick which brought this up. So really I wouldn't want to care about the details but just want to "Cancel" this thing out of my way. Whether or not users would prefer the much smaller click target of [x] for that is speculation; I doubt that.

> 
> > No. "Going offline" is still in process, as indicated by the present
> > progressive form "going". 
> Just because something is happening, doesn't mean it's possible to cancel
> that.  Whomever makes that assumption has a high degree of control over
> their environment and over what happens to them (and/or a limited
> perspective); not everybody has that kind of agency.  The question itself
> assumes that this is already a settled question that it's happening, and the
> only choice is about how to prepare "for offline use."
> 
> Also, the CURRENT BEHAVIOR OF TB, as reported in comment 0, is that once
> this dialog shows up, going offline *IS* inevitable.

That's a bug which we are fixing here, no reason to assume it's by design (maybe, maybe not).
We can't base expectations about the new design on a bug in the old design.
We CAN base design expectations on a long-term established design pattern that CANCEL usually cancels the original action prior to the additional information for execution which this dialogue collects, and that CANCEL is usually a data-safe option to take. (Although I do agree with you that TB has had enough dataloss bugs to lose such trust).

> > And "Cancel" ALWAYS cancels whichever first user action triggered the dialogue. 
> You are making the assumption that the user will always be able to figure
> out what action that is.
> This assumed ability is not always present. 

There's always an element of fuzziness in prefabricated human-machine dialogues. We can strive to make it clearer, but we can probably never get total clarity without cluttering the UI to the extent of uselessness. And, as in this case, what's clearer to some might be obfuscating to others. At the end of the day, it's careful design PLUS experience and habit formation that make those interactions reliable. We don't put "Click here to stay online" as a button caption or tooltip because we're expecting our users to figure out some of the things themselves, and avoid over-explicitness which is a burden in the long run as it violates ux-minimalism. 

> Also, "cancel" *DOES NOT* ALWAYS cancel the user action that triggered the
> dialogue.  In comment 52, the user action was "Update Thunderbird" and the
> Cancel button in the triggered dialogue DOES NOT CANCEL that action.  It
> cancels a different action, delaying (BUT NOT CANCELLING) the
> (now-unstoppable) user action that triggered the dialog.

I see your point, and you're right to some extent, but I'd actually still challenge that.
My button in About Thunderbird says "RESTART Thunderbird to Update".
After that, I get the "Save Message" dialogue for unsaved draft.
So in that dialogue, CANCEL will cancel exactly the previous action which immediately triggered the dialogue for collecting additional information, namely it will cancel "Restart". As long as I don't restart, there'll consequently be no update. If I restart, I'll be auto-updated, which is defined somewhere else in the options UI, if you want automatical updates or not. It's obvious that after allowing/confirming application updates, the possibility of preventing them or rolling them back will be limited.

> After a lot of experience with TB, I definitely *don't* trust it to ask or
> warn me before it loses data or important functionality.  

Agreed... :| FTR, I'm at the forefront of campaigning for such dataloss bugs to be fixed, and we HAVE fixed a number of them recently.

> In my experience, I have clicked "Offline" *at least hundreds* of times
> accidentally,

I don't think this will happen to many users in such extraordinary frequency.


> Having an easy button that lets me stay online, without having to
> figure out where that dialog came from, solves the problem *when* those
> errors happen. ... There's one easily labeled with where I want to go [Stay Online].
> That's what's crystal clear.  

Online that "Stay Online" is NOT an easy choice if I never wanted to go there or have any of this in the first place.
 
> But if you want the familiar "close this dialogue," click the X.

I want the familiar "CANCEL", as a bigger and more explicit universally-known click target.

> If they want to be able to understand the options clearly, they should be
> able to do so.

Explicit "Stay Online" forces all accidental users to understand ALL the options.
And it's mostly for those accidental users that we're adding this button.

> > Why do you think is it that while "OK"
> > buttons went away (to be replaced by "action" buttons), "Cancel" has still
> > survived? It's because "Cancel is a universal no-brainer which reduces the
> > cognitive burden of explaining the details of the fact that we'll just go
> > back to where we came from.

Comment 57

[Thomas D. (:thomas8)]

Aceman, is it technically possible to have tooltips on those dialogue buttons?

> Online that "Stay Online" is NOT an easy choice if I never wanted to go there or have any of this
> in the first place.

/Only that.../

Comment 58

[WBT]

(In reply to Thomas D. from comment #56)
> > Also, the CURRENT BEHAVIOR OF TB, as reported in comment 0, is that once
> > this dialog shows up, going offline *IS* inevitable.
> 
> That's a bug which we are fixing here
So, can we make it obvious that it's fixed, and that a user now has the option to stay online? 

> Explicit "Stay Online" forces all accidental users to understand ALL the
> options.
No, it doesn't. This is like that foreign traveler of comment 55 who only has to understand the sign for where he wants to go.  The user only has to understand that one option.  
I think "cancel" is what forces accidental users to understand "Download now" and "download later" and try to figure out what action is exclusive of either of those.  
Since both of the other options are about downloading messages, and the question also is about downloading messages, an obvious interpretation is that clicking Cancel will cancel the action of "download messages." This Cancel would seem a lot like a "download never (unless I activate such a command explicitly in the future)." 

In this dialogue, TB is telling me that it's losing its connection to the internet and indicating it may lose access to my messages if I choose wrong here. I see this as "if I choose wrong, I will lose my messages or at least my access to them" and I would not really want to click on the only option ("cancel") that does NOT give any indication that I will have access to my messages after clicking.  "Stay online" indicates that I will still have access to messages, via the internet connection.  It also puts my mind at ease that I'm not going to have to figure out how to get back online after this dialogue.  As soon as I see "going offline" I might be thinking, "Aah! I don't want to go offline! I don't know how to get back on! How do I get back on?  Maybe there's something near where I just clicked.  Where did I just click?  That's important to remember, so I can try to figure out how to get back online after I take care of this dialogue about downloading messages." If I then see "stay online," that solves my problem about having to figure out how to get back online, and I know it's solved.  

> And it's mostly for those accidental users that we're adding this button.
I agree.  I think those are the users we need to make things clear for.  Even more specifically, within that set there are two groups of users: (1) the ones who just want to dismiss things very quickly without trying to understand what they're being presented with, using a standard that they've learned from lots of experience with windowed applications, and (2) the ones who want to read the dialog, understand the results of clicking on each button (especially because TB is indicating that at least some choices will result in the loss of data/access), and make an informed decision.

Users in group (1) have the X button.  You're saying they might prefer the larger click target of "Cancel" and that might be true.  But we need to support the users in group (2) and give them an option as well, and I think that clear buttons which indicate unambiguously what the results of clicking on them will be is most appropriate for such users.  The value in "stay online" over "cancel" for group 2 is a much greater delta than the small benefit Group 1 users could get from a larger click target.

Comment 59

[:aceman]

(In reply to Thomas D. from comment #57)
> Aceman, is it technically possible to have tooltips on those dialogue
> buttons?
I don't think it is possible while using confirmEx(). We'd need a full .xul-file-driven dialog to be able to use all the special elements and attributes.

Comment 60

[Magnus Melin [:mkmelin]]

Comment on attachment 8607399 [details]
dialogs.png

Oh well, maybe the top version isn't that bad after all.

Comment 61

[Wei Zhang]

The bug is still here.
I'd like to work on this. What should I do?

Comment 62

[Magnus Melin [:mkmelin]]

This bug has an almost finished patch. Have a look at that and update it according to the review comment.

Comment 63

[Wei Zhang]

(In reply to Magnus Melin from comment #62)
> This bug has an almost finished patch. Have a look at that and update it
> according to the review comment.

I suppose you are referring to patch-v2, and review comment 11?

Comment 64

[Magnus Melin [:mkmelin]]

No, the newest one. patch-v4 comment 33 and on.

Comment 65

[Wei Zhang]

Attachment: patch-v5.diff

Improved patch-v4 according to comment 33.

Comment 66

[:aceman]

Comment on attachment 8804883 [details] [diff] [review]
patch-v5.diff

Review of attachment 8804883 [details] [diff] [review]:
-----------------------------------------------------------------

Hi, thanks for improving the patch. There are still some nits to fix.

::: mail/base/content/mail-offline.js
@@ +54,5 @@
>      {
> +      // We solve two problems in this section: the user can cancel going offline
> +      //  and also can: download or don't download messages for offline use
> +      var goOffline = true;
> +      var downloadForOfflineUse = true;

Please use 'let' instead of 'var' for local variables.

@@ +56,5 @@
> +      //  and also can: download or don't download messages for offline use
> +      var goOffline = true;
> +      var downloadForOfflineUse = true;
> +
> +      // check for pre-set beavior

behavior?

@@ +63,5 @@
> +      if (prefDownloadMessages == 0)
> +      {
> +        // ask user what to do
> +        // 0 == Download, 1 == Cancel offline, 2 == Don't download
> +        var decision = this.askDownloadMessagesForOfflineUse();

'let'

@@ +179,2 @@
>     * May update the value of offline.download.download_messages
> +   * Allows the user to cancel the go offline process

Dot at the end of sentence.

@@ +181,2 @@
>     *
> +   * @return integer: 0 == Download, 1 == Cancel offline, 2 == Do not download

@return {integer}  0 == Download, 1 == Cancel offline, 2 == Do not download

@@ +185,2 @@
>    {
> +    alwaysAsk = {value: true};

Why loosing the 'let' ?

@@ +197,3 @@
>        this.offlineBundle.getString('downloadMessagesNow2'),
> +      this.offlineBundle.getString('downloadMessagesCancelOffline2'),
> +      this.offlineBundle.getString('downloadMessagesLater2'),

Please use double quotes for strings.

::: mail/locales/en-US/chrome/messenger/offline.properties
@@ +4,4 @@
>  
>  # Download Messages Prompt
>  downloadMessagesWindowTitle1=Download Messages
> +downloadMessagesLabel1=Going offline. Do you want to download messages for offline use first?

You need to change the downloadMessagesNow2 ID when you change the string text.

@@ +8,2 @@
>  downloadMessagesCheckboxLabel1=Always ask me when I go offline
> +downloadMessagesNow2=&Download

You need to change the downloadMessagesNow2 ID when you change the string text.

Comment 67

[gene smith]

While working on another bug I just noticed this. There is no "are you sure" before you go offline, it just goes offline. Also, there is a checkbox for going offline that is probably instant, but I assume this patch changes that too (haven't tried to read the patch or all the comments above).

Comment 68

[Leonardo Nobrega]

Attachment: patch-v6.diff

Hello,

Here's an update to Wei Zhang's patch (comment 65) with the changes requested by Aceman (comment 66).

I tested in on top of changeset 30008:376d4a7f56f6 (2020-06-29), on a Ubuntu machine. It seems to implement the cancel-offline behavior correctly.

I'm available to help with any remaining work I could do.