How to extend the noun-verb paradigm to multiple nouns

Question

Schemes used to command computers usually rely on noun-verb combinations or verb-noun combinations. For instance typical file managers use noun-verb combinations: if you want to remove a file, you first select the file in some manner and then issue the verb with a contextual menu to complete and validate the command. A verb-noun system file manager would offer an other kind of interaction, where you first inform the system, you want to delete some file and then complete the command with the particulair file you want to delete.

Jef Raskin's Humane Interface recommends to favour noun-verb combinations over verb-noun combinations in user interfaces—this is because selecting a verb usually introduces a mode but selecting a noun usually does not. I would like to know how to deal with verbs needing several nouns to produce a complete command.

A popular example of user interface making extensive use of verbs needing several nouns to produce complete commands is the UNIX shell (considered as a user interface and not as a programming language). Incidentally, the UNIX shell is verb-noun based, but I think that Jef Raskin's advise merely concerns graphical user interfaces.

I thought of the following possibilities to implement user interfaces allowing verbs needing several nouns in noun-verb interfaces:

1. Turn the noun combination required by the verb into a noun itself. It has the drawback that it artificially increases the number of different types of nouns the user and the developer has to deal with. This is a lot of work, because it increases the number of concepts and dialogs in the application.

2. Introduce a generic concept of multiple selection and the corresponding application artefacts (like an inspector, a manager, etc.) and allow verbs act on such selections. This introduces only a new noun multiple selection but only works if the items in the selection are distinguished, so that they are easily understood by the user and identified by the verb.

3. Represent a verb by an object having slots that can be connected to nouns and add a „commit“ button. This is reminiscent of formular posting interaction.

What is the correct way to represent (multiple nouns)-verb actions in a graphical user interface? Does it belongs to the list above or does it lie somewhere else?

Answer 1

It’s Not Really Nouns and Verbs

Most commands have more than simply a noun and verb. They have a noun (or object), a verb (or action on the object), and parameters (details on how to do the action). For example, in Unix, “cp tsplan /usr/snowden” copies (action) the file tsplan (object) to the /usr/snowden directory (parameter). The parameter may be a “noun” (like a directory), but it’s not the same as the object –it’s not the thing the action happens on. It’s how the action does what it’ll do to the object. Furthermore, a parameter could be an “adjective” or “adverb” for the action (like the -s switch in cp, which makes a symbolic link rather actually duplicating the file). So when I type “cp tsplan /usr/snowden -s,” I’m not typing multiple objects, but I am typing multiple parameters.

Depending on how the user executes the command, the object, action, or parameters can be defaulted. For example, for cp, the default is to duplicate the file, rather than make a symbolic link. In a GUI, when you double click a document, the action (open) and the parameter (program in which to open the document) are defaulted.

Multiple Nouns as Objects

So to your question: What if there are multiple nouns? Well, are the nouns multiple objects or are at least some parameters for the action? If they are all objects the same action acts on (e.g., copy all these files; group all these shapes together), then multi-selection (your Option 2) is a commonly used and relatively well-understood approach. It’s analgous to using wildcards in Unix (e.g., cp /usr/alexander/* /usr/snowden).

Some users often have trouble with ctrl-click, shift-click, and even drag-selection, but the problem there isn’t the concept of multi-selection, but the concept of using rather arbitrary modifier keys. If your users usually do commands on multiple objects, you can make a simple click do a persistent selection like ctrl-click normally does. In that case, your app probably should provide graphic design signals that click works differently than usual.

Nouns as Parameters

Usually the syntax is object-action-parameter. Here’re common GUI examples:

• The user drags an object to a noun to associate the object with the noun (e.g., move a selected document to a different folder).

• The user selects an object, then selects and drags a visible “handle” on the object to “tie” it to a noun (e.g., create a many-to-one link from one database table to another).

• The user selects an object, selects an action from a pulldown menu, and gets a dialog box to specify a noun parameter(s) (e.g., print a selected document on a particular printer).

But you can also have object-parameter-action. For example, when you right-click-and-drag a document to a folder in MS Windows, you give the object (the document), then the parameters (the folder), and then the action (move, copy, create shortcut).

How you can do it is really only limited by your imagination. There is no one right way, and you can have multiple ways in the same application. Don’t worry about inconsistency –users don’t think at this level of abstraction so won’t even notice that sometimes it’s object-parameter-action and other times it’s object-action-parameter. As far as the users concerned, there are just different ways of making a command. That’s more to learn, but multiple object-action-parameter methods would be just as challenging. Having multiple methods makes for a richer, more flexible, and more efficient UI. If it’s a complex app used frequently by the users, it’ll be worth it.

What Really Matters

What’s most important is following basic UI design principles, such as minimizing modes. For example if you implement the third bullet above with a modal dialogue box, then you’re introducing a strong mode even though the syntax is object-action. On the other hand, your Option 3 is a potentially good solution even though it’s probably action-object not object-action: in order for the UI to know what “slots” to provide the user, the user will probably have to specify the action first. However, if you show the slots in a modeless window or pane, then you’re minimizing the “modiness.” Add such niceties as the ability to drag nouns into slots from other places (in addition to typing them in), plus the ability to name, save, edit, copy, and re-run the set-up for the command-object, and you’ve provided users with an efficient and powerful means to manage complex commands.

The distinction between verb-noun and noun-verb is an artifact of the metaphors used to make commands. Verb-noun falls out of a verbal metaphor while noun-verb falls out of a physical metaphor. With the verbal metaphor, the UI is an agent that the user orders. With the physical metaphor, the UI is a set of objects the user directly manipulates. Neither metaphor is inherently better than the other, and the two can (and do) co-exist in the same UI. We stifle our creativity if we try to restrict ourselves to a single metaphor. For more, see Delivery Spectrum.

Answer 2

Option 3, the expansion of the grammar from verb-noun to verb-noun1-noun2-...-nounN, is the only one that works for me. It is similar to Option 2, but I have concerns whether the system can understand a noun-list. Additionally, some users may find the GUI confusing if there is not a sufficient amount of direction for them.

Option 3' formulas reduce the ambiguity of each noun and does become similar to the shell / command prompt mental model that some users may be familiar with. Basically, you would be creating a graphical version of shell commands, which sounds reasonable. Once the verb or action is selected, the other fields can be prompted with examples, even if they are optional.