[WEB4LIB] Re: of mouse balls and such

Debra Lords dlords at library.utah.edu
Sun Jan 2 20:10:28 EST 2000


One thing I should say was that the manager was able to fix the
problem.  So it wasn't fat-fingering on the part of the user.  A
significant factor ultimately was that the troublesome database
would work if another (relatively popular) database by the same
publisher was used since the last reboot.  The compter was turned
off nightly.  

When the staff would try the database in the morning, it wouldn't
work.  Once the "it doesn't work" call came I answered it right
away and verified their experience.  No later tests of the
database were tried, it having been defined as not working.  By
the time my boss got in, the other database would have been used,
so the testy one worked for him.  

The problem ultimately was a fault in the configuration files of
the testy database. Once that error was corrected, the database
worked like a champ, even with later updates.

Debbie

Stacy Pober wrote:
> 
> Not to be immodest, but I'm the kind of human that computers like.  So I
> find myself in your manager's situation quite often.  It's frustrating
> to me to tell someone the answer to their computer problem, only to have
> them tell me, "No, I already tried that and it didn't work".  So I go
> and personally type in the exact same commands and suddenly - no
> problem.
> 
> Okay, sometimes this is due to mysterious magic.  However, when I've had
> the opportunity to watch people demonstrate that "it didn't work for
> ME!" as they would put it, here's the discrepancies I've seen between
> what I do with computers and what they did:
> 
> 1. Timing.  There are times when a specific response must be returned
> from the program or user interface before the user can successfully
> enter the next command or keystroke.  When I watch people doing
> supposedly "the same thing" that I do, they often don't have their
> timing in sync with the program they are using.  They're ususally not
> waiting for the response from the program or they are entering the
> keystrokes/mouse clicks in too rapid succession, or they're simply not
> waiting long enough at the end of the entire command sequence.  (They
> simply give up too easily).
> 
> 2. Persistence. Some computers and programs are simply buggy.  We had
> the problem of crashes with some programs that were annoying but minor
> (no data loss, machine could be restarted, etc.)  Some of our staff
> would be completely thrown by the experience of a Windows crash or the
> screen freezing on an application, and they'd assume that this meant
> they needed expert assistance, instead of just rebooting or closing the
> app. from the task manager and trying again.
> 
> 3. Minor differences in user input.  I've seen problems caused by
> programs that were unexpectedly case sensitive, those that regarded
> spaces as signficant characters and thus would not perform correctly if
> dan extra space were added to a command or search, and by people who
> just didn't quite have the full understanding of what exactly they had
> to be pointing at with the mouse.  Not to mention the more obvious
> mousing and typing errors that can happen with computer novices.
> 
> 4. Expectations.  Some users expect programs to come back with
> acknowledgement that a command was completed successfully or that the
> input was accepted - and that just doesn't happen in every stage of
> every computer function.  So, not getting a constant string of
> 'validation' responses, they assume something must be wrong.  And the
> converse can be true.  Users can misunderstand acknowledgement messages
> or easy to bypass error messages and sometimes think that they are fatal
> errors.  "Just click OK!"
> 
> Of course, it could be that none of the above is the significan factor
> and the computer just likes your manager and is not fond of the rest of
> the department.
> 
> Stacy Pober
> Information Alchemist
> Manhattan College Libraries
> spober at manhattan.edu <- don't bother, mail server down again <sigh>
> raingoddess at juno.com <- works
> 
> > From: Debra Lords <dlords at library.utah.edu>
> > To: gmasters at tamiu.edu
> > Our Government Documents area had a database which was
> > particularly "temperamental" in its behavior.  After one update,
> > the staff of the area repeatedly complained that the database
> > would not work properly.  I would go and verify their
> > experience.  I was new in my job and did not know how to
> > troubleshoot and fix the particular problem I was seeing.  Yet,
> > everytime my manager came around and tested the database, it
> > worked perfectly.  He was convinced the librarians and I were
> > perfect idiots but we were making the same keystrokes that he
> > was.  It would work for a day or so and then work strangely
> > again.
> >
> > One day the Head of the Government Documents group grabbed me and
> > showed me the database was working improperly again.  I found my
> > manager.  "Please humor me this time," I requested.  "I know you
> > think I'm out of my mind, but just go along."  I asked him to
> > come and watch us use the database.  I wanted him to neither
> > speak nor touch the keyboard ... just watch.  My purpose, I
> > explained, was to keep the computer from knowing he was there.
> > He agreed.
> >
> > We tried the database again.  Its behavior was as difficult as we
> > had always experienced. My boss watched our attempts that had
> > worked for him but did not work for us.  Following the test, I
> > said, "this is what it keeps doing."  He replied, "Now that I've
> > seen what it is doing, I think I can fix it.  Let me try one more
> > thing."  He sat down and began a search in the database, using
> > the same search strategy we had used.  The database functioned
> > perfectly.  "I don't beleive this!" he said.  "This is what we've
> > been trying to tell you," I answered.  "It works for you but not
> > for us."
> >
> > Thus far, I've not had anyone able to explain why the database,
> > in so short a time space, using the same search, did not work one
> > moment and worked the next.  However, I will tell people that
> > computers have a mission in life.  That mission is to make the
> > user look like an idiot in the worst possible way.  Using that
> > explanation, I've been able to calm many a deeply frustrated
> > person.  Although they aren't happy about their experience, they
> > feel better knowing that the computer people don't think they are
> > idiots, that its the machine and not them.

-- 

Debbie

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Debra Lords			Experience is what you
dlords at library.utah.edu		have just right after 
ACLIS Labs			you need it.
585-9810


More information about the Web4lib mailing list