VICUG-L Archives

Visually Impaired Computer Users' Group List

VICUG-L@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stan Berman <[log in to unmask]>
Reply To:
Stan Berman <[log in to unmask]>
Date:
Sun, 6 Mar 2016 07:12:18 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (150 lines)
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.

Stan


-----Original Message-----
From: Visually Impaired Computer Users' Group List
[mailto:[log in to unmask]] On Behalf Of peter altschul
Sent: Saturday, March 05, 2016 5:10 PM
To: [log in to unmask]
Subject: [VICUG-L] Those Annoying Error Codes

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]


    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]

ATOM RSS1 RSS2