Interfacial Relations VI

By Joost Romeu, CIS 72371, 3160 (ALink X0102)

Last time we looked at icons to see how well--as metaphorical pictures--they communicated their function. Inspecting these visual statements, we investigated the range of rhetorical and communications possibilities (of which metaphor was just one) available to the icon designer.

Interfacial Relations Part VI samples the way applications employ abstract icons. (Abstract icons employ designs that signify rather than depict.)

Unlike representational interface--which allows the developer to rely on metaphor to provide meaning--abstract interface forces the developer to dig further to provide the interaction and responsiveness necessary to make the program relate to each user.

We are moving from real world space to computer space. Real world processes that yesterday we were trying to emulate and refine--traditional concepts that we thought would never change, such as the distinction between a “Plain” font and its “Italic” or “Bold” face counterpart (see below)1--now must be approached in an increasingly abstract manner.

Interfacial Relations Part VI looks at just one abstract icon, the arrow, to see what the factors are that make this non-metaphorical take on reality succeed. Though the functions being discussed may not seem to directly impact your development efforts, the approach they demand may significantly affect how you decide to design your interface.

Mid-life Crisis?

Apple Computer, and the Macintosh interface, seems to be suffering a mid-life crisis. Agreements with Big Blue, and interface-design acceptance from the Windows, Motif, and Open Look community mark a development crossroads. Apple can choose to rest on its laurels and by exercising small, incremental interface “improvements” fade into the GUI landscape. Or Apple can re-assert its reputation as a interface innovator and supercede its interface by introducing a more abstract and relational look and feel. As a long time Macintosh user, I find solace and security in programs whose nostalgic interface calls up memories of the way we were. But tomorrow’s computer sophisticate--the user born with a silver computer in his/her grasp--will require a more interactive, responsive vehicle to escort him/her into the future.

When I began writing this article I thought there was an obvious distinction between representational and abstract interface design. As I became more deeply involved, I recognized that the distinction was less clear and the interplay more involved--and interesting--than I had imagined.

Re-presentation

Design cycles, like art movements, swing from representational to non-representational. Representation is a vehicle through which the user recalls something that existed. The designer that re-presents capitalizes on nostalgia.

Abstract design promotes accessibility by emphasizing participation rather than recognition. The designer is counting on the independent and lifelike nature of the design to entrance and sustain the user.

The issue of abstract vs metaphorical strikes directly to the heart of the GUI as it is understood today. Yet its aim is not to kill the GUI we find so reassuring, but to escort it into another development phase.

It also has profound implications for the Macintosh. The Macintosh Human Interface has finally been recognized industry-wide. The Macintosh interface needs to find ways to supercede (not merely extend) its interface guidelines. As competitors emulate the Mac GUI--as the Mac interface becomes a metaphor itself--the tenets of this 70’s approach will be compromised.

Teaching or Being Taught?

The interactive nature of abstract gadgets brings up the question of whether we--as users--configure programs, or whether those programs force us to conform to their dictates.

The difference isn’t always easy to discern. Once you’ve accepted certain tenants, it’s hard to recognize (or admit) that the reason you conform to these rules may be because you’ve been trained that way. (Users shifting from object/verb to verb/object computer approaches find the change disturbingly difficult to describe.) But in emerging fields such as handwriting recognition, it’s an open question whether you’re training a computer to recognize your handwriting or the computer is teaching you to write differently.

Part of the art of interface design is to convince the user that the computer is responding to him/her rather than vice-versa!

The Move to Abstraction

An evolving computer interface demands more interactive and abstract elements. This realization comes at a good time. Functionality notwithstanding, Windows is taking the wind out of Macintosh’s “We’ve got a better interface” argument.

Unfortunately, as lower priced Macs hit the streets, developers may think they need to design software that appeals to a least common denominator. Believing the new user is less sophisticated, they may feel that to capture the user’s interest they need to imitate reality. Metaphor’s paint-by-the-numbers approach can reduce interface to the level of cheap reproduction and harm the development of programs that want to challenge and capture the imagination.

There’s also a school of critics that says abstraction is inherently a more “difficult” form, capable of being appreciated only by the specialist. In the computer arena, abstraction--because it is so interactive--can be a more accommodating approach. It welcomes all users because it doesn’t requires they be steeped in the tradition the metaphor is alluding to; and it compliments the new user because it retains an open and engaging attitude. Abstraction, and the interactive and relational approach that goes with it, invites rather than intimidates.

Mac-stract

The Macintosh interface represents and abstracts. It does this through pictures as well as words. Each approach has its advantages.

We feel attracted to icons that are familiar because of the things they remind us of. But as soon as we begin to operate the program we discover that we must train our minds to accept the fact the metaphor is--procedurally and resultwise--different than what we were accustomed to.

Some metaphorical tools don’t take long to get used to. MacPaint, while it was a stand alone paintbox, wasn’t intimidating. It didn’t threaten any discipline and the tools it presented were simple to understand, operate, and relate to.

But as the experience of using the digital tool begins to challenge the understanding of its non-digital predecessor, the relationship changes. No longer can an artist feel confident that when he picks up a tool--even one as apparently simple as a pencil or eraser--it will operate the way he understood it to operate under MacPaint or expects it to operate in the non-digital world.

The issue isn’t only between the traditionalist and the computerphyle. As computer users begin to expect more control over their tools, they grow more dissatisfied with programs that take specificities for granted. A spreadsheet user wants the interface to allow him to insert a column exactly where he wants to put it. The user doesn’t want to have to remember that “Insert Column” means the column will squeeze itself to the left or right of the selected column. (Why can’t Excel provide insert functionality as unambiguous as its interactive Column Resize interface.)

Representational interface relies on the user recalling “the way it was done.” Abstract designs force the program designer to go one interactive step further. They require we find ways to immediately make it obvious how the user can--within the immediate context--apply the tool he/she has chosen.

The Arrow

Arrows are primitive symbols that evoke primal responses. Like the action of pointing, the arrow depends on the present but looks to the future.

The arrow is one of the most prevalent icons on the Macintosh window. Like every abstract icon, it begs immediate interaction between the actor (the program) and the viewer (the user).

In looking at some of the many ways the arrow is used, ask the question: “How effective can an abstract indicator be? Is an icon that signifies as effective as one that represents?”

Viewing Arrows

The most familiar Macintosh arrows are those that control scrolling functions.

Nisus2 assigns the scrollbar arrow icon an accelerating scroll. The user sets the maximum scroll speed.

Illustration: Nisus scroll arrows

The utilities AltCDEF3 modifies the scroll arrow so that you can more easily get to up/down or left/right scrolling. (Why not provide quad arrows?)

The user is willing to trust the abstract icon on its own terms. Switching between single and dual arrows or between applications that provide constant vs accelerating scroll speeds doesn’t seem disruptive at all. It requires as little reorientation (recognizing and adapting) as the real world action of picking up two similar objects of different size and shape.

An aside: Abstract icons tend to be more difficult to describe than they are to use. For example, pressing a down arrow to cause text to travel up doesn’t make much sense, but operating that device does. (True, the elevator box goes down, but the user’s attention isn’t usually focused on the elevator box.)

3D Arrows

Two-dimensional programs address movement through space in similar ways. (They handle the construction of that space quite differently however, as we’ll see in a future article.) Three-dimensional programs must contend with a much more complicated paradigm as they attempt to situate and move an environment that consists of subjects, objects, and the space they share.

Super 3D

Super 3D4 changes the window arrow motif by depicting the scroll bar as a knurled knob (notice how the gradations narrow at the ends).

Illustration. Super 3D arrow

Choosing a world, object, or camera icon and pressing a window arrow causes the window, object, or camera to rotate about the horizontal or vertical axis. Super 3D arrows have been transformed into three dimensional manipulation tools. A crosshair screen and judicious use of a rotating axis clues the user into what is happening. Adding to its effectiveness is additional reinforcement supplied in other areas of the program. For example, the user changes light placement and shading through a dialog box using the same motif.

A floating palette containing pine tree like arrows controls the linear camera qualities zoom (in and out could’ve been combined into one icon w. modifier key) and position. Camera attitudes and window movement is indicated by the movement (in/out or side-to-side of a rectangle representing the window plane).

Swivel 3D

Swivel 3D5 retains the traditional window scroll arrows and adds icons to control the XY location, XZ location, Yaw, Pitch, and Roll of each object.

Illustration. Swivel arrow

Moving the XZ arrow upwards/downwards causes the object to move backward/forward. Option clicking on the pitch and roll icons allows you to simultaneously control both yaw/pitch or yaw/roll. As an object is moved or rotated, the object reduces itself to a wireframe, an effective way of indicating precise object movement (wireframe w. grayshading would be even more spectacular and could provide better overlap and distance cues).

Infini-d

Infini-d6 has abandoned traditional window scroll icons for a scroll bar that you reach through a dropdown attached to each window. This departure from the standard window configuration is understandable when you consider how much a user relies on the 4-view orthographic projection (front, side, top, and perspective views) to compose and manipulate objects.

Illustration. Infini-d arrows

Infini-d’s approach does away with unnecessary scroll bars and allows a larger active object/window space. It also allows the program to control window manipulation on a per-window basis. For example, an extra arrow is provided in the perspective view to control camera movement/rotation. It’s important to remember that by changing or eliminating scroll bars you may eliminate the greying scroll bar cue that indicates objects exist outside the window view.

For object rotation, Infini-d uses a similar scheme to Swivel with an added feature. As you move/rotate the wireframe, the original remains on the window as a reference. When you release the mouse the window redraws itself. You have the choice of seeing the original as a wireframe or rendered.

StrataVision

Deciding to move an object or resituate one’s point of view in StrataVision7 immediately brings up a visual reminder. The reminder consists of a set of handles and a pivot point.

Illustration. Strata arrow

Pulling on one of those handles moves the object(s) around the pivot point. All the 3D programs mentioned involve object specific pivot points but in none of them is its location and importance as eminent as in StrataVision.

3D Conclusions

Going into the specifics of each of these programs is beyond the scope of this article. But lessons can be learned from the way they implement the arrow icon.

Users will adapt to a response that provides immediate visual feedback, reinforced by relevant--and if necessary, restricted--movement. (I wonder if providing the option of an equally engaging undo procedure--one that animatedly steps backward--would be a helpful tool.)

Users don’t need to manipulate completely rendered objects. Movement, rather than image resolution, provides the necessary cues.

Finally, programs can benefit by introducing animated elements into the interface to aid the user in performing a tool function.

Hierarchical Arrows

Arrows situated at the end of a menu line indicate that menu item houses a cascading set of sub-entries8. The arrow typically points right yet the arrow direction doesn’t necessarily reflect either the position or the direction of the cascade it alludes to.9

Illustration. HandOff hierarchical menu

This doesn’t seem to cause much confusion however. Even totally contradictory signs (such as an arrow pointing in one way and the action proceeding in the opposite direction or in no specific direction at all) are taken in stride. Since the user doesn’t know what’s coming up or where it will come up, the user isn’t putting up with this arrangement because he/she inherently understands the menu is trying not to collide with the edge of the screen. The user is simply willing to accept some element of surprise if it remains consistent with the user’s desire to stay on a path.

Once the hierarchical menu is taken seriously there will be many refinements that can cause this interface tool to occupy a valuable place in the GUI. But even in its present rudimentary form, the cascading menu shows that the user enjoys following a continuous route to a destination rather than having to consolidate a destination into a series of short trails.

Outliners

ACTA10, a very intuitive outliner, uses arrows to indicate topics. Used in conjunction with the Enter (Delete), Cmd-R(ight) and Cmd L(eft) keys, or by dragging, ACTA allows you full outline composing functionality.

Dragging a topic from one location to another, if done quickly, provides no interface guideline help. However, if you wait a moment, a frame will show up around the complete selected item indicating what you are about to move and (as you move it) where it is going to go.

An ACTA outline can contain a cacophony of arrows. The solid arrow pointing to the right indicates a solitary topic; the open arrow indicates a topic with subtopics; the open down-arrow indicates that the subtopics are showing; and the thin arrow indicates a collapsed topic with more information available (when expanded).

Illustration. ACTA arrows

Just described or pictured this scheme may seem confusing, however, in practice, these multifarious arrows detract very little from the content and don’t disrupt the outline in ways more representational descriptive icons might.

Contrast ACTA with Microsoft Word11’s outliner. Arrow icons allow you to promote/demote either text or topic, and demote the topic to body text. Other abstract icons permit you to expand or collapse topics, display topics to a certain depth, repress formatting, etc. You can also move topics by dragging. Some of Word’s icon bar facilities are less than helpful. Icons don’t dim when functions aren’t available, the + and - topic indicators are less explanatory than ACTA’s versatile arrow topic heads, and subtopics are spaced so widely apart that it’s hard to easily tell which level you’re on.

Less Than Excellent

Excel12 has added outlining capabilities to its industry standard spreadsheet. Though I applaud the changes Microsoft has made to Excel, I find its interfacelift less far reaching than I expected.

Capable of “showing” and “hiding” selected rows or columns of information, Excel’s outliner interface consists of promotion/demotion arrow buttons situated along its main horizontal icon bar.

Illustration. Excel outline

If--to begin an outline--you choose to first click on the left (promote) arrow (the most approachable icon for a Western user) the program tells you that you cannot initiate an outline by promoting an entry. This problem would never arise if the program dimmed the unavailable button.

Every time you press an arrow button you are presented with a dialog asking if you intend to apply that arrow to the rows or columns bordered by the selected entry. Leaving aside the fact that buttons that bring up dialog boxes should be followed by ellipses, this inevitable dialog box is distracting, disturbs the flow of what you’re doing, and reduces what you thought was going to be a meaningful action to a weak request.

Your response to this center-screen dialog causes something to happen either near the top or near the left edge of the spreadsheet. Creating an Excel “outline” requires your attention be focused practically everywhere but the location of the item you’re trying to modify.

More informative solutions might be:

Illustration. Excel modification.1

or

Illustration. Excel modification.2

It’s important, when designing interactive gadgets to be very cognizant of how the user’s attention is focused. It’s important to maintain a smooth presentation flow so that the interface interacts in a supportive rather than disruptive manner.

Presentation Arrows

Right next to Excel’s outlining arrow set is a downward pointing arrow that presents a dropdown menu which expands the style field next to it. Its meaning is clear immediate and direct. (An alternative tack might be to allow the field to expand if the user holds down the mouse button within the field for a certain length of time. This would reduce objects on the interface and give the field added functionality.) Easy Alarms snooze button is a device that registers a default time period if you press it and brings up a list of alternative time periods if you keep the mouse depressed.

Metaphorical vs Referential

When I studied the 3D programs cited above, I found their references to cameras intimidating. Since I’m not a camera buff, Micro, Fisheye, Wide Angle, Macro, Telephoto and Supertelephoto, and Custom (?) lenses, focal lengths, dolly (the verb), and camera zoom--concepts as clear to the initiated as the difference between Helvetica and Futura are to me--seem intimidating and confusing.

Illustration. Infini-d.camera.lens

I understand that referring to cameras can cut through a lot of explanation. But even to just understand focal lengths the user needs to be grounded in--lens type, light considerations, film speed, shutter speed and aperture size (f-stop), depth of field, and a smattering of optic theory--concepts basic to camera operation in the real world but unnecessary to operate a 3D program in computer space. Why not design an alternative interface that avoids the mention of cameras and instead sets up an interactive relationship between subjects and objects.

In most programs, showing a normal and magnified view does away with any of the technicalities involved with defining and positioning a magnifying lens. A relational view that allows the user to directly manipulate distances and relevant angles might replace camera allusions.

But I don’t want to throw out the baby with the bathwater. Someone may want to use a 3D program to set up a photographic shoot. That person would need to know that if he stands at a certain location, using a camera with a particular focal length that he will be able to capture the image required. In this case, the user needs to relate what’s on the screen to an event that will eventually involve a camera.

But though the metaphorical camera may address this approach, this approach doesn’t necessitate retaining the metaphorical camera as part of the 3D interface. You shouldn’t confuse real world referents with metaphorical interface any more than you should confuse good spelling with accurate writing.

Real world referents can help every user. You don’t have to be an engineer to want to draw a football field as a rectangle 100 yards long by 50 yards wide. But like spell checking (and like the way many drawing programs handle dimensions) real world referents might better be addressed as background processes which can be called up (or can interactively) check what the artist is doing on screen.

Most 3D programs allow design by dimension; most use the camera metaphor and carry camera nomenclature; most map a number of textures such as wood, metal, and glass onto the objects they construct. Yet none provide a texture-checking function that tells the user that a 3 mile structure made of glass isn’t going to hold up. This doesn’t mean that these programs need to add texture checking functionality, but it does mean they might think of implementing less metaphorical ways of expressing the camera concept.

Other Arrows

The most prevalent and common use of arrows might be to select and insert things. The Canvas13 menu provides an arrow that selects when you click, resizes when you drag on a handle, and fences (with a markee) when you click on an unoccupied space and drag. Canvas manages this multiple functionality nondisruptively by changing the cursor shape (note the three cursor shapes in this canvas selection arrow montage).

Illustration. Canvas.arrows

Arrows have been used to select, to magnify, to move, to add and erase points, etc. They indicate tabs, carriage returns, the Line Tool, and other functions.

Yet their employment seems to cause little consternation. Abstract tools concentrate more on how the tool is implemented than on how it appears to relate to something in the real world.

Abstracting the Modified Metaphor

Underlying metaphor is the presumption that when we do something on a computer we need to emulate a way we do (or more accurately, “did”) it in real world space. No matter what it is the program’s really doing, its interface tries to adopt means and ends that relate to real world space.

How do we modify these tools when we find real world tools wanting? The traditional approach results in a tool that isn’t unlike the punk t-shirt whose rips and tears and safety pins strain the credibility of what we know as a t-shirt. It’s a mutant consisting of an original metaphorical icon with anthropomorphic tentacles attached to as many metaphorical devices as possible. Safety pinned on this metaphorical fabric are techno-jargonese additions for which the program designers never found a real world correlate. What a burden for any tool to shoulder! A more realistic approach might be to institute a more relational, abstract, and interactive tool.

Painter14 is a program whose tools are destined to change the face of illustration. Maybe because they are so radically different, they are also the most grotesque example of the strain between interface that’s trying to stand on its metaphorical roots while stepping into the future.

Looking at the ultra realistic full color icons that portray Painter tools, you would think you were about to open the computer equivalent of a Crayola box. Exploring those tools you find yourself sharpening leading edge computer assisted tools. Each paint tool variant, a combination of factors that (metaphorically speaking) animate every “bristle of the brush” can be modified to reflect size fluctuation, pressure sensitive tablet interaction, paper responsiveness, and behavioral fluctuations.

Pictured is the brush behavior palette:

Illustration. Painter brush behavior

Notice the jargonese used to describe functionality which the traditional painter either found indescribable or ascribed to rheumatism. Though changing the jargon might make these features seem less technical, it’s probably not worth the time to describe features that themselves will probably be modified.

But if we:

2) Push the feature bars together (temporarily remove the words). rotate and resize the chart

Illustration. Painter modification.1

3) Reduce the chart to a brush stroke, superimpose it over a grid, and provide an interactive way of editing the stroke...

Illustration. Painter modification.2

We’ve succeeded in reducing a set of complex variables into a (paint)stroke. The stroke retains all the features of the original tool but now exists as a signature that is easier for the stroke maker to identify, implement, and manipulate. The new tool has an identity of its own that’s unique, clean, clear and succinct. It doesn’t depend on its past to give it a raison d’etre.

We don’t have to sacrifice the original. We can still provide the user the option of breaking down the tool into its component parts. In fact, we can go further and segregate component parts into numbers and assign those numbers to a spreadsheet. In spreadsheet form we can compare different tools and structure tool modifications in a way better suited to modifying number sets. All in all we’ve managed to provide the painter with a tool definable and recognizable as a stroke, and the craftsperson with a tool that can be incrementally modified by the numbers.

As metaphor is superceded by meta-metaphor the problems of holding on to the past are becoming apparent. Metaphor fails to respect real world space on its terms or appreciate the capabilities of computer space.

The Optional Metaphor

We don’t have to throw out the metaphor. We can maintain it as an option.

The difference is subtle but profound. It’s the difference between considering Helvetica a font type infinitely modifiable through True Type or considering Helvetica as a pre-True Type font that, to maintain its identity as Helvetica, doesn’t participate in the technology True Type provides us with. We’re not doing away with Helvetica. We’re merely recognizing a hinted Helvetica for what it is--another typeface.

An Abstract Abstract

Abstract icons focus our attention on some quality of our environment. They encourage us to explore what they represent rather than compare what they purport to represent with something we assumed we knew. Though less reassuring than a representational icon, the effect tends to be more immediate and current. It demands less of our memory and more of our participation. And it gives us a sense that we are creating rather than replicating something.

There are many things we ask different programs to do that they do differently than we expect. Some approaches we find perplexing and others we’re willing to accept. The degree to which we can switch from one interface instance to another should not be dependent on our ability to remember what each program does and how it does it. It should depend on each program’s ability to make its functions contextually apparent.

It’s hard to measure and quantify empirical evidence. But it’s important to understand that human beings are adaptable and more important to recognize that we enjoy adapting if the context in which we operate is supportive.

Abstract icons point out the role kinesthetics and movement plays in our appreciation of and comfort level with interfaces. We can identify with representational elements and the way they work and still find the programs they host annoying. Abstract gadgets can’t be so easily divorced from their program environment. If we accept the functionality of the abstract interface, we are usually accepting the program that interface defines.

Every job can be considered from two viewpoints. One view appreciates the job because of what it accomplished, no matter what price it extracted. The other view looks at the experience. If we can provide users with a more contextually sensitive, interactive, interface we may cause more people to say when they accomplished their task that their job was a “moving experience.”

References and Footnotes

1 The question of what is Plain, Italic, and Boldface, or even what is the true look of a typestyle has been challenged by technological refinements made possible through TrueType.

2 “Nisus 3.06.” Solana Beach, CA 92075: Paragon Concepts, Inc., 1991.

3 Colwell, Alexander S. “AltCDEF V1.3.” 1991.

4 “AldusSuper 3D.” V2.5: San Diego, CA 92126-4551: Silicon Beach Software, Inc., 1991.

5 “Swivel 3D Professional.” 1.5.7, San Francisco, CA 94111-1030: Paracomp Inc., 1990.

6 “Infini-D 1.1.” Amherst, MA 01002: Specular International, Ltd., 1991.

7 “StrataVision 3d v2.0.2.” St. George, Utah 84770: Strata Inc., 1991.

8 Apple Interface Guidelines suggest you limit hierarchical menus to no deeper than two levels. (Technical limits are slightly different.) However, recently there have been an insurgence of programs offering multiple hierarchical cascades that transcend Apple’s suggested and technical limitations. Hopefully these programs will cause developers to research how to expanding the functionality of hierarchical menus.

9 “HandOff.”Menlo Park, CA 94025: Connectix Corp., 1991.

10 “ACTA 7.” Scottsdale, AZ 85258: Symmetry Software Corp., 1991.

11 “Microsoft Word 4.0.” Bellview, WA 98004: Microsoft, 1989.

12 “Microsoft Excel.” V3.0, Bellview, WA 98004: Microsoft, 1991.

13 “Canvas 3.0.” Miami, FL 33126: Deneba Systems, 1991.

14 “Painter 1.0.” Aptos, CA 95003: Fractal Design Corporation, 1991.