32 Some O-O techniques for graphical interactive applications Famous Designer has recently designed an automobile.It has neither a fuel gauge,nor a speedometer,nor any of the idiot controls that plague other modern cars.Instead,if the driver makes a mistake,a large "? lights up in the middle of the dashboard."The experienced driver",says Famous,"will usually know what went wrong". Unix folklore.(Instead of "Famous Designer",the original names one of the principal contributors to Unix. erinerfaces have beomrepartof ay udt Advances in display hardware,ergonomics (the study of human factors)and software have taken advantage of interaction techniques first pioneered in the seventies:multiple windows so you can work on several jobs,mouse or other fast-moving device so you can show what you want,menus to speed up your choices,icons to represent important notions,figures to display information visually,buttons to request common operations. The acronym GUL,for Graphical User Interfaces,has come to serve as a general slogan for this style of interaction.Related buzzwords include WYSIWYG(What You See Is What You Get),WIMP("Windows,Icons,Menus,Pointing device")and the phrase "direct manipulation",characterizing applications which give their users the impression that they work directly on the objects shown on the screen. These impressive techniques,not long ago accessible only to users of a few advanced systems running on expensive hardware,have now become almost commonplace even on the most ordinary personal computers.So commonplace and popular,in fact,that a software developer can hardly expect any success from a product that uses just a line-oriented interface,or even one that is full-screen but not graphical. Yet until recently the construction of interactive applications offering advanced graphical facilities remained so difficult as to justify what may be called the Interface Conjecture:the more convenient and easy an application appears to its users,the harder it will be for its developers to build. One of the admirable advances of the software field over the past few years has been to start disproving the interface conjecture through the appearance of good tools such as interface builders
32 Some O-O techniques for graphical interactive applications Famous Designer has recently designed an automobile. It has neither a fuel gauge, nor a speedometer, nor any of the idiot controls that plague other modern cars. Instead, if the driver makes a mistake, a large “?” lights up in the middle of the dashboard. “The experienced driver”, says Famous, “will usually know what went wrong”. Unix folklore. (Instead of “Famous Designer”, the original names one of the principal contributors to Unix.) Elegant user interfaces have become a required part of any successful software product. Advances in display hardware, ergonomics (the study of human factors) and software have taken advantage of interaction techniques first pioneered in the seventies: multiple windows so you can work on several jobs, mouse or other fast-moving device so you can show what you want, menus to speed up your choices, icons to represent important notions, figures to display information visually, buttons to request common operations. The acronym GUI, for Graphical User Interfaces, has come to serve as a general slogan for this style of interaction. Related buzzwords include WYSIWYG (What You See Is What You Get), WIMP (“Windows, Icons, Menus, Pointing device”) and the phrase “direct manipulation”, characterizing applications which give their users the impression that they work directly on the objects shown on the screen. These impressive techniques, not long ago accessible only to users of a few advanced systems running on expensive hardware, have now become almost commonplace even on the most ordinary personal computers. So commonplace and popular, in fact, that a software developer can hardly expect any success from a product that uses just a line-oriented interface, or even one that is full-screen but not graphical. Yet until recently the construction of interactive applications offering advanced graphical facilities remained so difficult as to justify what may be called the Interface Conjecture: the more convenient and easy an application appears to its users, the harder it will be for its developers to build. One of the admirable advances of the software field over the past few years has been to start disproving the interface conjecture through the appearance of good tools such as interface builders
1064 SOME O-O TECHNIQUES FOR GRAPHICAL INTERACTIVE APPLICATIONS $32.1 More progress remains necessary in this fast-moving area.Object technology can help tremendously,and in fact the fields denoted by the two buzzwords,GUI and O-O, have had a closely linked history.Simply stated,the purpose ofthis chapter is to disprove the Interface Conjecture,by showing that to be user-friendly an application does not have to be developer-hostile.Object-oriented techniques will help us concentrate on the proper data abstractions,suggest some of these abstractions,and give us the ability to reuse everything that can be reused. A complete exploration of O-O techniques for building graphical and interactive applications would take a book of its own.The aim of the present chapter is much more modest.It will simply select a few of the less obvious aspects of GUI building,and introduce a few fundamental techniques that you should find widely applicable if your work involves designing graphical systems. 32.1 NEEDED TOOLS What tools do we need for building useful and pleasant interactive applications? End users,application developers and tool developers First,a point of terminology to avoid any confusion.The word "user"(one of the most abused terms in the computer field)is potentially misleading here.Certain people,called application developers,will produce interactive applications to be used by other people, to be called end users;a typical end user would be a dentist's assistant,using a system built by some application developer for recording and accessing patient history.The application developers themselves will rely,for their graphical needs,on tools built by the third group,tool developers.The presence of three categories is the reason why "user" without further qualification is ambiguous:the end users are the application developers users;but the application developers themselves are the tool developers'users. An application is an interactive system produced by a developer.An end user who uses an application will do so by starting a session,exercising the application's various facilities by providing the input ofhis choice.Sessions are to applications what objects are to classes:individual instances of a general pattern. This chapter analyzes the requirements of developers who want to provide their end users with useful applications offering graphical interfaces. Graphical systems,window systems,toolkits Many computing platforms offer some tools for building graphical interactive applications.For the graphical part,libraries are available to implement designs such as GKS and PHIGS.For the user interface part,basic window systems(such as the Windows Application Programming Interface,the Xlib API under Unix and the Presentation Manager API under OS/2)are too low-level to make direct use convenient for application developers,but they are complemented by "toolkits",such as those based on the Motif user interface protocol
1064 SOME O-O TECHNIQUES FOR GRAPHICAL INTERACTIVE APPLICATIONS §32.1 More progress remains necessary in this fast-moving area. Object technology can help tremendously, and in fact the fields denoted by the two buzzwords, GUI and O-O, have had a closely linked history. Simply stated, the purpose of this chapter is to disprove the Interface Conjecture, by showing that to be user-friendly an application does not have to be developer-hostile. Object-oriented techniques will help us concentrate on the proper data abstractions, suggest some of these abstractions, and give us the ability to reuse everything that can be reused. A complete exploration of O-O techniques for building graphical and interactive applications would take a book of its own. The aim of the present chapter is much more modest. It will simply select a few of the less obvious aspects of GUI building, and introduce a few fundamental techniques that you should find widely applicable if your work involves designing graphical systems. 32.1 NEEDED TOOLS What tools do we need for building useful and pleasant interactive applications? End users, application developers and tool developers First, a point of terminology to avoid any confusion. The word “user” (one of the most abused terms in the computer field) is potentially misleading here. Certain people, called application developers, will produce interactive applications to be used by other people, to be called end users; a typical end user would be a dentist’s assistant, using a system built by some application developer for recording and accessing patient history. The application developers themselves will rely, for their graphical needs, on tools built by the third group, tool developers. The presence of three categories is the reason why “user” without further qualification is ambiguous: the end users are the application developers’ users; but the application developers themselves are the tool developers’ users. An application is an interactive system produced by a developer. An end user who uses an application will do so by starting a session, exercising the application’s various facilities by providing the input of his choice. Sessions are to applications what objects are to classes: individual instances of a general pattern. This chapter analyzes the requirements of developers who want to provide their end users with useful applications offering graphical interfaces. Graphical systems, window systems, toolkits Many computing platforms offer some tools for building graphical interactive applications. For the graphical part, libraries are available to implement designs such as GKS and PHIGS. For the user interface part, basic window systems (such as the Windows Application Programming Interface, the Xlib API under Unix and the Presentation Manager API under OS/2) are too low-level to make direct use convenient for application developers, but they are complemented by “toolkits”, such as those based on the Motif user interface protocol
§32.1 NEEDED TOOLS 1065 All these systems fulfil useful needs,but they do not suffice to satisfy developers' requirements.Among their limitations: They remain hard to use.With Motif-based toolkits,developers must master a multi- volume documentation describing hundreds of predefined C functions and structures bearing such awe-inspiring names as XmPush ButtonCallbackStruct-with the B of Button in upper-case,but the b of back in lower-case-or XmNsubMenuld.The difficulties and insecurities of C are compounded by the complexity of the toolkit. Using the basic Application Programming Interface of Windows is similarly tedious: to create an application,you must write the application's main loop to get and dispatch messages,a window procedure to catch user events,and other low-level elements. Although the toolkits cover user interface objects-buttons,menus and the like- some ofthem offer little on graphics(geometrical figures and transformations).To add true graphics to the interface is a significant effort. The toolkits are incompatible with each other.Motif,the Windows graphics and Presentation Manager,although based on essentially similar concepts,differ in many ways,some significant(in Windows and PM creating a user interface object displays it immediately,whereas under Motif you first build the corresponding structure and then call a"realize"operation to display it),some just a matter of convention(screen coordinates are measured from the top left in PM,from the bottom left in the others). Many user interface conventions also vary.Most of these differences are a nuisance to end users,who just want something that works and "looks nice",and do not care whether window comers are sharp or slightly rounded.The differences are an even worse nuisance to developers,who must choose between losing part oftheir potential market or wasting precious development time on porting efforts. The library and the application builder To answer the needs of developers and enable them to produce applications that will satisfy their end users,we must go beyond the toolkits and provide portable,high-level tools that relieve developers from the more tedious and repetitive parts of their job, allowing them to devote their creativity to the truly innovative aspects. The toolkits provide a good basis,since they support many of the needed mechanisms.But we must hide their details and complement them with more usable tools. The basis of the solution is a library ofreusable classes,supporting the fundamental data abstractions identified in this chapter,in particular the notions of window,menu, context,event,command,state,application. For some of the tasks encountered in building an application,developers will find it convenient to work not by writing software texts in the traditional fashion,but by relying on an interactive system,called an application builder,which will enable them to express their needs in a graphical,WYSIWIG form;in other words,to use for their own work the interface techniques that they offer to their users.An application builder is a tool whose end users are themselves developers;they use the application builder to build the parts of
§32.1 NEEDED TOOLS 1065 All these systems fulfil useful needs, but they do not suffice to satisfy developers’ requirements. Among their limitations: • They remain hard to use. With Motif-based toolkits, developers must master a multivolume documentation describing hundreds of predefined C functions and structures bearing such awe-inspiring names as XmPushButtonCallbackStruct — with the B of Button in upper-case, but the b of back in lower-case — or XmNsubMenuId. The difficulties and insecurities of C are compounded by the complexity of the toolkit. Using the basic Application Programming Interface of Windows is similarly tedious: to create an application, you must write the application’s main loop to get and dispatch messages, a window procedure to catch user events, and other low-level elements. • Although the toolkits cover user interface objects — buttons, menus and the like — some of them offer little on graphics (geometrical figures and transformations). To add true graphics to the interface is a significant effort. • The toolkits are incompatible with each other. Motif, the Windows graphics and Presentation Manager, although based on essentially similar concepts, differ in many ways, some significant (in Windows and PM creating a user interface object displays it immediately, whereas under Motif you first build the corresponding structure and then call a “realize” operation to display it), some just a matter of convention (screen coordinates are measured from the top left in PM, from the bottom left in the others). Many user interface conventions also vary. Most of these differences are a nuisance to end users, who just want something that works and “looks nice”, and do not care whether window corners are sharp or slightly rounded. The differences are an even worse nuisance to developers, who must choose between losing part of their potential market or wasting precious development time on porting efforts. The library and the application builder To answer the needs of developers and enable them to produce applications that will satisfy their end users, we must go beyond the toolkits and provide portable, high-level tools that relieve developers from the more tedious and repetitive parts of their job, allowing them to devote their creativity to the truly innovative aspects. The toolkits provide a good basis, since they support many of the needed mechanisms. But we must hide their details and complement them with more usable tools. The basis of the solution is a library of reusable classes, supporting the fundamental data abstractions identified in this chapter, in particular the notions of window, menu, context, event, command, state, application. For some of the tasks encountered in building an application, developers will find it convenient to work not by writing software texts in the traditional fashion, but by relying on an interactive system, called an application builder, which will enable them to express their needs in a graphical, WYSIWIG form; in other words, to use for their own work the interface techniques that they offer to their users. An application builder is a tool whose end users are themselves developers; they use the application builder to build the parts of
1066 SOME O-O TECHNIQUES FOR GRAPHICAL INTERACTIVE APPLICATIONS $32.2 their systems that may be specified visually and interactively.The term "application builder"indicates that this tool is far more ambitious than plain"interface builders",which only cover the user interface of an application.Our application builder must go further into expressing the structure and semantics of an application,stopping only where software text becomes the only reasonable solution. In defining the library and the application builder,we should be guided,as always, by the criteria of reusability and extendibility.This means in particular that for every data abstraction identified below (such as context,command or state)the application builder should provide two tools: For reusability,a catalog (event catalog,context catalog,state catalog...)containing predefined representatives of the abstraction,which developers can include directly into their applications. For extendibility,an editor (context editor,command editor,state editor...)enabling developers to produce their own variants,either from scratch or more commonly by pulling out an element from a catalog and then modify ing it. Using the object-oriented approach In the object-oriented approach to software construction,the key step is to find the right data abstractions:the types of objects which characterize applications in the given area. To advance our understanding of graphical user interfaces and devise good mechanisms for building applications,we must explore the corresponding abstractions. Some are obvious;others will prove more subtle. Each of the abstractions encountered below will yield at least one class in the library. Some will yield a set of classes,all descending from a common ancestor describing the most general notion.For example,the library includes several classes describing variants of the notion of menu. We will first examine the overall structure of a portable graphics library;then consider the main graphical abstractions covering the geometrical objects to be displayed, and the"interaction objects"supporting event-driven dialogues;finally we will study the more advanced abstractions describing applications:command,state,application itself. 32.2 PORTABILITY AND PLATFORM ADAPTATION Some application developers want a portable library,which will enable them to write a single source text that will then adapt automatically to the look-and-feel of many platforms,at the price of a recompile but without any change.Others want the reverse:to gain full access to all the specific“controls'”and“widgets”of a particular platform such as Microsoft Windows,but in a convenient fashion(rather than at the typically low level of the native libraries).Yet others want a bit of both:portability as the default,but the ability to go native when needed. With a careful design,relying on a two-layer structure,we can try to satisfy all ofthem:
1066 SOME O-O TECHNIQUES FOR GRAPHICAL INTERACTIVE APPLICATIONS §32.2 their systems that may be specified visually and interactively. The term “application builder” indicates that this tool is far more ambitious than plain “interface builders”, which only cover the user interface of an application. Our application builder must go further into expressing the structure and semantics of an application, stopping only where software text becomes the only reasonable solution. In defining the library and the application builder, we should be guided, as always, by the criteria of reusability and extendibility. This means in particular that for every data abstraction identified below (such as context, command or state) the application builder should provide two tools: • For reusability, a catalog (event catalog, context catalog, state catalog…) containing predefined representatives of the abstraction, which developers can include directly into their applications. • For extendibility, an editor (context editor, command editor, state editor…) enabling developers to produce their own variants, either from scratch or more commonly by pulling out an element from a catalog and then modifying it. Using the object-oriented approach In the object-oriented approach to software construction, the key step is to find the right data abstractions: the types of objects which characterize applications in the given area. To advance our understanding of graphical user interfaces and devise good mechanisms for building applications, we must explore the corresponding abstractions. Some are obvious; others will prove more subtle. Each of the abstractions encountered below will yield at least one class in the library. Some will yield a set of classes, all descending from a common ancestor describing the most general notion. For example, the library includes several classes describing variants of the notion of menu. We will first examine the overall structure of a portable graphics library; then consider the main graphical abstractions covering the geometrical objects to be displayed, and the “interaction objects” supporting event-driven dialogues; finally we will study the more advanced abstractions describing applications: command, state, application itself. 32.2 PORTABILITY AND PLATFORM ADAPTATION Some application developers want a portable library, which will enable them to write a single source text that will then adapt automatically to the look-and-feel of many platforms, at the price of a recompile but without any change. Others want the reverse: to gain full access to all the specific “controls” and “widgets” of a particular platform such as Microsoft Windows, but in a convenient fashion (rather than at the typically low level of the native libraries). Yet others want a bit of both: portability as the default, but the ability to go native when needed. With a careful design, relying on a two-layer structure, we can try to satisfy all of them:
$32.2 PORTABILITY AND PLATFORM ADAPTATION 1067 Graphical libraries Platform-independent library (Vision) architecture (See a similar archi tecture for concur- WEL MEL PEL rency:page 970.) (Windows) (Motif) (Presentation ■■■■■■■■■1■■■ Manager) To make things more concrete the figure shows the names of the corresponding components in ISE's environment,but the idea is applicable to any graphical library.At the top level (Vision)there is a portable graphical library;at the bottom level you find specialized libraries,such as WEL for Windows,adapted to one platform only. See "AN APPLICA- WEL and other bottom-level libraries can be used directly,but they also serve as the TION:THE HANDLE platform-dependent component of the top level:Vision mechanisms are implemented TECHNIQUE”,24.3. page 817. through WEL on Windows,MEL on Motif and so on.This technique has several advantages:for the application developers,it fosters compatibility of concepts and techniques;for the tool developers,it removes unneeded duplications,and facilitates the implementation of the top level (which relies on clean,abstract,assertion-equipped and inheritance-rich O-O libraries such as WEL,rather than interfacing directly with the C level,always a dangerous proposition).The connection between the two levels relies on the handle design pattern developed in an earlier chapter. Application developers have a choice of level: If you want to ensure portability,use the higher layer.This is also of interest to developers who,even ifthey work for a single platform,want to benefit from the higher degree of abstraction provided by high-level libraries such as Vision. If you want to have direct access to all the specific mechanisms of a platform (for example the many "controls"provided by Windows NT),go to the corresponding lower-layer library. The last comment touches on a delicate issue.How much platform-specific functionality do you lose by relying on a portable library?The answer is necessarily a tradeoff.Some early portable libraries used an intersection (or "lowest common denominator")approach,limiting the facilities offered to those that were present in native form in all the platforms supported.This is usually not enough.At the other extreme the library authors might use the union approach:provide every single mechanism of every supported platform,using explicit algorithms to simulate the mechanisms that are not natively available on a particular platform.This policy would produce an enormous and redundant library.The answer has to be somewhere in-between:the library authors must decide individually,for every mechanism present on some platforms only,whether it is important enough to warrant writing a simulation on the other platforms.The result must be a consistent library,simple enough to be used without knowledge of the individual platforms,but powerful enough to produce impressive visual applications
§32.2 PORTABILITY AND PLATFORM ADAPTATION 1067 To make things more concrete the figure shows the names of the corresponding components in ISE’s environment, but the idea is applicable to any graphical library. At the top level (Vision) there is a portable graphical library; at the bottom level you find specialized libraries, such as WEL for Windows, adapted to one platform only. WEL and other bottom-level libraries can be used directly, but they also serve as the platform-dependent component of the top level: Vision mechanisms are implemented through WEL on Windows, MEL on Motif and so on. This technique has several advantages: for the application developers, it fosters compatibility of concepts and techniques; for the tool developers, it removes unneeded duplications, and facilitates the implementation of the top level (which relies on clean, abstract, assertion-equipped and inheritance-rich O-O libraries such as WEL, rather than interfacing directly with the C level, always a dangerous proposition). The connection between the two levels relies on the handle design pattern developed in an earlier chapter. Application developers have a choice of level: • If you want to ensure portability, use the higher layer. This is also of interest to developers who, even if they work for a single platform, want to benefit from the higher degree of abstraction provided by high-level libraries such as Vision. • If you want to have direct access to all the specific mechanisms of a platform (for example the many “controls” provided by Windows NT), go to the corresponding lower-layer library. The last comment touches on a delicate issue. How much platform-specific functionality do you lose by relying on a portable library? The answer is necessarily a tradeoff. Some early portable libraries used an intersection (or “lowest common denominator”) approach, limiting the facilities offered to those that were present in native form in all the platforms supported. This is usually not enough. At the other extreme the library authors might use the union approach: provide every single mechanism of every supported platform, using explicit algorithms to simulate the mechanisms that are not natively available on a particular platform. This policy would produce an enormous and redundant library. The answer has to be somewhere in-between: the library authors must decide individually, for every mechanism present on some platforms only, whether it is important enough to warrant writing a simulation on the other platforms. The result must be a consistent library, simple enough to be used without knowledge of the individual platforms, but powerful enough to produce impressive visual applications. WEL (Windows) MEL (Motif) PEL (Presentation Manager) Platform-independent library (Vision) Graphical libraries architecture (See a similar architecture for concurrency: page 970.) See “AN APPLICATION: THE HANDLE TECHNIQUE”, 24.3, page 817