While parts of PC programs run on the Mac, such programs are not considered by users to be “Mac-like.” So, what is this elusive quality that makes a program “Mac-like”?
A Macintosh, to its user, is more than just another computer platform. When technically-oriented people look at a program, they tend to look at the functionality of that program—what it does and how it does it. When typical Mac users look at a program, they look at the program’s interface—what the program shows of itself to the outside world. Along with all their expectations, they bring to the program all the experiences that they have already had with any Mac program. In general, Mac users feel that they are in control of their computer, rather than the reverse being true. This feeling is due to the three attributes of a “good” Mac program:
- · responsiveness
- · permissiveness
- · consistency
A responsive program quickly follows the user’s actions with the direct results of that action. Indeed, you might consider this attribute to be the foundation of a Mac application. What I mean is that Mac programs generally execute in an endless loop that looks for user-initiated events to occur. Once the event is detected, it is handled. Handling the event means doing whatever it is that the event requires to be done. It is the total opposite of the fascist programs that I used to write before the Mac came along. Oh sure, there would be the odd “get input” line. But I decided when that would occur, and the user had better be ready to respond! My programs executed top-down, one line at a time, the way I wrote them; that was that.
However, a Mac program turns this concept upside down. The program’s main loop is an event handler mechanism that branches to the subroutines, which do all the work, and then comes back and waits for another user event. Of course, all sorts of initializations must occur before the main loop can work, but you get the idea. This difference explains why so many MS-DOS programmers could never make it on the Mac side. They had to rethink their entire concept of programming. (Windows eventually made them change, but they went kicking and screaming.) So, responsiveness is more than just some lofty idea; it is the very core of the Mac experience and most Mac programming.
Permissiveness follows up on the user-centered approach to computing. It means that the application will allow the user to do anything that is reasonable. The user decides what to do next, not the system or program.
The simple way to encourage permissiveness is to avoid modes. A mode is some part of the program that restricts the user’s options and must be entered and exited. Modes are generally confusing to the user, especially when the user is in the wrong one. However, some modes may be acceptable. A short-term “spring-loaded” mode (when the user does something to keep the mode active) may be all right. Alert modes that make the user rectify some situation may be necessary but should be kept to a minimum. A mode may be acceptable if it changes the attributes—not the behavior—of something.
Let’s consider one example of mode-less operation. Suppose you’re developing a word processing program that includes an automatic spell-checker. At some point, the user makes a spelling error. The modal response to this would be to throw up an alert box of some sort when the error is detected and to force the user to correct the mistake before proceeding. The non-modal way might consist of alerting the user to the error (perhaps by bolding the text) but allowing the processing to continue. This non-modal way gives the user—not the program—the choice of when to correct the error. Permissiveness reinforces the user’s control of the computing experience.
Consistency means that, in certain respects, most Mac programs are alike. For example, Mac users expect the File menu to be the menu at the far left, followed by the Edit menu just to the right. They are used to this convention because of their experiences with other Mac programs. Smart designers know to play off of the skills that people bring with them, rather than force them to learn new conventions just to use the program. Really smart designers capitalize on these learned responses to make their program interfaces seem natural to the user.
One last thing to consider is that Mac programs should be as country- and hardware-independent as possible. Words that the user sees should be stored in changeable resources, not hardcoded into the program. Accessing hardware directly from the program—rather than calling the system routine (“manager”) to deal with it—is guaranteed to cause the program to fail when next year’s Mac shows up. I use a 15-year-old word processing program on my G3 Mac that works as well as it did on my Mac Plus. It did everything the right way because it avoided machine dependencies. I’m sure that it would be easy to “localize” (that is, translate the program into non-English operation), too. The same code has migrated with me by following these simple concepts. Your code can be this enduring, too. It just takes thought and planning to avoid the bad habits that we’ve picked up along the way.
Larry Loeb has 20 years of computer journalism experience. He was Consulting Editor at the late, lamented BYTE magazine, he launched WebWeek, he ran the online Macintosh section of BIX (the BYTE Information eXchange), and he wrote numerous articles for many major computer magazines. Recently, he also wrote a book on Secure Electronic Transactions, the protocol endorsed by MasterCard and Visa that allows merchants, cardholders, and banks to work together over the Internet. For banter, tips, and general screaming, send Larry an e-mail .The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.