Re: UI Design in Windows Software

[JGREY <JGREY -at- MADE2MANAGE -dot- COM>]

Hi Hope,

My interest in your note was piqued when you mentioned that you're
working under an MSF model.  At Made2Manage, we do all our software
development under our "M2MSF" model, which is based on MSF.  I sit on a
couple design teams (we call them "feature teams") and have run into the
very issue you mention.  Also, like your users, many of our users use
their computer only for our product.  If you ask them what kind of
computer they have, they reply, "Made2Manage."  (Our company's name and
product name are the same.)

Our current Windows product goes a long way to accommodate our old DOS
users. For example, in our DOS product, the login screen required that
you type your username, press Enter to move off the field, type your
password, press Enter to move off the field, and then press Enter to log
in.  The Windows product behaves the same for the comfort of former DOS
users -- you can type name, Enter, password, Enter, Enter.  It also
supports the Windows standard of pressing Tab between fields.  But now
our user base has expanded far beyond former DOS users -- I'd say that
75% of users never used our DOS product.  So when they log in by typing
their username, pressing Tab, typing their password, and pressing Enter
(to activate the OK button), they are very confused when nothing
happens.  They still have to hit Enter one more time.  It's
counterintuitive.  It's an education and support issue now.

We have learned.  As we redesign interface elements, we try to
*reasonably* accommodate users of systems we used to sell by offering
alternatives that work as they're used to.  But we no longer make design
decisions that cater to those users or adversely affect users who have
never used those systems.

We are also introducing usability testing into our interface design
process.  I suggest that your design team try it.  Create a longer tree
structure, bring in some likely users, and have them try it out to see
if it stops them.  This will give you empirical evidence from which to
base your decisions.  (I recommend _Handbook of Usability Testing_ by
Jeffrey Rubin, ISBN 0-471-58403-2, to help you get started.)

I really enjoy the cross-discipline design teams that MSF encourages.
However, a potential downfall is that those on the team present their
pet ideas or want to drive features into the product based solely on
their experiences.  To minimize this effect, it is critical to expose
the teams to the kind of evidence that usability testing provides.

Peace,
jim

jim grey \ Documentation Manager
Made2Manage Systems, Inc. \ jgrey -at- made2manage -dot- com


-----Original Message-----
From: Hope Cascio [mailto:hcascio -at- GTE -dot- NET]
Sent: Wednesday, July 08, 1998 7:35 PM
Subject: UI Design in Windows Software


Techwhirlers,

I've recently had a wonderful opportunity within my company to be a part
of a MSF (Microsoft Solutions Framework) team developing a new interface
design for our product.  MSF teams are very neat things which pull
together people from programming, development, testing, support, and
user ed to solve a problem.  Reminds me of the Quality Improvement teams
I used to take part in at a former employer.

Anyway, I've found a difference in opinion among the team members that
seems to take (and this is, of course, my very subjective viewpoint) a
divide between the user advocate types (support, user ed) and the
programmer/developer types.

The product we're designing for is a few years old, and this is going to
be the first time it's offered without its DOS counterpart, which was a
very popular workhorse.  Our user base is for the most part almost
completely inexperienced with Windows, and often is only familiar with
the computer as that thing they have to turn on to use our old DOS
program.

In designing the new interface for the Windows product, the programmer
types seem very concerned with doing things that are less likely to
confuse the Windows-newbie-- like, for instance, keeping tree metaphors
very short so the user doesn't ever have to use the scroll bar to
discover more folders at the bottom.  Their workarounds, inevitably,
cause the design to veer further from the Windows metaphors we're trying
to emulate. Don't get me wrong-- some of their ideas I think are good--
like always making sure there are keyboard navigation alternatives, not
just for DOS types who don't like mouses very much, but for
accessibility to the disabled.

The idea first presented to the group, and the one we're all laboring
under, is that the new interface should be MSIE/Windows Explorer-esque.
My argument pretty much from the beginning has been that we should stick
fairly closely to the standards set up by MS Windows and the various MS
products.  I can give several valid reasons for this.  I can also see
the other side, which is, that our user base is very DOS-oriented, used
to the old product, resistant to new technology, and "just want to get
their job done."  This is probably more of an opinion poll than anything
else, but if anyone could provide a response with logical arguments for
one way of doing things or the other.  If you want to keep it all
offlist, I'll compile and organize the responses and post them when the
flow trickles.

TIA,
Hope Cascio

--
"Just because a network architecture has been designed to survive
 nuclear holocaust doesn't mean it is immune to WebTV or a bunch
 of sociopathic 12 year olds." -Lon Stowell, alt.folklore.science