LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous (more recent) messageNext (less recent) messagePrevious (more recent) in topicNext (less recent) in topicPrevious (more recent) by same authorNext (less recent) by same authorPrevious page (March 1997, week 1)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Tue, 4 Mar 1997 22:48:35 GMT
Reply-To:   jspool@uie.com
Sender:   "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:   "Jared M. Spool" <jspool@UIE.COM>
Organization:   User Interface Engineerng
Subject:   Reprint: Integrating Other Applications

SAS Developers:

People have recently shown interest in developing new applications that leverage the functionality built-in to existing applications. The following is a reprint of an article that was printed in the November/December 1996 issue of Eye For Design. I thought you might find this of interest.

(There is information on how to get a sample issue of Eye For Design at the end of this message.)

- o - o - o -

Integrating Other Applications by Will Schroeder

Problem: Your application or web site needs some functionality. There's another product or site (either third-party or from your company) which already does what you need. Should you just integrate it with your application, or spend the effort to "reinvent the wheel?" Integration is a tempting solution, but we've learned that it can cause problems of its own.

Recently, we tested three applications (a chemical compound database, a financial analysis package, and a process modeller) that extended their functionality by launching Microsoft Excel. We observed that users had some interesting problems users had with the integration of the two products.

__________ A Drink from a Fire Hydrant

Complementing your application with another feature-rich application is like getting a drink of water from a fire hydrant. Beware of creating learning hurdles when you integrate an application. In our tests, the users were familiar with Excel, and we still observed some Excel-related usability issues. If your users aren't proficient in the other application, or you just need a few of its functions, attempting to integrate it might place an undue burden on users.

__________ Two Applications or One?

As a designer, you must decide how tightly to integrate with the other application. Do you want the user to perceive the boundaries between the applications or to treat them as one? Most of the usability problems we saw pertained to the users' mental models of how the two products worked together.

__________ Breaking the Mental Model

Over time, users develop a mental model of how a product or site works. If any aspect of the integration changes the way the familiar product works, this can disrupt users' mental model.

One product added a formula to the Excel Function Wizard to calculate and display a mathematical curve (in Excel, functions result in a number in a spreadsheet cell). After users completed this function, we asked them what they expected and they all said, "I'll get a number in a cell." When they got a 3D graph instead, they were surprised - the integration had broken their mental model.

__________ Crossing the Boundaries

In switching from one application or web site to another, the user crosses a boundary. Even if users are familiar with the place they're going, they can become temporarily disoriented if they don't realize where they are or how they got there. When we tested applications that put users into Excel, some users took a while to realize that they were in Excel, and a few even thought they had gotten into Excel by mistake!

We've seen similar problems when applications use object linking and embedding (OLE) technology to provide in-place editing, or when web pages link to other sites. Even though parts of the screen change, users often don't realize that they are suddenly in a different context.

__________ Methods of Switching

One development team wanted the two integrated applications to look like one. They added commands to Excel's Window menu so that users could switch among the open windows in the two applications. This didn't work; users didn't look there. The team revised their design by adding a palette of icons for switching, and this worked better. We also saw that users who knew Excel would notice the addition of an icon to Excel's toolbar, but only if it was flagrant (in this case, large and red!).

__________ Incompatible Data Types

If functions in the other application don't work on all your types of data, you're likely to see problems. We saw many examples of users attempting to apply familiar functionality in ways that didn't make sense with the integrated product. One developer had added a feature to display chemical diagrams in Excel spreadsheet cells. In the usability test, he grinned ruefully when users tried to sort on a column full of pictures.

Another example comes from Goldmine (a contact manager), which uses the Crystal Report Writer to provide its reports. The filtering syntax in the two applications are different - a filter written within Goldmine won't work in the report writer.

Sometimes problems like this can be avoided by integrating an application behind the scenes. For example, a VBX called Formula One acts like an invisible spreadsheet, so developers can add spreadsheet capabilities to their application without making users learn another interface.

We did see a pattern in users' expectations in a couple areas. Uniformly, users expected automatic data updating (where changes in the Excel data are reflected in the calling application, and vice versa). However, when we asked users whether they could load an Excel file directly into the calling application, users weren't sure whether the file formats were directly compatible.

__________ Duplication of Functionality

In some cases, it may make sense to duplicate some functionality from the other application if it avoids confusion. We tested a product which relied on Excel for printing, and therefore omitted a Print command from the product's File menu. Several users could not complete a printout task. Even though they knew that Excel was available, using it to print did not occur to them. We have also seen instances where users looked in Help in the "wrong" application, searching for functionality that was in the other application. But not all users searched in Help, so some simply concluded that the functionality didn't exist.

- o - o - o -

Eye For Design is published six times a year with articles on a variety of product design and usability issues.

If you would like a complimentary issue mailed to you, just send your postal address to efd@uie.com. (Sorry, we do not have an email version available, yet.)

Or, you can check out our website at http://www.uie.com.

Hope you found this to be of interest.

Jared

p.s. We'll ship your complimentary issue anywhere in the world, as long as you tell us what country your from.


Back to: Top of message | Previous page | Main SAS-L page