Closed Bug 818359 Opened 12 years ago Closed 12 years ago

The "Ok" button should be labeled "Close".

Categories

(Firefox OS Graveyard :: Gaia::System, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia::System
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-basecamp:+)

Status:
RESOLVED INVALID
Milestone:
B2G C3 (12dec-1jan)
Project Flags:
blocking-basecamp +

People

(Reporter: iliu, Assigned: rudyl)

References

Details

(Keywords: late-l10n, Whiteboard: UX-P2)

Attachments

(1 file)

Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6819
355 bytes, text/html
timdream
: review+
Details
If there is only one button, it should be labeled "Close". Tapping "OK" is an action that confirm the interaction on the dialog, which doesn't apply to our value selector behavior.
Triage: the "OK" button will confuse user, and against the usual UI pattern of OSes. Read "The behavior of value selector has been changed" thread on dev-gaia.
Should we reuse the "Cancel" label, which was proposed by Sergi in the mail, or just use a new one "Close"? I prefer using "Close", in case "Cancel" would make the user think that this button can revert the selection he made. (For now, if you click on the option, the change would occur right away.) BTW, I found that "Close" string was added in, https://github.com/mozilla-b2g/gaia/pull/6330/files#diff-4
(In reply to Rudy Lu [:rudyl] from comment #2) > Should we reuse the "Cancel" label, which was proposed by Sergi in the mail, > or just use a new one "Close"? > I prefer using "Close", in case "Cancel" would make the user think that this > button can revert the selection he made. > (For now, if you click on the option, the change would occur right away.) Don't use "Cancel" coz the exact reason you'd said. > BTW, I found that "Close" string was added in, > https://github.com/mozilla-b2g/gaia/pull/6330/files#diff-4 Good. Stas, can we reuse it?
Assignee: iliu → rlu
blocking-basecamp: ? → +
Priority: -- → P1
Comment on attachment 688695 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6819 The label has been changed to "Close".
Attachment #688695 - Flags: review?(timdream+bugs)
No problem, we can use the label "Close" instead of "Cancel". What i'm concerned is about the behavior of the button. I mean, in the case of a single value selector, the user should be able to choose an element from the list and, when he does that, the value selector hides again. There's no need to tap any other button to validate the selection. If the user taps the "Close" button the value selector will close without making any change. I think we agree on this. Where i see a problem is in the multiple value selectors, as i've stated before. In this case it's not possible to automatically close the overlay screen when the user makes a selection, because he may be choosing more than one element. So if you propose to use one button in multiple value selectors, which one you suggest to use? Because if we use "Close" it won't be possible for the user to validate his selection, and if we use "Ok" it won't be possible for the user to close the overlay without making any selection.
Sorry guys, the label should be "Cancel". * It's an accurate description of the user's option, whereas "Close" is ambiguous. * It's the standard system-wide nomenclature. Can we please change this back? Thanks!
(In reply to Josh Carpenter [:jcarpenter] from comment #7) > Sorry guys, the label should be "Cancel". Cancel does look like 'Reset the select' to me. Do we really reset the option when the user clicks the button?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #3) > (In reply to Rudy Lu [:rudyl] from comment #2) > > Should we reuse the "Cancel" label, which was proposed by Sergi in the mail, > > or just use a new one "Close"? > > I prefer using "Close", in case "Cancel" would make the user think that this > > button can revert the selection he made. > > (For now, if you click on the option, the change would occur right away.) > > Don't use "Cancel" coz the exact reason you'd said. > > > BTW, I found that "Close" string was added in, > > https://github.com/mozilla-b2g/gaia/pull/6330/files#diff-4 > > Good. Stas, can we reuse it? Yeah, I think we're good to reuse it. Thanks for checking.
> Cancel does look like 'Reset the select' to me. Do we really reset the > option when the user clicks the button? IMHO it's exactly what it does. It completely cancels the process without making any selection.The last option chosen when the user accessed to the selector is the one that remains selected. i.e. the user wants to change the time zone. "Paris" is already selected, so the user clicks the button to change it. The value selector appears showing all the available options: 1. The user doesn't select any element on the list but clicks "Cancel". The value selector disappears and the selected option is still "Paris". 2. The user selects "London" in the value selector. The value selector disappears and the selected option changes to "London"
Sorry for cross-posting, but I would like to give a explanation on why this should be a "Close" label but not the "Cancel" label. See image Josh posted on dev-gaia: https://wiki.mozilla.org/images/5/54/BB_ValueSel_2.jpg Mock-up #1 is doable, however it doesn't quite fit into the Clock use case (user would have to open the selector again and again in order to try out all the ringtones). Mock-up #2 is the previous implementation. It doesn't fit the Clock use case since Clock app will not be able to know the selection without user actually pressing the Select button. The difference between mock-up #1 and the current implementation is that pressing a selection _does not_ close the selector, but give the app a message on what the user has selected. Given the fact this kind of interaction leaves no room for user to change back the selection, the button should be "Close" and not "Cancel". If mock-up #1 is better than the current implementation, we should do that instead. But if we are stick to the current implementation, the button label must be corrected to "Close" (NOT "Cancel"!)
Flags: needinfo?(jcarpenter)
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
Comment on attachment 688695 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6819 r=me, we should land and close this bug first. We can still carry on the discussion on this bug, and spawn bugs for other follow-ups (e.g. if I am really wrong about the label for this implementation, or we decided go to mock-up #1 or revert back to mock-up #2)
Attachment #688695 - Flags: review?(timdream+bugs) → review+
[Cross post from email thread]: Thanks Tim and Rudy. I understand now. In the new implementation: * Pressing an option triggers the change immediately, but does not close the prompt. * The user must press a separate button to close the prompt. You're right then: "Cancel" would be wrong. The user can't cancel a choice. They can only confirm. ...Even if their choice was not the change anything... :) So if we keep this model, we need to use "Close" or "OK". However "Close" is not right, either. It doesn't fit what is actually a positive confirmation button. It is also carries spatial implications of "opening" and "closing", which we deliberately avoid in our value selectors. Spatial metaphors create mental overhead (complexity). People don't need to think about where they are. They just need to quickly change something (or not change something) and hit the happy "OK" button. So let's change to "OK". Thanks!
Flags: needinfo?(jcarpenter)
Summary: [System][Value Selector] The "Ok" button should be labeled "Close". → The "Ok" button should be labeled "Close".
Whiteboard: UX-P2
(In reply to Josh Carpenter [:jcarpenter] from comment #15) > So if we keep this model, we need to use "Close" or "OK". However "Close" is > not right, either. It doesn't fit what is actually a positive confirmation > button. It is also carries spatial implications of "opening" and "closing", > which we deliberately avoid in our value selectors. Spatial metaphors create > mental overhead (complexity). People don't need to think about where they > are. They just need to quickly change something (or not change something) > and hit the happy "OK" button. Alright, I am going to revert the code back to OK.
Thanks Tim!
Are we going to use "Ok" in all cases? i mean, if the case having problems is clock, i don't see the point in changing the button to ok for all cases. Anyway, if that's the solution, let's use the button in gray, not blue.
I have a suggestion that to use "Done" in the case with blue button.
Blue buttons are supposed to indicate main actions when there're at least two buttons. If not the suggested color to be used is gray. I still think using one single button with "ok" and/or "Done" won't work, as users will find it difficult to close the screen without making changes. Let's say you have a ringtone and you access the value selector to check which ones are available. You start testing them, but you prefer to keep the one you had before accessing the value selector. You can't. You have to remember the name of the ringtone, or you have to try until you find it. This seems a very specific scenario, but we will encounter this same use case a lot of times Anyway, i'm sure that's something that will arise when we do user tests.
(In reply to Sergi from comment #21) > Blue buttons are supposed to indicate main actions when there're at least > two buttons. If not the suggested color to be used is gray. > > I still think using one single button with "ok" and/or "Done" won't work, as > users will find it difficult to close the screen without making changes. If you don't select any option, then you could click the single button without any change. The behavior is same with the "Cancel" button. (And I feel more easy and trivial for the behavior personally when I use value selector in iPhone.) > Let's say you have a ringtone and you access the value selector to check > which ones are available. You start testing them, but you prefer to keep the > one you had before accessing the value selector. You can't. You have to > remember the name of the ringtone, or you have to try until you find it. I'm sorry that I cannot understand what you mention trying something until I find it(selected ringtone?). > This seems a very specific scenario, but we will encounter this same use > case a lot of times > > Anyway, i'm sure that's something that will arise when we do user tests. For the comment 6, of course we cannot hide the selector automatically. Because we cannot predict the ending time which are confirmed by user. In this case, I think use "Done" for the single button suitably.
(In reply to Ian Liu [:ianliu] from comment #22) > For the comment 6, of course we cannot hide the selector automatically. > Because we cannot predict the ending time which are confirmed by user. In > this case, I think use "Done" for the single button suitably. We need to use "OK". It's out standard confirmation phrase. Creating an exception in this instance in an attempt to be more accurate would actually increase the complexity for the user who has to interpret this exception to usual label naming. Better to keep it simple. :)
INMHO, we have Mockup 1, Mockup 2 and current implementation, let's say Mockup 1b. Now, our meanings for "Ok", "Close" and "Cancel" are more or less something like: "Ok" --> "I agree and close" "Cancel" --> "I change my mind, revert to a previous state and close" "Close" --> "Anyway, close" In Mockup 1, you open the value selector, choosing one automatically select that value and close so it means something like "Select & Ok" so I think the button should be labeled "Cancel" as it is because your changed your mind and want to "Cancel the selection". In Mockup 2, obviously, yo need "Ok" to confirm your selection and "Cancel" if you change your mind. Here "Cancel" restores the previous value because selecting a value is only a preview, nothing has happened yet. In current implementation, Mockup 1b, we have an hybrid (and, from my point of view, a little weird) behavior because selecting means "Select & Ok but don't Close" and you can not restore the previous state. It has no much sense to say "Ok" because you already agree when changing the value and, if you don't change anything, "Ok" sounds weird because you did not do anything to agree with. I think the correct label is just "Close". Counting with the commentaries of Larissa, I think anyway we are missing a button, if so, we could label them "Cancel" and "Close" but as this pair sounds strange we could simply change "Close" by "Ok" but notice you already agree because selection has been made. My impression is we should not effectively change the value when selecting a value, only by pressing Ok (or with the Mockup 1). If you want a preview for alarm tones, implement your own custom dialog or may be introduce a new event, something like `previewchange` but this look rare again.
The problem with current implementation is subtle but you can see how this behaves: 1- Open settings 2- Go to display 3- Tap on value selector for Screen timeout 4- Tap on "never" 5- Tap Ok 6- Tap on value selector for Screen timeout again 7- Tap on "1 minute" 8- Do not do anythin for 1 minute What I expect: the screen is still on because you did not agree yet. The button says "Ok" and I don't tap on Ok yet Current: the screen is turned off because the option is set as soon as the new value is selected.
QA Contact: jshih
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: