Live data from Hacker News

Open Letter to sites with annoying interfaces

bitonic.org

31–40 of 79 posts

Re: Open Letter to sites with annoying interfaces

#31
post #2

And good luck discovering these with a touch screen interface. People always forget that one.

Yes, absolutely so. Amazingly, iReader, from Apple, for the iPad, uses this antipattern in the critical main navigation bar! It disappears instantly and one has to click randomly at the top of the screen to get it to reappear, then try to press the tiny button that takes you back to the table of contents before the whole thing rolls up again after a delay of a second or two. Very frustrating. This sort of nonsense is…

That’s not how iBooks actually works. (That doesn’t get Apple off the hook, though. You encountered the problem so it’s a valid one. Confusion about how something works is definitely not the user’s problem, it’s the developer’s.)

The navigation bar only disappears automatically after you selected a book in your library. It is displayed for a few seconds to show that there are controls. After it disappeared you can make it appear by taping anywhere. It works analogous to the video player.

So it’s consistent with other navigation controls that don’t have to and probably shouldn’t be displayed all the time.

Once you tap the text to make the navigation bar show up it won’t disappear automatically – ever – at least as long as you are reading the same book and don’t go back to your library, no matter where you switch to.

One of the problems with the current behavior is that anywhere doesn’t really mean anywhere inside iBooks. The left and right margins are reserved for turning the page. That can frustrate users who want to make the controls appear. If they tap the wrong place they turn the page instead of making the controls appear. There is no obvious demarcation about safe places to tap. Making the controls disappear when playing a video works better because users really can tap anywhere. There are no unsafe spots.

Here is how I would change it: I would just not hide it by default. Users would still be able to hide it by taping on the text.

Re: Open Letter to sites with annoying interfaces

#32
post #24

Earlier quoted context omitted.

position: fixed; is long as you use percents. Thing is position: fixed doesn't even work on iOS: https://gist.github.com/1196262

position: fixed was added in iOS 5. However, it becomes unstuck when pinch/zooming.

This kind of problems amazes me. It's year 2011, almost 2012 - we should have had flying cars and forcefield doors by now. Yet we are still struggling with getting a web page to work identically in different web browsers.

Re: Open Letter to sites with annoying interfaces

#33

I've always thought that reveal-on-hover controls makes perfect sense when you present a list of similar things. In that case, showing one edit button, one delete button, and possibly a detail button is too much noise. My basic rule is, if there's more than one or two of the same control, then it should be hidden.

Yes, hidden, but with a visual clue (small arrow, button with an ellipsis) that clearly says: look, here are additional controls relevant to this part you're looking at.

Re: Open Letter to sites with annoying interfaces

#35
post #18

Thanks so much for this article. Hidden interface elements that only appear when hovering over a secret spot like it's some kind of easter egg is one of the most frustrating things I have seen. It's not really user interface design so much as it is user interface abject failure and total ignorance of how interfaces work . I refuse to call anything so dysfunctional design! This has been sneaking into desktop applicati…

My work involves designing interfaces and this discussion could help me understand this topic better; but like the author of the article, your post shows some intense frustration towards rollover-only elements, but none made it very evident to me as to why it's so frustrating and why it's so "stupid". We all experience things differently, and I'd love to picture a perspective where it's so frustrating. Here's how I s…

Why are hidden rollover affordances so stupid? Because the user doesn't know they are there.

Re: Open Letter to sites with annoying interfaces

#36
post #18

Earlier quoted context omitted.

My work involves designing interfaces and this discussion could help me understand this topic better; but like the author of the article, your post shows some intense frustration towards rollover-only elements, but none made it very evident to me as to why it's so frustrating and why it's so "stupid". We all experience things differently, and I'd love to picture a perspective where it's so frustrating. Here's how I s…

Your understanding of the term affordance, as inferred from your usage of it, is not the standard use. You use it as if it means the reason for something. Affordance is a clue something gives regarding its use. Doors with handles are pulled, with plates are pushed. Just seeing the interface component intrinsically describes its use. This is not possible for invisible components, therefore they have no affordance at a…

  the user is not going to intuit that the function
  must be invisible because he can't see it
User intuition changes over time as familiarity with new interfaces is gained. A system whereby edit/action buttons appear only when the mouse is on the right hand side of the screen seems reasonable -- if users have trained themselves to expect this behaviour and UIs consistently use this pattern in predictable ways.

If every user interface with mouse input used a "hover the cursor to the right of the screen for edit/action buttons" pattern, it'd become quite natural to users.

Gnome 3 is a good example of where hidden elements are used successfully. Hovering the mouse in the top left "Activities" corner of the screen will show hidden content. The bottom right corner of the screen also shows hidden content (this time, without any visual affordance). Users learn to expect the hidden items to appear when hovering the cursor. No affordance is required. The downside is that users may not be able to discover this behaviour without help from a tutorial or manual (at least until "hot corners" become a standard UI pattern).

Re: Open Letter to sites with annoying interfaces

#37
post #27
post #18

Earlier quoted context omitted.

My work involves designing interfaces and this discussion could help me understand this topic better; but like the author of the article, your post shows some intense frustration towards rollover-only elements, but none made it very evident to me as to why it's so frustrating and why it's so "stupid". We all experience things differently, and I'd love to picture a perspective where it's so frustrating. Here's how I s…

I don't know anything about design. The solution that I propose seems obvious though; am I missing something? > Too many elements are a distraction. > What is the affordance of invisibility? There is a middle though: instead of either making it invisible OR cluttered, couldn't you just design it with a small clue, such as an arrow, which would open a drop-down menu when rolled over (on a computer) or tapped on (on a…

I agree completely with you, and bestow upon you the title of designer. Good design includes sympathy for the user and common sense. Misconceptions about what is common sense are dispersed and corrected with user testing.

Some sort of clue would be really helpful. Advanced options can do in an options panel, but there needs to be someway to see the options panel exists.

Despite my horror and long post, I myself do use one form of invisible element in my own designs. Context menus. Right click and get tools that are relevant to what the mouse is currently above. This is a useful place to stick shortcuts for advanced users. It's not as great for things that are very rarely used. But here is the thing. Although there are definitely those who use them all the time, the hard core users, almost no normal users use them or are aware of them. In usability testing, if you ask someone to perform a task on an interface they have just seen for the first time, not even 1 in 100 will be able to do it if it depends on right clicking to find a menu item with the command. Users do not click on things they don't see. Since I use right click menus all the time it's easy to think others do as well. Well they will if they see it in a tutorial video, or someone demonstrating to them. I have had customers that have used my designs for many years and I meet them and go to demo something and when they see a right click use, invariably the response is something like "Oh, I didn't know you could do that!" Not right click, but do the hidden function. They know there is a right mouse button. They just don't use it to find contextual menus. Right click menus are there for the advanced users. So there's stuff that is faster to get to with the menu, but I try to always have another way to do the same thing. Rarely there are very advanced things. And yes I put them there to not clutter up the interface. Sometimes it is some rarely used function for which there is no obvious way to present it in a UI. It shouldn't be the only way to do anything done commonly, and probably shouldn't be the only way to do anything important. If it's something trivial and optional to use of the program, sure it can be an easter egg to be found by the hard core users.

Re: Open Letter to sites with annoying interfaces

#38
post #18

Earlier quoted context omitted.

My work involves designing interfaces and this discussion could help me understand this topic better; but like the author of the article, your post shows some intense frustration towards rollover-only elements, but none made it very evident to me as to why it's so frustrating and why it's so "stupid". We all experience things differently, and I'd love to picture a perspective where it's so frustrating. Here's how I s…

Your understanding of the term affordance, as inferred from your usage of it, is not the standard use. You use it as if it means the reason for something. Affordance is a clue something gives regarding its use. Doors with handles are pulled, with plates are pushed. Just seeing the interface component intrinsically describes its use. This is not possible for invisible components, therefore they have no affordance at a…

Affordance is a clue something gives regarding its use.

I misinterpreted your "What is the affordance of invisibility?" question as in "what are the benefits of invisibility?". Thanks for clarifying. I didn't know (and couldn't find) that specific definition of affordance. Is it a technical term?

Just seeing the interface component intrinsically describes its use. This is not possible for invisible components, therefore they have no affordance at all.

It's true. But this isn't very relevant to this article is it? we're talking about hidden items, not invisible items.

"Your brain is able to predict that if you don't see it, it might very well be rollover-only." This statement is so wrong I don't even know how to react to it or steer you away from this sort of thinking. I'm just completely taken aback. Not trying to be argumentative or anything, but no no no no no. No, the user is not going to intuit that the function must be invisible because he can't see it. Arg.

You can be argumentative by showing some reasoning to your opinion. That would help. What is wrong with my statement in your perspective? Either way maybe I can clarify further. I don't think intuition and experience (prediction) are separated. I strongly believe in Jeff Hawkin's theory [1]. All we do is this: we learn things, and later, based on what we learned, we make predictions, and act based on those predictions. And I think this is very relevant with interface design. If a certain pattern becomes frequent, people will become familiar with that pattern, and that pattern will become more usable. The drawback to that is that some patterns may be crappy, but it's still something I take into consideration in making interfaces, consciously or not. Of course you can try to ignore all that and think completely outside of the box - I've tried it a few times and while it's a lot of fun, a lot of people get disoriented for longer, even though the concepts are simple. Think about how fast the learning curve in a simple 2D platform game is. Their rules are quite alien to our real world (super high jumps without dying, hitting bricks throws a mushroom, etc etc) but what makes that learning curve really fast is that we've learned it again and again. It wasn't easy the first time, but 2D platform are a familiar pattern; my generation has learned it since early age, with Mario and Sonic. Intuitive is, in a way, anything that feels familiar. And a familiar pattern in github is hidden functionality that appears with a rollover. If I don't see something, I can guess that it may show up when I so a rollover.

Here is the proof. Usability testing.

How does usability testing prove that "the user is not going to intuit that the function must be invisible because he can't see it"? Can you elaborate? Have you done the testing or have you read about it being statistically proven otherwise?

[1] http://www.ted.com/talks/jeff_hawkins_on_how_brain_science_w... (to be clear I'm alluding to the part about prediction)

Re: Open Letter to sites with annoying interfaces

#39
This 'hiding' makes sense with lists of items, each of which has the same options. You wouldn't want to see 30 identical delete icons, it would be ugly. There are two important examples. Twitter hides the actions buttons and facebook doesn't.

Twitter uses icons and media-poor tweets. So having the actions invisible is the best way to go, otherwise the UI will be too cluttered with actions.

Facebook has wider spacing, more graphics in the post itself, and its actions are text-only. That's why they can be visible - they don't distract you from the content.

So I wouldn't say having invisible actions is bad. It's just not always good.

Re: Open Letter to sites with annoying interfaces

#40

That isn't the "delete contact" button. Did he even try it? The "delete contact" button is in the toolbar, which makes perfect sense. The trash can next to the name field simply clears the name field. So why not always show it? This is not just the "edit contact" screen, it's also the "view contact" screen, and cluttering it up with trash cans next to every field would absolutely detract from the scannability of the…

And right there you define where you should and shouldn't use roll-over based UI elements: if a UI element is only useful as part of interacting with another, then hiding it in other situations makes sense (e.g., clearing a text field as part of editing the text in the field).
Post reply on HN