Closed Bug 1273696 Opened 6 years ago Closed 6 years ago

Usability concerns for new "restore default settings" UI in SSL error page

Categories

(Firefox :: Security, defect, P1)

49 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 49
Iteration:
49.3 - Jun 6
Tracking Status
firefox49 --- fixed

People

(Reporter: mwobensmith, Assigned: jkt)

References

Details

(Whiteboard: [fxprivacy] )

Attachments

(3 files)

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.
Whiteboard: [fxprivacy]
This is probably best in the Firefox product since that's where the code is.
Component: Security: UI → Security
Product: Core → Firefox
Whiteboard: [fxprivacy] → [fxprivacy] [triage]
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)
Depends on: 1252068
Assignee: nobody → jkingston
Attached image Selection_177.png
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.
Flags: needinfo?(mgoodwin)
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.
Flags: needinfo?(mgoodwin)
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
Flags: needinfo?(past)
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+
Flags: needinfo?(past)
Status: NEW → ASSIGNED
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/0dfa11a25c89
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 49
Attachment #8753824 - Flags: feedback?(mwobensmith) → feedback+
Iteration: --- → 49.3 - Jun 6
Priority: P3 → P1
You need to log in before you can comment on or make changes to this bug.