Buttons Typically displayed directly in UI, grouped semantically Large, obvious and easy to use. Space consumption can be an issue. Menu Bars Typical on most desktop applications, show a complete set of actions, commonly organized (File, Edit, View) Actions can be global or contextual (operate on individually selected items) Often duplicate functionality in context menus or toolbars because they are accessible, can be reached through accelerators, etc Toolbars Long, thin row of iconic buttons. Often contain other types of controls (dropdowns, comboboxes, etc) Work best when icons can describe the action as well as the action name

Popup Menus Also know as context menus, invoked through right clicking Typically show a list of context specific actions, short in number Dropdown Menus Raise menus by clicking on a dropdown control such as a combo box or button Not also great for actions since these controls often represent state Links Used in web pages and many applications now Unlined clickable text Action Panels Also known as task panes, show a list or menu of actions persistently Often used when it’s better to describe the actions contextually than visually

Open this item Perform default action for this item Double-Clicking Items Short Cuts (Control + S = save) Accelerators (Alt key then underlined letter) Keyboard Actions Move this here Perform some action on item Drag-and-drop

User interface patterns to present actions

Present related actions in a small cluster of buttons Can be aligned horizontally or vertically Create several groups if more than 3 or 4 actions exist Best used when you have a set of actions (small number) that have complimentary effects and many other actions and commands do not exist in the close proximity Paradigm is very easy to use and understand, promotes the actions as primary user interface objects through gestalt grouping and alignment for strong visual hierarchy

Use a persistent panel to display a list of actions instead of using menus Organization, Layout and verbiage can be rich in content Best used when you have too many actions for a button group, or you want a group of actions to be prominent and obvious in the screen It may also be well used when the list of actions is too complex for a menu (standard or contextual) Paradigm is visually attractive and user friendly, however it can be difficult to use as it occupies a large amount of screen real estate Somewhat obsolete in the MS Office Fluent UI ™ paradigm Consider usage in conjunction with the “center stage” and “moveable panel” patterns discussed in visual hierarchy lectures

Place a button that finishes a transaction at the end of a visual flow Make the button large, obvious and well labeled Best used when you need a Done, Submit, Ok, etc button that should be visual prominent because it’s the final step of a transaction When labeling lean towards text rather than icons alone Place the button where the user would expect it, typically after the last input field. Often this action is keybound to the Return or Enter key, this lets the user quickly execute the action without moving focus from the current field The button here often creates good “diagonal balance” in the interface creating good visual flow

Change menu labels dynamically to show the user exactly what would happen when invoked Best used when the user interface has menu items that may behave slightly differently depending on context or selected item Ideally the action is disabled when not item is selected reinforcing the linkage between object and action This pattern can technically work for any button, link or action control that contains verb based action. Its less common due to the text length changes. This pattern encourages “safe exploration” as discussed during user behavior lectures

Show users a preview or summary of what will happen when they perform and action As known as “Live Preview” as coined by Microsoft Best used the user is about to perform some type of heavyweight operation that would have significant effect on task at hand or may cause the user some uneasiness. Give the user a way to commit the changes or easily back out, in the case of live preview this is left click to commit, mouse out to abort This pattern encourages “safe exploration” as discussed during user behavior lectures

Show the user how much progress has been made on a time consuming operation Best used when an operation will interrupt the user interface or run in the background, but will take longer than a second or two Try to show: What’s going on What percentage the operation is complete How much time remains How to cancel the action For multiple action progress it is ideal to show progress on the current action plus the overall progress across all actions

Provide a way to instantly cancel any time consuming operation Should have no side effects Best used any time your application provides operations that may take some time and in turn cause grief for the user This pattern encourages “safe exploration” as discussed during user behavior lectures Ensure that some type of indication is given that the action is actually cancelled, a message, stop in progress indicator, etc, so the user does not repeated try it out of aggravation

Allow the user to easily reverse a series of actions performed by the user Best used any time your application is highly interactive (sometimes even simple) where many commands may be chained together to edit a document, picture, file, etc This pattern encourages “safe exploration” and “incremental construction” discussed during user behavior lectures This also lets the user explore separate work paths quickly without the fear of losing previous work Only changes to the edited object are expected to go on the undo stack, not so much changes to the environment Stack should be items long at a minimum. No more than 12 – 15 is typically needed outside of advanced use cases Undo/Redo are typically keybound to Ctrl+Z and Ctrl+Y respectively “Smart Menu Items” are a good practice to use in Undo/Redo More advanced implementations let the user choose the spot in the stack to revert

Provide a visual record of actions that have been preformed that grows at the user makes commands Best used when your application has a long set of complex actions that can preformed with a GUI or command line Typically provided for more experienced users Often used when the user wants to: Repeat and action or command done earlier Recall the order action were performed Repeat a sequence of operations Keep a log of actions for legal or security reasons Convert a series of a commands into a script, macro or sub-routine

Provide a mechanism that allows you to define a single action composed of a sequence of multiple smaller actions Best used when users need to repeat complex sequences of commands over multiple data sets or objects This implements the pattern “Streamlined Repetition” discussed during user behavior lectures Macros help people work faster, but they also improves efficiency by reducing mistakes, oversights, etc This also aids the concept of “flow”, discussed during user behaviors, whereby the user can keep larger pictures in mind by reducing effort and time on mundane tasks Ideally you’ve also implemented “Command History” functionality so the user can pull past operations for their macro An even more advanced capability is to the let user record macros to define them