Closed Bug 966107 Opened 6 years ago Closed 6 years ago

Implement netError design changes

Categories

(Firefox :: General, enhancement)

enhancement
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: vtsatskin, Assigned: vtsatskin)

References

Details

Attachments

(3 files, 1 obsolete file)

No description provided.
Assignee: nobody → vtsatskin
Component: Theme → General
Blocks: 966115
Status: NEW → ASSIGNED
Depends on: 591737
Depends on: 966503
Attached patch newNetError.patch (obsolete) — Splinter Review
No longer depends on: 591737, 966503
Attachment #8373723 - Flags: review?(jaws)
Attachment #8373723 - Flags: review?(bmcbride)
Duplicate of this bug: 676795
Attachment #8368327 - Flags: ui-review?(ux-review)
Attachment #8373725 - Flags: ui-review?(ux-review)
Attachment #8373723 - Attachment is obsolete: true
Attachment #8373723 - Flags: review?(jaws)
Attachment #8373723 - Flags: review?(bmcbride)
Attachment #8373746 - Flags: review?(jaws)
Attachment #8373746 - Flags: review?(bmcbride)
Turns out I forgot to include SearchBar.jsm in the original patch.
From an FHR perspective, this looks fine: it adds a new search source, but IMO we don't need to bump the search measurement version for this (it's strictly additive).

Brendan and Greg, please overrule me if you disagree.

Code-wise there's nothing more that needs to be done for this search recording to work correctly.

Valentin verified that searches via netError are being reported in about:healthreport.
Flags: needinfo?(bcolloran)
OS: Mac OS X → All
Hardware: x86 → All
This looks very good!

Remembering your original design, I noticed two things:
1) You went for the help text being shown by default
2) The search field isn't pre-filled anymore
I don't feel too strongly about those, but I'd be interested in the rationale behind it nonetheless.
I should probably clarify why not all the changes were implemented just yet. I wanted to make logical enough UI update w/ simple search functionality without tweaking the rest of the existing error pages. There's room for some user testing to see how changes to copy affect user's behavior when encountering the error messages. The thing I'm worried about is making the experience more confusing and/or slowing down error recovery time. So the changes with collapsing some of the text/rewording it will come further down the line with more iteration. 

1) I felt that some users might not interact with the "more info" and thus lose some helpful error recovery text.

2) I agree with you on this one, the search field should definitely be filled in. Similar to the rationale stated originally, I wanted to make these changes simple and iterate later with stuff like this.
@rnewman: yes i agree. this looks to me like a content change, not a semantic change, and so i don't believe it should require a version bump. but i'm also happy to defer to gps. :-)
Flags: needinfo?(bcolloran)
FYI, I'm a little slow on reviews due to Australis.
(In reply to Valentin Tsatskin from comment #8)
> I should probably clarify why not all the changes were implemented just yet.
> I wanted to make logical enough UI update w/ simple search functionality
> without tweaking the rest of the existing error pages. There's room for some
> user testing to see how changes to copy affect user's behavior when
> encountering the error messages. The thing I'm worried about is making the
> experience more confusing and/or slowing down error recovery time. So the
> changes with collapsing some of the text/rewording it will come further down
> the line with more iteration. 
> 
> 1) I felt that some users might not interact with the "more info" and thus
> lose some helpful error recovery text.
> 
> 2) I agree with you on this one, the search field should definitely be
> filled in. Similar to the rationale stated originally, I wanted to make
> these changes simple and iterate later with stuff like this.

Testing is good :)
Are you planning to run this through user testing first or just instrument it and land on nightly?
On a side note: did you also change the error page for things like connection reset and other (non 404) errors? I could imagine that different errors could benefit from different treatments here.
(In reply to Philipp Sackl [:phlsa] from comment #11)
> Are you planning to run this through user testing first or just instrument
> it and land on nightly?

I think instrumenting it would be the best bet to see usage of the search bar. Doing a user test is pretty tricky with error messages, since doing them in "the lab" might not give us the most accurate results as how users actually interact with error pages. If you have any ideas on how to do the testing, I would be more than happy to hear.

> On a side note: did you also change the error page for things like
> connection reset and other (non 404) errors? I could imagine that different
> errors could benefit from different treatments here.

This applies to all error messages which use about:neterror. A crude list can be found in netError.dtd: http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/overrides/netError.dtd

Do you have any specific examples of how you would treat specific errors differently? As a follow up, I've outlined a lot of my thought process here around the idea: http://people.mozilla.org/~vtsatskin/notes/Projects/Message%20Cleanup/message.cleanup
On a side note, the search bar modularity might be better handled as a web component.
(In reply to Valentin Tsatskin from comment #12)
> I think instrumenting it would be the best bet to see usage of the search
> bar. Doing a user test is pretty tricky with error messages, since doing
> them in "the lab" might not give us the most accurate results as how users
> actually interact with error pages. If you have any ideas on how to do the
> testing, I would be more than happy to hear.

Sounds good! You might want to bug blake about this – he knows a thing or two about instrumentation ;)

> > On a side note: did you also change the error page for things like
> > connection reset and other (non 404) errors? I could imagine that different
> > errors could benefit from different treatments here.
> 
> This applies to all error messages which use about:neterror. A crude list
> can be found in netError.dtd:
> http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/
> overrides/netError.dtd
> 
> Do you have any specific examples of how you would treat specific errors
> differently? As a follow up, I've outlined a lot of my thought process here
> around the idea:
> http://people.mozilla.org/~vtsatskin/notes/Projects/Message%20Cleanup/
> message.cleanup

I haven't looked through all of them, but as an example, the »Server too busy« error would benefit from a link to a Wayback machine or Google cache version (more than from a search box).
But don't let that slow down your current efforts :)
The design direction has changed from the original proposal. However, the feedback taken from this discussion and work done on this bug will transition over to bug 982347.

I'm closing this bug and continuing the work in bug 982347 due to scope and definition being more clear.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Attachment #8368327 - Flags: ui-review?(ux-review)
Attachment #8373725 - Flags: ui-review?(ux-review)
No longer blocks: 966115
You need to log in before you can comment on or make changes to this bug.