That 8088 MPH demo is a tour de force. Which tells you that the millions of Apple laptops being bricked right now instead of being recycled could have some amazing use if it were possible to wipe them clean and reuse. Sigh.
Well-balanced, well-written article. It linked to a site called demozoo that used Cloudflare bot detection to block me at least 6 times from my home IP that CF had heretofore permitted, which is damn nice of them considering nothing nefarious ever originated from this address.
So, no way to tell if the illustrations were illustrative.
In general for the 40+ years I’ve been a programmer I have detested the practice of not surfacing diagnostic information to users when technology makes it possible to do so in a clear and unambiguous way.
This is because error messages have historically been bad, unintelligible, un-actionable, and hard to separate from soft errors that don't actually matter.
'Segmentation fault. Core dumped.'
'Non-fatal error detected. Contact support.'
'An error occurred.'
'An illegal operation was performed.'
'Error 92: Insufficient marmalade.'
'Saving this image as a JPG will not preserve the transparency used in the image. Save anyway?'
'Saving as .docx is not recommended because blah-blah-blah never gonna give you up nor let you down.'
I can't blame any normal user from either not understanding nor giving a shit about any of these. If we'd given users actionable information from day 1, we'd be in a very different world. Even just 'Error 852: Couldn't reach the network. Check your connection to the internet.' does help those who haven't turned of their brains entirely yet.
Now imagine if that error said 'Error 11: A memory error occurred. Your program may be faulty or misbehaving. Contact your software vendor." That's miles better than what most things provide.
That one's a good example of why these things are hard. The user could have been running 5 different programs, any one of which caused this error, and MacOS can't point the finger at anyone. Not to mention that the problem could be MacOS itself, or the user being a dunce who misconfigured something. I'm not sure if that error can occur without 3rd party software being involved, but if it can, then that error message might need to be even more vague, helping the user even less. Not to mention it could just be faulty hardware.
A paper manual offering troubleshooting steps for each error would be really helpful. Just 'Error 11. Consult your manual.' and the manual actually telling you what the problem could be is also miles better than what we usually get.
> The user could have been running 5 different programs, any one of which caused this error, and MacOS can't point the finger at anyone.
It's still an example why it's worth giving your users a fighting chance. MacOS may not know enough to point the finger at anyone, but the user knows what they were doing at that moment, and even if they were not paying attention, they might start now. They'll realize if something is off. Or, after 10th time they get this error, they'll connect the dots and realize it's always happening when application X is running and they try to launch Y.
Or maybe sometimes they won't. Maybe they'll form a story and maybe it'll be all bullshit, or maybe good enough. Either way, the important part is, the user retains agency in the process. Giving people information is how they can become self-sufficient users and trust technology more.
This was 30 years ago, it was Mac OS classic with co-operative multitasking and zero inter-process memory protection, when the error comes up the only option was "restart" (the computer, not the task).
Don't blame this one on programming techies. This one is ALL the fault of shitty UI designers abusing modal dialog boxes.
A modal dialog is supposed to be for something damn near irreversible--like about to blow away your application because of error. You are supposed to STOP and go get the guru or you are about to lose, badly.
Unfortunately, UI designers throw them up for everything and people get used to simply clicking "OK" to make them go away so that they can get back to doing their task. So, when the user gets an actual error, they've already blown away the dialog box with information.
Your 'Saving this image as a JPG will not preserve the transparency used in the image. Save anyway?' line is a horrifically excellent example. That is a standard "Save As..." response, and it should NEVER have been. That should have always been under "Export..." as saving should never throw away information and it would be perfectly fine to regenerate a JPG as long as you have the full information still available in the original file.
This is the stuff that infuriates me about the UI designers. Your job is about interactions, first, and pixels, second.
This is because error messages have historically been bad, unintelligible, un-actionable, and hard to separate from soft errors that don't actually matter.
And they've only got worse: "Something went wrong". Well no shit Sherlock, I can tell something went wrong because the thing I tried to do didn't work. Possibly the single most useless error message every created, and it's everywhere. Most of the worst-case error messages in the quoted response are still better than this one.
If you ever run into a developer who thinks "something went wrong" is an appropriate error message, have them killed. Then kill their entire family and pets, burn their house down, and plough salt into the ground where it stood. Finally, put up a sign that says "The person who used to live here thought 'something went wrong' is an appropriate error message to display when something goes wrong. Take note of their current situation when you next add an error message to your software".
reply