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