This has been sneaking into desktop application interfaces also for about 5 years now.
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.
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.
What is the affordance of invisibility? There isn't one.
Here's how I see it (and as you'll see, I'll be taking various assumptions. Please feel free to tell me I'm wrong (but make a case)):
We like to have everything at hand, but we also like (it's more like a need actually) to focus. Too many elements are a distraction. That's basically why we put things in boxes even if we don't intend to transport them anywhere: out of our sight. Our brains want/need to focus. That would be my answer to your question "What is the affordance of invisibility?".
The example of Google - if that really is a delete contact button, I don't use that app - I would agree is bad design, because its effort to find it outweights the benefits of having it hidden (partly because its placement is not apparently logical and that makes it extra hard to find).
In the first example in the article (github) however, I would tend to think that that specific solution is OK. The author of the article forgot to explain what that button does. A quick look at github, a rollover and a click (three actions) shows me that its function is it edits the description of the repository. How often do you edit the description of a repository? Not that often. Probably very rarely. And the more you use github, the smaller its usage gets proportionally to the rest of the app. The day you need it, you'll find it relatively quickly. Because you've experienced this practice for a while in other sites, and even more so because you've seen github act like that every now and then. Your brain is able to predict that if you don't see it, it might very well be rollover-only. The first logical place you try is the within the repository dashboard, over the description of the repository. Not too hard. I think in this case the benefits of every time I read that page not having that element there and not having to neutralize it myself with my brain by ignoring it vastly outshine the effort of looking for it when I rarely need it. It's a good deal. [1]
I would love to understand a little more about why this concept didn't work out for you.
edit: typos, formatting and deleted some unneeded parts
--
[1] The github element in the case of a touch interface is not great, I would agree, because it's harder to predict that by touching the white area of the description the button will show up. But it works (as in: you can still access it). And you have to cut interface designers some slack (or instead give us the strength we need): we're still trying to figure out what to do exactly with the current mess of having two very different types of clients (mouse and touch) accessing our web interfaces. After we figure out if we should unify, we need to figure out how. Killing rollover interactions might be a necessary casualty in that road (but that would make part of me sad, there are wonderful usages of rollover, see for example the custom sliders in here: http://worrydream.com/LadderOfAbstraction/), either way I'd love to understand a little more, and I assumed that in this discussion we're focusing on rollover, not touch.
"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.
Here is the proof. Usability testing.
> 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 touch device)?
A drop-down menu with a small icon to prompt the user would hit the middle between simplicity and obnoxious prompting.
Can you imagine how frustrating that is?
Now imagine I'm someone who is used to using the keyboard; or I have a motor-function illness which means I find using mice hard or etc etc.
For sure I understand all the points about why some people love this functionality. But please give me an option to turn it off and have all controls exposed on the page.
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.
It is ok if clicking on an element enables additional contextual actions… the problem is that we don't look at a page with our mouse pointer. The pointer is a proxy for our hand not our eyes.
extremetech.com and geek.com
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.
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.
I actively avoid reading any of those sites, since I read HN from my phone about as often from a regular browser.
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 these don't scale. 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.
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 ever got through any reasonable kind of QA.
Edited for excessive usage of caps. Sorry.
Onswipe sucks.
You can read people lamenting onswipe here http://news.ycombinator.com/item?id=2699610.
Onswipe benefits no one. It makes the content unreadable, and doesn't add any value for anyone except themselves.
I don't read sites that use onswipe, in part because I want to boycott them, but mainly because I simply cannot get the UI to work. I suggest you avoid them too.
It makes sense to show only some controls when your mouse or cursor is focussed in the right place, because then you know those controls are relevant to what you're doing.
What I think was overlooked with the two examples - Github and google - is the replacement of text-based controls with icon-based ones. Github's top nav is now just tiny icons, the Google pages are all icons. You can barely tell what these are unless you hover over them long enough to see an explanation. This is the real problem, I think.
Here is another semi-close example. Not about hovering, but how about needless hiding of important user experience?
https://github.com/mozilla/browserid/issues/797
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.
I can understand this on a UI like an iPhone, but on a web page?
Oh well.
Here is another issue I just filed last night:
https://github.com/mozilla/browserid/issues/809
tl;dr: Super minor, but the case of buttons is actually important UX too.
I'm worried about BrowserID UX because we are implementing it on our site as an additional login system along with Facebook Connect. I'd love to see BrowserID become successful since we need an alternative to Facebook and OpenID is a train wreck. But, I worry that with bad UX, it will remain just an unused interesting idea.
Here is my rule of thumb: avoid attaching functionality to the hover event. Visual effects/indications are fine.
http://www.webpagesthatsuck.com/mysterymeatnavigation.html http://en.wikipedia.org/wiki/Mystery_meat_navigation
Mystery meat was weird looking inexplicable icons that you had to click to find what they do or hover to get a description. Sometimes, including in both those references, they extend it to be cases where the inexplicable icon doesn't even exist and a description is invisible until hover. The hover patter, what you call scrubbing, seems to me to be related to but different from mystery meat, which is characterized by seeing a navigation element and saying "What on earth is that supposed to be?"
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?
My basic rule is, if there's more than one or two of the same control, then it should be hidden.
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.
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.
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...
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.
With the button all the way to the right, that connection is somewhat lost.
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.
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.
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!
I dare say that when you wireframe out the possible pages of your web app, the very best interface 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.
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.
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.
