|
CASE STUDY #2 – LARGE INTERNATIONAL CROSS-PLATFORM FIRM
This international organization fielded 15 members on their standards
committee. It encompassed both Motif and Windows. The IS manager preferred
anonymity. We'll call her Adamantine. The following is based on several
interviews. HFI's Dr. Eric Schaffer and Dr. Diana Nelson both headed the
very large project.
Q: What were some special problems with this project?
Adamantine: One of the big issues for us
is the lack of widgets in Motif. We used lots of Windows widgets, and
our developers were concerned about how to develop equivalent ones and
make them work in the Motif/UNIX world. We reminded them they only had
to do that once, but they worried about it. Some managers resisted the
expense of creating the Motif equivalent widgets. But they failed to take
into account the increased productivity of users with the standard objects.
Q: What's an example of a custom widget?
Adamantine: If you have a scrolled list with
more than one column, users need help scanning left to right across the
columns. Research shows that users make less mistakes with a blank line
every five or six lines. It serves to guide the eye like a ruler. Our
Motif scrolled lists didn't support that feature.
Q: Did your people agree to creating the custom Motif widgets?
Adamantine: Yes. However, as a tactical compromise,
we allow current projects to omit the precise tools for an interim period.
However, the application must emulate the "behaviors" given
by the standard. With our widely distributed development groups, including
contractors, we may have a problem enforcing the standards until we get
our custom Motif widgets. But I'm taking the five year point of view now.
First get a standard, which we have. Then a toolkit, which is coming.
Also, we'll give education to the developers. Then we're set until the
next big interface development. Maybe virtual reality?
Q: Any other big problems?
Adamantine: Long ago, I felt that the process
was the most important ingredient. [See table "The Right Way to Beat
the Rap"] We tried doing a standard before, using a different outside
contractor who failed to follow the right process. That standard dwelt
on principles you get from a books and research authorities. It bordered
on being a "generic" standard you can get from the bookshelf.
But we failed to give our users screen design options that were meaningful
to them. We didn't look at the business-specific tasks performed by our
many users. Consequently, the developers couldn't use the standard effectively.
There was too much reading. Too little connection with actual tasks in
our business. We need screen examples that promote performance accuracy,
ease of use, and task predictability.
Q: How did developers respond to the new approach at first?
Adamantine: We've discovered there is a global
lack of understanding for the need of a UI process in our organization.
We need to constantly battle against corporate culture and "ideology".
We have a lot of 3270 developers and users who have never seen a custom
GUI application that really accommodates a "workflow". Instead,
they use the "windows paradigm" they have seen (word-processing,
spreadsheet, and development tools). But these models lead to window thrashing.
Now we know that customer service representatives don't want to "bounce
around" with that kind of design. We really need to teach people
something they think they already know how to do! This is hard. Our people
just didn't know what could be done! And they're not familiar with potential
productivity gains available if you get the right screen types.
Q: Did you overcome developer resistance? Especially given a
second go-round on standards?
Adamantine: Doing it a second time was a
definite challenge. We faced emotional exhaustion in our team. However,
three strategies made it work.
- First, the committee consisted of developers who were actively working
on projects. The standard had to be usable to them. No abstractions
allowed in the standard. They felt involved, and therefore were committed.
Plus we had good consultative leadership with concrete alternatives
and trade-offs for us to evaluate.
- Second, the user representatives became strong allies. They helped
set policies and requirements. They reviewed the screen types we had
obtained in prior interviews with other users. We educated our user
reps in UI design so they could talk the same language as our developers.
Previously, they hadn't known their options, and thus failed to articulate
what they didn't like. They were pleasantly surprised at their options.
- Third, we had a large, important project that needed the ideas we
generated during the standards process. It became a showcase project
for other projects to emulate. It was a big motivator because the showcase
project demonstrated concrete productivity increases from the standard.
Q: Any advice for others doing a multi-platform standard?
Adamantine: Be selective. Don't try to standardize
everything. For example, don't bother standardizing button sizes. You
can't predict all situations or CRT sizes and resolutions. Don't standardize
on a single color scheme. Instead provide several pre-planned color palettes
from which developers and users can select. We couldn't standardize on
accelerator keys except for "Alt-X" for Exit, and Escape for
Cancel. Previous applications and future situations varied too much across
applications to allow such niceties. We were also limited in standardizing
on F-keys except for Help and Exit. Obviously, other organizations would
benefit if they could standardize at least certain F-key functions.
In general, we had to create "function tables" that allowed
us to compare features across both Motif and Microsoft Windows platforms.
We identified commonalties. Then we had to make hard decisions about non-overlapping
functions. In some cases we used text to describe differences, or we excluded
standards on contradictory features like different F-key assignments.
Q: What areas were ripe for standardization?
Adamantine: We found that the major benefits
of standards applied across platforms easily. These included special over-all
screen designs that handled our special task flows. In the screen types
we selected, our developers got phraseology for instructions, examples
of indentation, and important navigational ideas. They got a lot of "cosmetic"
tips like the design of groups with headers and use of particular icons
for warning, system failure, and informational dialogs. We standardized
on the fact that the DEFAULT button should appear at the lower left, and
this is not necessarily the OK button!
|
