Restore Session doesn't follow Fitts Law

[Muelli]

Binary package hint: firefox-3.5

Restarting Firefox after it has crashed brings up the site that asks you whether to restore the old session. It is very likely, I'd say, that the user wants to recover her crashed session. However, the button for starting a new session is much bigger than the button for restoring.

ProblemType: Bug
Architecture: amd64
Date: Tue Nov 17 01:11:57 2009
DistroRelease: Ubuntu 9.10
Package: firefox 3.5.5+nobinonly-0ubuntu0.9.10.1
PackageArchitecture: all
ProcVersionSignature: Ubuntu 2.6.32-4.5-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.32-4-generic x86_64

[Zeniko (zeniko)]

No dataloss issue: you can always either navigate Back or enter about:sessionrestore again after accidentally clicking "Start New Session".

[Jwalden+bmo (jwalden+bmo)]

That might be true, but I think it's far from obvious.

[Beltzner (beltzner)]

Not a blocker.

> * make the "Restore session" button larger
> * align one button to left, one to right so spatial memory can be more helpful

These are good ideas. I think I prefer the latter, really, and it seems pretty easy to do. I don't see the need to make one button larger than the other.

> * make the "Start new" button not a button (e.g. a small-size link like cert
> errors show)
> * hide the "Start new" behind a disclosure widget, a la cert error again

I don't think either of these are appropriate. Especially since in the all-too-possible case that the user is experiencing a recurring crash (remember: they now only get here when there have been two crashes in a row) starting a new session might be an extremely reasonable option. The analogy to the certificate error doesn't really fit, as in that case we're trying to avoid a "whatever" response.

(removing ui-wanted, please consider the above your response!)

[Faaborg (faaborg)]

> * make the "Restore session" button larger
> * align one button to left, one to right so spatial memory can be more helpful

Probably the most effective way to differentiate the buttons is the same way it is done in dialog boxes, with one of them being visually presented as the default choice. Changing the size or position both seem sort of strange, and feel like inventing new solutions to an otherwise addressed problem.

[Zeniko (zeniko)]

(In reply to comment #4)
> with one of them being visually presented as the default choice.

Which already happens, doesn't it?

[Michael Kohler (michaelkohler)]

(In reply to comment #5)
> (In reply to comment #4)
> > with one of them being visually presented as the default choice.
>
> Which already happens, doesn't it?

Right. "Restore" is the default choice.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090528 Minefield/3.6a1pre ID:20090528031402

[Michael Kohler (michaelkohler)]

Created an attachment (id=380234)
WIP

* this doesn't work yet. The right button is not aligned right (but is not because of |#buttons button:nth-of-type(2)|)... Any hint?
* is this going toward the right direction?

[Michael Kohler (michaelkohler)]

(From update of attachment 380234)
>+ -moz-margin-end: 0px;

s/px/em/

[Faaborg (faaborg)]

Another thought, if we move the buttons apart they lose their mapping as being a choice between two options, and instead present themselves as two independent tools. Sp this has the overall effect of making it hard for the user to realize they are even being asked a question. This is compounded by the fact that we have morphed an otherwise modal dialog box into an informational page.

I think the default control styling is the most effective way to solve the UI problem.

[Michael Kohler (michaelkohler)]

(In reply to comment #9)
> I think the default control styling is the most effective way to solve the UI
> problem.

What do you mean with "default control styling"?

[Faaborg (faaborg)]

On OS X it the default button is dark blue (and in other apps that support widget animation) pulsing. On Vista the default button gets a light blue glow. XP just adds a blue line around the edge of the default button (with Luna), etc.

[Zeniko (zeniko)]

This means that #errorTryAgain needs default="true" and for platforms other than OS X, this styling will have to be dynamically removed, whenever a different button gets the focus - as we already do for dialogs:
http://hg.mozilla.org/mozilla-central/annotate/48ffab521d3f/toolkit/content/widgets/dialog.xml#l409

[Michael Kohler (michaelkohler)]

Created an attachment (id=381941)
v1

>-
>+

This removes two unnecessary spaces.

[Michael Kohler (michaelkohler)]

Created an attachment (id=381943)
v1.1 : comment edited

I guess the comment for the event listener is better like that.

[Zeniko (zeniko)]

(From update of attachment 381941)
>+ // focus event listener for platforms other than OS X to make sure the styling is
>+ // removed dynamically if another button gets the focus
>+#ifndef XP_MACOSX

Please drop the bit about what platforms it applies to (that's obvious) and move the comment inside the #ifndef (it's not needed on OS X).

>+ document.getElementById("errorTryAgain").addEventListener("focus", function() {
>+ var defaultButton = document.getElementById("errorTryAgain");
>+ if(defaultButton)
>+ defaultButton.setAttribute("default", this.originalTarget == defaultButton);
>+ }, false);

This doesn't work. Please include a passing test to ensure it does.

The spec is: Mark the button as default, unless another button is selected (and we're not on OS X).

[Dao (dao)]

So you're removing default="true" from the Restore button when the other button has focus, because Enter won't activate the Restore button in that case. Correct? But Enter won't active that button whenever it loses focus, regardless of whether focus goes to the second button.

[Michael Kohler (michaelkohler)]

(In reply to comment #16)

That's right, that's what I'm gonna do now. Thanks.

Simon (is it okay to call you Simon here on bmo?): do I need to "connect" Enter with the Restore button or is it okay to just remove default="true" when #errorCancel has focus?

[Dao (dao)]

I'm not sure you understood comment 16. I think there's a problem with Simon's specification.

[Michael Kohler (michaelkohler)]

Simon: could you please explain what is to do exactly?

[Zeniko (zeniko)]

(In reply to comment #16)
> So you're removing default="true" from the Restore button when the other button
> has focus, because Enter won't activate the Restore button in that case.

No, we're removing default="true" in this case because otherwise two buttons would *look* active. Changing the behavior of the Enter key is a related but different bug.

[Dao (dao)]

(In reply to comment #20)
> No, we're removing default="true" in this case because otherwise two buttons
> would *look* active.

That would be on Windows, where default="true" just gets the focused appearance. That's not the case on Linux.

> Changing the behavior of the Enter key is a related but
> different bug.

Adding default="true" without adjusting the behavior of the Enter key would /introduce/ a bug.

[Michael Kohler (michaelkohler)]

(In reply to comment #20)
> (In reply to comment #16)
> > So you're removing default="true" from the Restore button when the other button
> > has focus, because Enter won't activate the Restore button in that case.
>
> No, we're removing default="true" in this case because otherwise two buttons
> would *look* active. Changing the behavior of the Enter key is a related but
> different bug.

Okay, so I'll write a patch that removes default="true" when the other button has focus. And for the Enter bug I'll file an other bug report which I'll fix after this one.

[Dao (dao)]

Enter is consumed in the tree, which probably shouldn't be changed. So you might not be able to solve that issue, and default="true" might be the wrong approach for this bug.

[Michael Kohler (michaelkohler)]

(In reply to comment #23)
> Enter is consumed in the tree, which probably shouldn't be changed. So you
> might not be able to solve that issue, and default="true" might be the wrong
> approach for this bug.

what about making sure that Enter just calls restoreSession() if nothing in the tree is focused?

any other possible propose how to fix this bug?

[Dao (dao)]

(In reply to comment #24)
> what about making sure that Enter just calls restoreSession() if nothing in the
> tree is focused?

As soon as the tree has focus, the selected row will have focus as well, and there's always a selected row. The interesting question is whether it's an expandable container (where Enter will be consumed) or a tab (where Enter won't be consumed).

> any other possible propose how to fix this bug?

see comment 3

[Michael Kohler (michaelkohler)]

(In reply to comment #25)
> > any other possible propose how to fix this bug?
>
> see comment 3

see comment 9 which is an argument against different alignment.

[Paul-oshannessy (paul-oshannessy)]

*** Bug 505449 has been marked as a duplicate of this bug. ***

[Michael Kohler (michaelkohler)]

What is the best way to go?

[Der-joni-gmail (der-joni-gmail)]

I would suggest something different: I recently saw a Safari Session Restore window (some plugin) which had the buttons "Cancel" and "OK", aligned to the right. It actually is a dialog box popping up before the browser is started, but after thinking about it I think this would also be a good way for Firefox, even when session restore is not a modal dialog box, along with replacing the heading "Well, this is embarrassing." by "Restore Session" (as it also is in the page title).

Why?
 - When the user reads the headline "Restore session", the meaning of the options "OK" and "Cancel" is obvious
 - Even if "Start New Session" and "Restore" say more explicitly what is done, "Start New Session" reads like an "OK" message which I think is one of the reasons I am clicking it unintentionally
 - There is a default layout for "OK" and "Cancel" buttons that every user is familiar with
 - The heading "Well, this is embarassing." might be true but is not what the user needs to read when first seeing this page and quickly deciding which button to click. The sentence could be included in the text paragraph below.

[Michael Kohler (michaelkohler)]

Alex, do you have any further thoughts on this?

[Faaborg (faaborg)]

We are preparing a lot of UI work that leverages a single action button (new notification system [1], content page to temporarily disable third party plugins, etc.). So I think keeping about:session restore internally consistent with a single action button is the best overall approach.

[1] http://people.mozilla.com/~faaborg/files/20090821-notification/newNotification-i1.png

[Michael Kohler (michaelkohler)]

(In reply to comment #31)

So how should that button look exactly? (wording)

I thought of something similar to this:

----------------------
| Restore | v | <---- Button with dropdown arrow
--------------------------
| Restore | <---- Menuitem if clicked on arrow
---------------------------
| Start new Session | <---- Menuitem if clicked on arrow
---------------------------

When clicking on the button (not the arrow), Firefox should restore the session, right?

[Michael Kohler (michaelkohler)]

.. or actually it would be better to display "Start new session" as first item in the dropdown menu to fix this issue.

These kind of buttons are not implemented yet, right? What's the bugnumber of this UI enhancement?

[Highmind63 (highmind63)]

button type="menu" with some styling should do, no? Or maybe there needs to be a new widget created to express this separation of button and menu [button|v] ?

[Dao (dao)]

(In reply to comment #33)
> .. or actually it would be better to display "Start new session" as first item
> in the dropdown menu to fix this issue.

Err, no. Than it would be way too easy to lose all your tabs.

If that single button with "Restore" as the default option doesn't fix this bug, then maybe it's not the right solution.

[Michael Kohler (michaelkohler)]

(In reply to comment
> > in the dropdown menu to fix this issue.
>
> Err, no. Than it would be way too easy to lose all your tabs.
>
> If that single button with "Restore" as the default option doesn't fix this
> bug, then maybe it's not the right solution.

I disagree. If theuser wants to restore the session he just clicks on the button without using the dropdown menu. If he wants to start a new session it's better to not need to move the mouse over the restore menuitem.

[Dao (dao)]

I was assuming that the option on top of the list is also the default option.

[Faaborg (faaborg)]

I'm fine with us not using a split button (bug 509642) in this particular case, but if we want to, we should have it change its state to "Start New Session" in the event that the user unchecks everything. Also, I'm pretty sure these buttons are only supposed to expose additional actions in the drop down (so not including the main action).

[Canon138545 (canon138545)]

Worse than "Well, this is embarassing" is the text "Firefox is having trouble recovering you windows and tabs..." It's inappropriate for those people who prefer to have browser.sessionstore.max_resumed_crashes set to 0.

[Faaborg (faaborg)]

We don't design for about:config customizations, the whole point of about:config is giving some technical users extra control without going through all of the work and boundary cases involved in creating an actual pref in the UI.

[Beltzner (beltzner)]

This bug has gone off into the weeds. Let's pull it back. I suggest filing a new bug for modifying this dialog so that it uses a compound button, since that's predicated on other parts of our UI using those types of buttons.

This bug is about the fact that the button text and placements are confusing users. To solve that issue, I would suggest:

 - changing the text of "Start New Session" to "Close" (probably needs a new bug so we don't get held up on string freeze)
 - moving the "Restore" button so that it is always beneath the "Restore" column

The close button should close the session restore window and replace it with the user's home page.

This will break slightly with the OSX consistency of always putting the "passive" option on the far right (ie: Cancel / OK ) but has the benefit of being cleaner in terms of information hierarchy as there is strong alignment with the options for restoring.

(In reply to comment #39)
> Worse than "Well, this is embarassing" is the text "Firefox is having trouble
> recovering you windows and tabs..." It's inappropriate for those people who
> prefer to have browser.sessionstore.max_resumed_crashes set to 0.

File a separate bug for that, if you wish. Suggest new strings. While I agree with Alex that it's not a priority, it also shouldn't be hard for someone interested to come up with a patch, and the community who're adjusting those prefs are the type who like writing patches, too.

[Michael Kohler (michaelkohler)]

^ I have filed bug 523137 and bug 523140 for this.

[Faaborg (faaborg)]

Going back to comment #9, if we use the correct default button styling (default="true") the user should have an easier time finding the control to restore their session. In any case where we have two buttons (dialogs, content area, etc.) the expected path should be styled as the default choice.

[Beltzner (beltzner)]

(In reply to comment #43)
> Going back to comment #9, if we use the correct default button styling

Yes, you've mentioned. Is there a bug on supporting this in our toolkit? By all means, let's do that as well.

I don't think that alone will solve this issue, though. At a glance, it's far too simple to mistake "Start New Session" with "get back to what I was doing." I think we should make it clear that the in-content page is about restoring your session, and that your alternative is to close that page at which point you have declined to restore any part of that session.

[Faaborg (faaborg)]

Right I'm not really disagreeing, just chiming in so that we don't forget that small fix as well (I was assuming we just didn't bother to set a default button, we need to check if the issue is that it doesn't render as default while in content).

[Paul-oshannessy (paul-oshannessy)]

*** Bug 526754 has been marked as a duplicate of this bug. ***

[Michael Kohler (michaelkohler)]

Please feel free to take this bug.

[Hskupin (hskupin)]

*** Bug 527610 has been marked as a duplicate of this bug. ***

[Simon Ruggier (simon80)]

One more suggestion. Add a menu item under History for something like "Recently Closed Sessions". If this isn't a data loss issue, then implementing that should be easy, right?

[Muelli (ubuntu-bugs-auftrags-killer)]

Binary package hint: firefox-3.5

Restarting Firefox after it has crashed brings up the site that asks you whether to restore the old session. It is very likely, I'd say, that the user wants to recover her crashed session. However, the button for starting a new session is much bigger than the button for restoring.

ProblemType: Bug
Architecture: amd64
Date: Tue Nov 17 01:11:57 2009
DistroRelease: Ubuntu 9.10
Package: firefox 3.5.5+nobinonly-0ubuntu0.9.10.1
PackageArchitecture: all
ProcVersionSignature: Ubuntu 2.6.32-4.5-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.32-4-generic x86_64

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Created an attachment (id=413544)
Screenshot of buttons

Restore would seem more likely, but Start New Session is larger.

Upstreamed from Launchpad.

[Gavin Sharp (gavin-sharp)]

*** This bug has been marked as a duplicate of bug 477322 ***

[Gavin Sharp (gavin-sharp)]

*** Bug 530022 has been marked as a duplicate of this bug. ***

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

The Launchpad user wanted to mention Fitts's Law with regard to this as well. Didn't see it mentioned yet.

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: https://bugzilla.mozilla.org/show_bug.cgi?id=530022

[Micah Gersten (micahg)]

New upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=477322

[Toupsz (toupsz)]

Adding my 2 cents:

Solution:
Restore button should be on the left, not the right.

Reason:
Just ran down the list of my open tabs, dis-selected the ones I did not want, flowed straight down and hit the button that was along the same vertical line of activity: Start New Session.

[Simon Ruggier (simon80)]

I think it would be appropriate to put a note in the crasher page to alert people that if they hit start new session by accident, they can simply hit the back button if they change their mind.

[Paul-oshannessy (paul-oshannessy)]

Created an attachment (id=449078)
An idea...

So I was thinking about this the other day. I got to thinking how there are a lot of forms on the web that have a "default" action as a button, and then the less desirable option as a link. Often this shows up on edit forms - "[Save] or _Cancel_". I know it's really common with 37signals products (and in turn ruby on rails based sites since it's in the default forms).

So I decided to mock something like that up here. I know it's standard practice for us to use buttons as action items, but since this is a chrome-in-content page, I thought it would be worth exploring treating it a bit more like content design-wise.

Thoughts?

[Jwalden+bmo (jwalden+bmo)]

Seems reasonable to me. I'd suggest, by analogy to the various bad-page bits we have, that the link should be opposite-aligned (or more spatially separated, somehow) from the button to further distinguish the two:

http://www.mozilla.com/firefox/its-a-trap.html
http://www.mozilla.com/firefox/its-an-attack.html

(I wonder whether this comment's bugmail will show up as dangerous in Thunderbird due to these links?)

[Simon Ruggier (simon80)]

It seems like a hack to me to make an action item like "Start New Session" a link, but I actually think it's a great idea, because a link would imply to the user that they can use the back button if they clicked on it by mistake.

[Paul-oshannessy (paul-oshannessy)]

(From update of attachment 449078)
Worth also noting that this approach would be anti-os-specific ordering. Currently on OSX, "Restore" is to the right of "Start New Session", but we wouldn't want to do that with one of them being a text link instead.

An additional benefit: links imply that the action is undoable. Buttons have the opposite implication. Since "Start New Session" is actually undoable, this might help give users who don't realize that now a little hint.

[Faaborg (faaborg)]

This feels a bit too much like web design (which makes sense for a 37signals product) as opposed to browser chrome. OSs already have a solution to this problem, styling the default button (usually blue).

[Jwalden+bmo (jwalden+bmo)]

Speaking only for myself, I would find the OS styling to be insufficient to prevent me from making this mistake. I find this manner of OS styling to be helpful when interacting with interfaces using the keyboard, but in the failure case here I'm using a mouse.

[Jorendorff (jorendorff)]

Nominating blocking1.9.3.

This bug is important. Firefox has a reputation for being crashy. Against that, we've sunk a ton of effort into Session Restore so we can recover as gracefully as can be expected. This single, tiny, easy-to-fix UI gaffe not only wipes out all that hard work, it piles frustration on top of frustration in the user's experience.

It won't take a lot of effort to fix this, either. Several good ideas have been suggested.

[Patrick-kinggroupmedia (patrick-kinggroupmedia)]

Effort? About 2 minutes of any competent coder's time to switch the behavior of the buttons. It's the 95 committees debating the bug that have stalled this fix. And oh so many others.

[Faaborg (faaborg)]

Yes, this bug shouldn't be at 62 comments. All of our new notification work is based on a single button for "yes", and the user ignoring and moving on for "eh" (where "eh" means probably no, but I can go back and say yes later if I feel like it). There are a lot of reasons why we think this is better, no forced choice, supports undo, etc. And I think all of those ideas apply here as well.

Single "Restore Session" button: restores the session

Closing the tab, opening a new tab, navigating this tab somewhere else, etc: starts a new session

[Dao (dao)]

> Closing the tab

We don't allow this.

[Faaborg (faaborg)]

right, because it is the first and only tab. Either way, the user has a number of controls to indicate that they want to move on, including new tab, location bar, search bar, bookmarks widget, etc.

[Gavin Sharp (gavin-sharp)]

Created an attachment (id=451682)
remove "Start New Session" button

[Faaborg (faaborg)]

an additional tweak based on feedback by zpao: we should have the first tab be the user's home page (or set of home page tabs), and the second active tab be about:session restore. This way the message does have a close button on the tab (since there is more than one tab) and there is even one more target for the user to indicate that they aren't interested in restoring right now.

We will end up doing this implicitly when we load the home tab and other application tabs, so we could just land this knowing that those other targets are going to be available later. (or we could add the home page now, really either way).

[Simon Ruggier (simon80)]

If arbitrary pages are opened after a crash, it partially defeats the point of not automatically opening the entire session. The home page(s) could be the reason why the browser just crashed.

[Dao (dao)]

I agree with the previous comment, also keep in mind that users might have multiple home pages.

[Faaborg (faaborg)]

yeah good point. Either way later when we get a locally hosted home tab we can be pretty sure that our own code isn't causing the crash (or if it is it's a problem bigger than session restore).

[Will Olbrys (willolbrys)]

Thanks for pointing me to this bug, Paul. Sorry I didn't see it earlier but I'm new and don't know how to use Bugzilla very well.

It seems to me that the technically correct arrangement of buttons is already in place, but we're still having problems with:

a) people clicking the wrong button
b) communicating you can go back if you pressed the wrong button

I propose this: http://imgur.com/mP3Qf.png

The message appears only when you select "Start New Session". It simultaneously informs the user that you can go back to that page whenever you want and gives them a way to do so quickly if they didn't mean to start a new session.

[David-vo2+bmo (david-vo2+bmo)]

I'd prefer removing the "Start New Session" button entirely, but that might confuse the user a bit if they didn't know they could still type in a web address in the location bar.

[Dietrich-mozilla (dietrich-mozilla)]

Not breaking or preventing major functionality, and not a regression, so not blocking on this.

However, the fix is very low risk, would definitely take it once UI-R+'d and reviewed.

Alex, if this patch is approach you agree with (sounds like it from comment 62) can you UI-R+ it?

[Paul-oshannessy (paul-oshannessy)]

Comment on attachment 451682
remove "Start New Session" button

I'm assuming the mozmill stuff is fine. Maybe it would be good for Anthony or Henrik to take a quick look.

[Dietrich-mozilla (dietrich-mozilla)]

Comment on attachment 451682
remove "Start New Session" button

Requesting additional review from Henrik per Zpao's comment.

[Hskupin (hskupin)]

Comment on attachment 451682
remove "Start New Session" button

Thanks Paul for the patch. It looks fine so far. But can you also create the patch against our mozmill-tests repository? The copy we have on mozilla-central is a bit outdated and needs a new sync in the next days once mozmill-1.4.2 has been released. All the current work happens on http://hg.mozilla.org/qa/mozmill-tests/. Thanks!

[Dao (dao)]

http://hg.mozilla.org/mozilla-central/rev/860c490eb849

[Paul-oshannessy (paul-oshannessy)]

Pushed to mozmill: http://hg.mozilla.org/qa/mozmill-tests/rev/9e5fee9dd48b

[Beltzner (beltzner)]

FTR, this was pretty confusing and surprising to me when I saw the change today; not sure if some of that will be resolved in zpao's follow-up work or not.

Alex: I'm assuming your comment 62 meant to imply that the recommended action here is always to restore the session, so that's the Very Obvious Path. As Dao said in comment 63, the user can't actually close this tab in the usual case of restoring-from-crash, so it's actually now pretty hard to get to a new, blank session.

[Faaborg (faaborg)]

>As Dao said in comment 63, the user can't actually close this tab in the usual >case of restoring-from-crash, so it's actually now pretty hard to get to a new, >blank session.

If we don't get a Home Tab landed, then we should probably go back to treating this tab like a modal dialog box. Ideally though the user should have a variety of targets to move forward (home tab, new tab, tab close button).

[Micah Gersten (micahg)]

Adding a task for firefox source since that will most likely receive the update.

[Beltzner (beltzner)]

In that case, I think the easiest thing to do is to back out this change until some of those other dependencies have landed.

[Dao (dao)]

I was going to suggest the same. Backed out:
http://hg.mozilla.org/mozilla-central/rev/0868c30effb1
http://hg.mozilla.org/mozilla-central/rev/9599efaaa3d8

[Paul-oshannessy (paul-oshannessy)]

*** Bug 639990 has been marked as a duplicate of this bug. ***

[Paul-oshannessy (paul-oshannessy)]

*** Bug 696274 has been marked as a duplicate of this bug. ***

[Ghostgunna (ghostgunna)]

I use FireFox on Mac & Windows. Because the buttons are back to front compared to each other I am constantly pressing the wrong button. Especially since FF has been crashing so often lately. Anything would be better than the default buttons.

[Ws-bugzilla (ws-bugzilla)]

Perhaps it’s time to attempt removing the Start New Session button again, or replacing it with a link? Both are good ideas. Both would have saved the 10 or so Panorama groups, each with lots of tabs, that I have now lost, apparently irreversibly.

("Back" no longer has any effect on any of the tabs I still have; "about:sessionrestore" is blank.)

This UI issue + Panorama = major data loss.

[Jruderman (jruderman)]

See also bug 639992 for making it less catastrophic if you hit the wrong button (and know where to look).