4 There is such thing as modeless dialogs, you know.
source | link

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 I believemaybe 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.

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 I believe 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.

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.

3 Less space hogging
source | link

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 I believe 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.

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 I believe 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 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.

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 I believe 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.

2 Simplify design
source | link

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] – [Propose Alternative][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 I believe 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 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.

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] – [Propose Alternative] [Decline] – [Nominate] [Email Host]

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 I believe 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.

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 I believe 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 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.

1
source | link