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.


    VICUG-L is the Visually Impaired Computer User Group List.
Archived on the World Wide Web at
    http://listserv.icors.org/archives/vicug-l.html
    Signoff: [log in to unmask]
    Subscribe: [log in to unmask]