This kind of post annoys me. It's driven by the fact that the author has some theories about UI design, and wants to share them with us. There's nothing wrong with that. But this post pretends to be like a real usability audit, which it is not.
> When I tap it, it turns red — but wait — it doesn’t give me the visual feedback. Did I break it?
> The alarm is shown as a red filled square, so when I tap it, it should perform a negative action, right?
These comments are disingenous. You didn't get confused by these things.
You, as a person who's analysing a UI, have an almost totally different mindset to someone who is just using the thing for real. You know this, so here, you're just play-acting. You're thinking, what might I get confused about if I was a normal user? That's a bad way to look for what's really wrong in a UI design.
Yes, when you present points like these, they sound reasonable, but that doesn't mean they're right. Perhaps the alternative (e.g. banning the use of red anywhere in the OS other than for a negative action) might be over-restrictive as a requirement, which could cause excessive complexity elsewhere in the UI and lead to a worse overall result. Or perhaps you're right, the colour–meaning thing should be 100% consistent above all other considerations. Either way, you don't know, and speculation about what might confuse a real user should not be presented as fact.
>This kind of post annoys me. It's driven by the fact that the author has some theories about UI design, and wants to share them with us. There's nothing wrong with that. But this post pretends to be like a real usability audit, which it is not.
Wrong on all counts. What the author complaints about are examples of broken standard usability guidelines that all experts agree upon.
Like consistency, affordances, the principle of least surprise, color coding actions, etc.
The excerpt you provide is characteristic: "When I tap it, it turns red — but wait — it doesn’t give me the visual feedback. Did I break it?"
The similar looking button in the Timer screen DID give visual feedback when pressed. In a consistent UI, either this button would do too, or neither would.
>These comments are disingenous. You didn't get confused by these things. You, as a person who's analysing a UI, have an almost totally different mindset to someone who is just using the thing for real.
Wrong again. Even a UI expert, or someone like me, who's been using DOS, Windows, SunOS, HPUX, Linux, FreeBSD and OS X UIs for 20+ years (and has designed some apps' UIs) can be confused by a UI, even in the most common app and in the most basic actions.
> The similar looking button in the Timer screen DID give visual feedback when pressed. In a consistent UI, either this button would do too, or neither would.
Visual feedback needs to serve a purpose. This is a stop watch we're talking about - one that shows time in tens of milliseconds, which is less than one frame interval at 60fps. Any animation done would hinder the function of the stop watch and raise ambiguity about when the stop watch actually started and stopped. So not using an animation is the right thing to do here. If they'd gone for consistency in this case, it would've been "foolish consistency" [1].
[1] "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson
I did not comment on the implementation. I said, in effect, that an animation would affect the perception of the start/stop times and using one would therefore be a bad idea in this case.
Yes the stopwatch's buttons are different, but there is a reason for this. Imagine you are using a stopwatch. When the gun fires, you press the button with your finger. When the runner passes the finish line, you push the button with your finger. You will probably expect it to stop and start timing at these times, with no regard for how long your finger spends sitting on the screen, right? Now look at the buttons in other apps: they trigger when you release your finger, not when your finger touches the screen. This makes sense because you may be tentative about submitting a form, and it'd be scary if it just submitted the moment your finger grazed the screen, right?
>These comments are disingenous[sic]. You didn't get confused by these things.
What right do you claim in calling the OP a liar? Do you not think that he is capable of observing his own emotional reaction to UI independent of his intellectual understanding of it? Are you really claiming that he disliked the iOS UI because his theory told him to?
That is utter hogwash. No sane person goes out of their way to assign an explanation of dislike when there wasn't dislike to begin with. It's entirely reasonable to dislike something, and it is also very reasonable to then check with theory as to why that might be the case. Moreover, if someone takes the trouble to a) make screenshots, b) write it up in a blog, and c) share it with the world then I think they deserver far better than to be called a liar.
> What right do you claim in calling the OP a liar?
I didn't, I said his comments were disingenuous (what was your "[sic]" for btw?). I meant exactly what I said. I wouldn't call it lying, I'd call it disingenuous (i.e. put-on naivety).
> Are you really claiming that he disliked the iOS UI because his theory told him to?
No. I'm saying his theories about what's confusing, while sometimes interesting, are not necessarily representative of what regular users will actually find confusing, and you'd need to do testing to find out. The problem is he presents them as if they're definitely true, with absolutely no evidence.
He put the [sic] there because you spelled "disingenuous" as "disingenous", lacking the penultimate "u." Clearly just a typo, as you have now spelled it correctly several times.
You are missing the point here. The app in question performs a very simple task. Of course most of the users will be able to figure out little issues without getting stuck. But, if we consider the default apps as examples of what we will get with the new UI design, the article points out to how things could get out of hand when the interaction gets more complicated or the user isn't sure of what the app does. This is something people complain about, because iOS is the exemplary product that comes without a manual, and everybody just figure out how to use it.
No you missed my point, completely. I didn't say anything about the changes in iOS7. I don't know whether they are good or bad for general users, and neither does the OP. Both of us can have our own feelings about it, and both can come up with theories that back our feelings up. But theories are a dangerous thing in UI design. They can be incredibly convincing and yet still be proven wrong in testing. As a UI designer you have to constantly doubt your own theories about what is good and bad, and trust scientific observations (of real-life usage and stats) over your instincts sometimes.
No matter how the OP came to his conclusions do we not agree that if you look at it, it could be better and not everything shares usability practices between apps. For a fresh look (2 month tested) release iOS 7 has too many bugs.
>It's driven by the fact that the author has some theories about UI design, and wants to share them with us.
This was exactly my reaction. The author points out things which are "confusing" within the context of some logical UI design theory. But nothing in the article is practically confusing. From the article:
The Plus could mean “Add Something”, but why does it have no outline? And why is it red? Does it perform a negative action? Confusing.
This feels like forced criticism. Immediately, they guess the correct function of the UI element (to add new alarms). Why should the plus sign have an outline? Why is it confusing that the plus sign is red, when the app has red as a primary component of the color scheme?
The author's points are interesting from a certain perspective, but it just doesn't matter in practice. I mean, is the biggest critique of iOS7 that a rectangle is clickable in one place and not in another?
If you want to see broken UI set a recurring alarm for workdays at 7:45 and 8:00 and then try to select each alarm in the week view. This must be the worst interface I have ever seen in an iOS app, the people that did it don't deserve to be called designers.
I wouldn't necessarily elevate an expectation of visual and behaviorial consistency to "theory". I have learned that a chair can hold my body weight. When I rest my body on an object that resembles a chair and that I've never encountered, I expect to be able to rest my body on it. This is the foundation of design, industrial or interactive.
We're not debating the outer contours and nuances of this idea. The article presents a cut-and-dry analysis of basic application of it.
You put far too much stock in your own experience and comfort exploring a tablet UI, and yet you seem to hold yourself as more representative as a "real user" than the author. I disagree. I've witnessed people in my personal and professional life get basic things wrong. What you perceive as a button, a data grid, a message window, they often perceive as an indiscriminate arrangement of text, lines, and color. Which is why I think the author's analysis, in those terms, is worthwhile.
> "You put far too much stock in your own experience and comfort exploring a tablet UI, and yet you seem to hold yourself as more representative as a "real user" than the author"
Nope. We're both totally unrepresentative, the moment we start analysing.
My complaint is: I don't believe that all the points the author made came from him genuinely finding things confusing and then working out which design inconsistencies caused his confusion. I think his ability to make those judgements are clouded by his endeavouring to analyse and critique a design (as would be mine). That's why we have user testing.
I didnt like the article either. I had different experiences than the ones he described and I also doubt he even had those experiences himself.
Also, while some of the experiences are not consistent within the time apps, they are artifacts that users already recognize- did he really get confused by the "cross?" Its a plus and its in the upper right hand corner of an app where you can add alarms...
This kinds of reminds me of an anthropologist trying to get a paper published in an journal for psychologists. Where is the rigorous application of science? Where are the statistics?
The general point of consistency is valid though. On the add alarm screen, I personally couldn't tell at first how you would add an alarm because the + was small and had no outline -- i.e. inconsistent with buttons elsewhere in the app.
Icons being thin-lined isn't bad per se, I'd rather say them being tiny and not obvious and inconsistent with buttons in other applications, especially for buttons that you'll use so often, is the problem. It's like the HN 'reply' link would be flat 5pt text right aligned at the same height as the comment header.
> When I tap it, it turns red — but wait — it doesn’t give me the visual feedback. Did I break it?
> The alarm is shown as a red filled square, so when I tap it, it should perform a negative action, right?
These comments are disingenous. You didn't get confused by these things.
You, as a person who's analysing a UI, have an almost totally different mindset to someone who is just using the thing for real. You know this, so here, you're just play-acting. You're thinking, what might I get confused about if I was a normal user? That's a bad way to look for what's really wrong in a UI design.
Yes, when you present points like these, they sound reasonable, but that doesn't mean they're right. Perhaps the alternative (e.g. banning the use of red anywhere in the OS other than for a negative action) might be over-restrictive as a requirement, which could cause excessive complexity elsewhere in the UI and lead to a worse overall result. Or perhaps you're right, the colour–meaning thing should be 100% consistent above all other considerations. Either way, you don't know, and speculation about what might confuse a real user should not be presented as fact.
Theories just guide us in what to test.