Closed Bug 1273696 Opened 6 years ago Closed 6 years ago
Usability concerns for new "restore default settings" UI in SSL error page
192.37 KB, image/png
MozReview Request: Bug 1273696 - Moving pref reset button for cert errors and hiding retry when pref reset is possible.
58 bytes, text/x-review-board-request
63.19 KB, image/png
This is a great new feature, but the addition of the descriptive text plus button has been done in such as way as to make the error page as a whole difficult to use. The new text appears directly below the error in a way that does not differentiate the problem from the solution. Additionally, the user is now being presented with four possible UI interactions upon hitting this error: two buttons, one hyperlink and one checkbox. Both buttons reload the page, the link takes them to a lengthy help page, and the checkbox appears - to the user - to do nothing. I know that this page is the result of much deliberation, but the design might be a bit fragile to introduce this new functionality in the way it exists now. My suggestions: * If both buttons reload the page ("Try again" and "Restore default settings"), consider combining them into one button instead. * The "learn more" link is no longer contextually relevant. It could be moved back up to the area directly below the two bulleted items, since it directly describes the error and not the new feature. * The two sentences starting with "It looks like your network security settings ..." might be redundant, since we have already detected this condition and present a button. This could be shortened.
This is probably best in the Firefox product since that's where the code is.
Component: Security: UI → Security
Product: Core → Firefox
So this follows a discussion with Matt regarding the work in: https://bugzilla.mozilla.org/show_bug.cgi?id=1252068 After reviewing the code the try again isn't tied to the reporting as I had thought. The button also does get hidden in certain circumstances when it is presumed it won't work. This means we could make the changes mentioned and I am happy to do this follow up work. * The two sentences starting with "It looks like your network security settings ..." might be redundant, since we have already detected this condition and present a button. This could be shortened. I'm not sure if the sentence would work without the above, I mean we have detected there is an issue and resetting the preference may help with one part of the security error. (From a user perspective if the site had another cert issue afterwards the user may conclude we failed etc)
Review commit: https://reviewboard.mozilla.org/r/53504/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/53504/
Comment on attachment 8753824 [details] Selection_177.png Does this look closer to what you would expect? See comments above also :)
Attachment #8753824 - Flags: feedback?(mwobensmith)
Priority: -- → P3
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
Thanks Jonathan, this really does address my concerns. I appreciate it very much. I assume that by combining the two buttons that we still have TLS telemetry reporting intact. I'm setting needinfo to Mark to make sure he's aware of this change.
One question, though: looking at the proposed change, did we lose the TLS error string somehow?
Matt, no this particular site loads a tls 1.0 request halfway through loading over ajax so it looks different to the error you were seeing.
Attachment #8753821 - Flags: review?(mgoodwin)
I just realized that my question in comment 6 was already addressed in comment 2, so removing the ni? request.
If we're sure the error is a result of their non-default setting, why recommend that they "contact the website owners"? [And do we want these kinds of errors reported to Mozilla, hence the checkbox? I'm less sure about that one, since I'm not what what's being reported.]
(In reply to Justin Dolske [:Dolske] from comment #10) > If we're sure the error is a result of their non-default setting, why > recommend that they "contact the website owners"? > > [And do we want these kinds of errors reported to Mozilla, hence the > checkbox? I'm less sure about that one, since I'm not what what's being > reported.] A site owner is probably interested in loss of users. They might be more interested in a server misconfig than something caused by a problematic add-on (which they can't easily fix), but there seems to me to be value in both scenarios. I imagine this would have a similar value to us in our telemetry, assuming we captured these cases.
Comment on attachment 8753821 [details] MozReview Request: Bug 1273696 - Moving pref reset button for cert errors and hiding retry when pref reset is possible. https://reviewboard.mozilla.org/r/53504/#review51728 Looks good to me - you need a review from a module peer. If I recally correctly, :past has done these for me before.
Attachment #8753821 - Flags: review?(mgoodwin) → review+
Thanks Mark! Panos would you be able to check this over, the change is in the attached screenshot. Thanks
Comment on attachment 8753821 [details] MozReview Request: Bug 1273696 - Moving pref reset button for cert errors and hiding retry when pref reset is possible. https://reviewboard.mozilla.org/r/53504/#review51754 Looks good to me too, thanks.
Attachment #8753821 - Flags: review+
Status: NEW → ASSIGNED
Attachment #8753824 - Flags: feedback?(mwobensmith) → feedback+
You need to log in before you can comment on or make changes to this bug.