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
Double-Clicking Items
• Open this item
• Perform default action for this item
Keyboard Actions
• Short Cuts (Control + S = save)
• Accelerators (Alt key then underlined letter)
Drag-and-drop
• Move this here
• Perform some action on item
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 10 -12 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