Closed Bug 986631 Opened 6 years ago Closed 2 years ago

"offline" banner during email account setup need improvement


(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Not set


(Not tracked)



(Reporter: dietrich, Unassigned)



(Keywords: papercut, polish)

1. should link to Settings for configuration.

2. should use a building block. it's currently a weird inline banner with a black background.
UX plz to comment on proper treatment here.
Flags: needinfo?(firefoxos-ux-bugzilla)
Keywords: papercut, polish
I believe Harly has noted this in his building block work, and we can add the link change (which should also be a standard patten). Adding Harly and Rob on cc: but adding Harly on ni? as well just to check the accuracy of my comment here.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(hhsu)
I was looking for inconsistency issues and found out that the "offline" banner didn't follow building blocks. However, banner is design to display info to the user in a transitory fashion, typically to confirm a user action or to alert the user. If we need to add a link to Settings for configuration, banner isn't suitable then. I would suggest using a confirmation windows instead.
Flags: needinfo?(hhsu)
A modal confirmation window seems like a worse UX flow than not having a confirmation window.  Also, we are going to use the same general idiom for inline display of errors in the background mail sending bug, so perhaps we should just formalize this as a building block?

Also, modal confirmation window-wise, it's not clear if the proposal would then be to put a hyperlink to the settings app in the confirmation window (which seems weird/I don't think we've done), or to make the confirmation window have the two buttons be "go back/close this" and "bring me to settings".  While being offline is the type of thing that it makes sense to strongly guide the user to turn on their internet, most of our other errors are likely to be of the typo variety where the introduction of a modal dialog adds another click and inline error display seems more appropriate.

Also, it's not clear what probabilities we are assigning to:
1) the user being offline by having manually disabled their internet connections. In this case, swiping down to bring the tray down is probably the most efficient way to re-enable internet since it provides affordances for toggling both mobile data and wi-fi.
2) the case where the user is offline through no action of their own and so there is no action that can be taken
3) wi-fi is on, but the user needs to select a (different) wi-fi access point.  I think this is the case that the settings link is most likely to be useful for.  This is a deficiency of the current UX for the wi-fi icon in the system tray since the non-intuitive trick is that you need to toggle wi-fi off and then on again to get the settings app to show up and bring you directly to the wi-fi menu.

In terms of linking into the settings app, I think our general goal is to avoid explicit paths.  I think the best way to handle that would be to create a generic "I need data / you are offline" web activity.  The first baby step implementation would have the settings app provide this by just dumping the user in the wi-fi menu and ignoring the possibility that it's mobile data that needs to be turned on.  The long-term fix would be to have that trigger a bit of a wizard that could present the immediate options as well as other options.  If you don't have a SIM card, note that and don't provide mobile data.   If you're in airplane mode, mention that, but don't offer to try and turn mobile data on while airplane mode is on.  Do offer to turn on wi-fi, etc.
Flags: needinfo?(jhuang)
We do use "toast" for the error cases in email app. Yet the bug is more like talking about a general "offline" situation, this will not only happen in email, but also calendar, browser & importing contact from social network.

I suggest we consider this bug as a building-block level bug and pop out a confirmation window that display the offline status along with a "Settings" to go to setting app, a "OK" to cancel the window. 

The reason I don't recommend "toast" as the generic UI is because offline UI needs actions if we want to bring users to settings app. Most of the toast cases have no action (except for "Undo") since they are more like a gentle reminder which is no need for urgent actions that require users to do. 

However, we got various of circumstances that cause offline status, just like what Andrew mentioned above. We probably need to list down all the offline cases to see what message we should provide for users. And I'm not too much worry about dumping users in an unknown view if we lead them to the first page of settings app instead.
Flags: needinfo?(jhuang)
Firefox OS is not being worked on
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.