Explaining the cause of problems to users

[pete]

The pfy and I have fallen into the habit of often explaining problems by saying "because $foo is (either) a) stupid / b) rubbish". Between the two of us (and bearing in mind we know $foo pretty well) that's not a bad problem description:

 

a) generally means that while $foo normally does $bar, it has inexplicably decided not to for no real reasons that we can determine.

 

b) means that you could reasonably expect $foo to do $bar (based upon cost, common sense, abilities of things similar to $foo and the job $foo was designed for), but its creators have failed to include $bar as an option.

 

Unfortunately, this baffles the users. When I was contracting I would happily spend hours explaining problems to clients - they were paying for the explanation at an hourly rate. If the explanation can prevent the same (user-initiated) problem cropping up again, we take the time to drill it into them. But usually it's just a drain on our time and few of them will actually understand the cause - that's not a criticism, it's not their job to know.

 

So, how detailed are the explanations you give to users?

[webman]

If it's something pretty basic like an option needing to be ticked, I'll explain that. Otherwise it's "just a technical glitch with the software/hardware".

 

Occassionally, I'll fire up the BOFH Excuse Generator (I've also got a vbscript version that puts them into a message box) and quote them an appropriate and believable reason :twisted:

[Gatt]

lol @webman - i could use a copy of the VBScript version

Tend to use the good ol' BOFH Excuses myself

[john]

ROFL@Webman, I love that BOFH generator Must resist urge to use it with the problems next week........

[GrumbleDook]

I tend to just say "Sometimes this stuff just doesn't work the way you would either expect or the way it should ... there are a few reasons why it has done x this time, but we will do what we can to either sort it so that it doesn't do that again, or we will try and find an alternative way of doing things for you."

 

Keeps most users happy.

 

The other answer is "There are some things that software / hardware are designed to do ... unfortunately reading your thoughts is not one of them. Just screaming at the computer to tell it to work mught be a flaw in the design, but a flaw in your design rather than the computer's..."

 

I do have a final one too ... "Do not confuse the computer's complexity with your idiocy!"

 

Yes ... I do save the last one for special occassions.

[webman]

Ah, sorry.. it's a JScript one (still runs under Windows Script Host) - get it here then save as .js.

 

Just run it to popup random message - Retry for another one, Cancel to close.

 

To show specific message, run (or make shortcut to) bofh.js . (The error number is shown in the title bar when ran without a parameter).

[pete]

@webman

 

The problem with using the bofh excuse generator (as a joke) is when a not-so-clued-up phb believes the excuse to be real and then uses it in a meeting with the (really quite technical) ceo.

 

Been there, done that, dodged the flack.

[webman]

Heheh, true..

[plexer]

How about:

 

"I could tell you but you wouldn't understand"???

 

Ben

[Ric_]

I often contemplate explaining the problem, then quickly realise that the luser would not understand the reason and resort to "it just happens sometimes" or "it's been doing that lately" orsomething equally vague.

 

I know it's naughty of me not to even bother trying to explain. Oh well.

[robert.mabbutt]

webman thats going to be really handy! now i can just run that instead of telling the teachers the real reason then having to deal with a buffer over run error and wait for them to reset! lol

 

Robert!

[sidewinder]

I dont bother normally

 

Sometimes theres a teacher that seems really interested in why something is happening, so I tell them without being overly technical

 

But some people you just know arnt going to care or understand, even when they do ask 'well what was the problem?' - generally then I use the same responses as Ric

[webman]

Sometimes when we explain we just get "Oh right, I didn't understand any of that but never mind" which makes you think "why bother". Just like we don't need to understand teaching practicses as such, they don't always need to know why computers do what they do.

[_Bat_]

Sometimes when we explain we just get "Oh right, I didn't understand any of that but never mind" which makes you think "why bother". Just like we don't need to understand teaching practicses as such, they don't always need to know why computers do what they do.

 

Oooh yeah. I only ever get two responses... the silent blank stare and finally an "okay.." or the one you said above.

[contink]

I usually stop after 30 seconds and ask calmly... "Did I lose you at the 5th or the 6th second back there?"

 

Most of the time they don't really want to know, they just want to know that you do..

[Vegas]

We've been getting away with the 'ID10T' line for almost a year now and still no one has caught on!!

[Jake]

I rarely bother to explain anything these days, they usually ask what was wrong, and within 30 seconds of answering they are staring blankly or saying "well that means nothing to me" . Leaves me thinking well what did you expect, its obviously going to mean nothing to you, cause if you understood it you wouldnt of needed me to remedy it

[bossman]

I find that all end users mainly want to know is when will it be fixed. Occasionally one clued up user will ask what the problem was and i will tell them at a ground level scenario otherwise i resist the urge to completely brainwash them as they walk about for the rest of the day like zombies.

[djm968]

And when asked "will it happen again" I always reply "if you want a guarantee, buy a toaster"