Gooey, Ooey, Fibbooey
If you look at the user interface approaches to databases and other information systems, you’re liable to see two basic kinds, the form-oriented UI (FBUI) and the object-oriented UI (OOUI). In a FBUI, the data is represented as a collection of labeled text controls such as text boxes and drop down lists, where the text in each control indicates the value of one of the attributes of a database record or other data object. For example, the employees for QuarkMart, the retail seller of isolated quarks, might have a window something like this for viewing and updating customer orders for quarks:
In an OOUI, data objects are represented by icons, typically labeled with some sort of identifier, and sometimes including additional text to represent other attribute values. Different variations on the icon itself may represent an attribute or the class of object, such as an order for a quark versus an anti-quark, as shown below. Making different objects visually distinct on a key attribute can speed searching tasks. Another attribute, typically a category for a data object, may be represented by the “location” of the icon (e.g., the “folder” the icon is in).
Overall, my impression is that FBUIs are more common for database UIs, especially when one includes web apps, for which an OOUI is a challenge to implement. OOUIs, however, are the norm for off-the-shelf information systems such as email, schedulers, and, of course, file managers.
It will come as no surprised that an OOUI is excellent for object-centered UI structures, given by definition it represents objects. FBUI, in contrast, are typical of task-centered structures, with the text controls used to specify the parameters of a step in a task. That’s how Jens Coldewey and Ingolf Küger described it in their 1997 paper (Form-Based User Interfaces – A Pattern Language (in Frank Buschmann, Dirk Riehle (Eds.): Proceedings of the 2nd European Conference on Pattern Languages of Programming; Bad Irsee). The distinction has carried through ever since, and can be seen today in MS Vista’s extensive use of FBUI’s for their “inductive interfaces” that supplement Window’s traditional OOUI.
But a FBUI can be used in an object-centered structured UI. As the name suggests, a “form” itself is an object, a metaphorical representation of a physical artifact, and while it may be used to represent a task step as Coldewey and Küger suggest, there’s no reason it can’t represent a data object such as a database record, like the quark order record shown above. (I can also imagine an OOUI used for a task-centered structure, but it would be a little weird).
Using a FBUI to represent an object provides plenty of real estate for a large number of object attributes to be displayed, giving FBUIs a major advantage for showing complex many-attribute objects. However, only one record is available in a given window or pane. To see another one, typically the user has to open another window, assuming the designer thought to let them do that.
In contrast, an OOUI is ideal for showing many objects all in the same window, whether as a list view, tabular grid, tiles, or free-form layout. With the window space used for multiple objects, there is less space to show the attributes of each object, and typically, the number of attributes shown per object is few, sometimes limited to just the object’s identifier. An OOUI is thus preferred for tasks involving searching for an object among many objects. FBUI is preferred for a task involving searching for an attribute among many attributes.
There are also differences in interaction. For a FBUI, the user directly edits the text controls to manipulate individual attributes. The number of attributes that may be edited is only limited by the (vast) number of attributes displayed. Even if an attribute is read-only, access is still available to allow the user to copy the attribute text in whole or part. (If you don’t do it already, you should always make the contents of your read-only fields selectable and copy-able even if you can’t think of why a user would want that; I could’ve saved a lot of time the other day if I could have copied the statistics from MS Word’s Word Count dialog box, rather than transcribe them). Actions on an entire data object however, are relatively limited, being typically accomplished through buttons or links (ack!) built into the form. Usually this limits actions to only one object at a time –the one that is displayed in the form.
OOUI, in contrast follow an object selection-action model. The user selects the icon or icons of the objects to act on, then selects a button or, more often, a menu item or toolbar control to execute the action. Dragging and dropping is also typically supported for actions such as copying and “moving” (re-categorizing) the data object. With multi-selection, a single action command can be applied to multiple objects at once. On the other hand, the number of attributes available for manipulation is limited. Typically only one attribute is represented as the “location” of the object. Other attributes may be displayed, both in the icon imagery and as text in some form of a table layout, but editing or even just copying one of attribute values is awkward if it’s possible at all.
Thus an FBUI is preferred for task where the user needs to manipulate many attributes for one object at a time, while an OOUI is preferred where the user needs to manipulate many objects for one attribute.
The choice of a FBUI vs. OOUI applies to individual windows, or sometimes individual panes within a window. A given application may have several windows of each type. For example, there may be an OOUI window to present multiple objects for object-wise tasks, but a FBUI properties dialog box may be opened for any selected object for attribute-wise tasks. As you design your UI you can choose what you want for a window contingent on the needs of the task.
All very neat. You have all you need to know to select a FBUI or OOUI for each window in your next UI design.
Same Coin, Two Sides
Now forget all that because it’s wrong.
The FBUI and OOUI distinction is only an artifact of how we’ve historically designed UI’s. FBUI versus OOUI is a false dichotomy, an artificial limitation we’ve imposed on ourselves. There’s no reason a UI cannot merge both the FBUI and OOUI so that they share the same basic visual design elements and interaction idioms. In the same pane of the same window you can make a representation of data that allows both individual manipulation of attributes and manipulation of objects as a whole. It’s equally happy displaying objects one at time like a form, or many at once in a table-type layout, as well as some more exotic configurations. Such a merging of FBUI and OOUI simplifies UI design, typically cutting down on the number of windows and the length of navigation paths while also promoting greater internal consistency, requiring users to learn less to use the application.
Look at a FBUI. What does it need to be OOUI? Well, if users are going to select one or more objects to be acted on, the first thing you need to do is give the users something to select. Give that form an icon. Similarly, what does an OOUI need to be a FBUI? Well, if users are going to be directly editing multiple attributes, I guess you better make multiple attributes editable. Give that OOUI a bunch of text controls. Once you’ve done that you can see how much the modified FBUI and OOUI are alike. In both, the atomic building block of the UI is an icon for the object adjacent to text controls for its attributes. Such a representation of an object and its attributes is something I call an object image.
More than an Icon
OOUIs already have object images in a sense, but to merge OOUIs with FBUIs, the object image needs to work a little differently than done today. For current OOUIs, clicking anywhere in the object image selects the entire object. This means the only way to allow editing of a text attribute represented within the object image is for the user do something after selection, such as navigate to a FBUI properties window or pane, or select a menu item to put the attribute in “edit” mode. In Windows Explorer, you rename a file by clicking on the name after you select the file, something which apparently has such low discoverability and/or accessibility that Microsoft saw fit to also include a Rename menu item. It’s also just a pain. How often have you tried to rename a file by doing the second click and ended up double-clicking instead, or vice versa? Whichever of these solutions you use to allow editing of attributes, it’ll be slow, cumbersome, and fertile ground for inconsistencies across applications.
Object images should instead work like a FBUI. If you click a text control in an object image for any object, focus moves to the text control irrespective of where the focus was before. The cursor appears within it and the user is ready to edit the attribute. Other controls, such as check boxes, option buttons, and the buttons for drop down lists likewise have this “click through” to the attribute controls
The only way to select the entire object for actions on it is to click the icon; clicking anywhere else doesn’t cut it. Multiple objects are selected through multiple selection of the icons by the usual means, control-clicking, shift clicking, and dragging a rectangle around the desired objects. To drag and drop the object, the user clicks and drags the icon. No other part of the object image may substituted. While icons in current OOUIs are little more than symbolic decoration, I’m suggesting the icon serve as a handle for the object, and have properties and behaviors that are unique to it. As such it should be regarded as more than an icon, more than just a small image label, but a specific kind of control in its own right. Let’s call it an object control.
With the object control, we can give users the ability to select either an attribute or the entire object without putting users through any contortions. There’re no “edit” modes to learn how to get in or out of. There are fewer windows or panes as it becomes unnecessary to have OOUI and FBUI versions for the same data. Interaction is more direct, with changes being effected immediately on the object image.
The menus may also be simplified, with commands overloaded on the selected object’s class. In a typical FBUI, you need to provide specialized command controls to allow your user to duplicate, convert, associated, or delete the data object. These application-specific controls add to the clutter of the UI and the learning load of the user. The UI would be improved by leveraging standardize command controls. By adding an object control, these functions can be handled by the standard copy-and-paste and delete menu items you should already have for handling text attributes. As always, these controls act on the current selection, but now the current selection may be some text inside a text box, or the entire object. For this to work, especially if you’re going to use the Delete key as an accelerator, it must be graphically clear when an object is selected, otherwise the users may, for example, accidentally delete the entire object when they thought they were only clearing a single attribute. When the object is selected, the whole object image should appear selected, not just the object control.
I realize this suggests a certain implementation hurdle. To accomplish a UI like this, you can no longer bind or dump a bunch of records into a single list or grid control. In addition to creating an object control, you have to have a separate control for each attribute to define your object image. Then you need to programmatically replicate the object image however many times it takes to fill the window or show all objects, whichever comes first. That may seem familiar with those of you who have used form developers in desktop DBMSs such as Access or Oracle Forms. What you need to do is reinvent what Access calls a “continuous forms” and what Oracle calls “multi-record forms.” So it’s is not a new idea. Heck, go back to the pre-GUI days and you’ll find Paradox had the same multi-record form concept. For some reason the need for something like this was forgotten when the time came to make many tools for of today’s database user interfaces. We’re long overdue bringing them back.
Layout
Looking at old FBUIs and OOUIs, you may have noticed something different between the two of them besides the presence or absence of icons and editable text attributes: the layout is different. OOUI arrange their objects in an array, usually a vertical stack yielding a tabular layout so that many objects are visible at time. A list is basically a table layout with only one attribute. Tiling can also be seen as a variation on the table theme or at least on the continuous/multi-record form theme. With horizontally scrolling tables, however, there’s not much need for it in database apps.
In contrast to an OOUI, a FBUI typically fills the entire window or pane with a single object. You might think that with object controls and object images behaving as I’ve proposed, the FBUI’s single-object layout is obsolete. In a window 800 to 1024 pixels wide, you can generally fit 10 or more text attributes in a table, all which may be directly editable. With horizontal scrolling you can fit even more. A tabular layout of object images with object controls may seem like the do-everything design, easily supporting manipulation of both multiple objects and multiple attributes, and for many cases it is.
But sometimes you have more than 10 or even 20 attributes. I’ve seen information systems applications with staggering numbers of attributes –too many to fit in a reasonably sized window even when it is laid out like a FBUI; they used tab controls to fit all the attributes. Also, sometimes an attribute is not just a simple date field or number or name. Sometime it’s paragraphs of text, or an entire rich-text document, or a picture, or a video. These “heavy” attributes need space, and lots of it.
It doesn’t make sense to put massive attributes or massive numbers of attributes into a table layout. You need to use the vertical screen space for the attributes rather than different objects. But if we’re back to filling an entire window with a single object like in most FBUIs, what’s the point in having an object control? It has little advantage if you can’t select multiple objects for a single action. There needs to be a way to show multiple object images in the same window or pane while still distributing your attributes controls over both the x and y dimensions.
Well, there’s always the z dimension. This is a solution you’ll again recognize if you’ve worked with a desktop DBMS. If a window isn’t laid out as Continuous or Multi-Record, then it was Single Form or Single Record: one data object visible at time, but then it stacks the objects on top of each other like pages in a book, and provides paging controls to flip among the objects. In fact, let’s call this layout a page layout to contrast it with the alternative table layout.
The page layout supports the display of multiple objects in the same window while making available nearly all space for attributes. Paging controls in effect take the place of a table layout’s vertical scrollbar, allowing navigation to any object for selection or multi-selection. Unlike a table layout, the user cannot not see which objects are selected other than the one that’s currently visible, so some kind of supplemental feedback on the state of multi-selection is necessary (e.g., a status bar hint or tool tip). Also, given the user cannot not scan through pages of objects as quickly as through a table of objects, a page layout works best when the number of objects to display for a task is usually relatively small, on the order of 5, plus or minus 4.
So, while FBUIs and OOUIs can be merged, you still need to decide between a table or page layout for a given window (there’s a third kind of layout, but we’ll save that for a later post). The number of objects and attributes to display are relevant in that decision, not unlike choosing between a FBUI or OOUI, but by using object controls, the downside to your choice is no longer so dire.
But Wait There’s More!
We’ve seen how the object control serves as a means to distinguish selection of the object from selection of an attribute control, allowing convenient manipulation of either. It also serves as handle for the object for drag and drop operations. It provides a common cognitive anchor point between table and page layouts, promoting consistency within an application by supporting largely the same interactions and feedback.
An object control has the following additional uses that make for a convenient merging of FBUI and OOUI idioms.
- Context menu access. Its capacity to distinguish clicks on the object rather than an attribute extends to right- clicking. The object control becomes the hot zone for a context menu for the data object. This is pretty standard in OOUIs, but such context menus are often absent from FBUIs.
- Double-clicking access. Relatedly, the object control becomes the hot spot for double-clicking to do the default action from the context menu. Consistent with many OOUIs, the best default action is generally to open a window providing greater detail on the object. Having a standard means of “drilling down” is extremely useful in database UIs. Sometimes this is done today by making the name of the object into a link, which is fine until you also want to let the user edit the name. It’s better if we used something separate from an attribute for linking to more detail. Double clicking a text attribute, by the way, probably should select a whole word within the text control, as is typically the case in FBUIs today.
- Keyboard navigation. A selectable object control also provides a good way to distinguish the meaning of cursor keys. When the object control has focus, cursor keys such as the arrow keys and Page Up and Page Down move focus among object controls, as you would expect in a OOUI. This allows easy keyboard navigation among objects, whether they are in a table or page layout. When an attribute control has focus, the cursor keys control motion within the control, as you would expect in a FBUI. For example, left and right arrow keys move the cursor one character in a text box. This is better than the modey alternative seen in some OOUIs and in Excel, where a second click is needed to change cursor key behavior from navigating between records and cells to within a control or cell. The tab key, meanwhile, moves focus among controls within an object image, as FBUIs do, except that it also moves focus to and from the object control.
Object controls also provide a convenient location for something else specific to database UIs. Database UIs make frequent use of master-detail windows, where the details of a single data object are shown in a separate pane (or window) from a summarized representation of the object. For example, for a chosen manager in one pane, all his or her subordinates are shown in an adjacent pane. Or for a chosen quark order in one pane, the “extras” on the order are shown in a pane below.
When many objects are shown in the master pane, it’s necessary to indicate to the user the “active” object in the master, that is, the object that determines the population of the detail pane. An active object is distinct from a selected object in that there is always exactly one active object in the master pane at all times. There’s no point in having an empty detail pane, so there should always be some active object in the master. However, there may or may not be a selected object in the master pane. There may be a selected attribute instead, or maybe nothing is selected. The detail pane can only show the attributes of one object at time, so there’s never sense in having more than a single active master object. On the other hand, many master objects can be in a selected state at the same time. Furthermore, using keyboard navigation, it is possible for one object to be selected but another to be active. The active object is the object image to last have focus. Following OOUI conventions, one can move focus from a selected object by using control-arrow keys (this is typically used to multi-select noncontiguous objects with the keyboard alone).
Desktop DBMSs have arrived at different solutions to indicate an active object, but there is some consensus that the indication should be in the left side of the pane. MS Access uses an arrow symbol in the left margin. The well thought-out Oracle Applications User Interface Standards recommend implementing a “current record indicator,” as a blue rectangle on the extreme left of the form. With the object control on the left of the object image, this suggests the object control is an excellent place for indicating the active master object. A heavy border around the object control (shown above) might be sufficient, marking the active object without consuming additional real estate, but remaining visually distinct from a selected object, which shows the entire object image in a selected state.
This post may seem like a lot of text for what is really a relatively small change from current practices. You still have page and table layouts. Now you’re just adding an object control to allow the user more flexibility with a given window. The actual idioms for interacting are only slightly different from what is done today, but that’s my goal: to make simpler and more powerful UIs without requiring a lot of re-learning by experienced users.
Summary Checklist
Problem: How to have one window for manipulation of multiple data objects and data object attributes.
Potential Solution:
- Represent data objects as a collection object images, each comprising multiple selectable and potentially editable “click-through” text controls.
- Include in each object image an object control, an icon used to distinguish action on the whole data object from action on an object’s attributes. This provides a place for:
- Selecting the entire object (rather than an attribute).
- “Grabbing” the object for drag and drop.
- Accessing a context menu for the data object.
- Double-clicking to drill-down.
- Distinguishing the effects of cursor keys.
- Showing the active object in a master-detail window.
- Graphically (and redundantly) indicating a key attribute or object class for search tasks.