Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm working on a social application whose main component we'll call Object. On the Object view there is a drop down that can contain as many as 9 options.

Some of these options impact only a single user's experience and some impact the experience of all users who are members of the Object. For example, if a user selects Mute Object, updates from that Object will not appear in their Overview page, but if they select Close Object, that closes the Object for all users.

There are also some options in the menu that don't have an impact at all, like Object URL which just opens a modal dialog that provides the user with the URL to the Object.

Users sometimes get confused about the scope of the option they select, not realizing that closing it will impact other users' ability to interact with the Object.

It has been proposed that we break up the options somehow, but I'm not sure what the best way to do that is visually. Should there be titles for the sections that bring out the scope? Should there be multiple buttons to open drop downs with options based on scope? Would it be better to re-word the options to indicate their impact (i.e. Mute Object for You and Close Object for all Users)?

We all know that users don't like to read things a lot, so long lists are just not good. Is there any information about how best to present long lists of options when the impact of the options has different scope or no impact at all?

Current menu:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

In parens is the scope of the impact of each option. That is not a part of the actual implementation, just for informational purposes.

EDIT
Examples of what's being considered to differentiate the impact of each option:

mockup

download bmml source

EDIT 2

I've tweaked the menu items a little to obscure away what our actual project is since it is proprietary. The Object view is basically a list of messages and a message entry text area. So, Mark All as Read refers to the messages in the Object and clicking Show System Messages means the view will refresh and system messages will be populated in the view in addition to user-generated messages.

I agree that proper labeling could also fix the issue and if someone here comes up with really excellent ideas for changing the way we label things, I'll accept that. But there are some historical reasons for our wording so some ideas that might be good are just not possible to implement.

share|improve this question
1  
+1 for a clear question to a complicated topic. Do you currently show the list to users with the notes in parenthesis? –  JohnGB Apr 26 '13 at 0:45
    
No, there are no notes about scope in the actual implementation. –  norabora Apr 26 '13 at 15:49
1  
Are the users well aware of the 3 types of options (global, personal, none)? –  rk. Apr 26 '13 at 20:54
1  
Could it be the problem of labeling? For example, does 'Close object' actually mean 'Make object Private'? I believe you should think about how users treat every item in your list before trying to group them. It seems like good labels can solve the problem. –  alexeypegov Apr 27 '13 at 14:08
1  
I've accepted @3nafish's answer because "don't alert the user's to the scope" is the most correct answer to my general question. –  norabora May 1 '13 at 20:39

2 Answers 2

up vote 1 down vote accepted

Don't bother the user with information about the system unless it directly impacts her. She only needs enough of a mental model to understand how things work with regards to her. (See the Design of Everyday Things by Donald A. Norman for more information on users' mental models.) This means that you should only make minor edits to some of the action names rather than listing full information about whom each option impacts.

More specifically:

  • Don't display "none." Most users won't care if clicking "Object URL" or "Download" has no impact upon the underlying representation of the object (or even understand what that means).
  • Don't display redundant information in text.

    • "Make object public" can be assumed to impact all users, so there's no need to add "all."
    • Most users will probably assume that "mark all as read" or "show system messages" will only impact their account as well. (Incidentally "system" will likely not be very clear to most users, especially if this social application has an audience beyond internal technical communication.)
    • Clicking "Language" (which should probably be "change language" for consistency) presumably brings up another form where the user can select a language. You can warn the user there that the change will impact all users, but there's no need to tell them this before they've even decided that "Language" is the option they're looking for

It sounds like your main issue is with vocabulary of "close object" versus "mute object."

For close object:
To me (and you should test with your users to see if they agree) clicking to close something just means closing the current version I've opened. Clicking "delete object" would get rid of it for all users (or if it's just hidden from other users but not removed altogether "make private" or "hide" could express what you mean).

For mute object:
Instead of "Mute Object" you could use "hide updates" or (if space is not a concern) "don't notify me of updates to Object." In his Seductive Interaction Design, Stephen P. Andersen explains that a computer should communicate with users in as human a manner as possible, so it's a good idea to use coherent phrases (and even sentences) whenever doing so makes the information presented clearer.

share|improve this answer
    
Sorry, I guess my inclusion of the scope in the example was confusing. That's not actually included in the design. "Deleting" isn't technically correct either because it can still be re-opened. Hide might work but that could still imply it only impacts the user who selects it but "Hide updates" I like. –  norabora Apr 26 '13 at 15:51
1  
@norabora I thought they might just be displayed in the mockup for clarification. My main point still holds true: you should hide the scope. (You asked if you should show "titles for the sections that bring out the scope" or "drop downs with options based on scope".) The scope shouldn't be displayed to the user for most actions because for most actions the user won't need to think about the scope. Just make minor changes to the labels for the few (two?) where scope matters. –  3nafish Apr 26 '13 at 16:46
    
Oh, ok. I understand your point now. –  norabora Apr 26 '13 at 16:53
1  
@norabora: I still think there's a wording issue, affecting the mental model. How about "Shut down Object"? or at least close down... Also, make sure you make some kind of feedback about it, like a "Closed" sign - I'm not a big fan of confirmation messages, but a shop closed sign in a cartoon or photo and a sure-you-want-to-do-this-yesno in a dialog might help... –  Aadaam Apr 27 '13 at 19:48
    
Yep, we have a dialog for when a user closes the Object and also when they view a closed Object, the UI is different and says that it has been closed. Shut down could work, although I doubt PM would like it. "Hide Updates" is a great suggestion for "Mute" and I'll be recommending that. –  norabora Apr 29 '13 at 15:46

You problem seems to be that you're collecting a number of buttons in the same list that are completely different from each other. Being in a single drop down menu implies a relationship between them that isn't there. Viewing system messages and marking an object as read are so far removed from each other, they should never be part of the same menu.

Usually, buttons are visually connected to the thing they affect. E.g. the power button on my stereo amplifier is on the amplifier itself and just says "I/O". If it were anywhere else (say on my CD player) it would need to be clearly labeled ("amplifier I/O"), but even with labeling it would be totally confusing. Another example: in Reeder (an OSX/iOS RSS reader), each item has its own "mark as read" button, while a list of items also has a separate "mark as read" button. Proper placement prevents any confusion as to what the button will affect.

There are of course user interfaces where the available actions are collected in a single area. Take the menu bar at the top of many Windows applications for instance. You'll notice however, that pretty much all applications are moving away from using such a menu. Primary functionality is offered inside the main UI where appropriate while the many covers all functionality including the less used ones.

In your situation you've got a number of "objects". I don't understand why there is a single menu entry on the "object" that affects so many different and unrelated things. E.g. "Mark All as Read" belongs in a list or master view. Offering it in a detail view is confusing: what is "all" in this context? Also, giving feedback on the effect of selecting this option is impossible if the list of objects it will affect is not visible.

The solution for your problem is not in ordering the options in the menu by their scope, or trying to explain their scope. The solution is in clarifying the scope implicitly by offering functionality together with the things they affect.


Side note: There is a problem with the verb "to close". The action of "opening" something in many applications means the same thing as "viewing" it. The opposite action would merely undo the opening of the object, not make it unavailable for other users. I've had a similar problem in a task lists application, where you can "close" a task (i.e. mark it as resolved). When we started offering the detail view in a popup, the verb "close" became confusing: would clicking it close the popup or the task?

share|improve this answer
    
I've edited my question to address part of this answer. All the actions impact the Object, it's just that some of them impact the Object just for the current user and some impact the Object for all members of the Object, or even all users in the system (i.e. Make Object Public). I agree that "Close" is tricky but no suggestion so far adequately addresses the action. –  norabora Apr 29 '13 at 15:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.