Reprint: Integrating Other Applications

Subject: Reprint: Integrating Other Applications
From: "Jared M. Spool" <jspool -at- UIE -dot- COM>
Date: Tue, 4 Mar 1997 16:51:51 -0500

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

(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

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

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 -at- uie -dot- com -dot- (Sorry, we do not have an email
version available, yet.)

Or, you can check out our website at

Hope you found this to be of interest.


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

Jared M. Spool User Interface Engineering
mailto:jspool -at- uie -dot- com 800 Turnpike Street, Suite 101
(508) 975-4343 North Andover, MA 01845
fax: (508) 975-5353 USA

TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
Search the archives at or search and
browse the archives at

Previous by Author: Resources for Document Organization
Next by Author: Value added by technical documentation
Previous by Thread: Technical Editing: Survey
Next by Thread: Seeking a techwhirler

What this post helpful? Share it with friends and colleagues:

Sponsored Ads