Greetings,
Yes, I've come across these and found the below interesting, lifted from
another techy group.
From: peter altschul <paltschul@xxxxxxxxxxxxxx>
Date: Sat, 5 Mar 2016 16:09:35 -0600
From Fastcompany
80004005: Why Error Messages Are Still So inin&%$#!
Indecipherable
Don't feel bad if you're stumped by an obscure code. There's a
good chance the engineers are too.
Jared Newman 03.03.16 11:16 AM
If you've ever been vexed by a phone, tablet, or PC, chances
are you've bumped into an error code.
From the iPhone's recent Error 53 to the mishmash of letters
and numbers that accompany a classic Windows' "blue screen of
death," these indecipherable codes heap insult upon injury. One
moment you're trying to write an email or install a software
update, and the next everything shuts down, with no clear
explanation of the problem or how to fix it.
Even with user-friendliness in personal computing at an
all-time high-and plenty of computing resources to devote to
explaining what went wrong-error codes have stuck around,
sometimes to the dismay of users who've come to expect better.
When Error 53 gained widespread attention last month, for
instance, one of the primary complaints from Apple observers was
about the uselessness of the error message itself. Surely, Apple
could have done better than "unknown error occurred (53)."
But if there is a better way to handle errors, it's unlikely to
obviate the need for error codes, at least according to some
experts with whom I spoke. These codes are just too ingrained in
the way software is made, which means they'll continue to pop up
at inopportune moments for years to come.
How Error Codes Are Born
The important thing to know about error codes is that they're
not really meant for users. Instead, they're a remnant of the
software development process, in which programmers assign strings
of letters or numbers to specific problems for the sake of
debugging. The assumption is that users will rarely, if ever,
run into such problems once the software ships.
"If [programmers are] there to see that tree fall, they know
what to do with it," says Wes Miller, a former Microsoft manager
who is now an analyst for Directions on Microsoft. "But
unfortunately, it's when you distribute that software, and people
start pushing harder against it in ways the developer didn't
foresee. That's when the error codes shine through."
After the software launches, error codes find a new purpose in
life. They are no longer just internal testing tools but a form
of external feedback that users can reference when
troubleshooting a problem. Instead of overwhelming users with
information or making them remember exactly what happened when
their software failed, error codes serve as a shorthand that can
work its way back to the engineering team.
The Problem With Plain English
Ideally, software makers would never confront users with just
an error code. A better solution might be to explain the nature
of the problem, along with a code that tech support or the
development team could reference later. But this approach raises
its own challenges.
Some companies, for instance, have separate teams for
programming the core system and the user interface, says David
Ko, a former Google engineer and cofounder of Jide, which is
building a productivity-centric version of the Android operating
system. Those two teams would have to coordinate on what an
error message should say, and that process can become burdensome.
"To be honest, you get new error codes almost every day,
because the engineers, when they think of a new feature, or new
sets of code, they will have a new error code," Ko says. "So, I
think there can be a disconnect between the front end and the
back end of the system."
Hardware constraints can also get in the way of helpful
messages, especially when an error prevents the system from
booting. As Miller points out, a system that hasn't booted yet
may lack the resources to fully explain what is happening or
accept any additional input from users.
"Now, when we do see these gross error dialogs-let's call them
useless error dialogs- you're sitting closer and closer to the
hardware, and there's less and less to work with to actually help
the user when the metaphoric object has hit the fan," Miller
says. Rather than create what is essentially a separate
operating system to deal with boot errors, it's easier to just
throw up a code that users can look up on another device or
direct to tech support.
On a more fundamental level, translating an error code into a
useful explanation may not even be possible until the engineers
have more information. After all, the reason these codes exist
in shipping software is because the developers failed to account
for every possible scenario.
"In support issues as a whole, if you knew this would happen,
you generally would have prevented it, because support is money,"
Miller says.
Apple's Error 53 is a perfect example. At first, the company
suggested that the iPhone's boot failures were due to "additional
security checks," which occurred during a system update or
restore. Only later, when issuing a fix for the boot problems,
did Apple explain that those tests weren't supposed to happen
outside of the factories where iPhones are made.
In other words, Apple's own public explanation of the problem
was incorrect for nearly two weeks, and even that explanation
came months after users began experiencing Error 53. It's hard
to imagine a plain English description of the problem that would
have been truly informative during this period.
Fewer, Better Error Codes
Although error codes will be tricky to banish from modern
computing, software makers are getting better at making them
occur less frequently.
Jide, for instance, doesn't throw error codes at all in its
alternate version of Android, called Remix OS. When a crash
occurs, the program simply shuts down or tells the user to
restart. "I don't think that pushing out an error code helps
users, because most users don't know what that means," Ko says.
Besides, these days software makers can still determine what
went wrong without showing an error code, thanks to the rise of
ever-present Internet connections and automatic collection of
telemetry data, Miller says.
"[Developers] started getting the ability to tune their
applications better, and say, 'Oh, my users are seeing this error
a lot. How can I make that error go away"'" he says.
If there's a downside to this approach, it's that users remain
in the dark about what went wrong and whether there's anything
they can do about it. This can create more frustration, or even
embarrassment.
Just ask Microsoft, whose infamous "Something happened" error
message in Windows 10 became a punchline. "It's almost like a
condescending dialog," Miller says. "I'm trying so hard to be
cute here-because there are so many error conditions that could
have happened, I can't identify it."
When error codes are absolutely necessary, perhaps the solution
isn't all that complicated. Just explain to users that they are,
in fact, looking at something not meant for them. Don't assume
that every user is savvy enough to know what that random string
of letters and numbers is for. "Something went wrong and the
system can't fix it," the message might say, "but here's an error
code you can refer to tech support for further assistance." That
little bit of extra hand-holding could be the difference between
keeping users in the dark and giving them the ability to take
action.
From: Stan Berman <sb2001@xxxxxxxxxxx>
Date: Sun, 6 Mar 2016 07:12:18 -0500
Peter and List:
I agree. However, I especially like the error messages that say something
like, "Internet Explorer has encountered a problem and needs to shut down.
OK." There are some variants of this where the program error message tells
the user that it can't find a file and presents that "OK" button which
either doesn't work , or which closes the message but the message keeps
popping up for a repeat performance 10 times or more, or until the
aggravated user presses the power off button on the computer.
From: Ana G <lot.of.yada@xxxxxxxxxxxxx>
Date: Sun, 6 Mar 2016 08:11:27 -0800
I used to take error codes very seriously, looking them up so I could
give them to tech support and researching them myself so I, a non-techy,
could either fix the problem myself or know how to talk about it when
getting help. The first thing I learned is that tech's weren't mostly
blew them off altogether, not using them to find a solution or logging
them for sending on. The second thing I noticed is that a lot of the
error codes are so vague they don't lead to a fix. I personally didn't
mind the Windows "something happened" error for this reason.
** To leave the list, click on the immediately-following link:-
** [mailto:access-uk-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** access-uk-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:access-uk-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** access-uk-request@xxxxxxxxxxxxx with the Subject:- faq
