Interfacing with the interface folk

["Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA>]

Suzette Seveny ran into an uncooperative developer and asked for
suggestions:

<<My initial reaction to the blank, grey screen was that the
application was not working or loading properly.>>

That would be my reaction too. In fact, it's such a common response
that developers have come up with all kinds of workarounds, including
a status bar that displays the progress of the load operation, a
"pick one of the following options" dialog box or wizard, and a
splash screen. No reason why you shouldn't insist on the same thing.

<<To add a template, I would select View>>Templates.  When the list
of templates appear, I select File>>New Template and answer about 50
questions. To generate a statement, I would select View>>Statements.
When the list of statements appear, I select File>>Generate
Statement. I felt that this process was confusing>>

It is confusing, in part because you're using two entirely different
sets of words to describe the same action. In both cases, the
solution is to use some consistent and relevant "affordances" (text
or other cues that help the user understand where they're going and
where to look). "View" is at least two jumps removed from what you're
doing (creating), so the solution is to add a "Create new" menu and
put "Templates" and "Statements" under it. If you've only got three
menus in total, adding one more is hardly overkill. More to the
point, you can point out to the developer that you just saved him
from coding and debugging one whole layer of interactions (the
"view before you create" step) that serves no purpose for either him
or the user. Win-win situation!

<<The developer responded quite defensively, along the lines of
"Well this is a complex application with a very intricate menu
system...">>

He's fallen into a standard and perfectly understandable developer
trap: "If I make it look easy to use, they'll think the programming
is easy, and I'll lose their respect." That's simply not the case.
You need to gently explain to him that the mark of skillful
programming lies in the algorithm itself, _and_ in the ability to
hide that algorithm from the user; the programmers will admire the
elegance of his algorithms, but the users want to admire how
efficiently the interface gets them to their desired goal.

<<At this point, I got angry... I then ended the meeting and
said we would continue another time.>>

Always a good strategy when you're too angry to get past your
emotions: walk away and come back when you're prepared to be
rational. If you stay, odds are that you're going to say something
you'll both regret for a good long time.

<<My options are: (I'm still angry) 1.  Put the developer's phone
number in the help file. 2.  Work on one of the many other, more
enjoyable projects I have on my desk and slow his down.>>

Don't do either; short-term satisfaction, but long-term trouble. Take
a deep breath, get past the anger, and try to understand why he's
defensive and how much of that reaction you're responsible for. Given
the dialogue you quoted, I think you pushed too hard when he was
pushing hard, and that's a sure recipe for a fight. Go back and try
again, but sell it to him so he sees the advantage to both him (e.g.,
less programming) and the user.

<<How would you guys have handled this situation?>>

In the past, I've tried several things (and by no means handle
it the way I'm writing it... show some tact! <g>):

1. The paper prototype trick: "Here's your solution; here's mine. How
many clicks/keystrokes does it take to get to the final step? Gee...
mine is half as long as yours. That means half the programming and a
happier user too, right? Let's do it my way..." General principle: If
it's difficult to describe, the sequence of steps is probably
unnecessarily complicated too, and by simplifying the steps, you also
simplify the programmer's task.

2. The second opinion: "Let's get a few typical users in here and see
which they prefer. See? I'm not just paranoid... they really are
intimidated/incompetent/outright stupid. Here's how we can solve it."
General principle: If you're too close to the software, you can't see
its flaws and you need a more objective view.

3. Politely walk away, write up the incident for Scott Adams
(Dilbert), then return when you can keep a straight face and try
again. For ex.: "Jean, I think I've found a bug. I just lost three
hours work because the software doesn't check if a database name
already exists when you choose Save as." [Long silence] "Why do you
consider this a bug?" A small terminology problem, as it turned out,
easily resolved once I could explain that it was a simple omission,
not a "bug" and therefore an omission, not an _error_ on his part.
Jean doesn't make errors, you see, and once we both agreed on that,
the problem was solved. General principle: If you understand why
someone doesn't want to do something, then you can figure out how to
persuade them.

4. Invoke peer pressure. Jean, for example, hates to do any more work
than necessary on his software; Denis, on the other hand, is always
willing to go several steps beyond what's necessary. So if I need to
get something done right, I convince Denis to do it first. Once
that's done, Jean has to do it the same way in his module for the
sake of consistency. Of course, the trick is to get to Denis before
Jean does his coding, because peer pressure also works in the
opposite direction. General principle: Programmers are like everyone
else, and like to go with the flow, even while loudly protesting
their individuality.

5. Show that you understand and respect the developer and where he's
coming from. If you really do, you'll be able to come up with a
solution that demonstrates your understanding and respect. When you
get angry, you're no longer doing either, and that sabotages any
attempt at rational dialog.

These are all generalities, thus, in need of tailoring to each and
every specific situation... but good starting points nonetheless.
--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca

When an idea is wanting, a word can always be found to take its place.--Johann Wolfgang von Goethe

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=