The other thing is that full-color, textured icons help a great deal with immediate recognition as well. It's easy when the "open" icon is a yellow folder.
Sadly, the move to flat design with monochrome icon outlines destroyed that entirely. I'm still waiting for full-color icons to come back in style again. They can still be flat, but being filled with color (not just colored outlines) helps immensely with fast recognition.
Why does the folder color matter? Is it just because that is what you are used to from a specific OS?
Color helps for some people but when making an accessible design you have to account for color blindness and other vision issues. Which means the icon needs enough contrast and can’t rely on just color to convey meaning, unless the icon is paired with a text label that also conveys the meaning the color was trying to convey.
So while I agree that color iconography can be extremely helpful for the average user, unless it is supplemented by other techniques it can make a product completely unusable for a subset of users
In the example, the folder is recognizable as such from just its shape. The color merely makes it more recognizable (because folders are yellow on Windows — it reinforces that the icon depicts a file folder).
For accessibility reasons, you shouldn’t rely on only the color, but that doesn’t mean that color isn’t a very useful property to apply.
What the GP is asking for does not affect the color blind. They are not suggesting there should be multiple folder icons of different colors. They just want color included in the existing icons. My understanding of color blindness means that that would be better for people with color blindness as well.
This is an example for something I have always troubling arguing with in technical discussions: Sometimes a solution only works if you apply it partially, "in good measure".
I can imagine the discussions on the issue above with the outcome being either no icons, or icons on every item, but nothing in between.
How go about convincing a group of people about this?
I prefer every item having both text and an icon. If I don't know what the icon mean, there's text there to explain it. If I do know what the icon means, i can scan just the icons and find what I need faster. In my opinion it's the best of both worlds. That being said, your first example might be even better, because a lot of those things like "close" or "versions" I'm not going to be clicking often, so if they had an icon I'd have to read the text to figure them out every time anyway
In your first example, my intuition tells me if some elements are more important than others in away that's worth distinguishing with icons, it's better to think on providing easier access to them (priority at the top?) or hiding the rest.
There's 17 options there, where only 5 are deemed important.
The second example is bad for different reasons. There's no apparent rime or reason to the options other than "places you might want to check", no grouping and no priorisation. It would be a hard to parse with or without icons.
The brilliant thing about the first example is that differentiating "important" items with the icon actually allows multiple forms of categorizing items in the list, whereas your suggestions only allow one. The items in the list are grouped by topic, and important/common ones are highlighted with an icon. Hiding the less important options makes them needlessly harder to find if/when you do need them. Moving important items to the top breaks the topical grouping. In both cases, the application becomes less discoverable.
In the first example the items are grouped by topic (such as “printing”), which I think makes sense. When you go select a “frequent” action, it’s useful to see which “less frequent” but related actions exist nearby. And the icons not being all grouped together but being (partially) isolated actually helps in better recognizing them.
It’s from Microsoft Word ('97, I believe), by the way. A later version had “expandable” menus that by default only showed the most frequently used options, and on expansion (or by global setting) then also showed the other options. Many users didn’t like that, however, either because they missed that the menu could be expanded and thus didn’t find the item they were looking for, or because the expansion changed the relative locations of the items, meaning they were at an unexpected position depending on the expansion mode; or just because the expansion required an extra click.
I’m just noting this because Microsoft deemed the topical grouping of items within the menu important enough that they kept it, orthogonal to the expansion mechanism. And they doubled down on the grouping with the later ribbon interface — which I personally dislike because it’s not linearly greppable and feels jumbled, and they felt the need to give every item an icon there, whether memorable or not.
Hiding parts of the menu hinders discoverability when those options are needed, creates a need for one extra action to show all the available options, and messes with the users' spatial and muscle memory. This particular mistake was already made a quarter of a century ago, in Office 2000.
There was no way to get the default "short" menu right. Although conventional wisdom holds that "everyone only uses the same few features in Office," the reality is that people use an amazingly wide range of functionality. So, one person's ideal default "short" menu was exactly the wrong thing for someone else.
I don't think its too bad (assuming you mean this one, I can't find a higher-level one) https://i.imgur.com/V06bwjJ.png There are a few similar arrow-and-dot ones, but at least they're directly connected to the related git action. The gitlab one... milestones are a clock, but activities are a clock running backwards? Projects and issues are just sets of rectangles in a different rotation. I feel like part of the problem is these concepts are not themselves super coherent already, but they didn't do a great job either. (how about an actual mile marker for mile-stones?)
Most of the world switched to phonetic scripts a long time ago. That's be because they're strictly superior to pictograms. Icons are optional. Text is required. Sorry if you have to translate it.
You don't need a label to say "Close" next to the "X" on your window. Or "Play" next to a right-facing triangle in your media player. Or the word "Search" next to a text box with a magnifying glass in it. We have certain "pictograms" that are just as widely understood as letters themselves.
There is a spectrum from widely-understood symbols that don't need labels, to totally ambiguous/confusing/custom symbols that are helped greatly by labels.
That said, I agree with the article that right now, a lot of apps could benefit from more labels rather than less.
Try to keep going though. Close. Play. Search. Pause. Stop. Fast forward. I'm guessing you can name a few more, and you might get a group of people to agree about 15 are super obvious and generally accepted. It's a tiny number.
I agree. Maybe I'd add the three horizontal line 'hamburger' for menu, folder, plus sign for 'create new" and directional arrows for back/forward. Maybe around a dozen all in but that's about it. Anything else should have words.
Instead, I find myself trying to puzzle out what the hell some cryptic pictogram means, very frustrating. I also have really come to despise this trend of not visually signifying that an icon is a pressable button.
How and why would I become an advanced user of a program I can't figure out how to use because none of the buttons have labels?
Pixelmator Pro shows you the names of the tool buttons, once, when you first launch the app. They disappear the moment you click a button. Nice. a whole 10 seconds to memorize all two dozen of them.
And they chose not to use the system tooltip on hover, so I have to wait for some humungous pictorial tooltip to load in when all I want to know is the goddamn hotkey.
How does that matter for the point? You can make it a setting for the user or just always show both. I never said that programs should exclusively use icons.
The initial claim was that text is strictly superior to icons, which means that icons have not a single thing they’re better at then text. That’s just plainly false.
That’s rarely the case, in my experience, especially when there are a dozen monochrome icons in a row. They just aren’t distinct or memorable enough. You learn their position after a while, but confirming the correct item by their pictogram remains slower than just reading a word or two, because the words are universal, whereas the pictograms are typically specific to the application.
I think the commenter you're replying to might have been referring to pictograms like many Chinese characters, not icons that you have to figure out. Or maybe not
A handful of Chinese characters are pictograms. As far as I recall, it is by far the smallest class of characters, and all of them, including the ones that started as pictograms, are treated by modern readers as phonetic indicators.
Every time I'm busy with a topic, the next day it somehow ends up showing up on HN!
I was creating a small drawing app for my 27-month-old son (mostly for me to draw tractors and excavators for him). At first, I only used icons, but they confused him. So, I added text labels, and surprisingly, even though he can't read, the labels helped reduce visual clutter. Suddenly, he could "learn" what each tool does and remember.
that's wild. I find that my.... 27-month old daughter (heh, what a coincidence) also recognises the titles of bluey episodes pretty easy..
we can be scrolling a list of bluey episodes, and she knows what they are by the words.. "what episode do you want to watch?" "curry quest!" - sure enough, that's what it's called and that's what the title is
all of the pictures are some form of the characters doing something, so i find them fairly indistinguishable... I haven't tried letting her pick one without the picture, which will be the real test i guess.
Cool, also yeah, what a coincidence! We had the same thing with books. My wife and I really suspected that he was somewhat reading until we figured out that he memorized the shapes of the sentences, so individual words or the same sentence in a different font wouldn't be recognized. It's fascinating to witness how a human brain evolves.
Also, about Bluey... The little guy has limited screen time so he can only see an episode or two per day, but I really want to keep watching even when he can't lol. I literally fell off the sofa laughing in the episode where they are trying to lick each others ice cream while the waltz music from the Nutcracker plays :)
On Windows 11, open the Microsoft Store app and select the Entertainment section, (confusingly) marked by a clapperboard icon. You'll notice an unfortunate design choice where the text labels disappear upon clicking, making navigation (or remembering where you are) less intuitive. I've raised this as a usability issue multiple times with the development team and they don't seem to agree or care. It drives me up the wall.
As an example, I look at the Markup Toolbar in MacOS, and I have no idea what those icons mean until I've tried using the tools. They're so similar, vague and monochrome.
I don’t mind an icon but I am frustrated if hovering the mouse doesn’t show a tooltip or alt-text style label
It makes learning new software much slower and basically requires going to the docs or a video tutorial if the ui design isn’t exactly spot-on and perfectly intuitive which it almost never will be
That's just a bug then. The tooltip should obviously just appear below the mouse, no matter how large it is, or it could just appear above the element instead of below.
I'd also defend the text from the emptiness. In the Magnolia evoke example the text label is small while there is plenty of space around.
Also, you can go on the attack with text and make it rich! Bold / emphasising individual letters with colors to make all those visual scan easier.
Though the ultimate solution is allowing easy user choice of both to override whatever mistakes the designers made, and at an "OS level", so that a user could use a single identical icon for "Export" and avoid the mentioned per-app inconsistency. But that will have to wait until the fantasy era of UI design arrives
> We’ve spent our lives learning to recognize words instantly, while most app icons require new visual vocabulary.
Unfortunarely we haven't reached that level of magic reading skills despite spending a part of our early lives learning to... well, also not instant recognition.
> Scanning text is fundamentally easier than scanning icons. A stacked list of text requires only a one-directional scan (top-to-bottom), while icon grids demand bi-directional scanning (top-to-bottom and left-to-right).
But this is a fundamental mistake, besides the fact that icons take less space, so "efficiency" is higher, you can recognize familiar shapes/positioning without full per icon scanning
I have always hated icons and their proliferation.
I advocate for text, but it usually falls on deaf ears. I've been wondering why and recently hit on a new hypothesis: many people are slow readers.
It takes me about a second to read all of the labels in a typical menu column, if I'm familiar with what sort of things might be in the menu. I'm starting to realize this is not true for everyone.
For me, there is never a time when it's faster to interpret an icon than text. But I'm becoming sympathetic to the fact that we may need to accomodate slow readers in UI design.
I just wish there was a toggle to disable all of the icons in my entire operating system, with the exception of minimize, maximize, and close.
This reminds me of what I’ve read about the Xerox Mesa/Cedar environment, which in turn influenced the look and feel of Wirth’s Project Oberon and the acme text editor from Plan 9 from Bell Labs. I also have a copy of Jef Raskin’s The Humane Interface, and while I haven’t fully read the book, I remember it advocating the use of text over the use of icons.
I agree that over-reliance on pictograms frequently causes confusion.
I remember reading an article some time ago about European vs North American traffic signs. The article was praising the European system that relies more heavily on icons over the North American system which is more text-heavy. I can't remember the details now, but I remember disagreeing vehemently with the article.
I find many of the traffic icons (particularly the ones indicating something about parking, stopping and one-way streets) very unintuitive. I strongly prefer the text-heavy signage that I see in the US.
It's not really accurate to call them the "European system". These signs are used in many countries. Which also immediately tells you why icons are more useful than text: language barriers.
Where the US is one big area with a single language, that's not the case in the rest of the world. Processing words in a foreign language takes longer than just seeing the same traffic signs in a slight variation.
As for intuitiveness. I don't know, I kind of subscribe to the notion that the only intuitive interface is the nipple. Everything else is learned. What people call intuitive is just familiarity. The traffic signs are easy to get familiar with if you grow up with them. A systems-minded (or traffic-interested) kid can easily learn the meaning of most traffic signs long before they can read fast enough.
People literally take courses on the meaning of the traffic icons.
That's why they are not confusing. If people take courses on the meaning of the icons on your software's menu, and you need to save every millisecond from them recognizing the items, that's the way to go.
If both don't apply to you, you should do something different.
Though it’s decayed somewhat in recent releases, I think the Cocoa/AppKit toolbar widget is a great example of how all parties can be made happy. Right-click any standard Mac app toolbar and you get options for text + icons or icons only as well as sometimes the option to shrink the toolbar items (depending on the app).
So when a user first starts using an app, they might leave it on the default of text+icons, but once they’ve used it long enough to build familiarity they can elect to hide the text and shrink the icons to save screen real estate if they want to.
Unfortunately it’s become the norm for toolbars to have zero adjustability, a trend that I feel was mostly popularized by Chrome, which has had a mostly static toolbar since its inception.
Chrome allowed hiding the extensions and the “current profile” icon until a handful of years ago (hmm maybe 6?). I remember because I was recording screencasts and I’d turn all the stuff off to keep it clean, and I was so mad when they introduced the change where you couldn’t turn off those icons anymore. Still kinda salty about it.
I agree, that text labels are usually much better than using icons. Icons are sometimes helpful too, but usually text is more helpful, I think. But, what is better than text and icons is documentation. Documentation is what makes the interface understandable, rather than icons.
I'd like to extend this to "In defense of having a consistently organized UI and menu structure and not throwing icon-only buttons, text-only buttons, right-click menus, mouseover menus and '...'/'hamburger' menus randomly all over the UI."
Notable examples would be MS Teams and the YouTube app, but almost every modern app seems to do that to some degree.
ObsidianMD is probably the biggest offender, it's completely unusable to me thanks to their aggressive iconification and aEsTHEtic low-contrast interface.
I think this one form of a slightly more general issue which is the belief that good UX (or even "good ways of doing things" in some broader sense) should not require verbal explanation. This is seen in various kinds of "streamlined" interfaces that attempt to make things "obvious" or "intuitive", but often this comes at the cost of functionality. Icons are fine if you only have a few simple things you want to do, but when you have more potential actions and/or those actions are more complex, you start to need more explanation of what you're doing and how you're doing it, and for that you need words.
The irony is that those UIs usually end up needing even more elaborate explanations - they just hide them away in "new feature" popups that are shown exactly once, usually at the worst possible time, then are gone forever.
But if they are doing accessibility they have to create alt text for the icons anyway and that needs to be translated. So the only i18n complexity left would the ltr vs rtl languages and depending on how you place the text they wouldn’t need to really change the layout to accommodate both.
I firmly agree, and I'll call out Linear for being struck with labelitis. The pieces of a good app are there, but so many things are buried behind buttons with funny symbols with obvious meaning.
My rule for user interfaces: A GUI is as good as it is easy to help someone use it verbally. The best interfaces have unique handles, names and minimal hidden features. The interface doesn't necessarily need to have tons of labels, but everything on a screen should be identifiable by name.
If you can guide someone through an app while sitting next to them, or over the phone, it's a good GUI. If you have to say, "The grey thing on the left. No, the other one. In the box. It's a rectangle with a sort of an arrow thing," then that's a sign the UI sucks.
The problem is cognitive load. I have to deal with 20 apps or websites, each has 5-10 non-text icons. I then have to drag my mouse over each icon and wait for the preprogrammed 1000ms timer to show me what the icon is actually doing, which I'll then forget by the time I next use your app. It's too much load, it's too much irritation waiting for your stupid 1000ms timer to fire. It makes me hate your app without consciously realizing why.
Jetbrains just did a redesign of their IDEs to "minimize distractions", it's basically just iconifying everything in the sidebars. I gave it two months to see if it would stick but it hasn't. It's added friction every time I have to hunt for the icons.
Often cited by people on this website as “designers dumbing down user interfaces” but I assure you that this is easily predominantly perpetrated by “i can do UX too, I know what’s best” developers.
I say this as a developer, and as someone that’s never identified or worked on paper as a ‘designer’.
I lead a team of developers, and we usually have no designer input unfortunately. It’s all us. My team OFTEN tries to “just use an icon” for something, and I almost always pull the back from this. It seldom works. It’s almost always confusing for people. Text all the way.
“Devs doing design” are absolutely largely responsible, but on the design side of things there’s also been a tidal wave of non-UI designers who've washed onto the shores of UI/UX design in the past decade+ which I believe are just as culpable. They’re great at making UIs that look amazing on a promo page but the usability of their products leave much to be desired.
If we're going to make icons bear 100% of the semantic burden of UI design, we can at least be consistent and use Chinese characters for our icons. Billions of people know what they mean - way more than the number of people who will know what symbol you picked from whatever symbol library is chic this week. /s
Balance is important. For example, having some icons in a menu provides anchor points and gives the menu a distinct “shape”: http://colfinder.net/materials/Supporting_Distance_Education...
But when every menu item has an icon, it’s all just a blur: https://us1.discourse-cdn.com/gitlab/original/3X/6/3/634da24...
Agreed, absolutely.
The other thing is that full-color, textured icons help a great deal with immediate recognition as well. It's easy when the "open" icon is a yellow folder.
Sadly, the move to flat design with monochrome icon outlines destroyed that entirely. I'm still waiting for full-color icons to come back in style again. They can still be flat, but being filled with color (not just colored outlines) helps immensely with fast recognition.
Why does the folder color matter? Is it just because that is what you are used to from a specific OS?
Color helps for some people but when making an accessible design you have to account for color blindness and other vision issues. Which means the icon needs enough contrast and can’t rely on just color to convey meaning, unless the icon is paired with a text label that also conveys the meaning the color was trying to convey.
So while I agree that color iconography can be extremely helpful for the average user, unless it is supplemented by other techniques it can make a product completely unusable for a subset of users
The commenter did not say yellow was important per se, or that the color yellow was the most important property of the icon.
The commenter said that adding distinct colors to icons help users tell them apart.
Folders were always yellow on Windows because people were used to Manilla folders.
In the example, the folder is recognizable as such from just its shape. The color merely makes it more recognizable (because folders are yellow on Windows — it reinforces that the icon depicts a file folder).
For accessibility reasons, you shouldn’t rely on only the color, but that doesn’t mean that color isn’t a very useful property to apply.
I absolutely despise color coding. I'm red-green colorblind but that affects all colors that have red or green as part of the mix.
What the GP is asking for does not affect the color blind. They are not suggesting there should be multiple folder icons of different colors. They just want color included in the existing icons. My understanding of color blindness means that that would be better for people with color blindness as well.
This is an example for something I have always troubling arguing with in technical discussions: Sometimes a solution only works if you apply it partially, "in good measure".
I can imagine the discussions on the issue above with the outcome being either no icons, or icons on every item, but nothing in between.
How go about convincing a group of people about this?
I prefer every item having both text and an icon. If I don't know what the icon mean, there's text there to explain it. If I do know what the icon means, i can scan just the icons and find what I need faster. In my opinion it's the best of both worlds. That being said, your first example might be even better, because a lot of those things like "close" or "versions" I'm not going to be clicking often, so if they had an icon I'd have to read the text to figure them out every time anyway
In your first example, my intuition tells me if some elements are more important than others in away that's worth distinguishing with icons, it's better to think on providing easier access to them (priority at the top?) or hiding the rest.
There's 17 options there, where only 5 are deemed important.
The second example is bad for different reasons. There's no apparent rime or reason to the options other than "places you might want to check", no grouping and no priorisation. It would be a hard to parse with or without icons.
The brilliant thing about the first example is that differentiating "important" items with the icon actually allows multiple forms of categorizing items in the list, whereas your suggestions only allow one. The items in the list are grouped by topic, and important/common ones are highlighted with an icon. Hiding the less important options makes them needlessly harder to find if/when you do need them. Moving important items to the top breaks the topical grouping. In both cases, the application becomes less discoverable.
+1 it would be silly to ungroup all the save actions
In the first example the items are grouped by topic (such as “printing”), which I think makes sense. When you go select a “frequent” action, it’s useful to see which “less frequent” but related actions exist nearby. And the icons not being all grouped together but being (partially) isolated actually helps in better recognizing them.
It’s from Microsoft Word ('97, I believe), by the way. A later version had “expandable” menus that by default only showed the most frequently used options, and on expansion (or by global setting) then also showed the other options. Many users didn’t like that, however, either because they missed that the menu could be expanded and thus didn’t find the item they were looking for, or because the expansion changed the relative locations of the items, meaning they were at an unexpected position depending on the expansion mode; or just because the expansion required an extra click.
I’m just noting this because Microsoft deemed the topical grouping of items within the menu important enough that they kept it, orthogonal to the expansion mechanism. And they doubled down on the grouping with the later ribbon interface — which I personally dislike because it’s not linearly greppable and feels jumbled, and they felt the need to give every item an icon there, whether memorable or not.
Hiding parts of the menu hinders discoverability when those options are needed, creates a need for one extra action to show all the available options, and messes with the users' spatial and muscle memory. This particular mistake was already made a quarter of a century ago, in Office 2000.
> it's better to think on providing easier access to them (priority at the top?) or hiding the rest.
Microsoft tried it. Hiding things doesn't work. Because what is unimportant to you is important to someone else.
See Why the UI https://web.archive.org/web/20080316101025/http://blogs.msdn...
--- start quote ---
There was no way to get the default "short" menu right. Although conventional wisdom holds that "everyone only uses the same few features in Office," the reality is that people use an amazingly wide range of functionality. So, one person's ideal default "short" menu was exactly the wrong thing for someone else.
--- end quote ---
This is essentially the problem that the average user uses only a few features, but no actual user only uses those features.
I am wondering why I agree with you!
I think because the shape creates landmarks. This is why some cities are easier to navigate than others. You need some stuff to be different.
The icons are also used on the most commonly used items.
"Groups" on that Git forge probably isn't used as often as "issues" but they both have vague little grey icons.
"Issues" should just be an icon of a bug
Yes, it’s the non-uniformity. The icons being colored and having high contrast also helps. They furthermore highlight the most important functions.
Should have done BitBucket's menu. Every entry has an icon and they are all some variation on arrows pointing at dots. Completely useless.
I don't think its too bad (assuming you mean this one, I can't find a higher-level one) https://i.imgur.com/V06bwjJ.png There are a few similar arrow-and-dot ones, but at least they're directly connected to the related git action. The gitlab one... milestones are a clock, but activities are a clock running backwards? Projects and issues are just sets of rectangles in a different rotation. I feel like part of the problem is these concepts are not themselves super coherent already, but they didn't do a great job either. (how about an actual mile marker for mile-stones?)
Most of the world switched to phonetic scripts a long time ago. That's be because they're strictly superior to pictograms. Icons are optional. Text is required. Sorry if you have to translate it.
This is obviously not true.
You don't need a label to say "Close" next to the "X" on your window. Or "Play" next to a right-facing triangle in your media player. Or the word "Search" next to a text box with a magnifying glass in it. We have certain "pictograms" that are just as widely understood as letters themselves.
There is a spectrum from widely-understood symbols that don't need labels, to totally ambiguous/confusing/custom symbols that are helped greatly by labels.
That said, I agree with the article that right now, a lot of apps could benefit from more labels rather than less.
A magnifying glass on its own could mean:
1. Search (across the application)
2. Find on page
3. Adjust zoom
Try to keep going though. Close. Play. Search. Pause. Stop. Fast forward. I'm guessing you can name a few more, and you might get a group of people to agree about 15 are super obvious and generally accepted. It's a tiny number.
I agree. Maybe I'd add the three horizontal line 'hamburger' for menu, folder, plus sign for 'create new" and directional arrows for back/forward. Maybe around a dozen all in but that's about it. Anything else should have words.
Instead, I find myself trying to puzzle out what the hell some cryptic pictogram means, very frustrating. I also have really come to despise this trend of not visually signifying that an icon is a pressable button.
> the three horizontal line 'hamburger' for menu
On modern Android menus are (more) often I under a button with 3 dots.
Occasionally horizontal, usually vertical.
> Or "Play" next to a right-facing triangle in your media player.
That's a good example. I love text buttons because they are _larger_.
> Or the word "Search" next to a text box with a magnifying glass in it.
And here I _definitely_ disagree. I hate the search interfaces that are hidden behind a small icon somewhere.
What are you disagreeing with if the "hidden behind small" is the assumption you've made? Nothing about icons demands hiding anything
If it’s your personal opinion and other people disagree, it’s not strictly superior though.
Also, text is literally just funny shapes that are used to communicate.
How are they strictly superior? Here are at least two reasons where icons are better: Speed of recognition and needed Space (especially width).
But that's just not true. If I have to sit there trying to figure out what an icon means, that's not faster than just reading the word.
Not when you first open the program, but for advanced users, absolutely.
How and why would I become an advanced user of a program I can't figure out how to use because none of the buttons have labels?
Pixelmator Pro shows you the names of the tool buttons, once, when you first launch the app. They disappear the moment you click a button. Nice. a whole 10 seconds to memorize all two dozen of them.
And they chose not to use the system tooltip on hover, so I have to wait for some humungous pictorial tooltip to load in when all I want to know is the goddamn hotkey.
How does that matter for the point? You can make it a setting for the user or just always show both. I never said that programs should exclusively use icons.
The initial claim was that text is strictly superior to icons, which means that icons have not a single thing they’re better at then text. That’s just plainly false.
That’s rarely the case, in my experience, especially when there are a dozen monochrome icons in a row. They just aren’t distinct or memorable enough. You learn their position after a while, but confirming the correct item by their pictogram remains slower than just reading a word or two, because the words are universal, whereas the pictograms are typically specific to the application.
I think the commenter you're replying to might have been referring to pictograms like many Chinese characters, not icons that you have to figure out. Or maybe not
> pictograms like many Chinese characters
A handful of Chinese characters are pictograms. As far as I recall, it is by far the smallest class of characters, and all of them, including the ones that started as pictograms, are treated by modern readers as phonetic indicators.
Compare e.g. 象 to https://img.zdic.net/zy/jinwen/33_E87E.svg .
They are the same character. Does that help you if you're looking at 象?
Every time I'm busy with a topic, the next day it somehow ends up showing up on HN!
I was creating a small drawing app for my 27-month-old son (mostly for me to draw tractors and excavators for him). At first, I only used icons, but they confused him. So, I added text labels, and surprisingly, even though he can't read, the labels helped reduce visual clutter. Suddenly, he could "learn" what each tool does and remember.
that's wild. I find that my.... 27-month old daughter (heh, what a coincidence) also recognises the titles of bluey episodes pretty easy..
we can be scrolling a list of bluey episodes, and she knows what they are by the words.. "what episode do you want to watch?" "curry quest!" - sure enough, that's what it's called and that's what the title is
all of the pictures are some form of the characters doing something, so i find them fairly indistinguishable... I haven't tried letting her pick one without the picture, which will be the real test i guess.
Cool, also yeah, what a coincidence! We had the same thing with books. My wife and I really suspected that he was somewhat reading until we figured out that he memorized the shapes of the sentences, so individual words or the same sentence in a different font wouldn't be recognized. It's fascinating to witness how a human brain evolves.
Also, about Bluey... The little guy has limited screen time so he can only see an episode or two per day, but I really want to keep watching even when he can't lol. I literally fell off the sofa laughing in the episode where they are trying to lick each others ice cream while the waltz music from the Nutcracker plays :)
On Windows 11, open the Microsoft Store app and select the Entertainment section, (confusingly) marked by a clapperboard icon. You'll notice an unfortunate design choice where the text labels disappear upon clicking, making navigation (or remembering where you are) less intuitive. I've raised this as a usability issue multiple times with the development team and they don't seem to agree or care. It drives me up the wall.
I've heard this sentiment phrased as "a picture is worth a thousand words, but often just one is enough."
I very much agree with this.
As an example, I look at the Markup Toolbar in MacOS, and I have no idea what those icons mean until I've tried using the tools. They're so similar, vague and monochrome.
I don’t mind an icon but I am frustrated if hovering the mouse doesn’t show a tooltip or alt-text style label
It makes learning new software much slower and basically requires going to the docs or a video tutorial if the ui design isn’t exactly spot-on and perfectly intuitive which it almost never will be
Accessibility wise, for those people with impaired vision, a larger mouse cursor obscures the tool tip text making it unreadable.
That's just a bug then. The tooltip should obviously just appear below the mouse, no matter how large it is, or it could just appear above the element instead of below.
I'd also defend the text from the emptiness. In the Magnolia evoke example the text label is small while there is plenty of space around.
Also, you can go on the attack with text and make it rich! Bold / emphasising individual letters with colors to make all those visual scan easier.
Though the ultimate solution is allowing easy user choice of both to override whatever mistakes the designers made, and at an "OS level", so that a user could use a single identical icon for "Export" and avoid the mentioned per-app inconsistency. But that will have to wait until the fantasy era of UI design arrives
> We’ve spent our lives learning to recognize words instantly, while most app icons require new visual vocabulary.
Unfortunarely we haven't reached that level of magic reading skills despite spending a part of our early lives learning to... well, also not instant recognition.
> Scanning text is fundamentally easier than scanning icons. A stacked list of text requires only a one-directional scan (top-to-bottom), while icon grids demand bi-directional scanning (top-to-bottom and left-to-right).
But this is a fundamental mistake, besides the fact that icons take less space, so "efficiency" is higher, you can recognize familiar shapes/positioning without full per icon scanning
On toolbars, text labels should be tooltips.
And tooltips should show up without delay, so I can go through the icons at my own pace by just hovering over them.
I feel that the idea that tooltips only show after a delay was a grave mistake, which has become cemented and is relentlessly perpetuated.
I have always hated icons and their proliferation.
I advocate for text, but it usually falls on deaf ears. I've been wondering why and recently hit on a new hypothesis: many people are slow readers.
It takes me about a second to read all of the labels in a typical menu column, if I'm familiar with what sort of things might be in the menu. I'm starting to realize this is not true for everyone.
For me, there is never a time when it's faster to interpret an icon than text. But I'm becoming sympathetic to the fact that we may need to accomodate slow readers in UI design.
I just wish there was a toggle to disable all of the icons in my entire operating system, with the exception of minimize, maximize, and close.
This reminds me of what I’ve read about the Xerox Mesa/Cedar environment, which in turn influenced the look and feel of Wirth’s Project Oberon and the acme text editor from Plan 9 from Bell Labs. I also have a copy of Jef Raskin’s The Humane Interface, and while I haven’t fully read the book, I remember it advocating the use of text over the use of icons.
I agree that over-reliance on pictograms frequently causes confusion.
I remember reading an article some time ago about European vs North American traffic signs. The article was praising the European system that relies more heavily on icons over the North American system which is more text-heavy. I can't remember the details now, but I remember disagreeing vehemently with the article.
I find many of the traffic icons (particularly the ones indicating something about parking, stopping and one-way streets) very unintuitive. I strongly prefer the text-heavy signage that I see in the US.
It's not really accurate to call them the "European system". These signs are used in many countries. Which also immediately tells you why icons are more useful than text: language barriers.
Where the US is one big area with a single language, that's not the case in the rest of the world. Processing words in a foreign language takes longer than just seeing the same traffic signs in a slight variation.
As for intuitiveness. I don't know, I kind of subscribe to the notion that the only intuitive interface is the nipple. Everything else is learned. What people call intuitive is just familiarity. The traffic signs are easy to get familiar with if you grow up with them. A systems-minded (or traffic-interested) kid can easily learn the meaning of most traffic signs long before they can read fast enough.
People literally take courses on the meaning of the traffic icons.
That's why they are not confusing. If people take courses on the meaning of the icons on your software's menu, and you need to save every millisecond from them recognizing the items, that's the way to go.
If both don't apply to you, you should do something different.
Though it’s decayed somewhat in recent releases, I think the Cocoa/AppKit toolbar widget is a great example of how all parties can be made happy. Right-click any standard Mac app toolbar and you get options for text + icons or icons only as well as sometimes the option to shrink the toolbar items (depending on the app).
So when a user first starts using an app, they might leave it on the default of text+icons, but once they’ve used it long enough to build familiarity they can elect to hide the text and shrink the icons to save screen real estate if they want to.
Unfortunately it’s become the norm for toolbars to have zero adjustability, a trend that I feel was mostly popularized by Chrome, which has had a mostly static toolbar since its inception.
There's sometimes a third option in there for "text" only. Can be nice in some cases.
A lot of times, if the dev didn't put the text only option in, you can force it by setting the NSToolbar's prefs in that app's CFPreferences plist.
Chrome allowed hiding the extensions and the “current profile” icon until a handful of years ago (hmm maybe 6?). I remember because I was recording screencasts and I’d turn all the stuff off to keep it clean, and I was so mad when they introduced the change where you couldn’t turn off those icons anymore. Still kinda salty about it.
I couldn't find an app that I have open right now that still uses the Cocoa toolbar widget.
I agree, that text labels are usually much better than using icons. Icons are sometimes helpful too, but usually text is more helpful, I think. But, what is better than text and icons is documentation. Documentation is what makes the interface understandable, rather than icons.
I'd like to extend this to "In defense of having a consistently organized UI and menu structure and not throwing icon-only buttons, text-only buttons, right-click menus, mouseover menus and '...'/'hamburger' menus randomly all over the UI."
Notable examples would be MS Teams and the YouTube app, but almost every modern app seems to do that to some degree.
ObsidianMD is probably the biggest offender, it's completely unusable to me thanks to their aggressive iconification and aEsTHEtic low-contrast interface.
Same for me, due to the low contrast in particular.
Switch to a high-contrast theme then?
I think this one form of a slightly more general issue which is the belief that good UX (or even "good ways of doing things" in some broader sense) should not require verbal explanation. This is seen in various kinds of "streamlined" interfaces that attempt to make things "obvious" or "intuitive", but often this comes at the cost of functionality. Icons are fine if you only have a few simple things you want to do, but when you have more potential actions and/or those actions are more complex, you start to need more explanation of what you're doing and how you're doing it, and for that you need words.
The irony is that those UIs usually end up needing even more elaborate explanations - they just hide them away in "new feature" popups that are shown exactly once, usually at the worst possible time, then are gone forever.
A.k.a. Mystery meat navigation: <https://en.wikipedia.org/w/index.php?title=Mystery_meat_navi...>
If I had a dollar for every time I had to teach someone how to share screen in Google Meets...
In Google's defense, text labels are hard for i18n, but icons without text is low effort, bad UX too.
The meanings of icons can also be highly dependant on culture, we just tend to ignore those dependencies easier than with text.
But if they are doing accessibility they have to create alt text for the icons anyway and that needs to be translated. So the only i18n complexity left would the ltr vs rtl languages and depending on how you place the text they wouldn’t need to really change the layout to accommodate both.
And they'll never know people are struggling. How would they?
They're institutionalized into replacing text with icons.
I firmly agree, and I'll call out Linear for being struck with labelitis. The pieces of a good app are there, but so many things are buried behind buttons with funny symbols with obvious meaning.
My rule for user interfaces: A GUI is as good as it is easy to help someone use it verbally. The best interfaces have unique handles, names and minimal hidden features. The interface doesn't necessarily need to have tons of labels, but everything on a screen should be identifiable by name.
If you can guide someone through an app while sitting next to them, or over the phone, it's a good GUI. If you have to say, "The grey thing on the left. No, the other one. In the box. It's a rectangle with a sort of an arrow thing," then that's a sign the UI sucks.
That is a brilliant rule for GUI evaluation
"Could I guide my Nana through your app over the phone?"
- Beattie's Law of UI
Text on Web pages can be found with ctrl-f too which I use almost daily to deal with Web UIs!
The problem is cognitive load. I have to deal with 20 apps or websites, each has 5-10 non-text icons. I then have to drag my mouse over each icon and wait for the preprogrammed 1000ms timer to show me what the icon is actually doing, which I'll then forget by the time I next use your app. It's too much load, it's too much irritation waiting for your stupid 1000ms timer to fire. It makes me hate your app without consciously realizing why.
Jetbrains just did a redesign of their IDEs to "minimize distractions", it's basically just iconifying everything in the sidebars. I gave it two months to see if it would stick but it hasn't. It's added friction every time I have to hunt for the icons.
I really should have cancelled over it, even if they mollified me with the ability to inconveniently disable it
Often cited by people on this website as “designers dumbing down user interfaces” but I assure you that this is easily predominantly perpetrated by “i can do UX too, I know what’s best” developers.
I say this as a developer, and as someone that’s never identified or worked on paper as a ‘designer’.
I lead a team of developers, and we usually have no designer input unfortunately. It’s all us. My team OFTEN tries to “just use an icon” for something, and I almost always pull the back from this. It seldom works. It’s almost always confusing for people. Text all the way.
“Devs doing design” are absolutely largely responsible, but on the design side of things there’s also been a tidal wave of non-UI designers who've washed onto the shores of UI/UX design in the past decade+ which I believe are just as culpable. They’re great at making UIs that look amazing on a promo page but the usability of their products leave much to be desired.
If we're going to make icons bear 100% of the semantic burden of UI design, we can at least be consistent and use Chinese characters for our icons. Billions of people know what they mean - way more than the number of people who will know what symbol you picked from whatever symbol library is chic this week. /s