TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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
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.)
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 http://www.uie.com