Feedback Search Top Backward Forward
EDM/2

The Codesmith's Library

Written by Carsten Whimster

 

Introduction

The Codesmith's Library is a monthly column which focuses on development oriented books and materials. The column is from the point of view of an intermediate PM C programmer and intermediate REXX programmer. Pick up whichever book strikes your fancy, and join the growing group of people following our PM programming columns. I have reviewed a number of beginner's books, and will try to concentrate a bit more on intermediate techniques and special topics from now on.

Please send me your comments and thoughts so that I can make this column as good as possible. I read and respond to all mail.

The GUI-OOUI War - Windows vs. OS/2, Mandel, is slightly different than most other books I have reviewed so far. It discusses interface design and psychology from the bottom up.

Errata

Well, life goes on, and I have finished one of the hardest months in my life, and should be on track for the rest of the year. Knock on wood. During this month I had to write a rudimentary file system, a swapping memory manager, and a reliable network protocol! But, as they say, that's another story.

The more time goes by, the more I enjoy working with Warp. The three above mentioned programs were supposed to run on SunOS when done, but were fully developed under Warp with Watcom C/C++! When it came to recompiling, all I had to do was copy the source code over, strip all ASCII 13's (why on earth don't they remove the requirement for these under OS/2?), and they compiled without an error. The fact that SunOS is more mature showed up in the fact that compiling under GCC fixed some minor errors with the standard I/O library I was having under Warp with Watcom. When the freeware compilers of one platform are more robust than the well-respected commercial compilers of another, well, I'll stop here. Of course, OS/2 also has GCC, but it is a port of the UNIX version.

The GUI-OOUI War - Windows vs. OS/2

This book is a little different than what I have reviewed so far. It is more theoretical in nature, and not nearly as terse as most programming books are; in fact it is written very "loosely". Before I explain what I mean with that, let me list the chapters:

  1. You and User Interfaces: The Real World
  2. The Psychology of Humans and Computers
  3. The Golden Rules of User Interface Design
  4. Interface Standards and Guidelines
  5. The Interface Design Process
  6. CUIs and Menus: The Dawn of User Interfaces
  7. Microsoft Windows: A GUI for the Masses
  8. IBM's OS/2: Is the OOUI Ready for Prime Time?
  9. GUIs and OOUIs: What the Tests Show
  10. Multimedia: The Future? Or, Just New Technology
  11. New Technologies: User Interfaces of the Future
  12. Index
Because of the unusual (for this column) format, I have had to review this book slightly differently. I cannot just recite what is being discussed in the various chapters, because the details of the subject are what is important. If I try to list the details, I end up writing a huge review, and a side-effect is that I would probably make purchasing the book less attractive <grin>. Therefore, I will just outline what each chapter discusses.

The first chapter is really an introduction to 'interfaces' in general. Many examples are discussed, such as VCRs (of course), telephones, cars (another perennial favorite), and so on. The point being made here is that some interfaces are successful, and others are not. It is not an uncommon occurrence to come across a new gadget, and to be totally unable to figure out how the designers intended you to use it. Bad choices of symbols, ambiguous commands and many other phenomena are at fault here, and frequently, the designers of these new gadgets do not have the proper background to understand the mechanics of human cognition. Of course, we can't all be psychologists, but there is definitely something to be done. Product usability is defined loosely in this chapter, and some approaches (both good and bad) to usability are outlined. Finally, the background for the IBM- Microsoft "war" is briefly explained. Basically, it comes down to disagreements, conflicting agendas, and money. Doesn't every feud?

In chapter two, the preferences, and different types of people and interfaces are looked at in some depth. The problems of poor user interfaces is raised again, with many illustrations. The fact is that more than one or two people are usually involved in any non- trivial project, and each of these people should act within their area of expertise, cooperating to create a superior product. Everyone has ideas, of course, but just as frequently as not, an uninformed idea can turn into a small disaster, with respect to usability. One amusing anecdote is stated here (which is commonly heard in computer circles): when a number of students were let loose writing essays on Macs, and also on a text-mode word processor on DOS, the Mac users ended up with inferior, but prettier essays. It turns out that this is not a Mac versus PC issue at all, but a GUI versus CUI (character-based user interface) issue. On the other hand, the GUI users enjoyed the experience more, so which is better ultimately? It is harder to say than it seems initially, because happier people can be more productive in other ways. CUA (IBM's interface guidelines), the idea of the proper use of colors, and a model called "the iceberg chart" are all introduced here. The iceberg chart states that 10% of "the iceberg" is related to aesthetics and the like, 30% with Interaction techniques, and a full 60% of the importance of the designer's job is related to object relationships, properties, behavior, and so on. An example illustrating these concepts is made of the "making a jam sandwich" program, in its various incarnations. The text-mode program is basically very linear in feel, and is mostly a disaster. The user has to know how the designer thinks in order to be able to use the program! This sounds silly, but we are all familiar with picking up some program with a lot of promise, and then throwing it out because it requires us to change our work habits, or ways of thinking too much. These programs work the way the designer works, and don't let you do things your way. This is a recurring theme in the book, by the way; all the way through. Finally, short-term and long-term memory are introduced, as these concepts will be used throughout the book to help explain why people work the way the do.

Chapter three starts talking about what interfaces should be like, and why you should care. The key idea is to place the user in the driver's seat. They will be using the program, and they should be able to do it their way. The evils of "modes" is briefly discussed (a pet peeve of mine; anyone out there who has tried any of the numerous Doom game editors will know what I mean). Modes have their place, but not nearly as often as they are encountered. Customization is a very important part of letting a user feel comfortable with your program, and the more aspects are customizable, the more users will like your program (all other things being equal). Another important item is to have visual cues to remind the user of how to accomplish tasks. This relieves their short-term memory, and lets them focus on the job at hand, rather than having to memorize procedures. In addition, you should assist the user's long-term memory by providing lists and menus with items that they can recognize. Consistency is another very important facet of interface design. If something works a certain way, some other similar component should work similarly.

Chapter four is more or less dedicated to outlining and explaining some of the more important parts of the user interface standards, specifically CUA (Common User Access). A bit of background is given as well, i.e. where does CUA come from, and where is it headed. Why does it specify certain things in the way it does, and why have other things been changed. Basically, Windows is CUA '89, whereas the Work Place Shell is CUA '91, and later. As this has had me curious, I was delighted to find an explanation for the reasoning behind the original "ugly" colors of OS/2 2.0. It turns out that a whole study of the effect of colors on people had been done, and various hues and shades had been linked to certain psychological factors and reactions. When enough was understood about this (!), the schemes were designed to assist people as much as possible. I am not sure where they went wrong, but I have never used OS/2 for more than a few minutes before have had to change the defaults. Different strokes for different folks, I guess. Near the end of the chapter, a few of the issues surrounding internationalization are raised.

In chapter five, how one goes about actually designing a real-world program to conform to interface guidelines is illustrated. The various issues that face the designer are listed, and the steps taken to address each of these issues are outlined, with justification. The importance of testing, or verifying the correctness of your interface is clearly spelled out. After all, once you have designed the "killer" interface to take the world by storm, wouldn't it be nice to know that you have it right, before spending hours and hours coding around this interface, until even the smallest change will have severe repercussions on the deadlines and cost?

In chapter six we are (finally?) treated to a bit of a history of the interface, starting with DOS. The strong points (few), and the weak points are described, and the roots of the DOS CUI are explained (UNIX, if you can believe it! Why did they remove so much of what makes UNIX so strong?). Then menus are explained, replete with pictures of the earliest full-screen menus. All along the way, lists of advantages and disadvantages are given. I don't necessarily agree with all the points that are being made here, but I am probably nit-picking, and in any case, I can only state my personal experience here, since I have no formal education in the subject. The menus of OS/2 are also explained, along with the reasoning that led to their creation. A brief guide to the proper design (and re- design) of menus follows.

Chapter seven is about Microsoft Windows. No, this is not (mostly) a Windows-bashing chapter, but rather an explanation of where we have come from, and the type of background new OS/2 users may have. The roots of Windows (the Macintosh and the work done at Xerox's Palo Alto Research Center) are explored, and the foundations of any GUI (Windows, Icons, Menus, Pointers) are explained. The term WYSIWYG (What You See Is What You Get) is introduced, and the importance of the concepts behind it are discussed in some detail. Basically, it is easier to learn and remember an interface which represents things visually that you can understand and remember (although there is more to it than just that). The various components of windows, menus, lists, and so on are all listed, along with the knowledge required for a user to be able to use these types of system. In spite of the myth that GUIs are so easy to use that no or little training is necessary, there is actually quite a learning curve to it, and the new user is confronted with a steep wall to be climbed before they can be productive in this new environment. The object-action sequence is the basic task model in Windows, and of course it has both advantages and disadvantages. The main drawback to GUIs is that they are very application oriented. The icon represents the application, the groups represent the application, and once you are in an application, you have to figure out how to get your document/spreadsheet/work into it. The question of whether the GUI hides the system from the user is raised, and some of the various metaphors that applications have tried are listed. Using a metaphor to make a program interface easier is all fine and dandy, but you also have to be very careful not to stray from the metaphor, and get carried away with gimmicks which in the end subtract from the overall feel of the application. Later in the chapter, the various controls available in Windows are listed, and an introduction is provided to the mouse as input, and drag-and-drop.

In the next chapter, we are finally treated to an in-depth description of OS/2's new interface, the Work Place Shell. The object-orientation is explained very carefully, and the reasoning is given for many seemingly small aspects of it. A bit of a history is also provided, but I skipped this lightly, because there is such an introduction in almost every book on OS/2 I have read, and that is quite a few. An OOUI (Object Oriented User Interface) contains almost all aspects of a GUI, and then some. Much of the difference between GUIs and OOUIs lies in the way in which things are manipulated, however. If you are still using OS/2 more or less like you used to use Windows, you probably don't know what I am talking about here, but if you are intrigued by the WPS, drag- and-drop, templates, objects, and so on, then you are getting the idea. The differences are subtle to explain, but profound in actual use. This is all part of CUA '91 and later. One of the basic ideas behind it is to keep related things and actions together. Thus, the time is set with the clock, not at the prompt or the control panel as in DOS/Windows. Another important area of focus is the notebook metaphor. The first time a user sees a notebook, they just intuitively know how to go from page to page. It seems obvious, but very few people ever thought of this idea in the hey-days of Windows, for example. It really wasn't all that obvious what a good idea this was before OS/2 2.0 was released. The object-action sequence has now been expanded upon, and we now choose the object to be manipulated followed by the action needed to a much greater extent than before. One example of this is the way that the WPS generally presents us with documents, rather than applications. There are still an awful lot of applications written for OS/2 which really would be just as at-home in Windows. The object-orientation is a hard concept for the programmer to embrace fully. One of the more obvious aspects of this object-orientation is pop-up menus. Instead of having to root through menu after menu, looking for an item to do what you want, you just get a pop-up menu with only the items on it that are relevant. Objects also represent actual devices in OS/2, to some extent. Most objects in OS/2 have more than one view to choose from. A rather trivial example of this is the icon view/details view common on the open item of many pop-up menus. A more conceptual example is thinking of the help facility as the "help view" of an application or object. Many examples are given throughout the chapter, and I wont attempt to list them all here. Much more detail is given on drag-and-drop, and how it works, both visually and conceptually. There is a fair amount of referring back to Windows going on in this chapter, for the sake of saying "this is where we were, and this is why it changed and what it became". The fact that learning the OS/2 interface can be more difficult for a Windows user than a Mac or DOS user is introduced. It sounds strange, but it makes sense.

Chapter nine gives some concrete examples and tests that show why OOUIs are where we are headed. There are many pitfalls in both performing and evaluating studies, but a sentence from earlier in the book really points out where some of these problems stem from. One of the first studies done by Microsoft had the expressed purpose of demonstrating that GUIs were easier to use. The point here is that they did not say "Are GUIs easier to use?"; they said "Show us that GUIs are easier to use". This is obviously not the right way to approach this type of study, but it is very common. Usability tests are also frequently used to iron out bugs in interface guidelines. Before IBM requests that every OS/2 developer use the CUA guidelines to go by, they must be sure that they know what they are doing. Hence, a usability study is performed. One interesting outcome of this is that GUI/OOUI users are not necessarily more prolific, as I stated earlier, but they are definitely more satisfied. This is important, because happy employees and users stay longer, and are probably indirectly more productive. GUIs and OOUIs are not perfect, however, and the ten major problem areas are listed. Stay away from these common pitfalls, and you are on your way. I won't ruin the surprise here, though.

The penultimate chapter discusses the relatively new field of multimedia. Is it all hype, or is there actually some usefulness there? Opinions on this range as widely as in politics, or which hockey team will win the Stanley Cup this year. Some say that it is overblown, and just candy and toys. Others say that it is the wave of the future. One thing is common to both sides, however; it is hard to define. Is it video? Is it sound? Both? Neither? It is hard to say, but most people agree that it can be used to make systems easier to use. On common example of multimedia in action is the touch-screen booths that stand around in malls. They just plain have to be easy as pie, otherwise people won't use them, because there is no training at all.

The last chapter discusses the interfaces of the future. When you think about it, this is not easy to discuss from the present <grin>. If we knew what they would be like, they would be here already. You can look at what we have today, and extrapolate, however. Mobile computing is already strong, and workgroup computing, such as Lotus Notes, is getting more mature all the time. Home computing is an idea whose time has come already, but it is one which many companies have trouble with. Trust is a major factor. Interaction is another issue. What does it mean, and how can we use it effectively? Pen computing is an area of computing which has been getting a lot of attention, but few products exist. The same goes for its cousin, PDAs (Personal Digital Assistants). Speech technology is an area where IBM is currently one of the leaders of the field. ESP (Extra Sensory Perception) technology is a slightly more flaky or technologically difficult area, depending on who you talk to <grin>. Finally, virtual reality is almost a reality today, although the book was written before the current wave of products really hit the market.

Summary

There are two main impressions I get from this book: the author is very knowledgeable, and the book needs a thorough edit, with brevity in mind. If it is aimed at OS/2 PM and WPS programmers, and managers, as seems to be the case, it is at times very hard to get through. Many of the chapters have so many examples, and so few concrete conclusions or recommendations that the impression they leave is a little muddy.

Having said that, there is a large amount of good information in here, and I have learned a lot about interfaces by reading it. It will definitely affect the way I use interfaces in my programs in the future, and I will most likely refer back to it for some time to come. The discussion of Windows versus OS/2 really turns out to be a discussion of GUIs versus OOUIs, and the amount of heated discussion is fortunately kept to a minimum. It should be interesting to see how much of the body of predictions about future usage of computers and interfaces turns out to be true.

The GUI-OOUI War - Windows vs. OS/2, Mandel

  • Van Nostrand Reinhold. ISBN 0-442-01750-2. US$30, CAN$45
  • Intended audience: OS/2 GUI programmers
  • Mark: B

Reviewed Books

Our Bookstore has reviews and links to Amazon for all books we have reviewed in the past, as well as several books waiting to be reviewed, and others which we recommend.