Mobile Insights: Defining the Human-Newton Interface

Shortly after its introduction, the Newton became the object of relentless industry and press criticism. Some of it was deserved of course. Not only was the Newton late and buggy, but it had the near impossible task of living up to its pre-launch hype.

However, the company that brought us the Apple ][ and the Macintosh has worked hard to earn a loyal following. And nowhere is this demonstrated more than the number (and quality) of shareware applications that have quickly appeared for the Newton.

One of the reasons for the success of the Macintosh was the comprehensive user interface guidelines that gave many programmers their first lesson on how to construct usable programs. The situation today on the Newton is markedly different.

Developers are blessed (or cursed) by a general lack of human interface guidelines. In this article, we’ll look at some of the best and worst features of several shareware and commercial Newton applications. Many of the lessons apply to all human interface design, while some of them are specific to the Newton.

Rule: Use feedback to let users know that their action was understood.

Even with its advanced RISC processor, operations on the Newton are seldom instantaneous and often frustratingly slow. Let your users know that the application has accepted the input. When an operation takes more than a couple of seconds, use a natural way to inform your users about what’s going on.

This particular issue has surfaced on several online forums. Apple recommends against using an alert box to indicate program status since users may already associate something more serious with this type of message.

Likewise, many Newton developers shy away from using an hourglass or rotating ball similar to what appears on desktop computers for just that reason—it’s too much like the desktop.

Apple recommends that you use a short string in your view that indicates that something is taking place. For example, you may want to use terms such as “Connecting…”, “Moving…”, or “Searching..” depending on your application’s context.

Some applications, such as Graphing 101, have started using a progression bar similar to the one used on a Macintosh to indicate the number of files copied. This seems to be appropriate when loading data in the Newton, or performing a time-consuming calculation or graph.

Rule: Enable users to abort a long operation gracefully without ill-effect.

Operations such as graphing data or searching for text can become very time consuming, especially on Newtons with books and other content. Give your users a way to stop a long operation.

Rule: Restrict the handwriting recognition system to the type of input desired to improve accuracy.

The commercial spreadsheet MobileCalc enables you to toggle between numbers and alphanumeric recognition, greatly improving results. Do this whenever possible.

Rule: Don’t use the full screen unless it’s necessary.

Screen real estate is valuable on PDAs. Most small specialized applications do not require the whole screen. In fact, too much white space makes an application appear feature-poor. If you can get away with a smaller floating view, use it.

However, it is also important to use white space wisely to make your screens readable. Crowding makes for tiring applications and makes the Newton seem more like work than play.

CheckPlease! is an application that is nicely designed graphically, however, it shouldn’t consume the entire screen.

Rule: Give users an option of controlling the amount of information displayed.

Some applications try to explain how to use the program on the main screen, near the respective data input fields. While this may be useful in some applications, it becomes very tiring when programs are used over and over.

A compromise between too much or too little information is to allow users to toggle between the two styles. When the user first runs the application, display the information along with the input fields. Later, allow the user to turn this feature off, retaining only the labels, fields, and buttons required to quickly complete the work.

MortCalc is an application that uses a lot of text to good effect on the main screen to explain the fields. However, other applications with this much text may be a candidate for a verbose toggle button.

Rule: Let users move small applications (applets) with floating views around.

Since the Newton has limited built-in scrolling, especially with the Notepad application, make sure that you enable users to move any floating views around so that all information on the screen is always accessible.

Rule: If you have a floating applet, make it easy for users to move data from the applet to another application.

Much of the pleasure of using MobileSoft’s MobileMath (commercial) application is the natural way you can drag the highlighted results from the applet’s view to the Notepad.

Rule: Don’t use flashing text anywhere in the application.

This is an old rule in user interface design. Aside from displaying your important information only half the time (while it’s flashing), it’s annoying, distracting, and consumes power needlessly.

Use other ways to attract attention to important information, including font size, bold text, and graphics.

Commuter features a flashing title which makes an effective application slightly annoying.

Rule: Use as few views as possible while maintaining readable screens.

Opening and closing views can be time consuming on the Newton, so minimize the amount of times users need to do this. In addition, applications with multiple views and levels can become confusing, especially on devices with small screens.

This seems contrary to how programmers usually organize information on the desktop. However, remember that the issue is screen size. The reason why nested views (windows) work on the desktop is because users have room to arrange them and maintain the context of the current operation.

Rule: Use the user interface components consistently.

Consistency is the golden rule of user interface design. For example, use the overview and arrow buttons to perform navigation. Don’t try to make users learn “another way” of doing the same thing.

Rule: Never use technical computer terms unless you are sure your audience will understand them.

Even though the Newton has introduced several new words into the PDA vocabulary, such as soup, frame, and store, refrain from using these words in your application. Your users should not need to understand these terms in order to use your application.

Discussed in this article…

Shareware Applications

• CheckPlease!, by Allan Hoeltje, [email protected]
• Commuter, by Ben Sharpe, [email protected]
• Convert! 2.0, by Clinton Logan, [email protected]
• Drug Finder (dFinder), by Ted Wei, Jr., [email protected]
• Graphing 101, by Prescience Corporation, [email protected]
• Metrorail, by Woofware, [email protected]
• MortCalc 1.0, by Steven Nygard, [email protected]
• Patience 1.0, by Nick Francis & Jonathan Greensted, [email protected]
• Solo 1.1, by Renaud Boisjoly, [email protected]

Commercial Applications

• MobileCalc and MobileMath, by MobileSoft, (408) 376-3475.

Remember that a PDA strives to be a consumer device and not a computer. In time, as the horizontal market develops, many applications will likely compete against traditionally published books and other titles.

Drug Finder (dFinder) includes a Soup Installation Utility with an “Install Soup” button. In general, it’s best to avoid these and other technical terms.

The exception to this rule, of course, is when you are developing an application aimed primarily at programmers or developers. In this case, avoiding technical terms is a sure way to confuse and frustrate.

Rule: Try to detect error conditions and work around them with as little user intervention as possible.

When you need to display an error message, explain the problem in the context of what the user is trying to do, as opposed to the task that the program is unable to complete. Again, use the language of the user and not the programmer.

Rule: Don’t use a button where you really intend to place static text.

Users will almost certainly try to tap the button and will be annoyed and confused.

Rule: Enable users to navigate sorted lists of information using an alphabetic keypad (like the Newton Names list).

Scrolling can be slow on the Newton. Enable your users to get where they want quickly and directly.

Rule: Have your program do the work for the user.

Since data input is slow and error-prone, have your application do as much of the work for the user as possible. This means using context information and filling in fields or setting options with as little input as possible.

In some applications, this could mean completing a form from information already stored in the Newton. On General Magic devices, you can even set an option to complete common words for you as you type them.

Rule: Reduce the amount of written input the user needs to perform.

We all know the Newton’s recognition system is less than 100% and will likely remain so for years. Be creative in substituting check boxes and pop-up lists for data entry, however, make sure it makes sense to the user.

Rule: Use the structure of the program to indicate the order in which users need to complete a form or perform a task.

In the case of a simple form, grouping the data entry fields in one region is more intuitive than having them all over the screen. Likewise, if order is important, position the fields from top to bottom.

However, it’s always important to remember that different cultures view different things as obvious. If you are aware of any of these differences, make your code flexible enough to easily support them.

Rule: Use sound to enhance your application, but never rely on it.

Sound can be a powerful tool to enhance the metaphor of your application. However, remember that producing sound consumes valuable power on your Newton. Also, people in meetings and other public areas tend to turn the sound off, so make sure your program is usable without the sound cues.

Rule: Placing items on the status bar is useful, however, be consistent.

Make sure that the items you place on the status bar conform to the size of existing items already there.

Rule: Use graphics frequently, yet efficiently.

Pages of text are tiresome on any computer; they are overwhelmingly tiring on a small screen with limited resolution (with potentially poor lighting). Using graphics breaks up the text, introduces a visual focus for the information, and can itself convey information more effectively in many cases.

However, graphics introduces overhead and requires extra storage. Think about how you can use graphics to help users navigate through your application.

Metrorail presents a map of the Washington D.C. subway system and enables users to click on stations for local sites and connecting information. This type of application has incredible potential as a truly useful horizontal PDA application.

Rule: Make the application entertaining. After all, the Newton strives to be a consumer device.

Right now, most applications that are entertaining are either games, or sample programs that perform little useful work. When you come across these programs, study how they use an interactive approach to engage users by entertaining them. The Newton designers realized this when they includes the “poof” scratch-out, and the “crumple” page deletion.

Rule: Include more information, or more ways of getting at information, than would be possible with paper.

Remember that users expect to get more value from the Newton than they already have with books, pen, and paper. When presenting information or performing a task, enable the user to do something extra.

Periodic Table enables users to get basic information about the elements. While this is useful, it would perhaps be even more interesting to be able to drag elements on top of each other and have a view display how they combine to form simple molecules (if possible). Now that’s a Periodic Table that would have been useful in high school.

Rule: Don’t be afraid to use the landscape mode.

The Newton was clearly designed to work best in portrait mode and no direct support is given to change the orientation. However, don’t let this stop you.

Some information simply works better when presented in landscape. You will have to construct your own user interface widgets to get the job done, however, it may be worth the effort. In addition, the Newton feels fine when held on its side.

A good comparison of the effectiveness of landscape vs. portrait for some applications are the programs Patience (landscape mode) and Solo (portrait mode). Both programs play the game of solitaire, however the natural horizontal orientation of solitaire make a good candidate for landscape.

Rule: Optimize your code and navigation through your program.

Don’t let anyone tell you that speed is unimportant—in the consumer market it can mean everything. Even though the program Convert requires limited navigation and performs relatively simple calculations, it is very fast and therefore a pleasure to use.