Task-Centered User Interface Design
A Practical Introduction
by Clayton Lewis and John Rieman
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book.
Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing | Tools | Documentation |

6.1 Concepts
        6.1.1 Object-Oriented Programming
        6.1.2 Event-Driven Programs
        6.1.3 Resources
        6.1.4 Interapplication Communication
6.2 OSF/Motif in X-Windows -- Toolboxes in the Trenches
6.3 Rapid Prototyping in HyperCard
6.4 Windows, the Shared-Code Approach, and Visual Basic


6.1.4 Interapplication Communication


Interapplication communication describes a situation in which two programs, running at the same time, exchange data. For example, a word processing program might send some numbers to a spreadsheet, which could calculate their average and send it back to the word processor. That would allow the word processor to have the calculating power of the spreadsheet, without duplicating the code. Communication between applications is a common technique on minicomputers (the world of UNIX), but it's only recently been implemented in personal computer operating systems. That's partly because early personal computers could only run one application at a time, and partly because, unlike the command-driven software that forms the basis of most minicomputer applications, interactive graphical systems can't easily be adapted to respond to commands from other programs.


Two major personal computer software environments, Microsoft Windows (currently version 3) and Apple's Macintosh System (version 7), support interapplication communication. They provide a communications pathway between applications, and they specify standard data formats for the interaction. As we write this, Windows seems to have the lead both in functionality and number of third-party applications that another application can access. On either the Mac or Windows, you should look for places where interapplication communications can help you avoid rebuilding systems that the user already has and knows.

HyperTopic: Roll Your Own UIMS for Unique Environments

"All right," you say, "These UIMS products sound great for programming on personal computers or Unix machines, but I'm building the interface to a walk-up-and-use airport baggage check, using all custom hardware. What do I do?"

Here are two suggestions. First, invest in a simple UIMS on a personal computer, something at the level of Apple's HyperCard, and use that to prototype your system. Evaluation of the prototype won't uncover all the problems that could arise with the real system, but it's a quick and inexpensive way to get started in the right direction.


Second, develop in UIMS style for the dedicated hardware. Don't go overboard on this -- if you decide to write your own object-oriented cross-compiler, your competition could have their baggage-check system on the market before you even have a prototype. But the application you develop can incorporate the basic ideas of event-oriented programming, modularized code, and table-lookup for resource information. The extra time taken up front to design this system will certainly be paid back as you iterate the prototype, and it will be paid back again when it's time to write a new version.



Copyright © 1993,1994 Lewis & Rieman
Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing | Tools | Documentation |