of mouse balls and such

Paul H. Gray dekerivers at earthlink.net
Sun Jan 2 16:32:05 EST 2000


And let's not forget the simple physics that become an increasing factor as
we move away from LAN resources to the Internet --

MANY times I have responded to a user complaining of a DNS error message or
a slow connection/timeout etc  -- only to find when I clicked on the same
link or whatever --
that it worked fine.

As much as I would love to take credit for 'fixing the problem' I smile and
explain that
The difference had nothing to do with anything the user did -- or I did --
or anything anyone can control ---- but a matter of congestion at any number
of possible bottlenecks  -- congestion that can appear and disappear in a
matter of seconds --

When that draws a glassy stare -
The best analogy I have heard is a freeway on-ramp  --- the same driver in
the same car at the same intersection may be able to merge seamlessly one
time only to have to sit and wait the next

PHG
Hurst, TX
> -----Original Message-----
> From: web4lib at webjunction.org
> [mailto:web4lib at webjunction.org]On Behalf Of Stacy Pober
> Sent: Sunday, January 02, 2000 1:14 PM
> To: Multiple recipients of list
> Subject: [WEB4LIB] Re: of mouse balls and such
>
>
> 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.
>



More information about the Web4lib mailing list