All users were logged out of Bugzilla on October 13th, 2018

[UX] Unify design of error and warning pages

RESOLVED FIXED

Status

P1
normal
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: bram, Assigned: bram)

Tracking

(Blocks: 1 bug)

unspecified
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxprivacy] [ux])

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
Created attachment 8677221 [details]
Error and warning pages - Desktop, Android, iOS and Firefox OS

Based on :Margaret’s comment on bug 1214859, we should unify the design and implementation of our error and warning pages.

Here’s our current situation:

* Three different designs for three different kinds of error/warning pages:
  * Network failures: not connected to the internet, server not found, etc.
  * Policy and Crypto failures: expired cert, self-signed cert, rc4, etc.
  * Safe Browsing warnings: attack site, unwanted software, suspected forgery site
* Some functionalities are missing or not at parity:
  * iOS and Firefox OS don’t have warning pages for Safe Browsing
  * On mobile, there’s no way to report error to Mozilla
  * On mobile, there’s an option to add temporary or permanent exception
  * On desktop, we’re redesigning it so that you always add permanent exception, but can revoke trust afterwards (http://brampitoyo.github.io/fx-untrusted-connection/)
* The design is all over the place:
  * Policy/Crypto failures on desktop is being redesigned to use the same template as Network failures
  * Safe Browsing on desktop still uses the old template
  * Android, iOS and Firefox OS implement their own templates


What’s our goal here, then? I see a few:
* Make the design responsive
* Share the same page implementation across platforms


Risks:
* There must be a reason why each platform implement its own error page and doesn’t share code base. My hypothesis is that it has to do with platform quirks. And platform quirks are hard (if not nearly impossible) to solve, especially for a quality-of-life bug like this.
* Keeping the design responsive while being respectful and “native” to each platform has never been easy.


Is there any point I’m missing out on?
(Assignee)

Updated

3 years ago
Blocks: 1214859
OS: Unspecified → All
Hardware: Unspecified → All
Interesting, FirefoxOS does have Safe Browsing now (they have TP and it works). I'm not sure how to turn it on though, but it would be interesting to see what error pages they show (if any) when they encounter itisatrap.org URLs.

Comment 2

3 years ago
(In reply to Bram Pitoyo [:bram] from comment #0)

> What’s our goal here, then? I see a few:
> * Make the design responsive
> * Share the same page implementation across platforms

This might be feasible for desktop/Android, but I don't think it will be feasible for iOS, since their code is in a different repo, and based on top of a different rendering engine.

> Risks:
> * There must be a reason why each platform implement its own error page and
> doesn’t share code base. My hypothesis is that it has to do with platform
> quirks. And platform quirks are hard (if not nearly impossible) to solve,
> especially for a quality-of-life bug like this.

For iOS, yes. For Android, I'm not sure why we have a totally separate implementation. I imagine it was more of an organizational challenge than a technical one (i.e. it's easier to change things if you only have to worry about working with one UX/eng team). This dates back all the way to XUL fennec... see bug 470876.

> * Keeping the design responsive while being respectful and “native” to each
> platform has never been easy.

I think we should focus on the goal of having a consistent design (especially language), and if a shared implementation turns out to be an easy way to get that, we can pursue that. My main worry is that we'll create a shared implementation, but then run into a bunch of places where we need to special-case things for different platforms.
Looking at the Android screens, this looks like a great start Bram. Thanks! 

Let me know how I can help, I'd be happy to lend an eye anywhere you need or provide some of our visual guidelines too.

Do you have a Nexus 7 (preferably 2013)? It might be worth including those as well.

CC'ing Darrin and Robin too
(Assignee)

Comment 4

3 years ago
(In reply to Anthony Lam (:antlam) from comment #3)
> Do you have a Nexus 7 (preferably 2013)? It might be worth including those
> as well.

I don’t have one, unfortunately. I’m testing the page using my personal OnePlus phone.

Could you take a screenshot of what these pages would look like on the Nexus 7?


> I'd be happy to lend an eye anywhere you need or provide some of our
> visual guidelines too.

At the moment, it looks like the desktop and Android pages are pretty well aligned.

My strategy to unify the layout is as follows:

* Take the header strips from Android
  * On wide layout, it should occupy the same area that the purple header on about:privatebrowsing occupies
* Take the expanded section style from desktop
  * On narrow layout, when you click on “Technical information” or “Advanced”, the section that expands will have a white background colour
* Take button and link style from desktop
  * On narrow layout, preferred buttons should have blue background colour
  * On narrow layout, secondary buttons should have border, with no background colour
  * On narrow layout, the button to “Continue anyway” or “Ignore warning” should be <a> links, to make them less attractive
* Text sizes should be kept true to each layout. No tweaking needed.

What do you think?
Whiteboard: [fxprivacy][triage]

Updated

3 years ago
Priority: -- → P4
Whiteboard: [fxprivacy][triage] → [fxprivacy]
(Assignee)

Comment 5

3 years ago
I’ve managed to create a fairly basic responsive design, but also merged the content of aboutNetError.css into info-page.css.

info-page.css is the stylesheet we use for other informational pages like about:welcomeback, about:sessionrestore and about:tabcrashed.

By merging, both our error and informational pages will use one stylesheet – a better solution than trying to maintain two.
(Assignee)

Comment 6

3 years ago
Of course, some positioning and layout bugs remain. Fixing these will be my next priority.

Network error:
http://brampitoyo.github.io/fx-untrusted-connection/responsive-network-error.xhtml

Cert error:
http://brampitoyo.github.io/fx-untrusted-connection/responsive-cert-error.xhtml

Blocked site (safe browsing):
http://brampitoyo.github.io/fx-untrusted-connection/responsive-blocked-site.xhtml
(In reply to François Marier [:francois] from comment #1)
> Interesting, FirefoxOS does have Safe Browsing now (they have TP and it
> works). I'm not sure how to turn it on though, but it would be interesting
> to see what error pages they show (if any) when they encounter itisatrap.org
> URLs.

SafeBrowsing is not enabled yet (see http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#355). I remember when we landed support that we got the same pages as desktop.

Overall we'd like to share as much design & code for these pages for FxOS with other gecko products instead of maintaining our versions. We need to discuss some technical points like how to provide localization though.
(Assignee)

Comment 8

3 years ago
Hi Fabrice,

Sharing design and code for these info pages would be great. It means that we can deploy new error strings easily and keep the platforms at feature parity.

The only concern I have is the fact that Firefox OS seems to have a “Server not found” page that resembles system-level notification, instead of an in-content error page. In this case, FxOS might want keep its own implementation instead of using a shared code.

What are some of your technical concerns?
Flags: needinfo?(fabrice)
(Assignee)

Comment 9

3 years ago
Continuing comment 6, my layout problem is as follows:

* The content height is variable.
* The layouts are designed so that the content is vertically centred.
* The more narrow a layout gets, the more likely that the content height will exceed the viewport height.
* Content that exceeds viewport will still be vertically centred

The solution: on narrow layout, the content should be positioned so that it’s always x distance from top, rather than vertically centred.

Updated

3 years ago
Blocks: 1216897
(Assignee)

Comment 10

3 years ago
The positioning and layout bugs have been resolved, and the layout was made responsive in the process. See the examples on comment 6.

Updated

3 years ago
Assignee: nobody → bram
Blocks: 1220481
Status: NEW → RESOLVED
Iteration: --- → 46.3 - Jan 25
Last Resolved: 3 years ago
Flags: qe-verify-
Priority: P4 → P1
Resolution: --- → FIXED
Summary: Unify design of error and warning pages → [UX] Unify design of error and warning pages
Whiteboard: [fxprivacy] → [fxprivacy] [ux]
(In reply to Bram Pitoyo [:bram] from comment #8)
> Hi Fabrice,
> 
> Sharing design and code for these info pages would be great. It means that
> we can deploy new error strings easily and keep the platforms at feature
> parity.
> 
> The only concern I have is the fact that Firefox OS seems to have a “Server
> not found” page that resembles system-level notification, instead of an
> in-content error page. In this case, FxOS might want keep its own
> implementation instead of using a shared code.
> 
> What are some of your technical concerns?

We don't need to worry about Firefox OS anymore.
Flags: needinfo?(fabrice)
Product: Toolkit → Toolkit Graveyard

Updated

2 years ago
Depends on: 1306853
You need to log in before you can comment on or make changes to this bug.