TITLE: Embarrassed for My Discipline
AUTHOR: Eugene Wallingford
DATE: August 18, 2005  6:59 PM
DESC: An hour with my university's financial information system was enough to cause me a little embarrassment to be a software developer.  The non-software folks in the room didn't hold the sins of my discipline against me, but maybe they should.
-----
BODY:
Earlier this week, I learned a bit about how to
use my university's financial information system.
It is an application built almost entirely out
of the box using
<A HREF="http://www.oracle.com/applications/">
   Oracle E-Business Suite</A>
tools.  By the time I left the room, I was
embarrassed for my discipline.

My college secretary gave an informal tutorial
to me, another new head, and our acting dean.
We learned that it is not straightforward to
do most of the tasks that we might want to do.
What was worst, from most point of view as a
software developer, is that the complexity of
the interface matched or exceeded the complexity
of the underlying data.

The primary users of this system -- secretaries
and office personnel -- seem to be good troopers.
They acknowledge the complexity of the system with
mostly good cheer and seem intent on mastering
the complexity of the interface.  Then again,
perhaps they are just being kind when they speak
to me, a "computer person", and are burning their
mousepads -- and me in effigy -- when I'm not around.
I wouldn't blame them.

The administrators I've talked to, who have to use
the system to manage their budgets and personnel,
openly grumble about the system.

To be fair, this software solves a very large
problem in our medium-sized institution.  As an
undergraduate, I worked as a programmer in
<A HREF="http://www.bsu.edu/web/ucs/">
   administrative computing at my alma mater</A>.
The database with which we worked seemed uncommonly
complex at the time.  Of course, it wasn't; I was
just inexperienced in the ways of computing.
Financial information systems these days are even
more complex, managing the interactions among
several classes of employees and supervisors,
payroll and grants and foundation accounts,
departments and units and colleges, ....  On top
of that are issues of security and responsiveness.
I don't doubt that our financial information system
is more complex than any IS with which I have worked.

But users shouldn't have to see any more of this
complexity than necessary.  Users of our system
seem to see nothing but complexity.  Layers of
jargon-laden links that serve as menus.  Several
cryptic codes that must be entered before you can
reach data on any form.  Few, if any, defaults.
Few, if any, shortcuts.

The giveaway that the system is too complex for
its own good?  Regular users have asked system
administrators to create a "cheat sheet", a page
containing advice of the sort, "If you want to
see data on <EM>x</EM>, do the following..."
Why can't frequent, knowledgeable users find their
way to commonly-needed data already?

The good news for users here is that the team
that administers our system has produced good
on-line training material.  (Someone at
<A HREF="http://www.oracleappsblog.com/index.php/oracle-applications-documentation-training-courseware/">
   OracleAppsBlog</A>
thinks so, too.)  Good.  But why should the
main focus of a software unit be to produce
good documentation?  As we in the agile community
know, the need to write better comments usually
indicates the need to write better code.  The need
for excellent training materials implies a need
for a better interface.

I don't want to be too hard on Oracle.  I know that
the task is complex, and I know that Oracle isn't
the only computing company producing software that
users can't use, at least comfortably.  This system
is just one example, albeit a very good one, of a
general problem in our industry.  But I guess I do
expect more from
<A HREF="http://www.oracle.com/corporate/about.html">
   "the world's largest enterprise software company"</A>
...

And I'm certainly not complaining about the UNI folks
who have assembled our information system.  They built
the system on a relatively small budget using standard
Oracle code, interface components, and style sheets.
But, as a user, I wish that we could do better.

Even sadder in these days of budget cuts in higher
education, my university has almost certainly sunk
in excess of $100,000 into this system and thus are
committed to the long-term costs of keeping it
functional.  When I add in training costs, the
total cost probably goes up significantly.  When I
add in the cost of the time lost battling the system
... I don't want to think about it.

We in software development do a disservice to users
when we tell them, explicitly or implicitly, that
things have to be complex, hard to use, uncomfortable,
painful.  We tell them that <EM>they</EM> don't
understand.  We tell them that they must just not
be smart enough to use technology.  We are wrong, and
they should be told that.

In thinking about concrete, relatively low cost
steps we would take to improve the quality of user
experience, a friend and I focused on the fact that
most accesses into the system recurring.  While I
was being "trained", I repeatedly heard "you don't
need to worry about these options.  You'll never use
them.  Focus on this subset of options...."  How about
something simple, which Mac OS has had forever: an
easily-accessible <EM>recent items</EM> menu?  Or a
"most-frequently accessed reports" menu?  I am guessing
that, within a few uses, most administrators would
never have to venture outside one of these lists.
More frequent users might need a longer list, but
that's no problem.

Upon further inspection, it seems that users of our
system can build their <EM>own</EM> shortcuts lists,
by "customizing" their own "portlets".  (Portlet?)
But I am not yet certain how to use this interface
feature properly.  I must not be smart enough to use
this system.  Maybe I don't understand.  Sorry, I
don't believe that -- about me or about any of the
regular users of this system.

We know
<A HREF="http://www.cs.umd.edu/hcil/pubs/books/dtui.shtml">
   how to do better</A>.
Most developers know better -- or should.
-----