Things exist while action happens.
Therefore (for GUIs):
Put lists of things (nouns) in a list pane (one of Few Panes) which persists through interactions.
Put actions (verbs) in Short Menus which pop-up and then disappear as the action commences.
For example:
The one time our domain specialists had trouble satisfying this pattern was for a menu they thought should include...
Decimal
Octal
Hex
We recognized that they were in fact thinking of the menu options as actions and suggested that they rename them...
Be Decimal
Be Octal
Be Hex
Therefore (for Object Oriented Programming):
Give classes "noun" names.
Base classes should have general, simple names. E.g.:
"List"
"Stream"
"Web"
Subclasses should have specific, adjective-noun names. E.g.:
"SortedList"
"FileStream", "NetworkStream", etc.
"IntranetWeb"
Give methods "verb" names. ("isHappy", "becomeHappy", ...)
(See Smalltalk Best Practice Patterns for more details.)
Exceptions to this rule:
(I can't think of any that justify the inconsistency. Can you?)
In the menu example at top, wouldn't the options Dec, Oct, Hex actually be a radio-button group that "just happens" to be nested in a menu?
If this were the case (as in several calculator apps I've seen), Decimal, Octal, Hex would be nouns that the user chooses from a list.
Trying to combine the thoughts above... if the choices displayed as radio buttons were prefaced by a verb, I think that would satisfy all requirements. For example, "Display as:" followed by radio buttons labeled as Decimal, Octal, and Hex.
I think the first paragraph so badly misstates the noun-verb/object-message relationship to menus that I'd like to try a different wording here, and then encourage others to replace the original if they agree.
Therefore (for GUIs):
Put things (nouns) on the desktop and allow them to be "selected".
Put actions (verbs) that apply to the selected item(s) in Short Menus that pop-up and then disappear as the action commences.
Sort the Short Menus from left to right in a Menu Bar from most-stable to most-dynamic. This usually corresponds to most-general to most-specific.
If a button, mnemonic, keyboard shortcut, and so on, is available, be sure it corresponds to exactly one currently-visible menu selection. If the menu selection is disabled, so should its alternative be.
Please note that this approach (shamelessly stolen from the Macintosh user interface guidelines of 1984) moots the Decimal/Octal/Hex example; every menu item should be a verb, applied to whatever the selection (noun) is.
The "Decimal/Octal/Hex" menu is generally presented as a "Format" menu, with the three choices listed and a checkmark placed next to the most-recently selected choice. The radio-button logic can be used to turn the checkmark on and off. A "Format menu" is a good example of a menu that changes dynamically; it should always appear as "Format" in its menu bar, but the "Decimal/Octal/Hex" choices only appear when the selection is a number for which they make sense. A non-numeric selection would end up with totally different choices.
See original on c2.com 