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:


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.

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


download bmml source


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.

  • 1
    +1 for a clear question to a complicated topic. Do you currently show the list to users with the notes in parenthesis?
    – JohnGB
    Commented Apr 26, 2013 at 0:45
  • No, there are no notes about scope in the actual implementation.
    – elemjay19
    Commented Apr 26, 2013 at 15:49
  • 1
    Are the users well aware of the 3 types of options (global, personal, none)?
    – rk.
    Commented Apr 26, 2013 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. Commented Apr 27, 2013 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.
    – elemjay19
    Commented May 1, 2013 at 20:39

2 Answers 2


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.

  • 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.
    – elemjay19
    Commented Apr 26, 2013 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. Commented Apr 26, 2013 at 16:46
  • Oh, ok. I understand your point now.
    – elemjay19
    Commented Apr 26, 2013 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
    Commented Apr 27, 2013 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.
    – elemjay19
    Commented Apr 29, 2013 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?

  • 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.
    – elemjay19
    Commented Apr 29, 2013 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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