Interface abusers
scraps.benkuhn.net
scraps.benkuhn.net
As a UX guy, this is why you do user testing. Just yesterday I was conducting a test, and one user was getting upset at our onboarding tutorial "Just get me to the app, I don't care about this." Not a moment later, "Oh wait, how do I do this? Haha guess I should have read the tutorial." It was a lighthearted moment given the circumstance, but in the real world and in aggregate, it shows how to lose users.
In the APIs we provide for them to do their own programming, ideally they only have to declare a new instance of a single object, with the necessary configuration data passed in as explicit arguments to the constructors, and all the communication methods are immediately accessible from that class' API. There's not a lot of extra new classes to hold configuration data, etc., because then the user doesn't know which fields are necessary to set in those objects. Sometimes that means you get more parameters than you might like in a constructor, but it makes it a lot easier for the user because they know exactly what you require from them.
(well the heavy automation guys probably do,
because there's real danger involved)
See, that's the risky mindset - not that I'm deriding you in any way, mind; we're all guilty of it! "They probably do" is the same as "they probably see what this button does", when they may perfectly well not even perceive that it is a button in the first place. Nobody's mind works in quite the same way as yours, or as mine, or as anyone else's.My point is, it's not just touch interfaces that suffer from this assumption that the user will "just get" the thing you thought up in the shower this morning.
Even a console application needs that moment of sanity checking - more than once I've sent out a script to users and found out weeks later that the one cool timesaving feature I was proud of just hadn't been used, because I hadn't told them about it, assuming instead that they'd connect the dots for themselves.
I think everyone who reads it had that experience at some point. Going back through the archive for the bonuses you missed is half the fun!
Apple is all about hiding non-essential information and functionality. Always has been. This is a consistent pattern you will be able to find in all their software if you pay a little attention. Basically, if Apple thinks something is a power user feature most users will not need then they have no qualms about not making it discoverable. They tend to even go a step further: they may outright hide it, making it impossible for users to ever be confused by it.
I don't think that's a bad design pattern (depending on context and circumstances, obviously, as always), you just have to make the right judgement calls about what's important and has to be discoverable and what's not. This allows the software to be simple to most users while also having some depth for more advanced users. Like always in design it's all about making the right trade offs, though. The devil is in the details.
On mobile apps it's even worse. Swipe up, left or right? Nobody knows.
I'm torn about this - it's annoying that it's hard to discover, but I also hate when an app gets all up in my face about how to use its features - I usually open an app (especially a utility app like iMessage) with a specific intent and having the app interrupt that intent to tell me about itself is annoying.
I also have the perspective of being an engineer who builds interfaces. I think these are just hard problems and these kinds of pain points are inevitable as we continue exploring interfaces. I mean, the door is an interface that has been around since at least Egyptian times, and people still screw up affordance with it (how many times have you pulled a handle on a push door?)
Why not always show the time, like WhatsApp does?
It does have the advantage that there are only four buttons on the whole unit, so trial and error works pretty well.
I'm thinking there are two things at play.
I'm from Scotland where nobody has AC, so when you are cold, you turn on the 'heating'.
And generally we have a separate control panel and thermostat so they don't get merged in my head and I would never say 'switch off the thermostat' when I meant 'switch off the heating/AC'.
Cthulhu_ was likely understating on purpose, but this "Apple UI/UX guy" is Don Norman.
Doesn't seem to match up with his statement "the fonts are pleasant to the eye, but difficult to read." Especially for something like a font, where the aesthetic and the utility are so difficult to separate.
An ugly but functional device will work worse than an equivalent device which is also pretty and fun. But if the pretty device has dreadful usability, it won't work well no matter how pretty you find it.
As for fonts, the prettiest and ornate ones are often the prettiest, yet more difficult to parse.
TFA seems to be complaining that it's too difficult to find a feature that most thermostats elide completely. Every other model I've owned in the past could only be turned off by unplugging, which requires un-mounting the entire thing or powering down the furnace (or similar).
I've never used one before, but does pushing the edge also work? Having used other devices with turn/push/pull knobs (like washing machines), that's what I'd probably try next.
Apple's slipping way behind on this.