8 ms·

> So this is what we actually get, devices that SILENTLY fail, designed for people who are assumed not to know what they're doing and who likely do NOT have any

by kemayo 4y ago

> So this is what we actually get, devices that SILENTLY fail, designed for people who are assumed not to know what they're doing and who likely do NOT have any technically-literate person around them that could assist them if they could in fact identify the problem. It sounds like your complaint isn't with the advice from the book, but rather that Apple didn't follow it. They did hide away the error messages, but they didn't provide help and insight. If they had done so, you'd have (presumably) been told in the software that there was a problem with certain albums, and been walked through a flow that would fix said problem. Or maybe a link to a support page that'd do the same. This, if it was done, would have been much better than showing "error 0xFHJAD1234". Thus I think it's fairly good advice, as long as you read the "instead" as a critical instruction. You should eliminate opaque error messages so long as you can provide help and insight for those cases you have removed.

kyaghmour 4y ago
I don't mean to nitpick, but please refer to my comment regarding the inability of being able to inventory everything that can possibly go wrong in a computerized system. That's especially true given that if you take any successful engineering project, you'll see that its useful lifetime usually spans several individual engineering careers. Take something like Windows, or even Android for example. The people who were involved in its early days usually end up moving on to other projects. It's in fact not uncommon to change teams or companies every 3-5 years. There generally is no way for newcomers to understand everything about the system they're inheriting and they'll typically be encouraged not to break legacy stuff. So not only are systems increasingly complex, but those maintaining them at any given point in time likely don't understand them nearly enough to accomplish what you suggest: understand all potential outcomes and provide useful error recovery. Therefore, the "provide help and guidance" advice provided by Norman effectively becomes "silent failure" for those cases not anticipated by the current-day release team. And since anticipating all outcomes is by definition impossible, Norman's advice is awful.
- kemayo 4y ago
  > And since anticipating all outcomes is by definition impossible, Norman's advice is awful. Yes, that's why I said that I read the advice as saying it should only be followed when you can provide help and insight. You don't have to do it in an all-or-nothing way. You can have common problems with a helpful flow that tells the user how to fix them. You can have less-common problems which just show an error code. Removing the error without providing help is the problem here, and is the thing that I feel goes against the book's advice.
- alistairSH 4y ago
  For the example you gave, as a user, what would you do with "Error: 0xFHJAD1234"? The best you could do is report it to Apple (or whoever). But, the error alone doesn't achieve anything. You would have been better off with "Something broke, click here to send log to Apple." (which is roughly what the book recommends - replace the error with something actionable).
  - kyaghmour 4y ago
    I have copied-and-pasted the strangest of kernel errors, compiler errors, god-knows-what-obscure-tool errors, etc. over the past 20+ years into search engines and have almost always been delighted and amazed at how somehow someone somewhere at some point in time had not only encountered the same thing but actually wrote a description of possible root causes and potential solutions that often unstuck me right away. The success of a site like stackoverflow is exactly this. It turns out that if you actually do take the time to report the error, no matter how obscure it is, someone in a dark corner of the internet will spend enough time on it that they'll even see fit to document it for others to help their own selves out. And given that, per my initial post, nobody is smart enough to understand how the computer system/software they're creating is going to work under all circumstances, providing error verbosity is sometimes the most empowering thing you can give to your users.
    - carapace 4y ago
      I call it "Somebody Else Has Had This Problem". It's a heuristic that became useful starting about twenty years ago, eh? Before the internet you had to have (and write) fairly complete manuals for software, now you put the error message into a search engine and, hopefully, amortize the suffering. However, I suspect this has also made it easier to write and (kinda sorta) maintain larger and more complex systems. Like the phenomenon where you widen a road to ease traffic congestion and it works for a while but then encourages more traffic. The reduced cost of creating and maintaining complexity may have encouraged it overall. - - - - As an aside, can I quote you, like, on my blog? > in my line of work I have to be able to walk engineers I work with from the gate-level silicon all the way up to cloud and AI. Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both.
dpatru 4y ago
> It sounds like your complaint isn't with the advice from the book, but rather that Apple didn't follow it. They did hide away the error messages, but they didn't provide help and insight. > If they had done so, you'd have (presumably) been told in the software that there was a problem with certain albums, and been walked through a flow that would fix said problem. Or maybe a link to a support page that'd do the same. This, if it was done, would have been much better than showing "error 0xFHJAD1234". The parent post addresses this: there are so many ways for for the system to fail that it’s not feasible to “inventory every possible problem in a computerized system and then provide a graceful exit”. So where an error is not gracefully handled, the system should allow for a human to see the error and solve the problem, rather than throw away the error. >> Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both. But since you've eliminated engineers from the design loop (see #1 above), no one will tell you you're full of it.
- kemayo 4y ago
  > The parent post addresses this: there are so many ways for for the system to fail that it’s not feasible to “inventory every possible problem in a computerized system and then provide a graceful exit”. So where an error is not gracefully handled, the system should allow for a human to see the error and solve the problem, rather than throw away the error. Yes, that's what I said as well. It's why I said the problem was that Apple didn't follow the book's advice, insofar as they removed error messages without providing help for them... and so it's unfair for the grandparent-comment to blame the book when its rule wasn't followed.
  - ars 4y ago
    It's definitely fair to blame the book when the book gives advice that is impossible to follow. If it's not possible to always give help and advice, sometimes you have to give an error message and unless the book mentions that then it is definitely fair to blame the book.
infogulch 4y ago
If you have to say "Oh it's good advice but you have to interpret it right," when the advice has an obvious misinterpretation pothole that clearly wrecks many prominent applications of it, maybe that reflects poorly on the original advice and indicates that it shouldn't be offered without the necessary critical context.
- wbsss4412 4y ago
  It’s perfectly reasonable to point out the second half of the sentence. “It says to provide help and insight” isn’t law school levels of interpretation.
wtetzner 4y ago
Why not just include an error code and help and insight? That way, when the help and insight inevitably fails to solve the problem at some point, the user can still dump the error code into Google to see if other people have run into/solved the problem.

by kemayo 4y ago

kyaghmour 4y ago

I don't mean to nitpick, but please refer to my comment regarding the inability of being able to inventory everything that can possibly go wrong in a computerized system. That's especially true given that if you take any successful engineering project, you'll see that its useful lifetime usually spans several individual engineering careers. Take something like Windows, or even Android for example. The people who were involved in its early days usually end up moving on to other projects. It's in fact not uncommon to change teams or companies every 3-5 years. There generally is no way for newcomers to understand everything about the system they're inheriting and they'll typically be encouraged not to break legacy stuff. So not only are systems increasingly complex, but those maintaining them at any given point in time likely don't understand them nearly enough to accomplish what you suggest: understand all potential outcomes and provide useful error recovery. Therefore, the "provide help and guidance" advice provided by Norman effectively becomes "silent failure" for those cases not anticipated by the current-day release team. And since anticipating all outcomes is by definition impossible, Norman's advice is awful.

kemayo 4y ago
> And since anticipating all outcomes is by definition impossible, Norman's advice is awful. Yes, that's why I said that I read the advice as saying it should only be followed when you can provide help and insight. You don't have to do it in an all-or-nothing way. You can have common problems with a helpful flow that tells the user how to fix them. You can have less-common problems which just show an error code. Removing the error without providing help is the problem here, and is the thing that I feel goes against the book's advice.
alistairSH 4y ago
For the example you gave, as a user, what would you do with "Error: 0xFHJAD1234"? The best you could do is report it to Apple (or whoever). But, the error alone doesn't achieve anything. You would have been better off with "Something broke, click here to send log to Apple." (which is roughly what the book recommends - replace the error with something actionable).
- kyaghmour 4y ago
  I have copied-and-pasted the strangest of kernel errors, compiler errors, god-knows-what-obscure-tool errors, etc. over the past 20+ years into search engines and have almost always been delighted and amazed at how somehow someone somewhere at some point in time had not only encountered the same thing but actually wrote a description of possible root causes and potential solutions that often unstuck me right away. The success of a site like stackoverflow is exactly this. It turns out that if you actually do take the time to report the error, no matter how obscure it is, someone in a dark corner of the internet will spend enough time on it that they'll even see fit to document it for others to help their own selves out. And given that, per my initial post, nobody is smart enough to understand how the computer system/software they're creating is going to work under all circumstances, providing error verbosity is sometimes the most empowering thing you can give to your users.
  - carapace 4y ago
    I call it "Somebody Else Has Had This Problem". It's a heuristic that became useful starting about twenty years ago, eh? Before the internet you had to have (and write) fairly complete manuals for software, now you put the error message into a search engine and, hopefully, amortize the suffering. However, I suspect this has also made it easier to write and (kinda sorta) maintain larger and more complex systems. Like the phenomenon where you widen a road to ease traffic congestion and it works for a while but then encourages more traffic. The reduced cost of creating and maintaining complexity may have encouraged it overall. - - - - As an aside, can I quote you, like, on my blog? > in my line of work I have to be able to walk engineers I work with from the gate-level silicon all the way up to cloud and AI. Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both.

dpatru 4y ago

> It sounds like your complaint isn't with the advice from the book, but rather that Apple didn't follow it. They did hide away the error messages, but they didn't provide help and insight. > If they had done so, you'd have (presumably) been told in the software that there was a problem with certain albums, and been walked through a flow that would fix said problem. Or maybe a link to a support page that'd do the same. This, if it was done, would have been much better than showing "error 0xFHJAD1234". The parent post addresses this: there are so many ways for for the system to fail that it’s not feasible to “inventory every possible problem in a computerized system and then provide a graceful exit”. So where an error is not gracefully handled, the system should allow for a human to see the error and solve the problem, rather than throw away the error. >> Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both. But since you've eliminated engineers from the design loop (see #1 above), no one will tell you you're full of it.

kemayo 4y ago
> The parent post addresses this: there are so many ways for for the system to fail that it’s not feasible to “inventory every possible problem in a computerized system and then provide a graceful exit”. So where an error is not gracefully handled, the system should allow for a human to see the error and solve the problem, rather than throw away the error. Yes, that's what I said as well. It's why I said the problem was that Apple didn't follow the book's advice, insofar as they removed error messages without providing help for them... and so it's unfair for the grandparent-comment to blame the book when its rule wasn't followed.
- ars 4y ago
  It's definitely fair to blame the book when the book gives advice that is impossible to follow. If it's not possible to always give help and advice, sometimes you have to give an error message and unless the book mentions that then it is definitely fair to blame the book.

infogulch 4y ago

If you have to say "Oh it's good advice but you have to interpret it right," when the advice has an obvious misinterpretation pothole that clearly wrecks many prominent applications of it, maybe that reflects poorly on the original advice and indicates that it shouldn't be offered without the necessary critical context.

wbsss4412 4y ago
It’s perfectly reasonable to point out the second half of the sentence. “It says to provide help and insight” isn’t law school levels of interpretation.

wtetzner 4y ago

Why not just include an error code and help and insight? That way, when the help and insight inevitably fails to solve the problem at some point, the user can still dump the error code into Google to see if other people have run into/solved the problem.