Hacker News Reader

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 all. Saying they have a reason in the designer's mind, to declutter an interface and make it all pretty and clean, is not related to saying they have an affordance, which is that they show the user how to use them. Buttons look pushable. Scroll bars look draggable. Invisible elements don't look anything.

"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.

  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).

Those are specific positions on a screen in a desktop OS UI. That's HUGELY different from yet-another-webapp, because you only need to learn it ONCE, and then it remains the same always, no matter what app you're using or what page you're viewing.

With web pages and apps, it's up to each designer to decide where and how things are laid out, and everyone has their own opinion, so if 20 designers decide to hide their components, how is the user to find them? The last thing I want to do is play hide-and-seek moving the mouse around a webpage/app randomly in the forlorn hope that maybe one of the gadgets or magic locations will pop up a control that I can use.

Put in a gear icon that I can mouse over. Put SOMETHING there that says "hey! I can be interacted with!" Otherwise I'll just ascribe the interface as designed by someone incompetent and look for an alternative.

What you describe works fine in theory; the problem is that in practice it's ridiculously easy to overestimate how likely the average user is to train themselves to expect this behavior. In general, we (power users, developers, etc.) tend to adapt to consistent UI behaviours very quickly and to overestimate how difficult it is for an average user, but when it comes to things that are _invisible_ until you do something, the gap is much greater yet.

The use of "GNOME 3" and "a good example" in the same phrase has been banned by the International Association of Common Sense.

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)

Affordance is a used extensively in the usability field and is a fundamental part of the vocabulary. Don Norman, Jakob Nielsen and Alan Cooper all use it quite a bit in their writings, so anyone who has background studying the literature of the field will be familiar with it. Not knowing it is something of a shibboleth that suggests one isn't familiar with the basics of the profession. It would be difficult to be in the usability field for long without having read works by one or more of the three practitioners mentioned, or having met them at conferences, or run into discussions with others about their work. The term is also used by many other designers as well, I just mention those three since they are pretty big names and I happen to see books by Norman and Cooper on the shelf directly above my monitor.

Yes, usability testing confirms this, which is why you do it. Put key functions in hidden controls and then ask people to perform tasks that require discovering the controls. Most won't find them. In another comment here I mention my experiences with usability testing and finding that the much more well known paradigm of context menus is used or thought of by extremely few users. Advanced users will use it a lot, especially after the first time they look for context menus and find they are there and robustly designed in a given app, but non-advanced users, which is the vast majority, will never look there. In working with customers, some find the existence of features in context menus only after many years of work with a given program. One absolutely can not depend on users to assume that needed functions can be found in invisible items.

Not knowing it is something of a shibboleth that suggests one isn't familiar with the basics of the profession.

I appreciate that it isn't too much of a shibboleth for you and that you could stick around, I'd be interested in knowing a little more about the literature you mentioned. Do they propose specific techniques to usability testing? Which one do you use? In my case it's watching friends/family/expo attendants interact with the app but I don't have much of a formulated technique, it's casual, but I'd be interested in knowing more (and in the process I may be convinced that I should actually read that literature).

One absolutely can not depend on users to assume that needed functions can be found in invisible items.

I don't think it's that simple. It depends on the context and on the target. On a professional tool targeted to software developers like github, and being a consistent pattern, then yes, I think you can depend on that. If on the other hand you use that pattern in a context where it's not frequently seen, and/or it's not a consistent pattern in your app, you probably shouldn't depend on it, no.

See http://en.wikipedia.org/wiki/Usability_testing for a description.

A quick overview - in usability testing, testers are chosen, given an introduction to the software, and observed while they try to get stuff done with your product. This ideally involves two people aside from the tester - the "greeter", who interacts with the user/tester and guides them through the process, and an observer who focuses completely on watching the user at work.

Usually, two types of measures should be taken: numerical (number of errors, amount of time taken to find functionality, etc.), and qualitative (the user's attitude, comments - all the things you didn't think to measure in advance).

Quantitative measures are very important because then comparisons can be made - do users find functionality more easily/complete tasks faster with the "Edit" button hidden? By how much? How much longer do they take (if at all) to find that functionality when the button is hidden?

In sum, a usability study should be systematic - more like a psychology experiment or ethnography study than a product demo.

Usability testing should involve more than just "time taken for a new user to become familiar with the interface". Experienced users also need to be observed to ensure that prolonged use also shows desirable usability results.

Pop-ups providing first use advice to users may improve usability results for new users. For experienced users, pop-ups are likely to decrease usability.

Placing many buttons on a screen will likely make it harder for new users to start using the interface. They will have to investigate many more options amongst the clutter, leading to more decision making ("what is this button? do I click it?") and a corresponding decrease in usability.

In the case of GitHub, the question of whether new and/or experienced users regularly need to use the "Edit" button needs to be investigated. The cost of making an interface control highly visible to new users may exceed the cost of experienced users needing to search for help on how to perform the rare action.

No dispute with you there - I mentioned some possible metrics, but those you mentioned are also clearly important.

I was commenting on the question about usability testing (which yes, should include testing of experienced users); I don't have the information to make a judgment on the Edit button; I presume Google and Github both saw something in their testing that led them to make their design decisions. However, I am interested to know, in Google's case, what improvement, and what problems, they saw from this particular change. Anyone work on the new Google Contacts?

But it's not consistent on github. I wanted to change a project description and expected to find it in admin - that's where everything else is for changing a project. I actually gave up until I read this post.

All this and more is available at your local library.

'Affordance' is a term due to Gibson. I cannot describe it better than <http://en.wikipedia.org/wiki/Affordance>.

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 touch device)?

A drop-down menu with a small icon to prompt the user would hit the middle between simplicity and obnoxious prompting.

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.

That's just hiding functionality again. MS started doing this by hiding vital functionality in a stupid looking windows logo jewel in the upper left hand corner. I had to ask other experienced people where the file menu was- it was not obvious that thing was anything more than decoration.

The solution to clutter isn't to hide functionality. It's to have your software do /less things/. If you need it to do more things, make those few things your software does a flexible set of tools that can be combined in novel ways.

Update: (I got downvoted so I thought I'd modify the post a bit, hopefully it's better?)

in any case, when it comes to software design, clutter isn't the worst thing software can do. Hiding things is, however, pretty close to the worst thing you can do. At least, without a consistent and obvious method of discovering the hidden things.

I liked the first post! The bit you removed: "Now you have two problems" I had just pasted it into my quote file, so it's not gone. I'm going to bring it back because it is a stylish way to say a lot. Ok I'll fiddle with it a bit too, play at being an editor.

> When it comes to software design, clutter isn't the worst thing software can do. Hiding things is. So, to paraphrase JWZ: "You have a problem with clutter, so you hide it. Now you have two problems." Thus, the solution to clutter isn't to hide the functionality because that creates more problems not less. The solution to clutter is to have fewer functions.

That's really good. Some reading this might be confused by fewer functions as meaning dumbing down and restricting the user, so let me expand that. That's not what it is. Fewer functions means making things simpler to the point that they are generic enough to have much more functionality, but with fewer explicit functions. For example, the unix command line is pretty simple to look it, but unlimited in what you can do. Type whatever you like there. The pipe thing lets you stitch things together in combination.

"Now you have two problems" is a common meme used to talk about a lot of computer programming decisions. It appears to be originally meant as a comment on regular expressions.

http://regex.info/blog/2006-09-15/247

thank you for clarifying and expanding my post. And for complimenting my (now missing) paraphrase. :)

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)?

I really, really like this idea as a solution to fix possible hidden rollovers usability issues. Like the best ideas it sounds obvious once you hear it. If it is well executed (I would imagine something clean and simple yet recognizable like a point within a circle) and when/where it does work, then - like you said - it's a solution that works for both touch and rollover, and that's exciting too.

Also, sometimes you really need some text beside your indicator arrow. On the native email app on the iPad, my Dad repeatedly cannot figure out how to reply to an email (despite it being the principle thing he wants to do), because the icon (a curved arrow) lies among 3 other icons of equal obscurity (to him).

Another compromise solution is to put text on the page, but to grey it out, or otherwise make it less visually distinctive according to it's lack of importance.

Yes, there is definitely the middle ground.

Hide all but the most common actions on a page, but make it clear and consistent where the other actions will be found.

I look at a facebook page of stuff. EG my wall. I want to remove a post. How do I do this? I dunno, there's a menu for that post underneath it, so I look there. It's not there. I hover around there. It's still not there. I maximise the browser window, just in case some element got hidden in a resize. Maximising is slightly tricky on OSX, I don't just clicky the green button. With the window maximised I still can't find it. I have a look around the post for extra items. I can't see anything. I start moving my pointer, and I see a flash of pale blue on a white background. Maybe that's it? Nope, that's some other function, but now I know there might be a hidden button. (Note that I don't know there is a hidden button, just that there might be one somewhere.) Eventually, I find this hidden button, and clicky, and the post is removed.

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.

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

Late answer here, but that's not the delete contact button. That's in a row of buttons above the contact (in a more... dropdown, to be precise). This button just blanks the name, and is kind of a shortcut alternative to ctrl-a delete.

Are you in the GNOME 3 "design" team by any chance?