Things exist while action happens.

----

'''Therefore (for GUIs)''':

	* Put lists of things (nouns) in a list pane (one of FewPanes) which persists through interactions.
	* Put actions (verbs) in ShortMenus 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 ObjectOrientedProgramming)''':

	* 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.:
			* "Sorted''''''List"
			* "File''''''Stream", "Network''''''Stream", etc.
			* "Intranet''''''Web"
	* Give methods "verb" names. ("isHappy", "becomeHappy", ...)

(See SmalltalkBestPracticePatterns 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 ShortMenus that pop-up and then disappear as the action commences.
	* Sort the ShortMenus from left to right in a MenuBar 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.

----
CategoryPattern CategoryGui