Hacker News Reader

> 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.

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.

> 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.

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).

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.

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.

That's an interesting take. Thanks for sharing. Sure, I can definitely see the "google this error" effect as having permitted a higher degree of complexity. Or, maybe to be more accurate, lowered the barrier to entry to create more complex systems. There are probably pros/cons to this. It takes less sophistication to build something very complex, thereby democratizing the ability of building sophisticated systems/services, but it also means there are many more complex systems out than there is a community of people who have a more-or-less "good" understanding of what they do and, possibly, whose overall behaviour is likely only partially understood by their own designers. Cue in all sorts of security implications, etc. Food for thought.

I don't mind the quoting, but, just in terms of mental hygiene, I generally dislike posting unequivocal opinions on the internet ... because it's often come back to bite me ;) I'm especially skeptical of my own writing when I use labels such as "ignorant" or "arrogant". So long as you understand that I don't take myself very seriously, I mostly stand by that quote you mention.

No, the best that you can do is paste it into Google.

Giving a user an error ID gives them a partially-if-not-completely unique identifier that they can then use to find other people struggling with the same error and possible solutions.

This is infinitely better than having no error message and having to try to type different permutations of your symptoms into Google in order to try to win search engine bingo.

Sure, if Apple quickly and responsively fixed issues, then you wouldn't need the error code. But, they don't! The problem is that "hide the error message and replace with actionable advice" only works in the idealistic case where the vendor will quickly fix the issue and/or the advice consistently fixes the problem. But, they don't, and it doesn't - the advice doesn't work unless implemented flawlessly - it's not robust.

The robust approach that will actually survive contact with the real world is "include an error message and ID code - even if you have to hide it behind a "more details" button".

Or worse, the fix suggestion being wrong: "Please try again later", when the root cause is a misconfiguration, so it'll never work until the configuration is corrected.

And if it's a program display it in some fashion where it can be selected so you can ^c^v it rather than have to retype it. Such errors are all too often displayed on non-selectable labels.

Bonus points to the mythical developer that includes a google-this button on the error display.

And then what? Is Apple going to receive the error log and dispatch a technician to your house to fix it?

In my experience sending crash data to software companies has never resulted in my satisfaction, nor has using some 'wizard' to diagnose an error. As alluded to above these systems are just not smart enough to actually know what's wrong. If the original programmers could create a fully automated flow to repair all error conditions then why bother notifying the user at all?

Interestingly, sending crash data to open source projects often results in timely fixes.

Sending them to large software companies does not have the same outcome. But then, that's certainly not a flaw with the format.

Apple doesn't have to lift a finger beyond showing an error message with some kind of identifier. The user isn't expecting an onsite visit anyway. They can go to the local Apple store and explain the issue to an employee there, instead of wasting time trying to reproduce the error.

If they're not tech-savvy (and you would never talk to Apple store employees besides at the checkout counter if you were), they likely won't be able to reproduce the error anyway. They'd fumble around trying to explain what went wrong, and the employee would run through multiple scenarios trying to reproduce it.

You are making the same error as the book: assume that every user is non-knowledgeable, helpless and stupid, and that no user has access to a trusted expert to help them (whether for free or for a fee). And by designing for that error, it will become true. And knowledgeable, capable and smart people will resent you for it.

> 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.

> 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.

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.

Eh, I read the book as presenting a maximalist vision: in a perfect world, all error messages would instead be help that lets you resolve your issue.

Since it says to hide error messages and instead provide help, anyone who hides error messages and doesn't provide help can't really be said to be following the book's advice. It feels wrong to me to blame the book for not, in every bit of advice it offers, saying "don't half-ass this incorrectly". That seems inherent to me.

It's not a very useful book if it doesn't provide advice that works in the real world. I have not read the book - does it give advice on what to do if it's not possible to give help? Or does it just assume that it's always possible to be perfect?

In Ye Olde Dayes, Macs would in fact give you messages like "error 39!" when something went wrong. Only, in those days, there was almost no way to figure out what that meant.

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.

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.

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.

This is such a weird take.

First off, Norman wasn't schooled at Apple, he basically created the HCI guidelines with Nielsen. Apple's design guidelines have long been based o years what Norman worked on so you have it the other way around.

In no part of the book does it say that engineers shouldn't be part of the design process. What the book advocates is that if engineers are entrusted with design, they should at least understand the users and design their products based on their needs and for the users. Anyone can be a designer, anyone can apply design thinking. No one is excluded.

And your comment about error codes, I would always say that an error message is more useful than an error code. You say that you would Google the code, wouldn't it be more useful if you could just read the actual error code and figure out what went wrong without habing to look it up first somewhere else?

What Norman advocates for is to help the users help themselves, show the state of the application and don't hide things behind error codes.

Again, silently failing is definitely not recommended by the book or anyone really so if thats been your experience with Apple, it's not because they follow the teachings of Norman's book, it's because they _don't_ follow it.

See the "Acknowledgements" section of his book -- pp. 299-304. Yes, Norman had written "The Psychology of Everyday Things" prior to joining apple. But in his acknowledgements to this particular book (i.e. "The Design of Everyday Things" p. 301) he very heavily credits his experience at Apple: "I have learned a lot in the years that have passed since the first edition of this book ... The most important experience was at Apple ... I learned about industrial design first from Bob Brunner, then from Jonathan (Joni) Ive. ... Steve Wozniak, by a peculiar quirk, was an Apple employee with me as his boss, ..."

So while Norman wasn't a neophyte when joining Apple, he clearly credits his experience at Apple for having heavily influenced the specific book we are discussing.

Norman certainly doesn't recommend silent failure verbatim. But what I'm saying is that this is the net effect of his recommendations.

I've read both editions, they're not really that different.

Hum... He clearly says that engineers have ideas that are antagonistic to interaction design. There is an implied message that they can learn not to, but one message is explicit, the other is implicit.

And it gets much worse in "The Inmates are Running the Asylum", that says engineers shouldn't do design right in the title, on the most sensationalist way possible.

Later he toned down that message a lot. Nothing from his group will say that anymore, and you will get a clear message that making your engineers think about design is better than nobody thinking about it. It still carries a message that you should leave design to experts, but you won't find anything there saying that engineers can't be UX experts anymore.

Regardless of what the book says, anyone too close to the product during its development will have difficulty designing it appropriately for the user.

If you know how the product works then you already have a mental model of interacting with it. That mental model is NOT the same as the user will have, and thus an engineer will think that something is obvious even though it is not obvious to the user.

The same goes with anyone else who is close to it during the development.

You need outside users to make it clear how people new to a product can understand and interact with it.

Unless you're an engineer who can forget everything they know about their own product, you shouldn't try to design everything yourself with no outside feedback.

That's correct, and the designer is too close to the product too.

That is the correct message, and the one every article about design should push. Neither the engineers nor the designers can design a product in a vacuum.

Those are both old books that do not deny this message, but focus on less relevant subjects, and have less than clear advice. We shouldn't recommend those books for people without previous knowledge on UX design, because they will be harmful.

Besides, given that Nielsen was himself a very important voice on the creation of the modern user-focused design, there is very likely a newer book from him to recommend instead (I stopped reading his books and started reading his papers at the time of the change, so I don't know one).

> 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.

I don't think you read the book. I read the book in 2000/2001. The emphasis was on helping the user.

Not a single line in that entire book, IIRC, advocates silently failing. I have no idea how you came up with that interpretation, when almost every single example in that book highlights "silent failure" as something to avoid.

There's an endless debate in programming languages about how to handle errors in software. Error codes, exceptions, optional types, NaNs.

One solution I try is to redesign the cause of the error out of the system. For example, compilers often have maximum quantities of language constructs that are supported, like the maximum length of a string literal. Then, when the length is exceeded, an error message is concocted and generated, then error recovery has to be done, then the compiler has to not generate an object file, etc.

I don't know what other compilers do, but one day I realized that it was less work in the compiler to not have a limit, but to keep enlarging the string literal buffer. There was only one limit left on all these things, that was globally running out of memory. Globally running out of memory is a fatal error for compilers, and so error recovery isn't necessary. Just print a message and exit.

This works great. Large numbers of errors just go away, like "line length too long", "string literal too long", "too many cases in switch statement", "too many symbols", etc.

There are, of course, still some limits, like the object file formats often have hard limits, and of course you don't want to overflow the program stack.

Yup, these days any serious use you can afford to throw memory at the problem. So many things become so much easier when the limits are pushed back to out of memory or integer overflow territory.

30 years ago I had to live with problematic memory limits and made some design decisions that over time I would come to hate because I had to shoehorn data into EMS memory banks. Data objects ended up sliced and diced into separate arrays, never did they point to the relevant things because such pointers would always have been into a different bank and the only possible allocation was the whole bank.

I had a funny discussion with Don Norman about pie menus and SimCity, in which I blamed the nuclear meltdown on the linear pull-down "Disaster" menu, and blamed round pie menus for putting out fires quickly but ultimately leading to urban sprawl:

https://www.youtube.com/watch?v=5GCPQxJttf0

Don Hopkins and Donald Norman at IBM Almaden's "New Paradigms for Using Computers" workshop

Talks by Don Hopkins and Donald Norman at IBM Almaden's "New Paradigms for Using Computers" workshop. Organized and introduced by Ted Selker. Talks and demonstrations by Don Hopkins and Don Norman.

Norman: "And then when we saw SimCity, we saw how the pop-up menu that they were doing used pie menus, made it very easy to quickly select the various tools we needed to add to the streets and bulldoze out fires, and change the voting laws, etc. Somehow I thought this was a brilliant solution to the wrong problems. Yes it was much easier to now to plug in little segments of city or put wires in or bulldoze out the fires. But why were fires there in the first place? Along the way, we had a nuclear meltdown. He said "Oops! Nuclear meltdown!" and went merrily on his way."

Hopkins: "Linear menus caused the meltdown. But the round menus put the fires out."

Norman: "What caused the meltdown?"

Hopkins: "It was the linear menus."

Norman: "The linear menus?"

Hopkins: "The traditional pull down menus caused the meltdown."

Norman: "Don't you think a major cause of the meltdown was having a nuclear power plant in the middle of the city?"

(laughter)

Hopkins: "The good thing about the pie menus is that they make it really easy to build a city really fast without thinking about it."

(laughter)

Hopkins: "Don't laugh! I've been living in Northern Virginia!"

Normal: "Ok. Isn't the whole point of SimCity how you think? The whole point of SimCity is that you learn the various complexities of controlling a city."