Break up options in a drop down by scope

Question

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.

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

^{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.

Answer 1

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.

Answer 2

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?