Command
Problem
A functionality must be exposed in to the UI to be perceived by the user as available. The command encapsulates this functionality wrapping.
Principle
Functionality exposure.
Forces
- The level of granularity in commands should be properly adjusted: few and complex commands can lead to a rigid system. On the other side, too many low level commands can make the system at the same time flexible and complex to use.
- Commands are tools in the way to fulfill a user goal in the system. If nobody can remember (or better: trace) what requirement this command satisfies consider if its needed at all and if not: remove it.
Solution
The command will encapsulate the access to the functionality. A command should be unequivocally recognizable: it can be accessed using different styles of interaction & context, however a command should be exposed consistently to allow the user to recognize the different short-cuts to the same functionality.
A command can be seen also in an application, as the minimal unit of change that can be produced in a system. When available, undo functionality can be used to come back to a previous state in case of errors.
Rationale
The command groups functionality in packets and provides a unique name. The user recognize the name, it symbol (e.g. icon or sound) and remembers the functionality associated to.

Figure 1. Microsoft Word™ Bold command
representation in the toolbar.
Examples
Menu items in a menu, items in a palette toolbox or links in a web menu can be examples of commands. A common example can be seen in Office applications like Microsoft Word™. It offer its commands in different alternative ways at the same time. For example, the command for Bold is offered in three ways:
- In the main menu: Format → Font → Font → Bold
- In the toolbar: Format → Bold (Figure 1)
- As an accelerator Key: Ctlr-B (in the English localized version)
Specification
A unique name and optionally: symbols (e.g. icons, sounds, glyphs) will represent the command in the User Interface.
Edit

