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

Status: RESOLVED WORKSFORME

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

Description

[Dietrich Ayala (:dietrich)]

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.

Comment 1

[[e-mail]]

Need UX confirm

Comment 2

[Stephany Wilkes]

I am flagging Patryk on visual refresh, to see if any of this will be addressed and when.

Comment 3

[Patryk Adamczyk [:patryk] UX]

+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.

Comment 4

[Harly Hsu[:harly]]

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

Comment 5

[[e-mail]]

Harly,

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

* [back][done] Sound -> Ringer
* [back][done] Sound -> Alerts

Comment 6

[Harly Hsu[:harly]]

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.

Comment 7

[[e-mail]]

I guess we have fixed them. @Tina could you help double confirm it?

Comment 8

[Tina Hsieh[:Tina_Hsieh] UX]

It looks good to me. I think you guys already fixed it.

Comment 9

[[e-mail]]

Thanks

Comment 10

[Dietrich Ayala (:dietrich)]

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.

Comment 11

[Tina Hsieh[:Tina_Hsieh] UX]

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.