Closed Bug 956518 Opened 6 years ago Closed 4 years ago

button model has inconsistent interaction & visual design in Settings app screens

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: dietrich, Unassigned)

References

Details

Most of Settings app is autosave. But there are a number of screens that have [ok][cancel] pattern (See bug 796499 for fixing the back-button ambiguities there.)

In these screens, there are inconsistent visual implementations of that pattern:


* [back][ok] Cellular & Data -> Data Settings
* [back][ok] Cellular & Data -> Message Settings
* [back][ok] Cellular & Data -> A-GPS Settings
* [back][done] Sound -> Ringer
* [back][done] Sound -> Alerts
* [x][ok] Internet Sharing -> Hotspot settings

And from an interaction standpoint, the Sound items above have the [done] button disabled until a change has been made.
Need UX confirm
Flags: needinfo?(firefoxos-ux-bugzilla)
I am flagging Patryk on visual refresh, to see if any of this will be addressed and when.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(padamczyk)
+Harly
I believe is part of the building blocks scan Harly did. So I'd expect this to be complete by v1.5. He should provide a spec.
Flags: needinfo?(padamczyk) → needinfo?(hhsu)
Currently we are pushing toward two types of header: [<] & [X] [OK]
[<] will save all results automatically when pressing [<], 
and for [X] [OK], press [OK] will save result, and press [X] will not save result.
Thanks
Flags: needinfo?(hhsu)
Harly,

Do you mean the following [<][done] pattern should be changed to [<][ok] pattern?

* [back][done] Sound -> Ringer
* [back][done] Sound -> Alerts
Flags: needinfo?(hhsu)
Hi Fred,
As I mentioned earlier, there would only be two kinds of headers:
1. Header with only back, which will save results automatically when press back
2. Header with cancel and ok/done/save, this will only save result when press ok/done/save. Press cancel will forfeit the modification and go back to previous case.

So for sound, I would say just use header with only back button would be sufficient for this case.
Flags: needinfo?(hhsu)
I guess we have fixed them. @Tina could you help double confirm it?
Flags: needinfo?(thsieh)
It looks good to me. I think you guys already fixed it.
Flags: needinfo?(thsieh)
Thanks
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
This is not fixed.

The problem is not even that they are different text - they are different *models*. Instant-apply vs set/cancel, and sometimes even permutations where you have instant-apply but also a cancel button.

Aside from mixed modes, Harley's recommendation in comment #5 was not implemented - it's currently [x][set].

"The details are not the details; the details make the product." - Charles Eames.
Currently we have two kinds of headers. As we can see that headers in sound settings (Sound, Ringtones, and Alerts) follow the standard headers. 

In Ringtones and Alerts, we would like to let users to have a chance of recovering their setting by tapping the [x]. That's the reason why we designed it as a header with cancel and set.
You need to log in before you can comment on or make changes to this bug.