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.

1. Tackle expensive computations when they can improve the interface.
2. Eliminate dialogs and command lines in favor of direct manipulation.
3. Drop old assumptions and idioms. Use the processing power to explore new interfaces.
4. Provide a starting point for exploration.
5. Avoid programming cleverness. Instead, assume a good compiler and write readable code.
6. Invest development time in user-centered design.
7. Learn the new rules for performance.
8. Design tiered functionality: take advantage of whatever hardware you're running on.
9. 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. *