Zeichick's Take: Remember CUA Compliance? Microsoft Doesn't
January 4, 2007 —
(Page 1 of 2)
Twenty years ago, when DOS ruled the desktop, IBM released a series of specifications called Common User Access. CUA defined principles of text-based user interfaces, and was key to making early PC applications friendly and consistent to use.
Unfortunately, I can't lay my hands on the original IBM CUA book, but it defined many critical aspects of user interface design, such as the use of the File and Edit menus at the top of the application screen, the behavior of radio buttons and check boxes, and the use of Tab and Alt-Tab to move within a window. Thanks to CUA, you could always quit an application by selecting the File menu with the pointing device or with Alt-F, for example, and then press X or click Exit. Or, you could use Alt-F4 to do the same thing.
Future revisions of the CUA guidelines were extended to cover advanced graphical user interfaces, like OS/2 Presentation Manager and Windows 3.1. One of the guiding rules of CUA was that the user should never see a blank screen; that's why Windows 95 brought out the famous Start button.
Many of the operating systems we use today, including Windows XP, Linux and Unix, are CUA-compliant. (Mac OS X follows a different metaphor; Apple's never been CUA-compliant.) Most non-Apple applications we use are also CUA-compliant: Microsoft Office and Internet Explorer, Firefox and so on.
While many developers chafed under CUA's strict limitations, the guidelines had a purpose: They meant that a user could sit down at a strange computer, or a new application, and instantly know how to use its user interface. Perhaps users wouldn't know how to work the program logic, but they'd know that Alt-F4 would get 'em out of the application, F1 would call up help, and that if you selected one radio button in a clustered group, the other radio buttons would be deselected. That right there was a huge boon to usability and training, and reduced frustration and "code rage."