[HN Gopher] In Defense of Text Labels
___________________________________________________________________
In Defense of Text Labels
Author : delaugust
Score : 229 points
Date : 2025-02-22 20:40 UTC (1 days ago)
(HTM) web link (www.chrbutler.com)
(TXT) w3m dump (www.chrbutler.com)
| sillywalk wrote:
| 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.
| Hizonner wrote:
| 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.
| greggsy wrote:
| Also, text is literally just funny shapes that are used to
| communicate.
| echoangle wrote:
| How are they strictly superior? Here are at least two reasons
| where icons are better: Speed of recognition and needed Space
| (especially width).
| DecentShoes wrote:
| 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.
| echoangle wrote:
| Not when you first open the program, but for advanced
| users, absolutely.
| wpm wrote:
| 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.
| echoangle wrote:
| 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.
| layer8 wrote:
| 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.
| alexvitkov wrote:
| Keyboard shortcuts are a feature for advanced users, not
| pictures.
| andybak wrote:
| For some definitions of "advanced".
|
| I use dozens of apps regularly enough to not be a
| beginner but not so much that I know their keyboard
| shortcuts. Icons have a role.
| echoangle wrote:
| Good luck learning keyboard shortcuts for every feature
| of a CAD tool. I understand Boolean modifiers from
| symbols faster than I can read them, but I'm not going to
| memorize every shortcut for stuff like that.
| crackalamoo wrote:
| 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
| thaumasiotes wrote:
| > 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. Xiang to
| https://img.zdic.net/zy/jinwen/33_E87E.svg .
|
| They are the same character. Does that help you if you're
| looking at Xiang ?
| crazygringo wrote:
| 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.
| cyberax wrote:
| > 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.
| echoangle wrote:
| If it's your personal opinion and other people disagree,
| it's not strictly superior though.
| eviks wrote:
| What are you disagreeing with if the "hidden behind small"
| is the assumption you've made? Nothing about icons demands
| hiding anything
| danielmarkbruce wrote:
| 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.
| mrandish wrote:
| 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.
| petepete wrote:
| > 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.
| Izkata wrote:
| > Maybe I'd add the three horizontal line 'hamburger' for
| menu
|
| Fun fact, the original icon for this was more like:
| /-----\ | --- | | --- |
|
| Because it visually represented a menu popping up from
| the bottom of the screen where the button was on Android
| phones. Back in this era and earlier, the three
| horizontal lines represented grips that indicated you
| could click+drag an element on a webpage.
| layer8 wrote:
| I wasn't originally a fan of the hamburger menu icon
| (it's not self-explanatory, you have to know what it
| means), but there was already precedence in Windows 1.0
| for the so-called system menu for each application: https
| ://upload.wikimedia.org/wikipedia/en/4/4e/Windows1.0.pn..
| .
|
| Similarly in some DOS TUIs:
| https://retrocomputing.stackexchange.com/a/23921
| mrandish wrote:
| > I wasn't originally a fan of the hamburger menu icon
| (it's not self-explanatory
|
| I definitely agree. I just think that it's just been so
| common in GUIs for long enough to be one of the few
| that's probably safe to just assume will be understood.
| Sort of like the two vertical bars for 'pause' on a media
| player.
| layer8 wrote:
| I hate that it's being used on the desktop, where there
| is plenty of space, resulting in a smaller hit target and
| often an additional click for items that would normally
| be top-level. Even on mobile, there would often be
| sufficient space to show a word like "Menu".
| BiteCode_dev wrote:
| Back arrow, reload sign, house for the home button (all
| them on most web browsers), +/- signs, trash can to delete,
| music notes, thumbs up and down, movie clap, compas for
| navigation, "?" for help, clock for time, lockpad for
| secured, git wrap for free, speaker for volume, bell for
| notification, battery, pen to edit, calendar for date,
| clipboard to copy/past, gear for settings, yellow triangle
| for warning, red circle carrying an icon for forbidden,
| check mark for approved...
|
| We are literally living in the era of emoji and there is
| one for every single one up there. Teens can have all
| conversations without using words.
|
| It happens because the more we use symbols, the more we
| attach and spread meaning.
|
| Send "lesser than three" to someone 30 years ago, you'll
| get a blank reaction.
|
| Send "<3" today, and it's a different game.
| tsm wrote:
| A magnifying glass on its own could mean:
|
| 1. Search (across the application)
|
| 2. Find on page
|
| 3. Adjust zoom
| hnlmorg wrote:
| > You don't need a label to say "Close" next to the "X" on
| your window
|
| A lot of windowing systems will show a tool tip saying
| "Close" if you hover over that X.
|
| Similarly, any menu items for Close (eg right clicking on the
| task bar) will have both text and an icon.
|
| > Or "Play" next to a right-facing triangle in your media
| player.
|
| It's actually pretty common on hardware devices to have text
| accompanying those icons.
|
| And particularly on older devices when those icons were less
| ingrained into everyone's memory.
|
| For example:
|
| https://www.bhphotovideo.com/images/images2500x2500/coby_cvr.
| ..
|
| > Or the word "Search" next to a text box with a magnifying
| glass in it
|
| And you'd be amazed at the number of nontechnical people who
| struggle with that.
|
| This is why websites designed for people of varying technical
| abilities, for example holiday booking sites, have text
| inside the search box describing what it's used for.
|
| For example in this picture of EBay, there is text that says
| "Search for anything"
|
| https://www.lifewire.com/thmb/DwZPyw8OFhQje9EAgEVOtBpUYVM=/1.
| ..
|
| > There is a spectrum from widely-understood symbols that
| don't need labels
|
| Widely understood by who? People writing the software? Or
| people actually using the software? ;)
|
| Software engineers sometimes forget that most people don't
| use computers nor websites for fun and thus don't want to
| learn what a bunch of pictograms mean.
|
| Frankly, I don't want to memorise icons either and I do use
| computers for fun. So there has better be some text labels
| available for when I'm old, eyesight going, and less
| comfortable with technology than I currently am.
| tristramb wrote:
| Text is in a sense universal. At least within a particular
| language. It is not tied to a particular app or operating
| system. You can interpret it using the same mechanism that you
| use to interpret a book, the label of a bottle of wine, or the
| name on a gravestone.
| xeonmc wrote:
| ObsidianMD is probably the biggest offender, it's completely
| unusable to me thanks to their aggressive iconification and
| aEsTHEtic low-contrast interface.
| layer8 wrote:
| Same for me, due to the low contrast in particular.
| saint_yossarian wrote:
| Switch to a high-contrast theme then?
| teddyh wrote:
| A.k.a. _Mystery meat navigation_ :
| <https://en.wikipedia.org/w/index.php?title=Mystery_meat_navi...>
| layer8 wrote:
| 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...
| ranger207 wrote:
| 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
| radicality wrote:
| Same for me.
|
| In case it's useful to someone, in many native Mac apps you
| can get the main toolbar to show both. Try right-clicking on
| the toolbar -> Customize Toolbar -> Icon and Text. Doesn't
| work everywhere though, but still super useful to me, I
| enable it whenever I can.
| olejorgenb wrote:
| But it's not as compact as icons only, which to me is the
| main advantage of icons. All icon buttons should have hover
| text with the command name of course.
| aqueueaqueue wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| 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
| layer8 wrote:
| Yes, it's the non-uniformity. The icons being colored and
| having high contrast also helps. They furthermore highlight
| the most important functions.
| crazygringo wrote:
| 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.
| fedorareis wrote:
| 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
| layer8 wrote:
| 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.
| mlx0x wrote:
| Folders were always yellow on Windows because people were
| used to Manilla folders.
| fmbb wrote:
| 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.
| y1n0 wrote:
| 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.
| drdec wrote:
| 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.
| Izkata wrote:
| Particularly with this example, because even with the
| not-the-same-yellow that a colorblind person would see,
| it would still end up closer to the object the icon is
| based on: https://www.amazon.com/AmazonBasics-File-
| Folders-Reinforced-...
| skywhopper wrote:
| I'm deuteranomolous myself, but I disagree. Color, shape,
| labels, and location can all combine to be useful for
| recognition. Using color _alone_ is definitely a mistake,
| or making color the only difference between two icons. But
| combine distinct shapes and distinct colors (informed by
| color-blindness awareness) for the best results.
| kace91 wrote:
| 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.
| layer8 wrote:
| 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.
| vvillena wrote:
| 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.
| nerdponx wrote:
| 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.
| 8n4vidtmkvmk wrote:
| +1 it would be silly to ungroup all the save actions
| troupo wrote:
| > 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/htt
| p://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 ---
| XorNot wrote:
| This is essentially the problem that the average user uses
| only a few features, but no actual user _only_ uses those
| features.
| immibis wrote:
| The easy access is that there is an icon next to them.
| Providing a collapsible menu just breaks muscle memory and
| adds an extra click to the other items. Microsoft tried this
| once.
| moron4hire wrote:
| Should have done BitBucket's menu. Every entry has an icon and
| they are all some variation on arrows pointing at dots.
| Completely useless.
| recursivecaveat wrote:
| 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?)
| fzeindl wrote:
| 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?
| pphysch wrote:
| When it comes to quantities, point to
| https://en.wikipedia.org/wiki/Subitizing. Simply put: "1, 2,
| 3, 4, many". Designers should be conscious when quantities
| might cross this (approx) subitizing threshold, and consider
| increasing the dimensionality with nesting or other
| techniques, rather than allow the size of simple visual sets
| to become overwhelming to users.
|
| Whether intentional or not, the Windows example has exactly 4
| icons in that column, and the rest are blank space. This
| makes it easy to visually navigate to, and identify, those
| emphasized options.
| Mikhail_Edoshin wrote:
| The first example was used together with a toolbar. Commands
| that had buttons on the toolbar also had icons in the menu, so
| the user could make a connection between the menu and the
| toolbar.
|
| The second example uses icons merely as a decoration. This is a
| wrong usage.
|
| Aside from that toolbar example menus normally should not have
| icons at all. A good use of icons is a list that may have items
| of different kind, like a list of files that displays a
| pictogram for each file type or maybe a tiny preview of the
| file's contents.
| globular-toast wrote:
| I wonder if the earlier Windows 95 style with a few choice
| icons was a deliberate design decision, or just a budget
| limitation? I'm thinking it's probably the latter. Funny how a
| limited budget often leads to better results.
| immibis wrote:
| I think the convention was that if the same command was
| activated by a menu item and a toolbar button, you put the
| icon from the toolbar button next to the menu item. This also
| tells the user that they can access the command more quickly
| in the toolbar, and doesn't force the user to only learn the
| toolbars by hovering the cursor over every icon.
| atoav wrote:
| The thing is you should structure your interface the way a good
| craftsperson would structure their tools.
|
| That means a single-digit number important tools should be
| directly accessible, ideally in the order in which you usually
| need them. Other tools sbould be organized in sections that
| make sense, even if you don't make these sections explicit.
|
| For example in the shown gitlab sidebar you put milestones and
| activity next to each other as they both are related to project
| managment. Projects and Groups maybe should just become
| something like "Dashboard" or "Overview" as having separate
| pages for them is probably not the most efficient way to get
| you where you want etc.
|
| Just putting everything in a menu is thr lazy option, the good
| option is to tbink long and hard how to organize the tools and
| create good defaults that suit many people
| emilfihlman wrote:
| To me the icons in the first are not useful and they are also
| distracting, I immediately only scan the text while ignoring
| the icons.
|
| I also immediately ignore the icons and scan the text on the
| latter one.
|
| I guess it's mostly from not trusting icons, the only ground
| truth comes from the text where there's no possible alternative
| meaning.
| bolognafairy wrote:
| 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.
| cosmic_cheese wrote:
| "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.
| cosmic_cheese wrote:
| 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.
| bluedino wrote:
| I couldn't find an app that I have open right now that still
| uses the Cocoa toolbar widget.
| dceddia wrote:
| 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.
| wpm wrote:
| 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.
| guelo wrote:
| 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.
| juped wrote:
| I really should have cancelled over it, even if they mollified
| me with the ability to inconveniently disable it
| aqueueaqueue wrote:
| Text on Web pages can be found with ctrl-f too which I use almost
| daily to deal with Web UIs!
| BrenBarn wrote:
| 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.
| xg15 wrote:
| 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.
| BrenBarn wrote:
| Yeah. Also they often wind up trading "no explanation needed
| for the most common use case" for "incredibly involved
| explanation needed for any other use case" (or even "all
| other use cases are unsupported").
| xg15 wrote:
| 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.
| quectophoton wrote:
| You forgot GitHub:
|
| One hamburger menu on the top left, with things related to your
| account, like repositories or the GitHub marketplace.
|
| One hamburger menu on the top right (using your profile picture
| instead of the hamburger icon), with things related to your
| account, like repositories or the GitHub website.
|
| And between those two menus there's no-man's-land.
| linguae wrote:
| 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.
| calderwoodra wrote:
| 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.
| xg15 wrote:
| The meanings of icons can also be highly dependant on culture,
| we just tend to ignore those dependencies easier than with
| text.
| esafak wrote:
| And they'll never know people are struggling. How would they?
| fedorareis wrote:
| 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.
| kmstout wrote:
| $ aspell dump master | egrep -i '^i.{18}n$'
| institutionalization internationalization
| card_zero wrote:
| They're institutionalized into replacing text with icons.
| russellbeattie wrote:
| 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.
| EdwardDiego wrote:
| That is a brilliant rule for GUI evaluation
|
| "Could I guide my Nana through your app over the phone?"
|
| - Beattie's Law of UI
| eviks wrote:
| 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
| puzzledobserver wrote:
| 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.
| marcosdumay wrote:
| 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.
| lucumo wrote:
| 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.
| numpad0 wrote:
| They have to have pictograms in Europe because of things like
| emergency stop buttons marked "NOT" in Germany[0], on top of
| having dozen different languages. They need a system that is
| deliberately disconnected from languages, ideally but
| optionally corrected for biases.
|
| North America can just get away with text labels because en_US
| is dominant in NA and learning curve for HMIs in English is
| flat as it gets.
|
| 0: Naturally, means emergency. If you think that's odd, English
| "emergency" is also just "arising" if taken literal. Emerging
| what?
| foobarbecue wrote:
| 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.
| userbinator wrote:
| I've heard this sentiment phrased as "a picture is worth a
| thousand words, but often just one is enough."
| veltas wrote:
| A good picture, unfortunately most modern apps are full of
| meaningless icons.
| energy123 wrote:
| 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.
| acc_297 wrote:
| 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
| hh2222 wrote:
| Accessibility wise, for those people with impaired vision, a
| larger mouse cursor obscures the tool tip text making it
| unreadable.
| Timwi wrote:
| 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.
| layer8 wrote:
| Tooltips appear below the mouse pointer. By the way, this is
| an important reason to use OS mechanisms for UI features like
| that, which take care of such details, and not (having to)
| roll your own. Another standard feature of tooltips is that
| they remain on screen for a configurable amount of time (OS
| setting) and you can move the mouse during that time, should
| it obscure the tooltip for some reason.
| chrismorgan wrote:
| I don't know what OS you're talking about, but that's
| basically never been true on Windows. Native tooltips don't
| natively try to dodge the cursor, and there's no
| configuration of times and such, and not much actually even
| uses the _original_ native stuff any more, nor should it.
| And as regards dodging the cursor, I don't know of a single
| piece of software that actually queries the cursor in order
| to dodge it--though my dad told me years ago he'd
| implemented such a thing personally back somewhere around
| 2000.
|
| This wasn't _much_ of a problem in the past, because the
| largest cursors shipped out of the box were only two or
| three times as big, and not _much_ would collide. But in I
| think 2019 Windows 10 gave you a colour and size selector,
| and it extends the range past 1-3 all the way up to _15_ ,
| which I think might have been 256x256 or something, which
| is absolutely huge and I actually had a lot of fun
| deliberately doing bright orange size 15 cursor for a whole
| week when that feature first came out, before eventually
| settling on 4, which is still _way_ bigger than people are
| used to, and well worth it, in my opinion, except that for
| size 3 and beyond, tooltips get occluded, and so I'd lose
| the first couple of letters of tooltips. (I like the way
| macOS enlarges the cursor if you shake it about, so you can
| find it if you lost it.)
|
| Huh, just checked the original Firefox bug from 2004,
| https://bugzilla.mozilla.org/show_bug.cgi?id=248718, and it
| looks like they've finally fixed this after twenty years,
| in https://bugzilla.mozilla.org/show_bug.cgi?id=1712669.
| Still took five more years of occasional complaints, but I
| wonder if Windows making it so easy to get bad tooltips has
| pushed more software to fix their tooltip placement. Nice
| to see, even if it's too late to benefit me any more.
|
| Of course, on the web you can't do it properly with in-DOM
| tooltips; only with native tooltips, which are
| unfortunately very limited and often unsuitable for other
| reasons.
|
| --***--
|
| Now as for Linux + Wayland... ugh. The situation is still
| laughably bad. I use Sway, `output eDP-1 scale 1.5` and
| `seat seat0 xcursor_theme Adwaita 96`, and the cursor still
| appears at at least three different sizes, depending on the
| app. It used to be five. GTK is just ignoring the size
| thing so I can't judge it, Qt seems to be actually
| positioning tooltips sanely these days, avoiding the
| cursor, which I don't think it did four years ago. Good
| show.
| ryukoposting wrote:
| 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.
| kmeisthax wrote:
| 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
| egeozcan wrote:
| 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.
| drekipus wrote:
| 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.
| egeozcan wrote:
| 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 :)
| IshKebab wrote:
| She's definitely recognising the pictures not the words.
| h3half wrote:
| Words are just little pictures with particular semantic
| meaning. My 33-month old definitely recognizes the word
| "no" in a few different fonts; that doesn't mean he can
| read, he just knows what the word "no" looks like
| Timwi wrote:
| 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.
| zzo38computer wrote:
| 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.
| withinrafael wrote:
| 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.
| frabcus wrote:
| I suspect people's internal mind abilities impact this a lot. I
| have little visual memory so icons are hard for me. Others I
| think struggle with quickly scanning words.
|
| I think both are needed as we are varied people, and empathy for
| the need for both is important.
|
| Finally... The UI that drives me mad for this is the Discord
| server list in its left bar. You can't turn on text! It slows me
| down and makes it hard for me to deal with - especially as I'm
| slow to learn the icons of new servers. The list changes and they
| have no coherent design! (And no, the hover tooltip doesn't solve
| the problem)
| holowoodman wrote:
| I'd say this also depends on the number of menu/icon bar/...
| entries that have to be distinguished. If there are only 5
| options, like new/open/save/settings/help, plain icons are fine.
| If you are making a very complex application and there are 50
| options, text is absolutely necessary. The alternative is me
| hovering over each icon and waiting for the tooltip hover text,
| status line help or (worst of all) using the context-help button.
|
| It also depends on how common and recognizable your icons and
| functions are. If you are doing new/open/save/settings/help, and
| the icons are resembling the usual standards everyone is used to,
| fine. If you either draw your own icons, or your functions are
| frobnicate/somnambulate/fart/discombombulate/deflagrate, then
| plain icons are insufficient, you need text labels as well.
| begueradj wrote:
| You don't need to translate a "delete" icon in a multilingue
| website.
| IshKebab wrote:
| You don't need to translate the word "Delete" either. Automatic
| translation can trivially deal with that.
|
| More broadly, unless your pictograms are _very_ clear (e.g.
| IKEA) then it 's still better to add text because then at least
| the information is there.
|
| I can't count the number of instruction manuals I've read where
| the authors have clearly thought they were IKEA and could avoid
| using text, only to make incomprehensible diagrams that confuse
| more than help. If only they had used text in any language! I
| don't care if it's Swahili, at least then I would be able to
| translate it.
| nloomans wrote:
| Only if you don't care about accessibility. You still want
| labels for screenreaders and other assistive technologies.
| pavlov wrote:
| UI research since the 1990s has shown this to be the case. Labels
| provide much better recognition than icons alone.
|
| Paradoxically we now have much better display technology that
| allows rendering sharp and legible text in UIs, but design
| fashion and localization laziness dictate that most UI designers
| have instead been trying to eliminate all text.
|
| Even when usability guidelines exist, they are ignored because UI
| design has become a vibes-based profession. For example, Apple's
| iOS human interface guidelines unequivocally say that tab bars
| should include both icons and text labels. It's been a long time
| since I met a designer who has actually read these guidelines.
| They seem to think anything Apple publishes is some kind of
| checklist for engineers, and can't be meant to inhibit their
| Figma freedoms.
| hiAndrewQuinn wrote:
| I like text labels because they let me Ctrl-F for the thing I'm
| actually looking for in a cluttered interface. I can't Ctrl-F an
| icon.
| levmiseri wrote:
| To add to this. UX Myth -- Icons enhance usability:
| https://uxmyths.com/post/715009009/myth-icons-enhance-usabil...
| globular-toast wrote:
| I'll take neither, thanks. The best user interface is a bunch of
| physical buttons/keys arranged in a board on my desk. A
| "graphical" UI seems to require similar brain engagement as, say,
| navigating the index of a book.
|
| Physical keys, on the other hand, engage a completely different
| part of the brain that is capable of "muscle memory". Ever seen
| someone knitting and watching TV at the same time? Or controlling
| a car while simultaneously watching other traffic and following
| road signs? It's the same thing. A keyboard allows you to express
| your intention to the computer without actually engaging the
| "thinking" part of your brain at all.
| md_rumpf wrote:
| My guess is a lot of these studies don't replicate as well in
| Europe vs. US.
|
| Road signs in the US are predominantly text: PED XING. ONE WAY.
| DO NOT PASS. Where the European equivalents are all pictograms.
| Europe needs to do it this way, because the countries are so
| small you'd expect German-speakers driving in France and vice-
| versa: French-only text signs would be criminal. Similarly, a
| French-speaker can navigate a German train station without
| understanding German writing.
|
| Europeans are actually much more attuned to deriving meaning from
| pictograms than their American counterparts.
| fsh wrote:
| As a European, I cannot make any sense of the low-contrast
| pictograms in "modern" software (VS Code, Obsidian, etc.).
| theandrewbailey wrote:
| French people don't do anything radically different on French
| roads and train stations than they do on German ones (and vice-
| versa for any pair of nationalities), but what one does in one
| app might be very different to another.
| kbrannigan wrote:
| What if the writings were English only would that be a sin?
|
| I think English speakers have this innate expectation for the
| world adapt to them.
|
| They Speak their native language and expect signage, menus,
| conversations, to be in English.
|
| But if a person attempts to only speaks their own non-english
| native language, that's being rude.
| mft_ wrote:
| I totally get your underlying point, but sometimes it comes
| down to pragmatism.
|
| If one's goal is for the world to work as efficiently and
| with as little friction as possible, then things like a
| single common language make a lot of sense.
|
| For example, in most spheres of international business
| English is the common language. It's not a value judgement
| about the importance of English or the inferiority of other
| languages - it's just pragmatism as English is the commonest
| _shared_ language that most people understand, whether as a
| first or second+ language.
| gary_0 wrote:
| It is standard practice to translate software into many
| languages, whereas road signs cannot be.
| eadmund wrote:
| I came here to post about European washing machines, which are
| labelled with inscrutable _pictograms_ instead of words. My own
| experience is that those pictograms are far less easily
| understood than words in a foreign language would be, at least
| to an English speaker who is familiar with cognates from the
| Germanic and Romance languages.
| moffkalast wrote:
| On smartphones it makes sense to have just icons, since screen
| real estate is extremely limited.
|
| But there's no reason not to have both icons and text on
| desktop/tablets. I don't get what people see in GNOME and W10+
| style taskbars with grouped icons where you can't tell shit about
| fuck about what's actually open. Labelled non-grouped tabs reduce
| the amount of steps and clicks needed to switch and it's not like
| we're running out of screen space to display them on 16:9
| monitors.
| andybak wrote:
| I wonder how many people with strong opinions commenting here
| have read any of the classic books and blog posts on this topic?
|
| There seems to be a lot rehashing of debates that I always
| regarded as mostly settled.
| macintux wrote:
| Every discussion here is mostly by people who haven't read the
| literature, but that's true of any online forum.
| codr7 wrote:
| Big issue in mobile apps from my experience, guessing which blob
| of pixels means what gets old fast.
|
| Even the icons aren't very good most of the time, seemingly
| aiming for anything but simplifying use.
|
| They do make a nice square target to tap compared to text, but
| the same effect could be achieved by using the first letter
| capitalized as icon or something similar.
|
| I sometimes dream of Lisp machine/SmallTalk like mobile
| interfaces, is there anything going on in that area?
| jll29 wrote:
| It's neither about icons nor strictly speaking "text" labels, but
| I'm bothered by the spread of menus titled "+" or "..."; they are
| a new thing, and they make stuff harder to find.
|
| In the 1990s, "..." was reserved as part of text labels, and it
| had a clear meaning: "save" without "..." saved a file
| immediately, whereas "save as..." with the three dots indicated
| there was another dialog coming once clicked (to determine the
| file name). The new uses of "..." (alone) don't mean much, as far
| as I can see.
| cassepipe wrote:
| One of the griped I had about Firefox latest UI design was
| actually that they removed text labels from their menu, among
| others
|
| Using this now, this embraces the new design but fixes poor UI
| decisions. It even has a one liner install/update script !:
|
| https://github.com/black7375/Firefox-UI-Fix
| WalterBright wrote:
| I've been saying this since the Mac was introduced!
|
| There's a reason why every pictographic language evolved into a
| phonetic language.
|
| > a trash can icon reliably communicates "delete,"
|
| Only because Jobs popularized it. Manny iphone apps use "delete".
|
| The trouble with pictures is they can indicate objects (though
| not very reliably), they cannot indicate verbs reliably at all.
| singpolyma3 wrote:
| If you don't know what a button does, tap it and find out.
| AlienRobot wrote:
| This is the correct opinion have. The text "Del" conveys the same
| meaning as a trash can and uses less space.
|
| >The more icons we have to scan over, the more brain power we put
| toward making sense of them rather than using the tools they
| represent
|
| While we're talking about brains, it's my personal theory that
| the monochrome icons like those in the screenshots are the bane
| of all GUI design. Humans were born with the ability to see all
| colors (that humans can see). Limiting icons to a single color
| effectively restricts the ability of the icon to convey visual
| information. If each icon was a distinctive color, we wouldn't
| even need to look at their shape.
| card_zero wrote:
| I just updated my Vivaldi browser, and here is the new icon for
| "home page":
|
| https://ibb.co/0RXBmf46
|
| It's a flabby pentagon with slightly rounded corners and a short
| horizontal line in the lower middle. I guess the old familiar
| house shape wasn't modern enough? So is this what modern houses
| look like, wider at the top than the bottom? The line,
| presumably, represents a door, in a stylish, minimal, modern way.
| oliviergg wrote:
| As a developer, I'm so used to fuzzy search command (ctrl+P) that
| I would like to see this in every complex application. Just some
| important icon with label the rest in the search bar.
| eirikbakke wrote:
| This problem was traditionally solved with menu bars (File, Edit,
| View etc.).
|
| Every action in the app would be listed somewhere in the menu,
| spelled out in text and with the icon and keyboard shortcut
| listed next to it if available.
|
| That user interface tradition was eventually lost, first with
| ribbons, and then with web apps.
___________________________________________________________________
(page generated 2025-02-23 23:01 UTC)