Closed Bug 476477 Opened 16 years ago Closed 16 years ago

Improve the wording of the about:sessionrestore page

Categories

(Firefox :: Session Restore, defect)

3.5 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: neilio, Assigned: beltzner)

Details

(Keywords: late-l10n, verified1.9.1)

Attachments

(3 files)

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.
(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?
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.
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.
(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
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)
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+
Attached patch for checkinSplinter Review
carrying over r+ from gavin a191=beltzner on behalf of drivers (checkin needed!)
Attachment #368435 - Flags: review+
Attachment #368435 - Flags: approval1.9.1+
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
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.
>--- 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
(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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: