Improve the wording of the about:sessionrestore page

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
Session Restore
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: neilio, Assigned: beltzner)

Tracking

({late-l10n, verified1.9.1})

3.5 Branch
Firefox 3.6a1
late-l10n, verified1.9.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

10 years ago
The current wording on the about:sessionrestore page is a bit too heavy on the "happy talk" (e.g. "We sincerely apologize for the inconvenience"). I'd like to improve this to be more concise and effective.

I will attach some improved wording in a day or so, but wanted to open this bug so I a) don't forget, and b) see if anyone has suggestions for improvement.

Comment 1

10 years ago
(In reply to comment #0)
> (e.g. "We sincerely apologize for the inconvenience").

That's the only bit of "happy talk" on that page, and considering that you need two consecutive crashes to reach about:sessionrestore in the first place, an apology sounds adequate to me.

Also, I'm quite sure that Alex has put enough thought into the wording when he suggested it, making this bug WONTFIX.
Whiteboard: [wontfix?]
An apology might be in order but "we apologize for the inconvenience" borders on the disingenuous - this might be due to a phenomenon that is more apparent in North America, where customers and travelers are always apologized to for "the inconvenience" in a way that seems at once aloof and insincere.

At any rate - this bug is not WONTFIX, but it certainly shouldn't ignore the thought and consideration that went into the current wording (see bug 459950 and bug 464155 for that).
Whiteboard: [wontfix?]
Current:

> Would you like to restore your session?
> 
> Your previous Shiretoko session closed unexpectedly. We sincerely apologize 
> for the inconvenience. You can restore the tabs and windows from your 
> previous session, or start a new session if they are no longer needed.
>
> If Shiretoko closes repeatedly:
>    * Try disabling any recently added extensions in the Add-ons Manager.
>    * Try restoring your session without any Web pages you suspect might be
>      causing the problem:

As Neil stated, the "sincerely apologize" portion of this does little to help the user get back on task, or explain what they can do about the fact that all their windows and tabs are missing. We do, however, need to explain what's going on and why they're not seeing their windows and tabs. I agree with Alex's assertion in bug 459950 that we need to lead off with a question, so the title seems good. The middle bit, though, could be shortened.

The text should:
 - explain that the reason the user is seeing this is that we've experienced repeated crashes
 - explain what this dialog lets them do
 - help the user understand that all is not lost

Proposal:

Sorry, Shiretoko is having problems restoring your session. You can restore some or all of the tabs and windows from your previous session, or start a new session if they are no longer needed.

If you keep seeing this page:
  * Try disabling any recently added extensions in the Add-Ons Manager
  * Try removing any recently opened tabs or windows from the list, below

That still doesn't quite feel right, though. Neil?
>I'd like to improve this to be more concise and effective.

I'm all for concise and effective.  I also forgot to take into account cultural implications of apology when proposing the current text.  After reading it again I agree with Mike that it might not come off as genuine, although I still think it is important that the text should include some form of recognition of the problem.

perhaps:

------------------------------------------------------

Would you like to restore your session?
 
We're sorry, Shiretoko closed unexpectedly. You can restore the tabs and windows from your previous session, or start a new session if they are no longer needed.

 If Shiretoko closes repeatedly:
    * Try disabling any recently added extensions in the Add-ons Manager.
    * Try restoring your session without any Web pages you suspect might be
      causing the problem:

------------------------------------------------------

Just "sorry" feels a little colloquial, and (at least for) even less genuine.  I also tried first person, but having Firefox talk to you is just freaky (I'm sorry I crashed, Dave).  So while the "we" is kind of ambiguous, I think it works the best.

Also, I'm worried that "Shiretoko is having problems restoring your session" instills too much doubt in the user when placed next to the question "Would you like to restore your session?"
>considering that you need
>two consecutive crashes to reach about:sessionrestore in the first place, an
>apology sounds adequate to me.

Although in most cases, the second crash will be so fast that it will look like just one from the user's perspective, right?
Keywords: late-l10n
I think we should note that each localizer should use a culturally appropriate form of apology here, since I know a lot of other countries really detest american happy talk and smiley faces.
(Reporter)

Comment 7

10 years ago
Alex, your new version is definitely much improved!

The only change I'd recommend is we say "Shiretoko unexpected quit", or, if this is accurate, just "Shiretoko has crashed". Crashed is more specific and it's also probably more clear. 

One other thought here (which probably requires its own bug) is that the actionable text ("Try disabling any recently added extensions in the Add-ons manager") should really be actionable. To a user this looks like a special web page anyway, so why not make "Add-ons manager" a clickable link that opens the Add-ons manager window?
>The only change I'd recommend is we say "Shiretoko unexpected quit", or, if
>this is accurate, just "Shiretoko has crashed". Crashed is more specific and
>it's also probably more clear. 

This got carried over from the last dialog, not sure if there was any specific reason to say "unexpectedly closed"

>One other thought here (which probably requires its own bug) is that the
>actionable text ("Try disabling any recently added extensions in the Add-ons
>manager") should really be actionable.

Yeah, I agree.  Previously we have had a ban on using hyperlinks for accessing chrome (we had to use a button) to establish a strict distinction between chrome and content.  However, on about:private browsing we changed from a button to a link because if you didn't read the message the button looked like the next thing you have to interact with (which would lead to clear recent history).  So now that we've scaled back our guidelines for links leading to chrome, let's make this a link and help the user.

Comment 9

10 years ago
(In reply to comment #5)
> Although in most cases, the second crash will be so fast that it will look like
> just one from the user's perspective, right?

No, Firefox simply doesn't load so fast. ;-)

If a page crashes instantly, SessionStore usually doesn't even get to save its URL to disk, so the crash won't happen until the user clicks the link on the previous page again. Alternatively a page can cause the crash after a delay, in which case the user will have Firefox load and crash again after several seconds. In both cases, it will obviously look like two different crashes (and you should get two crash reporters to make things even more obvious).

(In reply to comment #7)
> Crashed is more specific and it's also probably more clear. 

Air planes crash, computer programs don't - at least not outside of IT-jargon which we try to avoid (see the localization note in <http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/aboutSessionRestore.dtd>).
(In reply to comment #8)
> Yeah, I agree.  Previously we have had a ban on using hyperlinks for accessing
> chrome (we had to use a button) to establish a strict distinction between

I don't know if it was a *ban* per se, but it was discouraged, especially in cases where links were being used for no good reason (ex: download manager links for "retry"). Generally speaking, we should be making sure that we're matching user expectations.

I do think that most users will expect a link on _disable add-ons_ to lead to documentation (on SUMO, perhaps?) about what that means, how to do it, and how to undo it. That might be more helpful still than just popping open the Add-Ons manager.

(In the about:privatebrowsing case, there really is only one clear action to perform, whereas in this case, the add-ons manager provides a bunch of different actions, so it may not be as clear to the user how that relates to the link source)

I like the new text; better than my proposal. One question, though, you restored the second bullet to:

    * Try restoring your session without any Web pages you suspect might be
      causing the problem:

Do we think that users will be able to make that sort of judgement? I'd switched it to "recently opened" on the assumption that crashes follow action, and so opening a tab which crashed meant that the most recently opened tabs would be best suspects. Uncool?

Neil: wanna try your hand at a patch? We'd need this for the day we re-open to strings if we want to get it in.
>Do we think that users will be able to make that sort of judgement?

Only in the sense that they would probably remove things that were opened right before the crash, so your description is more direct.  Didn't mean to revert, just didn't notice that it was different.
Assignee: neilio → beltzner
Created attachment 368428 [details] [diff] [review]
update text & change to warning icon

Alex, Madhava and I put our heads together and re-worked this dialog to be apologetic, and far far less wordy. It acknowledges that Firefox is having problems recovering, and is very clear about what the user's options are.

We also switched to a yellow bang icon.
Attachment #368428 - Flags: review?(gavin.sharp)
Created attachment 368430 [details]
screenshot of new text and icon
Comment on attachment 368428 [details] [diff] [review]
update text & change to warning icon

>diff --git a/browser/themes/winstripe/browser/aboutSessionRestore.css b/browser/themes/winstripe/browser/aboutSessionRestore.css

> #errorPageContainer {
>-  background-image: url("chrome://global/skin/icons/question-48.png");
>+  background-image: url("chrome://global/skin/icons/warning-48.png");
> }

For some reason warning-48.png is called warning-large.png on Windows. r=me with that change.
Attachment #368428 - Flags: review?(gavin.sharp) → review+
Created attachment 368435 [details] [diff] [review]
for checkin

carrying over r+ from gavin
a191=beltzner on behalf of drivers

(checkin needed!)
Attachment #368435 - Flags: review+
Attachment #368435 - Flags: approval1.9.1+
Keywords: checkin-needed
https://hg.mozilla.org/releases/mozilla-1.9.1/rev/98b1a5f89537
Keywords: fixed1.9.1
Target Milestone: --- → Firefox 3.2a1
http://hg.mozilla.org/mozilla-central/rev/4be589e93b22
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED

Comment 18

10 years ago
The wording seems fine but how does the user "remove" one or more tabs?  There is a button for restoring but not removing.  I guess fixing bug 462618 would help out a heck of a lot since users are used to seeing actually text boxes and not a just a check mark that appears can't be unselected.  Also, the wording should say something about deselecting the tab below instead of telling a users to remove the tab and then not telling them how to do it.

Of course I know what to do but when I just looked over the screen shot even I was confused.  Plus the steps given are in a different order of the buttons below.
Maybe the button should say "Restore selected"?  I agree that bug 462618 will help a lot.

Comment 20

10 years ago
>--- a/browser/locales/en-US/chrome/browser/aboutSessionRestore.dtd
>+++ b/browser/locales/en-US/chrome/browser/aboutSessionRestore.dtd

>+<!ENTITY restorepage.errorTitle     "Well, this is embarassing.">

I thought it was spelled "embarrassing", or did I just missed the joke. :S

Comment 21

10 years ago
 (In reply to comment #20)
> >--- a/browser/locales/en-US/chrome/browser/aboutSessionRestore.dtd
> >+++ b/browser/locales/en-US/chrome/browser/aboutSessionRestore.dtd
> 
> >+<!ENTITY restorepage.errorTitle     "Well, this is embarassing.">
> 
> I thought it was spelled "embarrassing", or did I just missed the joke. :S

You are correct.
verified fixed on the 1.9.1 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090323 Shiretoko/3.5b4pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090323 Shiretoko/3.5b4pre.

verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090322 Minefield/3.6a1pre
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.