Excuse my ramblings.

Here’s a common mistake.

Say I’m building a client/server application. In attempting to understand the problem set I first design the back-end database layout, the data flow between systems, and the transformations (procedures, program statements) which perform the tasks that I need to use to achieve my system design.

The transformations then are mapped onto UI elements, so that the user can trigger these transformations by pressing a button or selecting a menu bar item, with the inputs and outputs of these transformations displayed in tables or custom views.

And we can call it a day, right?

Dear God, NO!!!

Of course you still need to design the back-end of the system, and how the data flows within the system. But users are not computer programs: most of us don’t think in terms of a sea of transformations that may apply against different data sets that can or cannot be grouped into larger transformation operations.

We think in terms of nouns, verbs and adjectives.

And user interfaces–at least when they’re done right–are not built in terms of transformation operations, but built in terms of the “parts of speech” that we understand, with the suitable “verbs” presenting themselves alongside the “nouns”.

I’m arguing for a deconstructionist perspective of design here: your interface will probably break down into a hierarchy of objects. In this hierarchy of objects you can discover the sub-objects and components which make up that object through “disclosure”: for example, double-clicking on a thing to open it, or pressing the disclosure button to reveal the sub-items in a list of items.

Actions that are appropriate to that object should be discoverable as close to that object as possible. The “verbs” (transformations) suitable for that object or it’s contained objects can be shown by updating a menu bar or having a small set of buttons associated with that item: in a sense, it’s a matter of balancing the atheistic of a minimal design with the need for discoverability: both work in favor of the user–with minimalism de-cluttering the screen from useless information, and discoverability showing the user (with subtle hints) how to perform an operation.

By associating the verbs with the nouns–the legal transformations with the objects they transform–we immediately move commands out of a global menu bar (where it’s unclear what may apply and why) and moving them with the objects that they operate on.

I like the [Edit] button on the iPhone and on the Address Book on the Macintosh: it helps balance the need of discoverability (how do I edit an entry? Hit the edit button) with minimalism (there isn’t a thousand edit boxes and icons on my main display confusing me). It adds a click to changing a record, of course–but the flip side is that this one click–this one moment in the user’s life–immediately makes it obvious what to do and how.

I also am starting to resent menu bars in general. In a perfect world they are the common verbs applicable to all (or almost all) nouns in the noun space of the application. But unfortunately most UI programmers use them as a dumping ground for noun-specific transformations, leaving the user to wonder why there are these twelve things that are always disabled. Most applications work with a menu bar because most applications operate on a very small uniform set of nouns. But with a more complex noun-space things become very messy very quickly.

It’s also why I’m very picky about the wording of menu items and the descriptions of objects in the documentation. Menu items should always be verbs: “Cut”, “Copy”, “Paste”, “Clear”, “Open”, “Close”, “Quit” are all direct verbs: “I copy this icon”, “I quit this application.” There are places where this is violated, and it sort of bothers me: in Safari the menu “User Agent” should in my opinion be “Set User Agent” (dropping the implied “to”). Of course sometimes the implied verb may be dropped, but I’ve never been quite comfortable with that: I’d rather have a sub-menu with a list of nouns buried under a menu item with the verb–using the submenu noun list as a modifier for the verb. (So: “Open >” pointing to a list of previous files, rather than a list of previous files.)

Of course, the idea is not to be strict about this–but to be clear: a new user should know if he selects a file it will open. Microsoft broke the contract of menu items as verbs with it’s quick open list in the File menu, and we’ve adopted it even though it’s bad UI design. But now everyone knows that “Open” is an implied verb, as is “Set”. *meh*

Overall I think the design of an application should be done both from the bottom up (data structures, then transformations, then presentation) as well as from the top down (user interface, then nouns and verbs, then map onto data structures and transformations). If we were to practice better design–and part of that is understanding the taxonomy of the nouns and verbs we are presenting to end-users–we could make user’s lives much easier.

And, as Apple has shown repeatedly with it’s Macintosh systems, iPhones and iPods, users will happily pay lots of serious money for systems which they perceive as easy to use.