593125 - Reword offline error text in the content area message

Status: VERIFIED FIXED

(Firefox :: Menus, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

When the user does not have an internet connection (or they have specifically instructed Firefox to be in offline mode), we display the content are page shown in the attachment.  It contains a try again button and one bullet:

* Uncheck "Work Offline" in the File menu, then try again.

We either need to reword this based on the presence of the Firefox button (in which case we would need to say developer menu isntead of file menu), or only display the message if we know that we are in offline mode:

* Unchecked "Work Offline," and then try again

The assumption would be that since the user knows how to get into offline mode, they would also know how to get out of it, so we don't have to worry about changing the text based on the menu structure.

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Offline (either mode or no access)

Screen shot of the current content area message.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

Should be a simple change but requesting blocking since the text can confuse the user.

Comment 3

[Axel Hecht [:Pike]]

Don't we go into offline mode automagically when the network disappears? That'd break the assumption that the user knows how to switch that on again.

Also, I recall talk about dropping the "Offline" switch alltogether, is that off the table?

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

If there is no connection offline mode isn't checked, I think we are saying to uncheck it just to be sure.  When it isn't checked the try again button will actually work.

I would like us to treat online and offline access per domain, but that's too complex for right now.

Comment 5

[Axel Hecht [:Pike]]

This has none of a patch, an owner, or a blocking decision but strings impact.

What's the triage or ETA status here?

Comment 6

[Dão Gottwald [:dao]]

(In reply to comment #0)
> The assumption would be that since the user knows how to get into offline mode,
> they would also know how to get out of it, so we don't have to worry about
> changing the text based on the menu structure.

I actually never go into offline mode but still need to get out of it sometimes :(

Comment 8

[:Margaret Leibovic]

Attachment: patch

Here's a patch that removes the reference to the file menu. It may not be ideal, but it's better than sending the user to the wrong place.

I did an mxr search, and there's also a reference to this in dom code (http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/appstrings.properties#49). Should we switch that string as well?

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

>Should we switch that string as well?

yeah, thanks for catching that

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Also need to rev the entity name.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Though that affects a bunch of downstream consumers that override this as well (thunderbird, fennec), sigh.

Comment 12

[:Margaret Leibovic]

(In reply to comment #11)
> Though that affects a bunch of downstream consumers that override this as well
> (thunderbird, fennec), sigh.

Is there a solution to that?

Comment 13

[:Margaret Leibovic]

Attachment: patch v0.2

Here's a patch that updates all the entities if we want it. However, like gavin pointed out, it would affect a lot of people.

Comment 14

[Axel Hecht [:Pike]]

I don't think there's a way around it, no.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

We could use a hack like http://hg.mozilla.org/mobile-browser/rev/c72e9cdf31ca (graceful fallback to the old string if localizers/overriders don't get the change, at the risk of increased odds that localizers will get it wrong)...

Comment 16

[Paul McAuley]

As mentioned in bug 593125, why not simply put an online/offline toggle directly within the content area when you get this error?

Comment 17

[Paul McAuley]

(In reply to comment #16)
> As mentioned in bug 593125, why not simply put an online/offline toggle
> directly within the content area when you get this error?

oops - I meant "as mentioned in bug 596121 ".

Comment 18

[:Gavin Sharp [email: [e-mail]]]

That's harder (the page isn't currently privileged), and covered by bug 435325.

Comment 19

[:Margaret Leibovic]

(In reply to comment #15)
> We could use a hack like http://hg.mozilla.org/mobile-browser/rev/c72e9cdf31ca
> (graceful fallback to the old string if localizers/overriders don't get the
> change, at the risk of increased odds that localizers will get it wrong)...

This could work for the string in overrides/netError.dtd, but what about the string in appstrings.properties. Would we need to do something similar, or would changing that string be okay because it isn't in an override file?

Comment 20

[Axel Hecht [:Pike]]

Regarding the DTD stuff, I frankly don't recall why and how that was supposed to work. Like, we do need to signal somehow that the old value changes. I'm wondering if we can hack the alias into the xhtml file, and rely on potentially double-defining the entity in the right order. (Yac) (Yes, I told margaret something different just a minute ago)

For .properties, we could make the code check the new string, and fall back to the old one if it doesn't find it. I guess that'd require us to leave netOffline in place there, which might actually be a good idea.

Comment 21

[:Margaret Leibovic]

Attachment: patch v0.3

Comment 22

[:Margaret Leibovic]

Attachment: patch v0.4

Comment 23

[Justin Dolske [:Dolske]]

Comment on attachment 476940 [details] [diff] [review]
patch v0.4

Now I remember why this trick looks familiar, I did it in the v.3 patch on bug 538910. :)

Comment 24

[:Margaret Leibovic]

http://hg.mozilla.org/mozilla-central/rev/e6f66ee57044

Comment 25

[(no longer active)]

:l10n should have really been CCed on this bug.  Here's a bunch of comments, even though it might be too late for that...

(In reply to comment #0)
> When the user does not have an internet connection (or they have specifically
> instructed Firefox to be in offline mode), we display the content are page
> shown in the attachment.  It contains a try again button and one bullet:
> 
> * Uncheck "Work Offline" in the File menu, then try again.
> 
> We either need to reword this based on the presence of the Firefox button (in
> which case we would need to say developer menu isntead of file menu),

Why didn't we choose this path?  We did the same thing for bug 593126, for example, and I fail to see how this bug is different.

> or only
> display the message if we know that we are in offline mode:
> 
> * Unchecked "Work Offline," and then try again
> 
> The assumption would be that since the user knows how to get into offline mode,
> they would also know how to get out of it, so we don't have to worry about
> changing the text based on the menu structure.

That's the wrong assumption, as indicated earlier in comment 0.  The user might get into offline mode if their network connection is dead.  We do not ask the user whether they want to go into the offline mode, and they might have no idea where the "Work Offline" menu item is for them to uncheck.  I think the net effect of this change will be getting out of the offline mode more difficult for the fraction of our users who don't have the location of every menu item memorized.  I don't have any data on this, but I have a hunch that this fraction may be the majority of our users.

Comment 26

[(no longer active)]

Bugzilla's user auto-completion helped me fail to CC :l10n on the previous comment.  For those who get this as their first mail on this bug, please see comment 25.

Comment 27

[:Margaret Leibovic]

(In reply to comment #25)
> :l10n should have really been CCed on this bug.  Here's a bunch of comments,
> even though it might be too late for that...

I'm sorry, I probably should have indicated that I talked to Axel in person
this afternoon, but he wasn't around to r+ the final patch because he was
flying from SFO to Germany.

This is supposed to be a quick fix to prevent us from directing the user to a
non-existent menu item. Unfortunately we're approaching string freeze, so it's
hard to implement ideal changes at this point :(

Comment 28

[Dão Gottwald [:dao]]

Can we at least hint towards "Work Offline" being a menu item?

* Uncheck the "Work Offline" menu item, then try again.

'Uncheck "Work Offline"' is close to being completely useless to users who haven't actually checked it and don't know our menus by heart.

Comment 29

[Axel Hecht [:Pike]]

Comment on attachment 476940 [details] [diff] [review]
patch v0.4

I think that Ehsan's comment is really about UE, not l10n. I only commented about the actual technical details about how to tweak shared neterror messages, really, and those look good in this patch.

(PS: I asked similar UE questions in comment 3, I guess :-) )

Comment 30

[(no longer active)]

(In reply to comment #27)
> This is supposed to be a quick fix to prevent us from directing the user to a
> non-existent menu item. Unfortunately we're approaching string freeze, so it's
> hard to implement ideal changes at this point :(

My comment was also half l10n and half UE, but Dao's comment 28 was a lot clearer on the l10n side.  Translating "Uncheck work offline" is going to be tricky, I don't think that it even makes a lot of sense in English.

But anyway, why is it hard to fix this the right way?  Can't you use the same technique as bug 593126?  I'd totally understand if you have too much on your plate and too little time for this, but I don't see why the correct solution is hard...

At the very least, we should have a bug on file for the right fix.

Comment 31

[Dão Gottwald [:dao]]

(In reply to comment #30)
> But anyway, why is it hard to fix this the right way?  Can't you use the same
> technique as bug 593126?

The error page isn't privileged.

Comment 32

[(no longer active)]

(In reply to comment #31)
> (In reply to comment #30)
> > But anyway, why is it hard to fix this the right way?  Can't you use the same
> > technique as bug 593126?
> 
> The error page isn't privileged.

Fair enough.  I'll shut my mouth then!  :-)

... before doing that, I still think that comment 28 should be addressed.

Comment 33

[:Gavin Sharp [email: [e-mail]]]

Attachment: address comment 28

faaborg said he was fine with this.

Comment 34

[:Gavin Sharp [email: [e-mail]]]

Attachment: address comment 28 (real patch)

Comment 35

[Axel Hecht [:Pike]]

Comment on attachment 477360 [details] [diff] [review]
address comment 28 (real patch)

r=me. I did already r- a sign-off for the previous version of this patch because the localizers apparently didn't change the string at all. Can we make the _2 something that's less subtle on what's the intention of that string? Not sleeping my jetlag off, so I don't really have a good suggestion.

Also, a quick post .l10n may help trigger the senses of our localizers.

Comment 36

[:Gavin Sharp [email: [e-mail]]]

Landed that, with a rename and L10N note that should hopefully help.
http://hg.mozilla.org/mozilla-central/rev/17c0971e7380

Comment 37

[Axel Hecht [:Pike]]

Looks good, thanks.

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101023 Firefox/4.0b8pre