X-Designer - The Leading X/Motif GUI Builder - Click to download a FREE evaluation
|
X-Designer - The Leading X/Motif GUI Builder - Click to download a FREE evaluation |
In this chapter:
Chapter: 1
Introduction to Motif
So many computers, so many operating systems, so many toolkits1.Developing an application used to be a simple choice, depending upon whether we targeted the application for the Microsoft world, for UNIX, or for the Apple MacIntosh. Each had its own distinct toolkit interface. If you wanted to write your application cross-platform, you had to encapsulate the functionality through a set of common C++ classes, each of which would have a separate internal implementation for each operating environment. Yet for the myriad of UNIX platforms, all you had to do was write Motif.
But now there is Linux, and Java, and GTK+ and Qt, and a host of other considerations. Life never was so complex, and all we want to do is write an application. In many ways, the task of the application programmer is now to write the application with the greatest degree of toolkit independence that can be achieved, whether through a client-server architecture to separate the interface from the back-end processing, or still through encapsulation techniques which hide the underlying toolkit from the higher levels. The toolkit ought in principle to be irrelevant; in practice this is not possible: there has to be a windowing toolkit somewhere at the bottom level, and that toolkit must be appropriate to the target operating system and environment. A emulator or cross-platform common toolkit never quite succeeds in providing the requisite functionality in all levels of detail; for some platforms, if it is not in the native toolkit, it simply isn't ported; this is particularly true of Windows environments, where using anything other than MFC is simply wrong in principle. MFC is the native windowing environment for Windows. It just is.
So why Motif? Because it remains what it has long been: the common native windowing toolkit for all the UNIX platforms, fully supported by all the major operating system vendors. It is still the only truly industrial strength toolkit capable of supporting large scale and long term projects. Everything else is tainted: it isn't ready or fully functionally complete, or the functional specification changes in a non-backwards-compatible manner per release, or there are performance issues. Perhaps it doesn't truly port across UNIX systems, or it isn't fully ICCCM compliant with software written in any other toolkit on the desktop, or there are political battles as various groups try to control the specification for their own purposes. Indeed it may matter very much whose version of the toolkit you have managed to acquire, or if the toolkit is open sourced so you have no idea who is going to stick their untrusted fingers into it at any time. So many problems with each choice you make. With Motif, you know where you are: its stable, its robust, its professionally supported, and it all works.
And yet whatever the toolkit you choose to write your application in, the design goals ought to remain precisely the same. You should be trying to present the application to the user in the most consistent, simple to use, and simple to understand manner of which you are humanly capable. Interfaces consist of basic controls and layout managers, irrespective of the language it is written in. In this respect, Motif, despite its long history, remains as fully capable as any basic toolkit. It is true that Motif 1.2 lacked some of the features which we now expect from a windowing toolkit - the philosophy of design moves on with time - but these issues are addressed in the 2.1 version of the toolkit. The ComboBoxes, SpinBoxes, Tree and Grid layouts are all there. Where Motif differs from other toolkits is the strength of the component inter-operability. The Motif toolkit is not just a collection of controls written in a particular language: everything, but everything, is designed to work with everything else, whether it be navigation between controls, or inter-object data transfer, or the sharing of style resources throughout the control hierarchy. And because it is based on top of the X interface toolkit, Xt, it will work with the vast range of third party components and add-ons which are available to the X world. In many ways, it is precisely these aspects which are stronger in the Motif 2.1 toolkit than ever before.
Much of this chapter can be read as a general introduction to graphical user interface toolkits; the concepts which we present are not specific to Motif, or indeed to any other windowing toolkit. The ideas presented here should be general enough to read in a toolkit independent manner; how you implement those ideas using the specific Motif toolkit is covered in subsequent chapters of this book.
Basic User Interface Concepts
Whether you are the designer of the software or an engineer responsible for implementing someone else's design, there are some basic principles that will benefit you in your work.Let's begin with the basics:
All applications running on a user's workstation should have a consistent interface design. Programs that deviate from the expected design will almost assuredly confuse the user even if the changes were intended for the user's benefit. Chances are also high that the user will not want to use the questionable software again.
Users rely on rote memory; they will remember seemingly complicated interface interaction techniques provided that the functions they perform are useful and are invoked frequently. There is a limit, however, to how much users want to remember. It is important that essential or frequently used functions follow memorable patterns.
Novice users will probably not want to customize or alter their applications in any way. If they do, the available methods must be as easy and painless as possible.
Users with more experience most certainly might want to customize the application in all sorts of ways: the greater degree of customization which the application allows, the better. 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 become over-problematic 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 important 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.
The customization issue has partly been addressed in any case by environments like CDE, or the Schemes mechanisms on SGI platforms: users can choose from (and add to) a range of preset styles which will affect all applications on the desktop. Part of the work of the engineer is now to ensure that the application participates in desktop schemes of this kind, so that the user can customize in a general way rather than having to configure the style of every application individually.
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). Look and Feel is not something specific to Motif; all windowing toolkits should present a standardized internally-consistent methodology so that the user is comfortable using the controls which the application presents. Specific toolkits, however, have distinct look and feel, although since some toolkits share a common design philosophy there is a cross-over so that users familiar with one platform are not necessarily naked when presented with an alternative. This will be made clear in the paragraphs which follow. Firstly, let us look at a Motif application.Figure 1-1 shows a Motif application, used for taking snapshots of windows or capturing areas of the screen.
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 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 inter-operability 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).2
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 output model describes what the objects on the screen look like. This model includes the shapes of buttons, the use of three-dimensional effects, the use of cursors and bitmaps, and the positioning of windows and subwindows. Although some recommendations are given concerning the use of fonts and other visual features of the desktops, Motif is flexible in most of these recommendations.
The input model specifies how the user interacts with the elements on the screen. 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.
Those familiar with Microsoft Windows should have little trouble in using a Motif-based application.This is not a coincidence; 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 modelled after IBM's Common User Access (CUA) specification, which defines the interface for OS/2 and Microsoft Windows. The reason for this is that there is a proven business model for profiting from an "open systems" philosophy. As a result, all of the major operating system vendors support Motif as their native graphical interface environment.
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 pre-written 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.
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:
Keep the interface as simple as possible.
Make direct connections to real-world objects or concepts.
If real-world metaphors are not available, improvise.
Don't restrict functionality to accommodate simplicity. 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 used to 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 feature full." They're half-right; the problem is not that they are too feature full, 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 feature full 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. Under-use 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 the goals of both 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, an irate customer just might call you for help.
1 Infandum, regina, iubes renouare dolorem...2 Both books have been published for OSF by Prentice-Hall and are available in most technical bookstores.
|
|
