This morning as I was updating my iPhone, I received the following error message in iTunes:
User Interface design, like website optimization, is all about removing friction for your end users, and I was offended by a number of Apple’s choices on this screen:
- An “unknown error”? That’s like a doctor telling you that you’re the FIRST person they’ve ever seen with a certain symptom.
- I was trying to upgrade, not “restore” my iPhone. I realize this is part of the process but this is confusing to end users.
- The error box offers no resolution path. This is a lost opportunity, with no guidance despite “Unknown Error 1604” being a well known, resolvable issue.
From a user-interface perspective, this process could be greatly improved with something like the following:
With this new, friendly error box we’ve:
- Calmly announced that a small issue, with a known resolution occurred.
- Eliminated specific error language that may confuse users.
- Created direct, next-step actions for users to resolve their problem.
These simple changes provide users with positive reinforcement, clarity, and a call to action that’s sure to lead to a higher resolution rate.
Why aren’t software error messages written from a user-interface perspective?
What am I missing?
PS – If you too have had trouble with Error 1604 you can find the link to the fix on this page https://support.apple.com/kb/ts1275
https://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
Hadn’t seen that before, good one.
because writing good error text for possibly multiple localizations costs money?
The answer is pretty obvious, if you think about it. It takes one line of code to implement the dialog box you saw (if result != success errormsg “The iphone $name could not be restored. $errorstring ($errno)”). This isn’t the case of just taking some lines of text and giving them to some marketing dude. The developer has to think about each possible error which might be returned, figure out why this error might be returned, find a link to a page on how to deal with the error (which probably involves *creating* such a page), and then have a massive function to determine which of these hand-crafted error messages to return. Heaven help you if the same error code could be caused by more than one root problem.
Software development takes a lot of time, and optimizing for the error case isn’t always the best way to spend this time. Maybe the developer who would have written the function to display the box you wanted is instead working on a fix so that in the next version you don’t encounter this error at all.
No, the error dialog should show the root cause of the error and how to resolve it, not a link to a website and an “OK” button.
To a user with no interest in spending time poking around a website to resolve his or her issue, both of these dialogs are equally terrible.
Error: AppHole doesn’t care about your problems!
Haha, good one!
Whoops! I’m a patronizing dialog box! You may remember me as clippy from Word 97! Let’s all sing kum-bay-yah while all your data gets deleted!
I agree that the “unknown error 1604” is too hostile, but there’s no need to assume your users are 7 years old.
Furthermore, the replacement is arguably worse because you’re throwing away potentially useful information. At least the original dialog told you that it was doing something with your iphone. The proposed replacement references some mysterious “update”. What update?
How about this:
A problem occurred applying the update for “iPhone”. [Help is available here](link to help), or you can [contact technical support](link to contact page) – please provide the error code “1604” to our technical support staff.
I like your suggestion! But I’d caution you that most users, in fact, are WORSE off than your typical 7 year old growing up in the digital age ;-).
What you’re missing is that when that error message was written, there *was* no known solution, because it wasn’t a known problem yet. If the person who’d been writing that error-handling path had known about the solution, they almost certainly would have been able to avoid the error entirely.
Of course, in this always-online world, there’s no reason why the software couldn’t be written to submit the error information to the Apple servers and relay back any helpful response to the user. Unless the error has something to do with the network connection itself, natch.
@caf:
Considering that the error has an actual number assigned and a definite solution, then it was a known possible issue ahead of time.
@zack: Instead of a link to a website, the error box should go ahead and download the relevant information from the site to show. In this case, the box should go to apple servers, look up error 1604, and display that text to you. If the error is unknown, then they can say “contact support, we haven’t seen this one before!”
In the event the error is with network connectivity, well, it should be obvious what to tell the user.
Agree that the original isn’t helpful.
But making me read more isn’t the answer, either.
Let me repeat it:
because of the cost.
Almost all calls to the system, and almost all library function calls, can result in error conditions. That means that the simpliest programs become ten times bigger when they must deal with errors, twenty or thirty times bigger when they must deal with errors “intelligently”, produced nice contextualized error messages.
Are you ready to pay for computers with more memory, and to pay for software ten to thirty times more than you are paying now? As soon as you’re ready to pay for it, we’ll produce it.
It would be spectacular if they were more friendly but with yours you are running into the realm of TL;DR. I have difficulty getting people to relay specific 2 word sentences when it comes to logging to computers nonetheless have then get to the bottom of that error message. They just need a button that connects to their phone and calls tech support or opens a live chat session.