I really don't think that has anything to do with flat design whatever that means.
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.
How about putting the advanced options into a menu or make them somehow discoverable? I hate it when after years I found out that something was possible but I didn't know that I had to press option+shift+ctrl while standing on one foot. It's OK to make advanced features less prominent but don't hide them.
On mobile apps it's even worse. Swipe up, left or right? Nobody knows.
But once you know how to do it (it's swiping from right to left in a chat screen, by the way) it's a genius use of touch movement, right?
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?)
I came from android (and am going back tomorrow) and I can't count the number of things that I couldn't figure out on my iPhone or its apps. I won't get into the apps, as thats an app developer thing mostly, but man, it took me googling after 2 months of frustration to find out to ignore a phone call (make it stop ringing so I can continue listening to spotify in my car) I had to hit the power button. On my Android I just swiped "ignore" or whatever it says.
Or the time you sit in front of a dialog thinking it's installing the software only to realize there's a flat button you didn't think you have to press first when a flat button always just means "disabled". We're using designers that want to create art pieces when we need designers who should create usable interfaces. I don't want to hang the GUI on the wall to look at, I need to interact with it with as little guesswork as possible.
"the way you bring up the main menu is by pushing on the screen"
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.
I don't get this criticism either. Maybe that's because it works just like an iDrive controller. Plus, it's not really pushing on the screen, it's moving the entire device.
Am I missing something, or does "turning off" a thermostat not really make that much sense? And therefore, a UI that made that easy and obvious, wouldn't really be that good a UI?
The post said he/she wanted to turn it off because they were too cold, which seems a strange response. Surely what they wanted was to adjust the thermostat temperature?
I think it was meant as 'turn off the AC' which would allow the room temp to equalize with the outside world.
I'm used to stand alone AC units so I think in terms of 'turn it off to allow room temp to rise'.
I turn off my HVAC frequently in the transition months between winter and summer. I would not buy a thermostat that did not allow me to do that, and this "feature" is yet another knock against Nest that will keep me from buying one.
There are two easy ways to turn the nest off. Press the dial in and turn it off. Or from anywhere in the world from your phone. Also you can set it to heat/cool and set ranges where it will cool above x temperature and heat below y temperature.
For reference, the very common Honeywell thermostats that seem to be in every US house built in the last 20 minutes just have an unmarked button that cycles between Auto, Off, Heat, and Cool. (Auto means Heat/Cool.)
It does have the advantage that there are only four buttons on the whole unit, so trial and error works pretty well.
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'.
Not ten minutes ago I had the same experience in a web browser on my desktop; it turns out that on this site, which I've been visiting regularly for years, there is a button (unlabelled) which brings up extra content related to that day's content. I only discovered this from a passing comment on a forum.
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.
This is something that happens with HN, by the way. Links are not underscored, so it is not immediately obvious that you have to click on someone's name, the domain, the timestamp, or the comment count. I personally had this problem when the "link" link to a subthread disappeared.
HN shows underscores on hover, which at least lets you check if something is a link by mousing over it. But it falls apart on touch devices where hover doesn't exist.
I dunno, pushing the Nest was pretty obvious to me. Also I can't see why you'd want to turn it off totally. If you want the heating on permanently or off permanently just turn the temperature to an extreme value.
This was my take...the interface for turning it off is difficult to find because it was designed to be thus. The last thing most thermostat users want to do is to turn it off completely. Instead, they want to "turn it off" or "on" relative to local environmental conditions...and that's the dead-easy interface mentioned in the link: turning the big dial ring and having it respond both numerically and by color: I am going to get hotter or I am going to get colder. The click side of the interface is deliberately more obscure and meant for the administrator (for lack of a better term) and not the random temperature adjuster.
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 have never owned a thermostat that did not have an "On/Fan/Off" switch. The only thermostats I have ever seen lacking those switches, besides the Nest, are the thermostats used in large central HVAC systems where the thermostat is actually controlling a local blower and air damper, not the actual system.
Not being able to turn off the device is a problem if it controls both AC and heating (not sure if the Nest does). What if you just want the room to be whatever temperature it is outside?
With all due respect to Don (and I do have a lot of respect, he built the foundation upon which my career rests). He misses the larger picture. I'll simply point at Apple's market cap as to why Apple can afford to get away with form over function.
Absolutely, I didn't mean to issue an appeal to authority. I just thought there might be people who'd be interested in Don Norman's take, who wouldn't otherwise click through to Yet Another Apple Critique.
It's been years since I read Design of Everyday Things, but the lingering idea I've taken away is that beautiful products also work well. i.e. beauty and functionality are linked.
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.
"Beautiful products work well" means that beauty adds a plus to usage, not that it's the only factor.
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.
The takeaway from this is that affordances are still important in UI design. Many sites/apps nowadays try to get away without it. Even having a tutorial during onboarding isn't really enough. Users often disregard them, so you need to make sure things are intuitive.
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.
It's not just mobile apps, it's everything. I write demo software and libraries to control sensors that are used in everything from university lab benchtop research to heavy automation. You can never trust that the user reads a word of the manual (well the heavy automation guys probably do, because there's real danger involved), so I do my best to make it so in the demo software, there's one button you need to press to start communicating with the sensor, and very clear options from there to change the sample rate, save data to a file, etc.
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.
It seems that any documentation for software is useful more as a reference or as an FAQ or after you messed something up. This is why it's important to make tasks reversible or to make dangerous tasks take longer. We need UX/UI cues and your example of keeping the UI simple is great.
First we couldn't have 3d widgets, then we got them and designers took it away during the flat ui craze. These designers surely don't use what they design. What's worse is that everybody (KDE and GNOME) went with it drinking the kool-aid. Add on top of that that GNOME doesn't want you to use your own theme and do everything to unsupport or stifle custom themes. GNOME is following Apple's lead of "we know best". It's a sad day to be a GUI user. Look at the wasted vertical space in GNOME3 and tell me how that makes sense with widescreen displays that shrank in vertical size. Designers do not understand that 3d widgets serve a purpose. I wait for the day that designers make everyday tools all totally flat but at least there we have people without sight who will object. I remember when people complained Linux desktops were didn't have UI designers. If this is what it means to have designers, then I'd rather have my OS/2 GUI theme please. Designers gave us square toilet seats and rectangle table ware but our sitting organs and spoons do not match.
This is why I can't wait for Apple to introduce Force Touch. Do I press this lightly to do something completely different - does this app have that? Do I press it harder to do something else? Did I press it hard enough / lightly enough?
Maybe be need a way of tells apps / devices / applications that I am trying do something exceptional so please show me the advanced menu. Perhaps a special "expert" icon is always visible or a convention like clicking in the bottom-left corner.
53 comments
[ 3.0 ms ] story [ 112 ms ] threadApple 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?
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.
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'.
https://xkcd.com/1576/
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!
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).
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.
https://www.google.com/search?q=fancy+font
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.
Apple's slipping way behind on this.