4 ms·

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 i

by stephth 15y ago

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

dvdhsu 15y ago
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.
- droithomme 15y ago
  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.

by stephth 15y ago

dvdhsu 15y ago

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.

droithomme 15y ago
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.