Interfacial Relations 6
Volume Number: 7
Issue Number: 12
Column Tag: Developer's Forum
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