Many possible responses to content

Question

I have an Event page, to which a viewer can have many possible responses (not mutually exclusive): accept, decline, nominate someone, propose a new time line, thinking about it, email host etc.

I think putting a lot of buttons at the bottom of the page make the page very cluttered. What should I do in this situation?

I am thinking of creating a left-side bar with multiple buttons. But this is a little bit unorthodox. What are my options and what would be popular solution for this situation?

Below is a sketch for my event page. (Sorry I don't have enough reputation to upload images yet).

________________________[Account][Setting][Nav_bar_items]

[Left side bar       ]          Event
[Accept                ]          location: Starbucks
[Decline                ]
[Send a message ]          Time: 10 AM Sunday, Nov 11, 2011
[Change time        ]          Duration: 20'
[Change location   ]
[Refer someone     ]
[Change channel    ]

Answer 1

Several options are available, which may be combined.

Spatial Grouping

From a usability perspective, a large number of commands can be scanned reasonably fast if you group your controls. You don’t even have to label the groups necessarily. Just bunch them together in twos, threes, and fours by similarity, maybe:

[Accept] [Considering It] – [Alt Time] [Alt Location] [Alt Channel] [Decline] – [Nominate] [Email Host]

(Not necessarily using the same captions I'm using)

If all your buttons fit in one row, this may be all you need to do. If some of your commands both execute an action and close the window, group them on the bottom to signify this (they’re the last thing the user does), while grouping other commands elsewhere.

Toolbar

If none of your commands (other than Close) dismiss the window, then maybe you have a primary window rather than a dialog box. That would be consistent with users conducting multiple commands on the same Event. If that’s so, then putt all your commands at the top of the window in a toolbar, which is the standard for primary windows. Use text labels rather than icons so you don’t sacrifice clarity. You can still spatially group the command for easy scanability. The main difference from the previous option is that toolbar with multiple commands looks less cluttering than a whole bunch of command buttons.

Dropdowns

If some commands are rarely used, then employ pulldown menus, split buttons, menu buttons, and/or a menu bank, and stash the rare commands under their respective dropdowns. This will help the user focus attention on the commands they most likely want, reducing clutter effects. Dropdowns should be necessary only if you have 10 or more commands.

Sidebar

A sidebar menu may be unusual for a desktop app, but it’s common for web apps and sites. If your users are used to the web, I don’t see why you can’t at least try this option.

Parameters, Not Commands

It occurs to me that in your particular case, maybe you don’t want commands at all. Maybe your only command is Send Response, and what the user is really doing is specifying what to send. Maybe a Decline (vs. Accept) radio button enables controls to optionally propose new time, location, and channel. A Nominate check box enables a field to refer someone. An empty multiline text box (possibly under an expander) allows a free-form message to be sent to the host. This eliminates the large number of buttons, keeps the window consistent with dialog box standards, and better guides the user through the task flow.

Answer 2

There's a few different things that can be done.

1. Merge some actions together to reduce the total number of items. For example, could you merge Change Time and Change Location into a simpler "Edit Details"?

2. Present the actions as links rather than buttons, especially the more minor actions. A vertical list of links is much less imposing than a list of buttons.

3. If you have a big list of links, try to arrange them into groups. If the groups are big enough you could apply group labels; if the groups are small (like 3-5 items) then just differentiate the groups by spacing them out.

4. Figure out what would be the most likely primary actions, and make those into buttons. In your example, I'd possibly make the Accept action into a big button, and leave the rest as links.

5. If you have a lot of related functions of which one is clearly the most common and can also stand in as an exemplar, consider using a split-button aka mutton (not to be confused with mutton-button).

Answer 3

It depends how many functions you have and how easily they can be organized. Typically, large numbers of options are tolerable if they're well organized, easily differentiated and can be found reasonably quickly.

Difficult to say more without seeing your current application (or a wireframe) and knowing what functionality you want to grant the dialog, and knowing (from your use-cases) what your users' priorities are.