Open Letter to sites with annoying interfaces(bitonic.org)
bitonic.org
Open Letter to sites with annoying interfaces
http://bitonic.org/blog/?p=176
25 comments
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/), either way I'd love to understand a little more, and I assumed that in this discussion we're focusing on rollover, not touch.
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.
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?
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.
> 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.
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.
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.
> 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
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.
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.
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.
Hide all but the most common actions on a page, but make it clear and consistent where the other actions will be found.
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.
"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
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.
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)
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.
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.
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.
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.
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?
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>.
Why are hidden rollover affordances so stupid? Because the user doesn't know they are there.
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.
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.
That isn't 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.
And right there you define where you should and shouldn't use roll-over based UI elements: if a UI element is only useful as part of interacting with another, then hiding it in other situations makes sense (e.g., clearing a text field as part of editing the text in the field).
Context sensitivity is a great justification for hidden elements. Litter your page with visible edit buttons and, in a poorly designed UI, you might forget what part of the page each edit button binds to.
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.
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.
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'.
Here is my rule of thumb: avoid attaching functionality to the hover event. Visual effects/indications are fine.
Here is my rule of thumb: avoid attaching functionality to the hover event. Visual effects/indications are fine.
I agree. I hadn't heard that term. There's a related anti-pattern called Mystery Meat Navigation.
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?"
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?"
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 horrible mobile interfaces that frequently show up on HN.
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.
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.
extremetech.com uses onswipe.
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.
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.
position: fixed; is long as you use percents. Thing is position: fixed doesn't even work on iOS: https://gist.github.com/1196262
position: fixed was added in iOS 5. However, it becomes unstuck when pinch/zooming.
This kind of problems amazes me. It's year 2011, almost 2012 - we should have had flying cars and forcefield doors by now. Yet we are still struggling with getting a web page to work identically in different web browsers.
I am willing to bet that when we have flying cars and forcefield doors, there will still be problems of this kind in "information management", or whatever name you want to give to the problem that the web tries to solve.
[deleted]
I agree!
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 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.
Wow, that's just silly. I agree - "Delete" is simply not a subset of "Edit"ing an option in a configuration. It may be a subset of editing the entire configuration, but having a two-step process that makes a non-connected action into a child action is mind boggling. People need to learn their CRUD/BREAD better.
Interesting that you write 'Edit' vs. 'edit'...
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 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.
Yeah, but I'm probably just used to it and since I was referring to BREAD, it kind of made sense. I guess it's one of those age old questions like "do we say 'your' or 'my'?".
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.
And good luck discovering these with a touch screen interface. People always forget that one.
HN isn't that great on a touch screen either. I guess pg doesn't use a tablet because the comments link is too small and awkwardly placed for a finger.
I've become very adept at zoom&tap. In fact I probably do it about as fast postioning the pointer with my laptop's trackpad. I agree it'd be nice not to have to zoom before tapping.
Yes, absolutely so. Amazingly, iReader, from Apple, for the iPad, uses this antipattern in the critical main navigation bar! It disappears instantly and one has to click randomly at the top of the screen to get it to reappear, then try to press the tiny button that takes you back to the table of contents before the whole thing rolls up again after a delay of a second or two. Very frustrating. This sort of nonsense is bad enough when one has to hover with a mouse. But when there is no hovering available on a device and one finds key interface elements are invisible and must be unhidden by clicking randomly, one must wonder what sort of monkeys they got working there, or at least what their background in UI design is.
That’s not how iBooks actually works. (That doesn’t get Apple off the hook, though. You encountered the problem so it’s a valid one. Confusion about how something works is definitely not the user’s problem, it’s the developer’s.)
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.
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.
Ahhhhhhh. Thanks. OK, so actually I now see that single (one-finger) clicking makes it go away AND makes it come back. It wasn't actually fading on its own because of a fade out hideaway timer, it's just that I was touching the pages.
And I wasn't having success bringing it back consistently because it doesn't listen to clicks along the very top of the page.
And I wasn't having success bringing it back consistently because it doesn't listen to clicks along the very top of the page.
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.
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.
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.
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.
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.
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.
With the button all the way to the right, that connection is somewhat lost.
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.
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.
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.
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.
Mystery meat nav (and bad design) is what I call it.
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.
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?
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?
Personally, I like those. I assume you are talking of the interface on some sites with let's say a user profile and there is a visible [EDIT] button in the upper right. Click on it, and all the nice formatted readable content is replaced with editable text elements that can be tabbed through, and these might have formatting bars in them or section delete buttons. Different from the discussed scenarios where basic functions are hidden and one must move the mouse around to different places to see if they may or may not exist, which is bad and smacks of video game treasure finding design, which is fine for video games and absolutely not fine for other applications. With the proposed [EDIT] design it is quite clear what is going on by examining the page visually. A related issue would be that the same profile viewed by other than the owner of the profile would show no [EDIT] button at all, nor would such button appear to them under any circumstances. No features hidden because for non-owners, there is nothing to edit.
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.
My basic rule is, if there's more than one or two of the same control, then it should be hidden.
My basic rule is, if there's more than one or two of the same control, then it should be hidden.
Yes, hidden, but with a visual clue (small arrow, button with an ellipsis) that clearly says: look, here are additional controls relevant to this part you're looking at.
[deleted]
The iOS interface is full of this behavior. I thought that was part the reason why it was so clutter free and easy to use due to less clutter.
I find the behavior can cut down on clutter when pulled off correctly, though. Twitter offering context-based actions, for instance.
You're right if by correctly you mean not like this. The 'correct' way to do it would be to indicate that the field is editable. Once the user has clicked you can enable/reveal the save button if you really want it hidden. Twitter's tweet box is obviously an editable form element that can be clicked on.
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.
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.
It helps when the activation hover area is large: anywhere over a tweet, all new per-tweet options appear.
I'm not sure I agree. It completely breaks on tablets for one thing.
Does not have to though, Tweetbot's UI behaves nicely in this regard. It does not have hover, but its equivalent is to tap a tweet. This opens a small "drawer" of 5 tweet-specific buttons (reply, retweet, favorite, detail and "actions", which include posting a link to the tweet, copying the tweet's content, emailing the tweet's content and translating the tweet's content).
Users, always them… My reaction? Meh!
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.
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.
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.
"Open letter to sites with annoying interfaces"?!
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.
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.
This is so true. I look forward to Web3.0 through...
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.