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 <i>design</i> so much as it is user interface <i>abject failure and total ignorance of how interfaces work</i>. I refuse to call anything so dysfunctional design!<p>This has been sneaking into desktop application interfaces also for about 5 years now.<p>There's no problem with it in a video game where you are finding a secret passage, or it is an easter egg that is of absolutely no consequence whether anyone finds or not.<p>But for critical functionality it is inexcusably and is so offensive to concepts of usability that any "designer" using this technique in software for basic functions should be identified and blacklisted from industry.<p>What is the affordance of invisibility? There isn't one.
That <i>isn't</i> 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 page when you're not editing. Why not have separate pages for viewing and editing? That's bad for usability too; it invites mode errors.
I have always called these interfaces 'scrubbing interfaces' and I believe it's a well known anti-pattern. It used to be popular with flash programming and design-heavy sites that didn't want all of those 'ugly controls'.<p>Here is my rule of thumb: avoid attaching functionality to the hover event. Visual effects/indications are fine.
Putting hover-revealed controls on elements users interact with often is perfectly acceptable. Throwing every single control on the interface, regardless of how often they are used, is bad design and it overwhelms non-techie users.
I'd like to add 2 other sites to this list with <i>horrible</i> mobile interfaces that frequently show up on HN.<p>extremetech.com and geek.com<p>Extreme Tech's mobile site is totally unusable. They have a very crummy interface, instituted with javascript, that overrides the simple scrolling ability built into the browser and overlay it with a system that tries pseudo-pagination. If they would simply get rid of their attempt at a clever interface and just display their actual site, there wouldn't be a problem. If any Extreme Tech developers are reading this, please fix your mobile site.<p>The 2nd culprit, geek.com, crashes Mobile Safari. I'm on an iPhone 4. Because of whatever you are loading on your mobile site, it freezes the browser for upwards of a minute. Half the time the browser crashes before its done loading. Please, fix that too.<p>I actively avoid reading any of those sites, since I read HN from my phone about as often from a regular browser.<p>Another more generic complaint are to the people who use position:fixed on their sites to create headers and side navigation. Guess what, on mobile devices <i>these don't scale</i>. What ends up happening is that I need to zoom in to read your text, but then 3/4 of the screen is covered with your nav menu. Please, stop doing that.<p>Test your sites on mobile browsers. Its easy. Take the one in your pocket out and try your site. I'm not even advocating extensive dedicated testing. Just try it out like a normal user does and make sure it works most of the time. These are things that are so horrendously, obviously bad that I don't know how they <i>ever</i> got through any reasonable kind of QA.<p><i></i>Edited for excessive usage of caps. Sorry.
I agree!<p>Here is another semi-close example. Not about hovering, but how about needless hiding of important user experience?<p><a href="https://github.com/mozilla/browserid/issues/797" rel="nofollow">https://github.com/mozilla/browserid/issues/797</a><p>I filed this super minor issue in the browserid issue tracker and it was closed with 'as designed'. No feedback as to why it was designed this way, but it sure seems silly to me to hide the 'remove' button under an 'edit' button.<p>I can understand this on a UI like an iPhone, but on a web page?<p>Oh well.
I agree. Google seems to have replaced the concept of "Simplicity is best" with a misconceived notion about elegance. I don't want to search for hidden buttons just to log off, or delete, or open, or save changes. I just want to get things done and move on.
It made me both LOL and think. We are doing a snazzy crazy UI in the admin panel. But the thing is, we don't want people to use it. That sounds strange, but we optimized our convention, and we do allow people to configure stuff by themselves, but we don't want to motivate them to do so. An input field is crying for you to put something there. A little edit button in the corner not so much. And the added bonus is that we can hide all those ugly forms until they are really needed.<p>Also, think about an experience that was the exact opposite of this post. You thought about something ('where is the delete button?') and you 'gambled' where that button will show up, or what touch move you should use - think how awesome the filling was when you were correct.
Strongly disagree with the article.
you have to ask yourself: How often are you searching for a contact and want to edit it and not only view it?
On average, most people won't edit it, so it's useless to have an edit button 90% of the time.<p>I think it's a pretty neat solution. The poster only has to get accustomed to 21st century technology, it's not 1990 anymore with textfields and buttons all over the place.
It's like the typical rant of an old grandfather, complaining that something has changed and that everything was better decades ago. Bullshit. Just be a bit more flexible.<p>The placement of the hidden edit button can be discussed though. I am wondering why the github button is so far away from the content to edit...<p>Another example: The G+ profile editing is one of the best i have ever seen. It's "this is how your profile looks like to another person, hover the field and edit it". It's just easy and it's change something where it is shown, not going to another page and edit some values and go back and forth to see the changes.
The GitHub example used to be better designed in that the "edit" link would appear right next to the text. So, you'd the see the repository title, move your mouse over it, and hey! see how to change it.<p>With the button all the way to the right, that connection is somewhat lost.
Tab. The tab key should first take me to the most important clickable (or text-entry) part of your page. If you don't do this... It's not the "I'm not angry, I'm just disappointed" routine. It's both. I'm both angry AND disappointed.
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.<p>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.<p>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.<p>So I wouldn't say having invisible actions is bad. It's just not always good.
Please. The first example is for editing the repository description, and becomes visibile when hovering over the description. The second is for clearing the name field, and becomes visible as soon as you are actually editing this field. I agree that hidden interface elements should be used carefully, but if these really are the best examples you've encountered, then it's not really a big problem. I wouldn't even consider the second "example" a hidden interface element.
On the one hand, it's better to reduce clutter for the less common case of editing rather than reading. On the other hand, it's better to indicate availability of functionality without requiring hovering.<p>What do you think of a modal solution whereby individual editing interface elements are shown collectively only when the user indicates editing intent through a single, master control?
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.<p>My basic rule is, if there's more than one or two of the same control, then it should be hidden.
I didn't read this carefully, but it seems that "hidden" interfaces that pop up during a mouse hover and so on are a main objection.<p>Well, I must say, that often when using a web app, I expect to have to wait 5 seconds for a reload as I am moving my mouse in for a click (for example, imagine if there is a text link "Rate this page" under the current average rating) -- when, instead, as I hover over it it turns to 5 empty stars immediately, so that I have just saved 5 seconds for a page reload, I am immensely delighted.<p>Basically, I do agree that hidden interface elements are awful. At the same time, every "second page" that you would normally have to wait for is far better as a 'hidden interface' that pops up right away!<p>I dare say that when you wireframe out the possible pages of your web app, the <i>very best interface</i> might be having most of those pages right in the main page, just hidden. Report feedback, report a bug, reset your password, all these things that would require a page reload and losing your scrolling in the page and so on, can be brought 5000 ms closer to the user but putting them in right at the point of the click.<p>So, I do agree that there is nothing as frustrating as a hidden user interface element. However, you can also pleasantly delight your user by bring the 'next page' right there.
"Open letter to sites with annoying interfaces"?!<p>Maybe I'll write an open letter to traffic. Or an open letter to waiting in line at the post office. Or an open letter to humidity.