First Apple Glass didn't learn from Windows Vista. Now Apple's Tahoe icons didn't learn from … Apple.
The issue is bigger than a mere disregard for the principles in the 1992 guidelines. It's that training for User Interface designers is nonexistent. As the old guard retires, untrained designers reinvent square wheels.
#UX #UserExperience #IxD #InteractionDesign #UI #UserInterface #UserInterfaceDesign #icon #icons #design #designer #training #education #retirement
Interesting talk from Scott Jenson. Apple and Microsoft have stopped innovating on the desktop UI. So what should we do next?
This talk focuses on that evil little term “UX/UI,” which is responsible for so much confusion and tension in open-source projects. Not only does it unnecess...
A very interesting take on how we came from the command line prompt to a graphical user interface. Just to go back to the command line prompt. Was it all for nothing?
#userinterfacedesign #ux #ui
John Gruber @gruber makes a lot of really good points in this, & hopefully we’ll see a renaissance in user interface design at Apple with this change. This point really stood out for me, though:
“I am not a Liquid Glass hater. I actually think, on the whole, iOS 26 is a better and more usable UI than iOS 18. But MacOS 26 Tahoe is a mess, visually, and I’m not sure there’s a single thing about its UI that is better than MacOS 15 Sequoia.”
Service design and the Mario complex
At Service Design in Government, I discovered that service designers see themselves as Mario. But that is an unrealistic model for what service design should be.https://duncanstephen.net/service-design-and-the-mario-complex/
To the user-interface designers and programmers out there: If the unfortunate event happens and you have to show an error message, please make sure the message is actually helpful for identifying the issue. You might think that hiding technical details is user-friendly, but in fact, the opposite is true. Do not make us guess what is wrong, tell us what you know!
You might be afraid that this confuses users who are less tech-savvy. Not necessarily, if you give them a rough idea first (maybe in a more emphasized font) and then continue with the details you have (maybe in a smaller font). I am quite sure users are able to ignore the parts they do not understand, and if they need support, at least the person giving support has something to work with.
Some simple examples:
❌ "Cannot connect to bluetooth device."
❓ "Okay, but why?"
✅ "Cannot connect to bluetooth device 'foo' (maybe it is turned off?): The device does not respond."
❌ "Cannot open file."
❓ "Which file? And again, why?"
✅ "Cannot open file 'testfile.txt' for reading: Permission denied"
❌ "Something went wrong when trying to load the website."
❓ "Again, what's the problem? Is the network interface down? Is the DNS server down? Is the target server itself down? Give me a hint, please!"
✅ "Cannot load the website. Maybe your computer is not connected to the Internet? Details: No route to host (192.168.10.1) when attempting to connect to the DNS server."
This is nothing new. In fact, it is just an adaptation of the top-down writing approach we also use when writing scientific papers, for example: You begin with a rough overview and give increasingly more details later in the text.
But do not omit the details completely!
#usability #userinterfaces #userinterfacedesign #errormessages #programming #writing #technicalwriting
Pull-to-refresh is an evil design concocted by the powerful to get people addicted to just having a tiny morsel of dopamine, particularly effective if one is vulnerable to having a gambling addiction as it purposefully mirrors the action of pulling a gambling machine lever.
Jerome
jpl99
obrhoff
A Guy Named Brian (he/him)
Duncan Stephen
Willow
Ars Technica News
Stefan Gast
Calicosine