Contents Previous Next

2 Introduction to Motif

This chapter answers the question "Why Motif?" in terms of the development of applications that are "easy enough for your mother to use." It suggests some of the complexities that the programmer has to master in order to make an application simple.

Congratulations! After slaving behind the computer for months, fighting a deadline that seemed impossible to meet, you've finished your software product and it's a big hit. The critics love it, you're in the money, and everyone, including your mother, is buying your new product. Just as everything seems to be going your way, your worst nightmare comes true: your mother calls and asks you how to use it.

An unlikely scenario? Not if you're developing applications to run under the Motif graphical user interface (GUI). As a proposed standard for graphical user interfaces, Motif may be implemented on a wide range of computer platforms, from large IBM mainframes right down to the PC that your mom may be using. The Open Software Foundation (OSF), developer of the Motif GUI, hopes to reach all kinds of computers and computer users no matter how advanced (or limited) their computer skills may be.

So, will your mom really call you for help? Well, mine did. In fact, she did something worse. She wanted me to explain how to use a software product I didn't write. I didn't know how her software worked or even what it was. Fortunately, though, the software was based on Microsoft Windows, which has more than a passing similarity to Motif. The experience of providing technical support to my mother reminded me of some of the fundamental concepts behind the design of a user interface and the role of the application programmer in carrying out that design.

2.1 A True Story

Before I tell my story, let me start with a little background. I have been developing software for the X Window System for several years. Every now and then, when the family gets together for dinner, someone always asks the same thing, "So, explain it to me again: just what is it that you do?" I launch into my usual speech: "It's called X Windows, dad... uh, no, mom, it's computer software... it's rather hard to explain, but..." The attention span lasts only until the next course is served, at which time the discussion turns to new ways for cooking eggplant. Little did I realize that something actually registered with someone in my family, because shortly thereafter, I got a call from my mom.

Mom: Guess what?!

Me: What?

Mom: Our company is switching to a new line of software based on your work!

Me: Really? You're going to use electronic mail?

Mom: No, all of our insurance packages use this new software that runs under Windows. You wrote that, didn't you?

Me: No, mom. I write software using X Windows -- and I didn't write X, I just use it. I think you're talking about Microsoft Windows. You're using it with your PC, right?

Mom: That's right, but it looks exactly like your software, so I figured you could show me how to use it. I have never seen this stuff before.

(Uh, oh... I see it coming now. Last time she wanted me to help her explain her computer to her, I ended up translating the entire DOS 2.0 user's guide into English, which she conveniently forgot in about a week.)

Me: Mom, I don't know Microsoft Windows, I know X Windows and they're not the same...

Mom: You mean you won't help me?

Me: You don't understand -- I can't help you. MS-Windows has nothing to do with X...


Me: I don't think I'm getting through to you.


Me: Ok, I'll be right over...

Despite all my explanations of the X Window System, the only keyword my mom remembered was Windows. I had high hopes, though, because I was actually going to teach her something related to what I do for a living. And this time she had to listen because her job depended on it.

After some fidgeting with diskettes and other necessary start-up procedures, I finally got Microsoft Windows 3.0 up and running. Sure enough, it looked just like Motif. Several applications came up by default: a clock, an editor of some sort, and a little calendar program. Immediately, the questions started flying at me:

Mom: How do you access those buttons at the top of the window?

Me: Those are called Pulldown Menus and every application has them. They are located in what is called a MenuBar.

Mom: What does "F1" mean?

Me: The "F" denotes a function key and the "1" indicates it's the first function key. Pressing it gives you help depending on where the cursor is. For example...

Mom (interrupting): Why are these keys labeled "ALT?" What do they do?

Me: Oh, those are used in conjunction with other keys. You press "ALT" and then some other key and you get special attention, like...

Mom (growing frustrated): Look what you did. Now there are too many windows up. How do I get back to the one I was using?

Me (fighting for words): Well, you see, you can move from one window to the next or between elements within a window by using the Tab key and possibly some other key like the Control key, the Shift key, or the Alt key, or maybe a combination of several of these keys depending on where you want to go...

Mom (sitting back and sighing): Oh, that's way too complicated, I'll never remember all that. And just look at those colors--they're awful.

Me (trying to sound encouraging): You can change them using this tool...

It was a long grueling day, but she eventually figured out how to do most of what she had to do. After she memorized those actions she used most frequently, she seemed quite capable and no longer needed my supervision. Her favorite trick was Alt-F3, which closed a window and terminated a program. Because she had several things figured out, I thought I'd dare teach her something new.

Me: You know, if you don't want to use that key sequence, you can define it yourself by...

Mom (protecting the computer like it was her only child ): NO! Don't touch anything! I know how to use it now, so don't confuse me any more!

My fault. I figured that since she was pleased that she could change window colors, she'd be eager to make other aesthetic alterations. Her reaction to my offer to teach her how to change keyboard input foreshadowed what was about to come. I was in the other room when I heard a screech: "The computer is broken! The Alt-F3 thingy you showed me doesn't work any more!" Sure enough, it didn't work on the window she was trying to use it on, but as we discovered, that was the only window on the screen where it didn't work. It turned out that the program she tried it on didn't understand the Alt-F3 thingy. It was devastating for my mom and, needless to say, she will never run that program again.

We never did get to her new insurance software; we didn't have to. All she needed to learn was how to use the graphical user interface. She now reports having figured out her company's software "all by herself" and I can't take credit for teaching her.

2.2 Basic User-interface Concepts

There are many lessons an application designer can learn from this story. As it so happens, the designer and the application programmer are often the same person. But whether you are the designer of the software or an engineer responsible for implementing someone else's design, there are still some basic principles that will benefit you in your work. Let's begin with the basics drawn from this particular story:

If you are a cast-in-stone UNIX software engineer, you may be quite skeptical about this last point. It is true that, traditionally, UNIX applications are extremely flexible, offering the user many options for modifying functional or aesthetic details. One of the first things the hard-core X programmer learns is that "the user is always right; if he wants to customize his interface, by God you had better let him."

This principle is absolutely correct. Unfortunately, many early X applications carry it too far and end up "spineless." Many such programs actually require the user to make certain customizations in order for the program to be usable or attractive. For some programs, the problem worsens if unreasonable customization settings are given, since there is no sanity-checking for unreasonable configurations.

So far, such customization issues have not gotten out of hand because UNIX and X applications are used almost exclusively by technical people who understand the environment and know how to work within it. But it is now time to consider users who know absolutely nothing about computers and who don't want to--they are only using your software because they have to.

2.3 What Is Motif?

So, back to Motif. What is it and how can it help you solve your user-interface design goals? To start, Motif is a set of guidelines that specifies how a user interface for graphical computers should look and feel. This term describes how an application appears on the screen (the look) and how the user interacts with it (the feel).

the figure shows a Motif application.

A Motif application

The user interacts with the application by typing at the keyboard, and by clicking, selecting, and dragging various graphic elements of the application with the mouse. For example, any application window can be moved on the screen by moving the pointer to the top of the window's frame (the title bar), pressing and holding down a button on the mouse, and dragging the window to a new location. The window can be made larger or smaller by pressing a mouse button on any of the resize corners and dragging.

Most applications sport buttons that can be clicked with the mouse to initiate application actions. Motif uses clever highlighting and shadowing to make buttons, and other components, look three-dimensional. When a button is clicked on, it actually appears to be pressed in and released.

A row of buttons across the top of most applications forms a menu bar. Clicking on any of the titles in the menu bar pops up a menu of additional buttons. Buttons can also be arranged in palettes that are always visible on the screen. When a button is clicked, the application can take immediate action or it can pop up an additional window called a dialog box. A dialog box can ask the user for more information or present additional options.

This style of application interaction isn't new to most people, since the Apple MacIntosh popularized it years ago. What is different about Motif is that the graphical user interface specification is designed to be independent of the computer on which the application is running.

Motif was designed by the Open Software Foundation (OSF), a non-profit consortium of companies such as Hewlett-Packard, Digital, IBM, and dozens of other corporations. OSF's charter calls for the development of technologies that will enhance interoperability between computers from different manufacturers. Targeted technologies range from user interfaces to operating systems.

Part of OSF's charter was to choose an appropriate windowing system environment that would enable the technology to exist on as wide a range of computers as possible. It was decided that the OSF/Motif toolkit should be based on the X Window System, a network-based windowing system that has been implemented for UNIX, VMS, DOS, Macintosh, and other operating systems. X provides an extremely flexible foundation for any kind of graphical user interface.

When used properly, the Motif toolkit enables you to produce completely Motif-compliant applications in a relatively short amount of time. At its heart, though, Motif is a specification rather than an implementation. While most Motif applications are implemented using the Motif toolkit provided by OSF, it would be quite possible for an application implemented in a completely different way to comply with the Motif GUI. The specification is captured in two documents: the Motif Style Guide, which defines the external look and feel of applications, and the Application Environment Specification, which defines the application programmer's interface (API). Both books have been published for OSF by Prentice-Hall and are available in most technical bookstores.

The Motif specifications don't have a whole lot to say about the overall layout of applications. Instead, they focus mainly on the design of the objects that make up a user interface--the menus, buttons, dialog boxes, text entry, and display areas. There are some general rules, but for the most part, the consistency of the user interface relies on the consistent behavior of the objects used to make it up, rather than their precise arrangement.

The Motif specification is broken down into two basic parts:

The key point of the specification is that consistency should be maintained across all applications. Similar user-interface elements should look and act similarly regardless of the application that contains them.

Motif can be used for virtually any application that interacts with a computer user. Programs as conceptually different as a CAD/CAM package or an electronic mail application still use the same types of user-interface elements. When the user interface is standardized, the user gets more quickly to the point where he is working with the application, rather than just mastering its mechanics.

My experience with Microsoft Windows and my mother's new software demonstrates how far Motif has come in reaching this goal. I was faced with a window system that I had literally never seen before and an operating system I rarely use (DOS), but that didn't prevent me from using the application. This is not a coincidence; I knew how to use MS-Windows because its user-interface is based on the same principles as Motif. Motif can be seen as a superset of both MS-Windows and Presentation Manager. Even though the others came first, Motif views them as specific implementations of an abstract specification.

The Motif interface was intentionally modeled after IBM's Common User Access (CUA) specification, which defines the interface for OS/2 and Microsoft Windows. The reason for this is twofold: first, there is a proven business model for profiting from an "open systems" philosophy; second, the level of success and acceptance of Microsoft Windows in the PC world is expected to be quite substantial. As a result, more and more vendors are jumping on the bandwagon and are supporting Motif as their native graphical interface environment.

Just as my mom becomes more and more familiar with how to use Windows-based software, so too are thousands of other PC users. As the PC world migrates to UNIX and other larger-scale computers, so too will their applications. In order to keep their customer base, the developers of those PC applications will adopt Motif as the GUI for the UNIX versions of their software. As a result, the next few years will see the number of Motif users and developers grow astronomically as Motif becomes the focal point for software and hardware companies alike.

You have two options for making applications Motif-compliant. You can write the entire application yourself, and make sure that all your user-interface features conform to the Motif GUI specifications, or you can use a programming toolkit, which is a more realistic option. A toolkit is a collection of prewritten functions that implement all the features and specifications of a particular GUI.

However, a toolkit cannot write an application for you, nor can it enforce good programming techniques. It isn't going to tell you that there are too many objects on the screen or that your use of colors is outrageous. The job of Motif is solely to provide a consistent appearance and behavior for user-interface controls. So, before we jump into the mechanics of the Motif toolkit, let's take a moment longer with the philosophy of graphical user interfaces.

2.4 Designing User Interfaces

The principles behind an effective user interface cannot be captured in the specifications for Motif or any other GUI. Even though the Motif toolkit specifies how to create and use its interface elements, there is still quite a bit left unsaid. As the programmer, you must take the responsibility of using those elements effectively and helping the user to be as productive as possible. You must take care to keep things simple for the beginner and, at the same time, not restrict the more experienced user. This task is perhaps the most difficult one facing the programmer in application design.

There is frequently no right or wrong way to design an interface. Good user-interface design is usually a result of years of practice: you throw something at a user, he plays with it, complains, and throws it back at you. Experience will teach you many lessons, although we hope to guide you in the right direction, so that you can avoid many common mistakes and so that the ones that you do make are less painful.

So, rather than having absolute commandments, we rely on heuristics, or rules of thumb. Here is a rough list to start with:

This list may sound flippant, but it is precisely what makes designing an interface so frustrating. Keeping an interface as simple as possible relies on various other factors, the most basic of which is intuition. The user is working with your application because he wants to solve a particular problem or accomplish a specific task. He is going to be looking for clues to spark that connection between the user interface and the preconceived task in his mind. Strive to make the use of an application obvious by helping the user form a mental mapping between the application and real-world concepts or objects. For example, a calculator program can use buttons and text areas to graphically represent the keypad and the one-line display on a calculator. Most simple calculators have the common digit and arithmetic operator keys; a graphical display can easily mimic this appearance. Other examples include a programmatic interface to a cassette player, telephone, or FAX machine. All of these could have graphical equivalents to their real-world counterparts.

The reason these seemingly obvious examples are successful interface approaches is because they take advantage of the fact that most people are already familiar with their real-life counterparts. But there is another, less obvious quality inherent in those objects: they are simple. The major problem concerning interface design is that not everything is simple. There isn't always a real-world counterpart to use as a crutch. In the most frustrating cases, the concept itself may be simple, but there may not be an obvious way to present the interaction. Of course, once someone thinks of the obvious solution, it seems odd that it could have been difficult in the first place.

Consider the VCR. Conceptually, a VCR is a simple device, yet statistics say that 70% of VCR owners don't know how to program one. How many times have you seen the familiar 12:00-AM flashing in someone's living room? Researchers say that this situation occurs because most VCRs are poorly designed and are "too featureful." They're half-right; the problem is not that they are too featureful, but that the ways to control those features are too complicated. Reducing the capabilities of a VCR isn't going to make it easier to use; it's just going to make it less useful. The problem with VCRs is that their designers focused too much on functionality and not enough on usability.

So, how do you design an interface for a VCR when there is no other object like it? You improvise. Sure, the VCR is a simple device; everyone understands how one is supposed to work, but few people have actually designed one that is easy to use until recently. Maybe you've heard about the new device that, when connected to your VCR, enables you to have a complete TV program guide displayed on your screen in the bar-graph layout similar to the nightly newspaper listings. All you have to do is point and click on the program you want to record and that's it--you're done. No more buttons to press, levels of features to browse through, dials to adjust or manuals to read. At last, the right interface has been constructed. None of the machine's features have been removed. It's just that they are now organized in an intuitive way and are accessible in an simple manner.

This method for programming VCRs satisfies the last two heuristics. Functionality has not been reduced, yet simplicity has been heightened because a creative person thought of a new way to approach the interface. The lesson here is that no object should be difficult to use no matter how featureful it is or how complex it may seem. You must rely heavily on your intuition and creativity to produce truly innovative interfaces.

Let's return to computer software and how these principles apply to the user-interface design model. The first heuristic is simplicity, which typically involves fewer, rather than more, user-interface elements on the screen. Buttons, popup menus, colors, and fonts should all be used sparingly in an application. Often, the availability of hundreds of colors and font styles along with the attractiveness of a three-dimensional interface compels many application programmers to feel prompted, and even justified, in using all of the bells and whistles. Unfortunately, overuse of these resources quickly fatigues the user and overloads his ability to recognize useful and important information.

Ironically, the potential drawbacks to simplicity are those that are also found in complexity. By oversimplifying an interface, you may introduce ambiguity. If you reduce the number of elements on your screen or make your iconic representations too simple, you may be providing too little information to the user about what a particular interface element is supposed to do. Underuse of visual cues may make an application look bland and uninteresting.

One of Motif's strengths is the degree of configurability that you can pass on to the end user. Colors, fonts, and a wide variety of other resources can be set specifically by the user. You should be aware, however, that once your application ships, its default state is likely to be the interface most people use, no matter how customizable it may be. While it is true that more sophisticated users may customize their environment, you are ultimately in control of how flexible it is. Also, novice users quickly become experts in a well-designed system, so you must not restrict the user from growth.

Simplicity may not always be the goal of a user interface. In some cases, an application may be intentionally complex. Such applications are only supposed to be used by sophisticated users. For example, consider a 747 aircraft. Obviously, these planes are intended to be flown by experts who have years of experience. In this case, aesthetics is not the goal of the interior design of a cockpit; the goal is that of functionality.

In order to design an effective graphical user interface for an application, you must evaluate both the goals of your particular application and your intended audience. Only with a complete understanding of these issues will you be able to determine the best interface to use. And remember, your mom just might call you for help.

Contents Previous Next