Closed Bug 796499 Opened 7 years ago Closed 2 years ago
[settings] apn and mms settings have both "Back" and "OK" buttons
[GitHub issue by autonome on 2012-08-20T20:10:49Z, https://github.com/mozilla-b2g/gaia/issues/3606] Should not have both, right? Also, back should be the standard icon, not a button with "back" text. /cc @jcarpenter @lco
I don't agree that it's not logical to have both the Back and OK button in this screen. The back button acts as cancel (or should be) whilst the OK button persists the settings.
What Jan said in Comment 1. We currently don't auto-save settings.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
We actually *do* auto-save settings throughout the *entire* Settings app except for here! (There might be another screen like apn but I can't find one... there's a lot of surface area in this app) The rest of Settings steadfastly convinces the user that they should make their changes and then hit the back button. Which means back == OK. And then there's APN screen. Which does the opposite. Back == cancel, and OK == save. Nice try engsplaining this one away guys, but I'll ni? UX and see what they have to say ;)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I guess there is a larger question about consistency then. I'm not convinced it always makes sense to auto-save. I suppose it depends on the type of field and function. We do not auto-save for: Sound Ringer Selection Sound Alert Selection Bluetooth Device Naming Hotspot Settings It seems like checkbox-only screens are pretty much the only time we auto-save. I think we should still close this, and perhaps file another bug for consistency, but I'll let UX weigh in :)
Hm, I don't think the problem is about making everything autosave vs mixed. The problem is that it's ambiguous in the current UX whether a change is saved or not saved when you hit back in some places. The consistency issue here is that Back sometimes means back+save and sometimes means back+cancel. Which are opposites. Bluetooth device naming doesn't have this problem: The back button is replaced with an [x] button. So far, the screens that have this issue: * Cellular & Data -> Data Settings * Cellular & Data -> Message Settings * Cellular & Data -> A-GPS Settings * Sound -> Ringer * Sound -> Alerts * Internet Sharing -> Hotspot settings
See also bug 956518 for visual/interaction inconsistencies in this button model across the screens listed above.
Flagging both Neo (on the Settings side, which is critical here) and Casey, for the visual refresh/inconsistency aspects in the linked bug #956518. Let me know who would like to own this going forward.
According new building block design, we are suggesting the follwing rule: 1.Header with only back will save results when tapping back. 2.Header with OK, Done button will not save result when tapping back. 3.Page with editable field should use cancel header instead of back. If any suggestions, please let us know.
Thanks Neo! However, this approach does not resolve the inconsistency that sometimes "back" results in save, and sometimes in "do not save". I think is a real problem (especially in Settings!) because the same button and it's icon have *opposite* meanings, and it's not visually explicit that is the case. In #2, can we also use cancel in place of the back button? This would resolve the ambiguity, and make the action explicit.
Hi Dietrich, I am the UX for the new building blocks design. I think what you've pointed out here does have some inconsistency issue, and the suggestion you provided will certainly solve the issue. I will modify the new building blocks design accordingly. Thanks
supposedly 1.5 BB refresh should solve this issue?
blocking-b2g: --- → 1.5?
Keeping it in backlog.
blocking-b2g: 1.5? → backlog
Whiteboard: [label:settings][label:needsUXinput][label:polish] → [label:settings][label:needsUXinput][label:polish][priority]
Removing flag for Casey since Harly has this.
ux-b2g: --- → 2.2
Whiteboard: [label:settings][label:needsUXinput][label:polish][priority] → [label:settings][label:needsUXinput][label:polish][priority], ux-most-wanted-nov2014
Whiteboard: [label:settings][label:needsUXinput][label:polish][priority], ux-most-wanted-nov2014 → [label:settings][label:needsUXinput][label:polish][priority], ux-most-wanted-nov2014, 2x-uxnom
I want to take this bug up if it's free. If it's assigned to me, can you please tell what all changes need to be done.
Changing ni? request to UX team to clearly describe the solution for this particular screen, so Jalpreet can work on it.
Flags: needinfo?(ghtobz) → needinfo?(firefoxos-ux-bugzilla)
Flagging Jenny to advise, even though I realize this request may not make sense in the current context of "no 2.2" or "new 2.2". Thanks Jenny!
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(jelee)
What changes have to be done?
Hello all, For these cases the issue no longer exists: * Sound -> Ringer * Sound -> Alerts * Internet Sharing -> Hotspot settings For these cases please refer to https://bug1032629.bugzilla.mozilla.org/attachment.cgi?id=8463205 for the header design change that resolves the issue. * Cellular & Data -> Data Settings * Cellular & Data -> Message Settings * Cellular & Data -> A-GPS Settings Thanks!
Ok, Thanks. I will look into these.
I am not able to see the Cellular and Data Settings option in the Settings as I am running firefox OS on the simulator as I don't have a hands-on firefox OS device. Is there any way I can make that setting visible? Thanks!
Hi Jalpreet! You can test through desktop B2G or Mulet, as documented here: https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Different_ways_to_run_Gaia#Using_Gaia_in_Firefox_Mulet
Whiteboard: [label:settings][label:needsUXinput][label:polish][priority], ux-most-wanted-nov2014, 2x-uxnom → [label:settings][label:needsUXinput][priority], 2x-uxnom, uxDebt
Assignee: nobody → firefoxos-ux-bugzilla
ux-b2g: 2.2 → ---
Whiteboard: [label:settings][label:needsUXinput][priority], 2x-uxnom, uxDebt → [label:settings][label:needsUXinput][priority], ux-tracking
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Closed: 6 years ago → 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.