Nick, There are several rows on the page. There's no clear majority or minority of locked/unlocked states, and in fact, there's an option menu to lock or unlock all of them.
There's no word "locked", just the usual padlock icon. There's not enough space for that. The text is only on the context menu. But interpreting your remarks assuming there were room, I agree, even if it isn't a clear majority, "unlocked" would do more to obscure than clarify in that case. As for the "press-and-hold" aspect -- tapping works. I think I should make it more button-like, however. But you've given me an idea. Currently, the unlocked icon is only there to make it clear where to click to lock it. I also designed the icon to blend into the background, so the more notable "locked" state stands out. I have a second icon there as well that denotes one of several states independent of the lock. The context menu applies to them all. Actually, it would apply to the entire row, but there are other usability issues with long presses in that area, and I ended up having to disable it there. I'm thinking that putting a sort of "icon tray" behind these individual icons might help communicate that the long press is available over the entire tray -- including the non-toggling icon, even when that icon is absent. That is, it lets me present the larger target for the long press. Normally, I wouldn't overload things this way. I thought about changing it for landscape mode, but that would give me two UI's which would be a worse problem. I'm also thinking about making it be a subscreen (drill-down) rather than a context menu. It would still have the same active content, but would give me a bit more control over presentation. Best of all, it would be discoverable. Thanks, (Mark, too) for getting me to think about that aspect again). I seem to be getting broader useful input here (by implication) than I was shooting for. I'm glad I thought to ask. Thanks, guys! On Feb 26, 2:34 pm, "Nick Owens" <[email protected]> wrote: > Bob: > > So you have several rows on the page? Options, records, items, whatever > they are. To follow w/ typical usability, the minority state should be > shown next to the record and the majority (more frequent) state should be > removed, as it will be assumed. > > As for indicating to the user that a long-click brings up a context menu, > that's a separate issue altogether and the word "Unlocked" doesn't help > either unless it says "Unlocked (press+hold to change)". > > Thanks, > Nick Owens > VP, ThreeClix > Office: (904) 429-7039 > Mobile: (847) 565-9392 > After Hours: (904) 540-5830 > > > > -----Original Message----- > From: [email protected] > > [mailto:[email protected]] On Behalf Of Bob Kerns > Sent: Friday, February 26, 2010 5:29 PM > To: Android Developers > Subject: [android-developers] Re: Usability: State vs Verb > > ?Huh? You're saying my menu option should be BLANK except for the > checkbox if not locked??? > > I'm sure I'm misreading you. > > I do get your point about "present the state on the screen and the > actions in the context". That's a nice statement of the argument for > presenting the menu as a verb. > > And I'm inclined to agree. It just feels like going against the > platform, and I'd like to understand why and when it's appropriate. I > do value consistency in UI. > > On Feb 26, 2:16 pm, "Nick Owens" <[email protected]> wrote: > > Bob: > > > The text next to the option should say "Locked" if locked and nothing if > > otherwise. A long-click should bring up the appropriate option for "Lock" > > or "Unlock", depending on the current state. Only one options needs to be > > presented. Present the state on the screen and the actions in the context > - > > in my experience, that has the most consistency across all software. > > > I think you're too deep into the analysis on this one and need to take a > > step back - sometimes that happens when we stare at something too long. > > > Thanks, > > Nick Owens > > VP, ThreeClix > > Office: (904) 429-7039 > > Mobile: (847) 565-9392 > > After Hours: (904) 540-5830 > > > -----Original Message----- > > From: [email protected] > > > [mailto:[email protected]] On Behalf Of Bob Kerns > > Sent: Friday, February 26, 2010 5:11 PM > > To: Android Developers > > Subject: [android-developers] Usability: State vs Verb > > > My business partner and I have a small disagreement, and I'm trying to > > figure out the best way to resolve it. > > > First, I should say I started out his way, and switched after > > reviewing a lot of applications. > > > The background is this -- we have an app, with some controls which can > > be locked. A lock/unlock icon is put next to the lockable controls. > > You can long-click the icon, and it brings up a context menu with > > several items, including the item for the lock state. > > > Currently, it brings up a "Locked [X]" or "Locked [ ]" item -- that > > is, a menu item with a checkbox that can be checked or unchecked, and > > the lock state is changed accordingly. > > > He would like me to change it to reflect the action being taken. I.e. > > the menu item would say "Lock" if it is currently unlocked, and > > "Unlock" if it is currently locked. > > > It would be acting as a toggle in either case; the only difference is > > how it is presented to the user. > > > I see arguments both ways: > > > * Consistency with platform standards suggests the checkbox. > > * This feels more active than the usual "change the state of a > > preference flag". > > > Locking has implications beyond this application -- and is a major > > motivation for the application, in fact. > > > Note that both he and I independently thought at first glance it > > should be 'Lock/Unlock'. I need to weigh this apparent intuition > > against platform-wide practice and user expectations. > > > Does anyone have any thoughts or opinions? Or alternatives I perhaps > > haven't considered? > > > Thanks. > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
