September 94 - DESIGNING APPLICATIONS FOR THE POWER MACINTOSH
DESIGNING APPLICATIONS FOR THE POWER MACINTOSH
GREG ROBBINS AND RON AVITZUR
The Power Macintosh offers surprises both for users and for developers. Users notice that it's a fully
compatible Macintosh and that native applications run blazingly fast. Developers, upon learning how
the Power Macintosh differs from a 680x0-based Macintosh, discover that it's still basically a
Macintosh. But the Power Macintosh can offer a much richer experience than was possible with
previous computers if developers break free of their old assumptions and harness the power of the
machine to make software not just faster, but easier and more enjoyable to use.
The Graphing Calculator desk accessory that ships with the Power Macintosh was designed to take
advantage of the machine's power to make some challenging mathematical tasks easily accessible --
in particular, algebraic manipulation and 2-D and 3-D graphing. In this column we'll share some
lessons we learned when writing the Graphing Calculator. We'll speak about software design rather
than programming details because we frequently discovered that our intuition and the standard
approaches to many aspects of the application design were no longer appropriate.
In general, we learned that it's time to break free of the idioms developed for the machines of 1984
and begin designing a new generation of software. We're not in Kansas anymore . The lowest common
denominator of hardware -- where developers usually aim in order to maintain consistency across all
Macintosh models -- has changed. The target has typically been an 8 MHz 68000 processor or, for
color applications, perhaps a machine twice as fast. The lowest common denominator for Apple's
RISC-based line of machines is a 60 MHz PowerPC 601 processor. This change represents an
enormous jump: on some floating-point operations, for example, the Power Macintosh is as much as
20,000 times faster.
In our tests, calculations using the PowerPC processor's single-precision floating-point multiply-add instruction were 20,000
times faster. This means that if we had started a lengthy floating-point calculation in 1984 at the release of the Macintosh,
and that calculation were still being worked on by the computer, it would take a Power Macintosh starting now just four
hours to catch up.*
Even for developers targeting 680x0-based machines, a new approach to software design can
dramatically improve users' experiences. The goal is to maximize use of whatever processing power is
available in the design of the user interface.
Here's a summary of the tips we'd like to pass on; we'll look at each one in more detail below.
- Tackle expensive computations when they can improve the interface.
- Eliminate dialogs and command lines in favor of direct manipulation.
- Drop old assumptions and idioms. Use the processing power to explore new interfaces.
- Provide a starting point for exploration.
- Avoid programming cleverness. Instead, assume a good compiler and write readable code.
- Invest development time in user-centered design.
- Learn the new rules for performance.
- Design tiered functionality: take advantage of whatever hardware you're running on.
- Test on real users.
THE TIPS IN DETAIL
1. Tackle expensive computations when they can improve the interface.
We took a fresh look at how to implement the visual feedback for dragging, scrolling, and zooming.
Traditionally, the Macintosh has represented these with XOR animation, which gives the impression
of the action without really recalculating the window contents. This is how we first implemented
them in the Graphing Calculator as well; redrawing an algebraic equation or 2-D curve, not to
mention a 3-D rendered surface, is computationally expensive.
But to try to stress the processor, we tested the direct approach, and we found that the PowerPC
processor could easily keep up. So now in the Calculator, when the user drags the axes, not only is
the image dragged live but the exposed parts of the function are calculated and drawn as the mouse is
moved. When the zoom buttons are clicked, the entire function is recomputed and redrawn several
times to animate the zoom. In this way, applications can take advantage of the PowerPC processor to
dramatically improve the quality of interaction in ways that are not possible on slower machines.
2. Eliminate dialogs and command lines in favor of direct manipulation.
Since there's processing power to burn in the PowerPC 601, we simplified the user interface by
replacing many dialogs with direct manipulation. The Graphing Calculator doesn't have the dialogs
typical of graphing programs for specifying the range and precision of a graph (xmin, xmax, ymin, ymax,
number of points, and so on). Instead, the user controls the view of a graph through direct
manipulation.
Today's computers are fast enough to allow you to implement direct interaction for complex tasks.
Certain time constants play crucial roles in human factors analysis. Recognizing these thresholds can
help create a smoother interface. If a task like interacting with an equation takes under one-tenth of a
second, users
won't be bothered by the delay; if it takes under one-fourth of a second, it's fast enough not to be
annoying. Longer delays, however, make users realize that they're waiting. With fast response times,
users can ignore
the computer and have fun exploring the subject at hand.
By emphasizing direct manipulation, we reduced even algebraic simplification, a task that might seem
to require a command-line interface, to the paradigm of MacDraw. Math is traditionally
intimidating, and math programs even more so, but we wanted to make mathematics fun. This was
really a user-interface challenge, and it required rethinking many fundamental assumptions. Usability
was our primary design goal; functionality was second. We were pleased to discover that with direct
manipulation, we could simplify the interface without giving up powerful functionality.
Since direct manipulation doesn't require users to learn any new commands or concepts, the
manipulations immediately become part of a user's arsenal of tools. A powerful example of this is the
drag algebra facility, which strikes many people as the most intriguing feature of the Calculator. The
user can select a term of an equation and drag it elsewhere in the equation, just like dragging an
object in a drawing program. The Calculator performs the algebraic manipulations necessary to keep
the equation consistent. This feature immediately boosts users into a realm where they can
confidently and easily manipulate an equation. Just as simple calculators did with multiplication and
division, it allows users who understand the essential concepts to immediately move on to more
interesting problems.
3. Drop old assumptions and idioms. Use the processing power to explore new interfaces.
On a Power Macintosh, you can handle hundreds or thousands of times more information than
before interactively. This might allow rendered 3-D objects to become user-interface components,
for example. While the Graphing Calculator flashes its buttons for the usual 8 ticks to indicate that
they've been clicked, in that time it could compute and render a 3-D surface with 1000 polygons.
Imagine what controls might look like if they really taxed the processing power of the machine.
Because functions are rendered so quickly on a Power Macintosh, we made 3-D surfaces spin by
default. This gives users more information about the functions right away. Furthermore, there are no
menus or dialogs to control the view of surfaces; just as it does for 2-D graphs, the Calculator lets
users change the 3-D view by grabbing the surface with the mouse.
4. Provide a starting point for exploration.
Applications should avoid batch setup operations, such as requiring users to set a lot of dialog options
before performing an operation. Instead, provide a starting point for exploration, with reasonable
defaults for whatever's necessary to get users to that point.
Perhaps the most unusual aspect of the Graphing Calculator is what it doesn't ask of users. They
don't have to set up any graphing options before viewing a curve or a surface; there are no
preliminary dialogs or required commands for users to do this. For any equation that can be graphed,
the user simply clicks a Graph button to draw it.
We've all had the bewildering experience of trying to use a program only to discover that we don't
even know how to begin. One of the toughest problems is to create an interface that makes
functionality available and enjoyable for first-time users. But clearly this is where the design effort
offers the greatest payoff.
5. Avoid programming cleverness. Instead, assume a good compiler and write readable code.
Cycle-counting and compiler-specific optimizations are favorite pastimes of hackers, and sometimes
they're important. But we could never have completed the Graphing Calculator in under six months
had we worried about optimizing each routine. Rather, we dealt with speed problems only when they
were perceptible to users.
We made no attempt to look at performance bottlenecks or at the compiled code of the Calculator
until after running execution profiles. We were surprised where the time was being spent. Most of
the time that the Calculator is compute-bound it's either in the math libraries or in QuickDraw. So
little time is spent in our code that even compiling it unoptimized didn't slow it down perceptibly.
Improving our code's performance meant calling the math libraries less often.
Programmers are often tempted to spend time saving a few bytes or cycles or to fine-tune an
algorithm. If the change isn't visible to users, however, the benefits may not extend beyond the
programmer's satisfaction. When most of the code in an application is straightforward and readable,
maintenance and improvements are easier to make. Those are changes that userswill notice.
To maximize drawing speed without sacrificing compatibility, the Calculator renders its graphs offscreen in GWorlds and
uses CopyBits to transfer them to the screen. See "Drawing in GWorlds for Speed and Versatility" in develop Issue 10 for
a discussion of this technique.*
6. Invest development time in user-centered design.
Complex algorithms should be used not for their own sake but to improve the user experience. For
example, as the user drags the pane divider in the Calculator window, the application redraws most of
the window (offscreen in a GWorld) rather than recalculating exposed areas. The Power Macintosh
is fast enough that it wasn't worth spending coding and debugging time to save on runtime
calculation, because the savings wouldn't be perceived by the user.
In contrast, when users click on a 2-D curve to read an (x,y) coordinate, some quite sophisticated
processing happens. As the user moves the mouse, a numeric root-finding algorithm looks for
interesting points such as maxima, minima, and zero-crossings to solve equations numerically.
Furthermore, because numerical methods to find maxima and minima are imprecise, we also compute
symbolic derivatives of the functions and then look for where the derivative is 0, which locates
maxima and minima much more accurately. All this work goes completely unnoticed by the user. But the user does notice the result: simply
clicking on the curve tells with great precision what's interesting at that point.
7. Learn the new rules for performance.
You may discover that thereare places where performance tuning would be worthwhile in your
application. The rules for performance have changed, and knowing the new rules is essential. Some
programming techniques that traditionally improve performance can be counterproductive. In
particular, on PowerPC-based systems, avoiding instruction cache misses is far more important than
saving instructions.
Getting good performance out of a fast machine doesn't always come without effort. To be able to
exploit modern hardware to improve an application, you must have some understanding of the
hardware and what allows it to be fast. It's extremely important to understand the processor and
memory architecture of your target platform.
The memory system in the Power Macintosh is much faster than the memory system of other
Macintosh models. The 64-bit bus allows for substantially improved data transfer. However, the
processor is much, much faster than the memory system. An uncached memory reference may take
20 times as long as a cached memory reference. Performance will actually be slowed down
dramatically by a speedoptimization that saves floating-point multiply instructions (expensive on some
processors, but not on the PowerPC) at the expense of extra memory usage that forces instructions or
data out of the cache.
Understanding patterns of memory reference is very important in analyzing algorithms for
performance. Stepping through an array across cache lines can quickly flush all lines out of the cache.
(Cache lines are discussed in the Balance of Power column in this issue.) This can cripple attempts to
walk the data structures typically maintained by interface-intensive applications. The PowerPC 601
has an eight-way set associative cache, which is fairly resilient to degradation from flushing of cache
lines. However, the 603 processor has just a two-way set associative cache. Any processor-intensive
calculations must avoid cache thrashing if they are to avoid degrading below an acceptable level of
user responsiveness.
For additional architecture insights and tuning strategies, see the Balance of Power column in develop Issue 18 and in this
issue.*
Because no two platforms will run at the same speed, it's important to design software to work well
on a variety of machines. In principle, this means that the same application could run on any
Macintosh, while being far more powerful -- and more pleasant to use -- on a Power Macintosh.
8. Design tiered functionality: take advantage of whatever hardware you're running on.
Just as it's frustrating for users of entry-level machines to be unable to run software, it's equally
frustrating for users of fast, high-end hardware with plenty of memory to have features execute
unnecessarily slowly, or to be constrained by programs that expect and only take advantage of
minimal resources.
The Graphing Calculator does assume a Power Macintosh as its base platform; otherwise its
expectations are modest. However, its appetite is unbounded. It does all drawing using offscreen
buffers in temporary memory when adequate RAM is available, but will scale back to onscreen,
QuickDraw-based rendering when temporary memory is limited. System 7 makes this easy with
purgeable GWorlds; once LockPixels fails, the Calculator knows that it must work within tighter
constraints. Later, when it can reallocate the offscreen buffer, it does so and resumes the fast, smooth
graphing effects. When memory is abundant, the Calculator uses many temporary GWorlds to buffer
frames of 2-D inequality graphs calculated for varying values ofn , such as the animation of cosn x <
0.
The Graphing Calculator does all 2-D graph computation in 15-tick chunks. For simple curves, this
typically renders the entire curve at once. But 2-D inequalities are drawn piece by piece. Once Power
Macintosh computers are fast enough that an entire, complex inequality graph can be drawn in a
single 15-tick time slice, users will be able to explore inequalities as fluidly as they can now play with
simple functions.
To take advantage of faster machines, always base computational units on real time rather than on
more arbitrary measures. If the Calculator had recomputed a fixed number of points and then called
WaitNextEvent, too much time would have been yielded to other processes, even on graphs simple
enough to be recomputed and drawn all at once. Instead, the Calculator calls TickCount and lets that
dictate when it needs to yield time. This approach allows for a smooth user interface and cooperative
execution regardless of the processor's speed.
Designing tiered functionality means abandoning assumptions about what is and is not practical on
the target hardware. For addressing resources, such as available hardware and memory, or when
execution can be threaded or time-sliced, the options are usually clear. For matters of raw speed, the
proper approach may not be so obvious. It may come down to measuring the execution speed of a
particular procedure at run time and basing a decision on that. For example, an animation effect
might be suitable if it takes under 8 ticks, or a routine that bypasses QuickDraw for drawing in a
GWorld may be worthwhile if it really is faster than its QuickDraw alternative.
For an example of timing graphics speed, see the article "Exploiting Graphics Speed on the Power Macintosh" in develop Issue 18.*
9. Test on real users.
The Graphing Calculator reflects our vision of a new kind of calculator. But user testing was essential
for showing us the holes in our vision. For example, elements that were directly manipulable in our
eyes were overlooked by users. So we redesigned them to make their functions clearer, and then
added a demo mode to point out important controls explicitly.
In tests, the users who looked at the help pages invariably turned first to the page at the end offering
"tips." This surprised us, but also made clear where to put the most important information for using
the Calculator.
Toward the end of the development of the Graphing Calculator, as the final user tests were being
conducted, we saw students using the Calculator effectively within minutes, without instruction.
Watching a high school student say "Wow!" as an equation came to life on the screen was probably
the most satisfying moment for us as programmers. It was also the one that offered us the greatest
hope about the future of personal computing. The Power Macintosh offers us the chance to reach
more people while making the experience more enjoyable and easier for users than ever possible on
earlier generations of computers. As developers, we have a new world to explore.
GREG ROBBINS began writing educational software on the Apple II as a high school student. Since then, he's picked up
computer engineering degrees from U.C. San Diego and the University of Pennsylvania, bagged wild boar in Fiji, and
evaded sharks off Australia. When he's not consulting on Macintosh development, Greg gets way off the beaten track as
a member of the Bay Area Mountain Rescue Unit. *
RON AVITZUR considered working on the Graphing Calculator to be an exercise in single-minded obsessive behavior --
good training for graduate school in physics. Ron has been writing educational math software since the dawn of the
Macintosh. You haven't really seen the Graphing Calculator until Ron has shown it to you; in fact, Stewart Alsop's PC
Letter names Ron one of the first Demo Gods. *
Thanks to Arnaud Gourdol, Mike Neil, Don Norman, and Alex Rosenberg for reviewing this column. *