[HN Gopher] Icons in Menus Everywhere - Send Help
___________________________________________________________________
Icons in Menus Everywhere - Send Help
Author : ArmageddonIt
Score : 787 points
Date : 2025-12-08 19:44 UTC (1 days ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| arcbyte wrote:
| This a really interesting and persuasive read for me. I've been
| thinking about this topic as part of brainstorming a simple
| design system and I had come to the conclusion that the
| inconsistency of not having icons for every menu item was a big
| annoyance. After seeing how descriptive the icons are in older
| menu examples compared to the abstract blobs in newer menus, I
| have to admit I might be wrong. At the very least, ensuring that
| the icons themselves are as illustrative as possible about the
| intended outcome of its selection is necessary.
|
| It also makes me think about the classic Save icon: the floppy
| disk. That was certainly descriptive at its origination, but is
| it still so? In the age of natively storing documents in the
| cloud or copying to a USB drive, it seems like we might want more
| than one save menu or an appropriate icon for where the file
| resides on the single Save menu item. Microsoft Office has the
| Autosave toggle switch that serves some of this purpose, but it
| could definitely be better.
|
| I also think about the Zune UI where sometimes a menu consisted
| only of the icons. How do you enable unique menu designs like
| Zune without icons for everything?
| DonHopkins wrote:
| Check out how Blender's entire UI (menus, buttons, hotkeys, pie
| menus, toolbar tools, context menus, etc) is built on a single
| abstraction: operators -- universal command objects that can be
| used in many contexts.
|
| Every operator has:
|
| Identifier: mesh.extrude_region_move
|
| Label: human-readable string, like "Extrude Region"
|
| Description: tooltip text, like "Extrude selected vertices,
| edges or faces along their normals"
|
| Icon: optional enum from Blender's built-in icon set, like ICON
| = 'MESH_EXTRUDE_REGION'
|
| RNA properties: parameters / flags like direction, axis,
| booleans
|
| Poll function: whether it is available in current context, like
| only enabled when a mesh is in edit mode
|
| Execution logic: the actual command code
|
| Blender's designers generally follow these principles:
|
| Operators always have labels. Icons are optional. Most menu
| items use no icon by default. Only well-established visual
| operations (cursor, transform tools, viewport shading modes,
| etc.) get icons.
|
| Unlike macOS Tahoe's vague "everything gets an icon" ideology,
| Blender uses icons when they convey meaning, but not when
| they're decorative filler.
| yuye wrote:
| >It also makes me think about the classic Save icon: the floppy
| disk. That was certainly descriptive at its origination, but is
| it still so? In the age of natively storing documents in the
| cloud or copying to a USB drive, it seems like we might want
| more than one save menu or an appropriate icon for where the
| file resides on the single Save menu item.
|
| It originated from when floppy disks were still widely used,
| yes.
|
| Nowadays, people associate the icon of a floppy disk more with
| "saving locally" than the floppy itself. Changing it will just
| cause confusion.
|
| Another example is how the icon for Database was chosen to
| resemble an old-timey stack of hard drive platters. Everyone
| knows what it means, even if your database isn't stored on
| HDDs, so there is no need to change it.
|
| Even the telephone icon on your phone resembles an old-
| fashioned telephone horn, despite these getting less and less
| common.
| abustamam wrote:
| I think local save is usually the floppy and cloud save is
| usually a cloud icon . The semantics change a bit when the app
| in question is a cloud app though.
| concinds wrote:
| > It also makes me think about the classic Save icon: the
| floppy disk. That was certainly descriptive at its origination,
| but is it still so?
|
| This is a pet peeve of mine and it feels like some cargo cult
| within the UI design "field". There's nothing wrong with the
| floppy icon. It's perfectly fine. Even if someone doesn't get
| it, the consistency of its use across apps is enough for its
| meaning to be clear, which is what really matters.
| arcbyte wrote:
| Before I read the blog post I would have agreed with you.
| It's pervasive, well understood, and the meaning is clear
| which you point out is what really matters.
|
| But after reading the article I find myself asking if that's
| really true? I'm doubting it now. Certainly, the Floppy disk
| icon is clear to computer users who experienced at least a
| few years of the 90's or early 2000's. That's becoming less
| and less a percentage of computer users. For most users, that
| floppy disk has receded into being just a nonrepresentative
| shape associated to save.
|
| I think it's that the blog post convinced me to reject
| nonrepresentative shapes as icons. You can't look at the
| extremely illustrative menu filled with icons that clearly
| describe window management actions or text formatting actions
| - where the icon itself conveys clearly, if abstractly,
| exactly how reality will look after you take the action - and
| tell me that a menu filled with random nonillustrative shapes
| has even a similar experience. I can't shake the idea that
| the menu icon needs to be more than just a logo or branding -
| it needs to be self-explaining.
|
| The floppy disk did exactly the above when floppy disks were
| where the data was actually saved. But in 2025, we have to
| accept that it no longer illustrates anything. Today its just
| a nonrepresentative shape.
| concinds wrote:
| The human brain works with nonrepresentative shapes
| perfectly fine, otherwise companies wouldn't emphasize
| logos so much, often without even their actual name next to
| the logo.
|
| Again, you don't even need to know what a floppy is or that
| it exists; its consistency and omnipresence, alongside the
| "Save" label most of the time, is enough to create meaning,
| such that most people will recognize it without the label.
| heavyset_go wrote:
| > _It also makes me think about the classic Save icon: the
| floppy disk. That was certainly descriptive at its origination,
| but is it still so?_
|
| It's a symbol, it could be a 7-pointed star and people would
| associate it with Save.
|
| Even when you knew what a floppy disk was, why would you push
| that button? You haven't seen a floppy in years, don't have a
| floppy drive and don't want to create a floppy disk.
| Someone wrote:
| FWIW: Apple's SF Symbols font doesn't have an image of a floppy
| disk, nor does it have an icon meaning "save".
| dexwiz wrote:
| I always thought menus had icons so they could be matched to the
| same functionality on the toolbar. If a menu lacks an icon, then
| it's probably not on the toolbar. This falls apart when there is
| no toolbar. But I have definitely found an action in the menu,
| looked at the icon, and matched it to a a button elsewhere.
| IcyWindows wrote:
| I believe some programs used to let you even drag menu items to
| the toolbar.
| garciansmith wrote:
| Many KDE apps (Dolphin, Kate, Okular, etc.) let you configure
| their tool bars (or get rid of them entirely) and set them to
| show just icons, text, or both (with the text to the side or
| below). It's the kind of thing most people won't bother with,
| but for frequently used applications it's nice to be able to
| customize it to suit your needs. It's done via a config
| option though, not by dragging menu items to the toolbar
| (which strikes me as something you could initiate by
| mistake).
| DaiPlusPlus wrote:
| MS Office's fully customisable toolbars, complete with built-
| in icon editor.
|
| ...ripped out when the Office Ribbon was introduced in 2007;
| the now-limited customisation is now considered an
| improvement because of the IT support problems caused by
| users messing up their own toolbars.
|
| I mean, yes; but that's what Group Policy is for! And the
| removal of the icon editor is just being _downright mean_ to
| bored school kids.
| HeavyStorm wrote:
| You made me feel old by saying "I believe".
| linguae wrote:
| I believe Microsoft Office 97 for Windows was the first time I
| saw icons next to menu items. Office 97 had highly customizable
| menus and toolbars. Each menu item and toolbar item could be
| thought of as an action with an icon and a label, and that
| action could be placed in either a menu or a toolbar. Not every
| menu item had an icon associated with it. Additionally, each
| icon was colored and was clearly distinct.
| jameshart wrote:
| This is definitely where I would this pattern - MS Office
| 97's customizable toolbars necessitated this model where
| every single thing you could do in the application had an
| icon.
|
| It then got copied into Visual Studio, where making all of
| the thousands of things you could do and put into custom
| toolbars or menus have visually meaningful icons was clearly
| an impossible task, but it didn't stop Microsoft trying.
|
| I assume Adobe, with their toolbar-centric application suite,
| participated in the same UI cycle.
|
| By the time of Office 2007 Microsoft were backing off the
| completely customizable toolbar model with their new 'Ribbon'
| model, which was icon-heavy, but much more deliberately so.
| VBprogrammer wrote:
| I still regard Office '97 as the best UI it ever had. I
| spent a lot of time inside it, including a couple of years
| at a bank reconciling corporate actions before I got my
| first programming job. The ribbon version was awful in
| comparison.
| emeril wrote:
| 2003 was the best/final iteration of it - I still miss
| old excel
|
| new excel is just garbage instead in virtually every way
| chungy wrote:
| Office 97 went pretty overboard on customization. It could be
| awesome if you know what you're doing, but I saw countless
| examples of where somebody had accidentally changed something
| and got stuck. Deleted the file menu? tough luck!
| DeathRay2K wrote:
| I changed the UX in my mobile app from text only to icon + text
| by default in menus, buttons, and links.
|
| There are several reasons I made the switch, but the primary
| reason is that it makes it easier to build a kind of muscle
| memory for navigating and performing particular actions. In
| essence, the text is there for new users and the icons are there
| for experienced users.
| TrianguloY wrote:
| This.
|
| I like icons (and colors, but those are still mostly missing)
| to quickly find a frequent action. If the menu is always the
| same you can learn the position, but with dynamic entries it's
| way more difficult.
| nmilo wrote:
| +1. I love icons, just be consistent. That MacOS example is
| egregious
| bromuro wrote:
| In my language "egregious" means "very good". In English
| means both very good and very bad. What's your meaning here?
| Just to be consistent :)
| 1986 wrote:
| In practice, "egregious" in English _never_ means very good
| itishappy wrote:
| It used to!
| DonHopkins wrote:
| Literally. Oh wait, I mean not literally?
| macintux wrote:
| Arguably.
| DonHopkins wrote:
| I could care less!
|
| https://www.youtube.com/watch?v=8Gv0H-vPoDc
|
| https://news.ycombinator.com/item?id=22820457
|
| https://web.archive.org/web/20150406073147/https://jarret
| the...
| antonvs wrote:
| https://slate.com/human-interest/2014/03/why-i-could-
| care-le...
|
| I tend to assume that anyone who objects to "I could care
| less" has never lived in the New York City area. See the
| mention of Yiddish in the above link. But for some who
| object to it, that's the issue: it's a shibboleth of a
| culture they're not part of.
| DonHopkins wrote:
| If you're a fan of de-emphasizing your agency with the
| passive voice, then you can say "less could be cared for
| by me" or just "less could be cared for" if you totally
| want to totally avoid responsibility for not caring.
|
| I loved MrHeather's comment (who worked with Weird Al to
| animate Word Crimes):
|
| https://news.ycombinator.com/item?id=22823632
|
| MrHeather on April 9, 2020 | parent | next [-]
|
| When I first met with Al about this project, I was quick
| to point out that linguists would disagree with about a
| third of the "advice" he's giving out. His immediate
| reply was "WELL THEY'RE WRONG"--really loudly in the
| "Weird Al" character voice.
|
| In my mind the joke is that the song's narrator is a
| know-it-all character that shouldn't be taken entirely
| seriously. But on the other hand, a lot of educators have
| contacted me to tell me they use the song as a learning
| tool.
| antonvs wrote:
| As an immigrant to the US, I'm a fan of recognizing that
| there are cultures different from my own. But sometimes,
| when encountering unthinking US bigotry, it can be
| difficult to keep that in mind.
|
| Have you ever traveled outside the US? I don't just mean
| to CS conferences, I mean really traveling.
| antonvs wrote:
| Addendum: "I could care less" is a perfectly natural and
| recognizable idiom in some circles. To someone
| unfamiliar, it can seem strange, but that's true of many
| idioms.
|
| The objections to it, though, fall broadly into two
| categories: ignorance, and bigotry. The former becomes
| the latter when someone refuses to recognize their
| ignorance, and doubles down on it.
| spudlyo wrote:
| I think it used to just mean "singular", from the Latin
| grex, gregis meaning herd, and e/ex meaning "out of". It
| could mean singularly bad or singularly good I guess in
| English, but in Latin I think it had more of a
| connotation of exceptional, extraordinary, eminent.
| yakshaving_jgt wrote:
| This hasn't been my experience.
| concinds wrote:
| Other built-in Tahoe apps have more consistent indentations
| and far more icons. The Safari team (not the WebKit team, the
| people building the app wrapping it) just phoned it in with
| the menu icons. They also somehow disabled the Tahoe window
| opening animation.
| lavataco wrote:
| Yes, just consistently line them up and it would be fine.
| There's plenty of UX research saying icon+label improves
| recognition and task speed. NN Group is a good resource for
| this.
| maxloh wrote:
| Exactly. Reading a line of text is a lot slower than
| recognizing an icon. Those icons are for power users who are
| really familiar with the app.
| petepete wrote:
| This is true when you know what you're looking for, the icons
| are distinct and you have good eyesight.
| marginalia_nu wrote:
| It's kind of a shame how we keep trying to make icons look
| uniform, either in color, or in shape.
|
| Like I open the app drawer on my Android phone and there are
| like 16 different icons, all different Google apps, all are
| round and various abstract configurations of the same exact
| four colors.
|
| Feels like we're falling into the same trap that Gothic
| handwriting did with the minims. Yeah it looks very pretty but
| it's almost completely illegible since we've taken away all the
| things that help set icons apart.
| https://en.wikipedia.org/wiki/Minim_(palaeography)#/media/Fi...
| mook wrote:
| Yeah, I learned that using Netscape 6 with a row of blue
| balls for icons; going from the older Mozilla builds with the
| Netscape 4-style icons it was a definite downgrade. Pheonix
| had a row of orange balls; they later switched to IE-style
| icons with distinct shapes, which was better.
|
| The recent Android releases where everything is a squircle
| really sucks too.
| lavataco wrote:
| Google has been universally panned for using their logos as
| app icons. I think most people in this thread are talking
| about UI vs app icons (essentially avatars for apps at this
| point).
| marginalia_nu wrote:
| Visually uniformity is a broad trend that affects both
| areas. The monochrome line-art UI icons that are used
| everywhere are every bit as bad as Google's app icons.
|
| Here are some icons I screenshotted off a website. I
| challenge you to tell me what they mean
|
| http://www.marginalia.nu/junk/icons.png
|
| http://www.marginalia.nu/junk/icons2.png
|
| Hint: ,,@sirdr@tu@ yrt,, si dn ot buituiod worra @Yt pua
| ,,s@sirdr@tu@,, si @qoSb @Y[?]
| itishappy wrote:
| I feel like shortcuts are often enough. They function quite
| like this: a symbolic language that allows you to build up an
| intuition. They use icons that you already know, and instead of
| being bespoke per designer (how many different save icons are
| there?) they work across your entire OS. The muscle memory you
| build, instead of being bespoke per menu (and dynamic in time),
| allows you to skip the menu entirely!
| PlunderBunny wrote:
| Two extensions/patches I'd like to see for macOS:
|
| 1. Remove all icons from menus.
|
| 2. Make mouse-over do nothing - I should be able to move the
| mouse anywhere on the screen, and nothing should change
| colour/pop out etc.
| oidar wrote:
| I think the key in apples guidelines is the word arbitrary. A
| lot/ most of the icons in apples menus are purpose made for the
| menu item - so it's not as big of an issue.
| nvader wrote:
| I think this is an example of the emojification of communication.
| I suspect that trend is being sustained, at least, by LLMs who
| are prone to abusing vapid emojis everywhere.
|
| I think that to a certain superficial level of analysis, a
| matched set of icons looks "complete" and indeed impressive.
| Designers and implementers of the interface can fool themselves
| through customary use that they're creating a language of
| ideograms. Their users, who interact with their product only a
| few hours per week, only perceive visual noise and clutter.
| duolanda wrote:
| This article made me realize why I always struggle to get
| through long documents generated by LLMs. The overuse of emojis
| doesn't make it easier for me to find useful information,
| instead, it just adds a lot of noise.
| gedy wrote:
| I always took it as a plus for soft internationalization, e.g. we
| may not have translated or localized to the current user
| language, but icons area decent generic hint.
| trinix912 wrote:
| It's also very useful if you're dealing with both English and
| local language versions of the same software, as translations
| aren't always 1:1, but icons generally are.
| etothet wrote:
| From the article: "What I find really interesting about this
| change on Apple's part is how it seemingly goes against their own
| previous human interface guidelines..."
|
| Welcome to Apple of the last decade. As an avid user of many
| Apple products, this has been extremely frustrating to
| experience. Hopefully Alan Dye's departure will see at least
| partial return to obeying Apple's own HIG.
| DaiPlusPlus wrote:
| I think the problem might be generational... the only people
| who know - or care - about the HIG are older millennials
| hurturue wrote:
| HIGs change. what made sense for people who first used
| computers in their 30s might not make sense for people which
| used them since 7
| layer8 wrote:
| I think you're underestimating how many people grew up with
| GUIs 30-40 years ago.
| luigi23 wrote:
| yearning for old apple and order, current times and genz are
| more chaotic. not sure if it's generational, old apple was
| obsessed about design, now HIG is mostly optional. they now
| even use hamburger on websites which was a big no in the
| past.
| 1718627440 wrote:
| Yes, the newer generation is used to computers being an
| inconsistent mess and slow. Only the the technically
| interested people know that it doesn't need to be this way.
| (And thus don't feed up with this and use Linux or *BSD :-)
| ).
| Kwpolska wrote:
| Icons in menus do follow the 2025 HIG:
| https://developer.apple.com/design/human-interface-guideline...
|
| The author is criticising 2025 macOS for not following the 2005
| HIG. This is not reasonable criticism, the HIG are not set in
| stone and they have changed many times in the past 20 years.
| wpm wrote:
| And if you go do the work of tracking down newer HIG
| versions, they say the exact same thing.
|
| 2014:
|
| "Avoid displaying an icon for every menu item. If you include
| icons in your menus, include them only for menu items for
| which they add significant value. A menu that includes too
| many icons (or poorly designed ones) can appear cluttered and
| be hard to read."
|
| Newer versions seem to have escaped being properly archived
| anywhere, so Apple can gaslight us all into believing the HIG
| has never changed, that we have always been at war with East
| Asia, that giving a bad icon to every single menu icon has
| always been good, and that rule was never arbitrarily changed
| at the whims of a cardboard box designer and his liquid
| glarse aesthetics.
|
| It works out though because it does give me ammo when people
| use these guidelines to thoughtlessly defend poor design as
| if they are axiomatic rules. For 20+ years having lots of
| icons in a menu was bad...but now...it's good! Why? I dunno!
| It just is!
| notpushkin wrote:
| 2020 was linked in another thread here: https://web.archive
| .org/web/20201027235952/https://developer...
| omgtehlion wrote:
| The link you attached still contains these:
|
| > Don't display an icon if you can't find one that clearly
| represents the menu item
|
| > Not all menu items need an icon. Be careful when adding
| icons for custom menu items to avoid confusion with other
| existing actions, and don't add icons just for the sake of
| ornamentation.
|
| > Instead of adding individual icons for each action, or
| reusing the same icon for all of them, establish a common
| theme with the symbol for the first item and rely on the menu
| item text to keep the remaining items distinct
| sixtyj wrote:
| Have you seen any specialized software, e.g. AutoCAD by Autodesk?
|
| In the top ribbon menu there are icons only. And not any familiar
| ones at all.
|
| Icons, text representations of the action behind the menu
| items...
|
| It's a designer hell in which you have no chance to please
| everyone. Like someone using a vim editor for 20 years... some
| people are using icons, other want text and the third group wants
| combination of both.
| DrewADesign wrote:
| Autocad (and most other professional design software) is like
| that because the vast majority of people that learn how to use
| it will do so whether they like it or not, because it's a
| professional or school requirement. It _sucks_ for beginners
| but if you're using the software day in and day out for a few
| weeks, you'll learn them, and then pick up the CLI commands for
| your most frequently used commands. After that, you'd be loath
| to give to give up the screen real estate for text labels.
|
| These are technical programs for technical work performed by
| trained technical people. They have different workflows, goals,
| mindsets and ways of reasoning about things than developers do,
| and that's fine.
|
| A lot of shade gets thrown at nontechnical software users for
| not grasping things developers find intuitive. Yet, when many
| of those same people throwing that shade encounter a technical
| environment they can't grasp immediately, it's _the interface
| 's fault._
| eviks wrote:
| Easy customisation / sharing is the gate to heavens out of that
| hell, but the lid on the designer' pot is too thick so the
| don't even notice
| anotheryou wrote:
| I love it for quickly finding items.
| fireflash38 wrote:
| When only _some_ things have icons, it 's almost like a flag that
| these things are more special/useful/used. I think that is by far
| more useful than everything having an icon that you have to think
| about (or see the text next to it) to understand
| marginalia_nu wrote:
| It's pretty common that some things are more likely to be the
| things you are looking for than others. Drawing eyes to such
| things is helpful, whereas putting abstract monochrome line-art
| icons everywhere is not really helping anyone find anything.
|
| Some things are only occasionally what you are looking for, and
| making them require a full scan of every menu entry is fine.
| dragonwriter wrote:
| I've seen some apps that have icons on menu items when those
| icons are used for the same functions in other UI elements
| (shortcut bars, etc.) that don't require digging into the
| menus, functioning as kind of a reminder that "you can do this
| elsewhere where you see this symbol". It is kind of like an
| inverse tooltip (where a tooltip you get by checking the icon
| and discovering the action description, this you get to by
| going to the action in the menu and discovering the icon.)
|
| I think this is a useful pattern, but I'm not convinced that
| having specific _distinct_ icons for menu items to highlight
| them as important is useful. Presentation order and /or simply
| a _consistent_ difference in presentation for the highlighted
| items makes more sense.
| iamcalledrob wrote:
| This has been my take too.
|
| The thoughtful inclusion and exclusion of icons in menu items
| builds hierarchy. When every item is special, none are. You've
| lost the ability to differentiate.
|
| Icons everywhere is a hallmark to me of "webby" UI.
| remyp wrote:
| Over the years I've noticed something unusual about myself: I
| don't even see these icons. My brain goes directly to the text.
| This applies to all visual material, but is most evident in
| printed advertising.
|
| Apparently other people notice the hot girl and the puppy and the
| fried chicken sandwich first. Meanwhile, I've already read all
| the fine print.
|
| No idea why I'm like this.
| lloeki wrote:
| I _used_ to notice and somewhat - but not solely - rely on
| icons, especially nice designed sets.
|
| It seems though that a combination of samey-sameness
| (greyscale, shape, etc...) and the constant bombarding of
| attention-grabbing imagery (emoji, gif, ads...) has
| desensitised me from visual cues and I zero in on text instead
| now.
| remyp wrote:
| I think you're right. Desensitization has to be a big factor.
|
| I'm certain that I just _like_ text, but I've also noticed
| recently that I miss very large attention-grabbing print (eg.
| "SALE" or "FREE WIDGETS JUST GIVE US YOUR EMAIL ADDRESS") as
| well. I think my brain has started flagging it as misleading
| noise along with the rest of the detritus.
| hinkley wrote:
| There was a comic artist I used to follow when I was doing more
| front end work, who would blog about his craft. One of the things
| he said that really hit me was talking about silhouettes. The
| visual noise in certain eras of comics make them very
| unapproachable. If you repainted your strip by flood filling
| everything with black, would people have any clue what's going
| on?
|
| One of the things I'm seeing in some of these examples is icons
| with the same silhouette doing nothing or less than nothing for
| scannability. This is the same problem AWS has. Their dashboard
| is just noise, because the icons are neither visually distinct
| nor descriptive of the project.
|
| I've also seen some of this same problem with card and board
| games as well. You can see that some designers care about
| accessibility. This type has both a distinct color AND shape so
| colorblind people can see it, all the icons are big enough that
| people can make them out sitting upside down in front of the
| person across the table from them, even if they're over 40.
|
| His first example, Google Sheets, does well by this metric IMO,
| but the next few are kinda bad.
| layer8 wrote:
| The trend towards monochrome, unhinted (blurry) icons certainly
| doesn't help.
| hinkley wrote:
| Yeah and the Amazon color schemes aren't exactly amazing for
| contrast either.
| agos wrote:
| ironically the new Amazon visual identity has plenty of
| contrast
| watersb wrote:
| macOS Tahoe has declared war on app icons with distinctive
| shapes.
|
| No silhouettes. If your icon isn't a squircle, it will be
| shrunk to fit inside a default shape. The penalty box.
|
| https://lapcatsoftware.com/articles/2025/6/2.html
|
| The loss of icon silhouettes is a big step down in usability.
| Erases decades of design guidelines.
|
| https://pxlnv.com/blog/roundrect-dictator/
|
| Frankly it's senseless.
|
| https://www.flarup.email/p/through-the-liquid-glass
|
| Insane but still working legacy workaround:
|
| https://simonbs.dev/posts/how-to-bring-back-oddly-shaped-app...
|
| ...
|
| macOS isn't fun anymore.
| deelowe wrote:
| Never thought I'd say this, but I kinda miss Jobs.
| antonvs wrote:
| > macOS isn't fun anymore.
|
| It was always closed source. That hasn't changed. That should
| be a hint.
| nntwozz wrote:
| First we lost the pinstripes, then brushed aluminium; then we
| lost colors in the sidebar icons. Then they made everything
| flat.
|
| Finally we lost the background and legibility.
|
| Pepe prayge now than Alan is out that things will improve.
|
| We need to get back to Dieter Rams 10 principles for good
| design.
| lavataco wrote:
| Surprised it took me this far down to see him mentioned.
| anal_reactor wrote:
| MacOS was never fun. I've been using MacOS at work for five
| years and it's never been fun nor intuitive. I always
| explained this to myself "that's because I grew up with
| Windows" but three months ago I switched to KDE on my private
| machine and it's miles ahead of MacOS. Just a week ago I got
| a new company Macbook and the UX is even clunkier than
| before. Shit just doesn't work.
| trinix912 wrote:
| I feel like the older versions had much more of a
| personality. OS 8-9, OS X (10.0-10.9). Once they (and
| Windows) started with flat design (which was over 10 years
| ago!) everything just converged and now all UIs look very
| similar to each other. MacOS Big Sur and Tahoe look quite
| similar to various 3rd party KDE and Gnome skins that
| predate them.
| hinkley wrote:
| Responding to myself to add: If AWS is bad at this, Atlassian
| is worse. I cannot scan the tab bar in my browser and find what
| tab I was in three minutes ago because they are all too
| uniform. They're more concerned that I know that a tab is an
| Atlassian Tab than whether I can get my work done.
| fainpul wrote:
| > You can see that some designers care about accessibility.
| This type has both a distinct color AND shape so colorblind
| people can see it [...]
|
| This is something visual artists usually learn and are good at
| and it's not primarily for accessibility, it's simply good
| design. Accessibility improves as a side effect.
| sznio wrote:
| > One of the things I'm seeing in some of these examples is
| icons with the same silhouette doing nothing or less than
| nothing for scannability.
|
| I have this issue with Google apps on my phone. Once they
| decided that all icons should have the same four blurred colors
| with low contrast, you just can't tell which app you're looking
| at without the text label below. And I'm not visually impaired.
| socalgal2 wrote:
| Not sure I agree. It's much easier for me to find the link icon
| than "Insert Link" in the Google Docs example. It's seem pretty
| close to a standard icon so, for me at least, it's helpful to
| find it. Same wit some of the others like increase indent,
| decrease indent, left, right, center justification, and lots of
| others.
|
| I can also be helpful for non-English (or non-language of your
| choice) when you haven't had time to localize or don't have
| perfect localization. Let's assume the user has Japanese as their
| second language. It's much easier to find the option you want
| with icons than without
| cs02rm0 wrote:
| With apologies to our American friends, Jeremy Clarkson had a
| take on this:
|
| https://www.youtube.com/watch?v=z7kXUbwngB4
|
| Somewhere in there, I think he does have a point.
| PunchyHamster wrote:
| 100% disagree. They make finding a group of commands very quickly
| and it's not like horizontal space in menu is at the premium
| layer8 wrote:
| Maybe you misunderstood the author. They wrote: ' _It's not
| that I think menu items should never have icons. I think they
| can be incredibly useful. It's more that I don't like the idea
| of "give each menu item an icon" being the default approach._ '
|
| The point is, if _every_ item in a long menu has an icon, then
| they typically can't all be very distinguishable and
| recognizable, and blur together visually. It creates more
| visual noise, and less structure, than if only _some_ items had
| an icon.
|
| As for finding groups quickly, for example it doesn't make
| sense give all of "Save", "Save as...", "Save all" an icon, but
| giving the first one an icon helps to recognize the "Save"
| group of operations.
| mttjj wrote:
| But isn't the second half of the article the author pointing
| out a bunch of menu examples from macOS Tahoe where some
| items have icons and others don't and still coming to the
| conclusion that it's confusing? How is that not a
| contradiction of the prior declaration?
| layer8 wrote:
| Yeah, that's a bit inconsistent. I think they are
| criticizing that it appears to be random which menu items
| have icons assigned, instead of (for example) giving all
| important or frequently used items an icon, or in some way
| that creates visual structure in the menu. Personally, what
| I find the most disconcerting in those examples is that the
| menu items aren't consistently inset.
|
| Here is what I would think is a fairly good use of icons:
| https://learn.microsoft.com/en-
| us/windows/win32/uxguide/imag... The icons are positioned
| such that they introduce groups of menu items, and they
| create a visual structure that one learns to recognize with
| repeated use.
| 1718627440 wrote:
| Aren't the icons for the different save actions typically
| different? The save as typically has some idea of editing,
| like a pencil or an editing box, save all has multiple save
| icons behind each other.
|
| First thing I found:
| https://raw.githubusercontent.com/step-/gtk-stock-
| icons2/ref... See the last row.
| rprend wrote:
| I like it.
| markbao wrote:
| Just right-click any file in VSCode/Cursor to see how absolutely
| chaotic and tedious a long menu is without icons. Now imagine
| that Google Docs example without icons.
|
| It's much easier to recognize the funnel icon to make a filter,
| than to skim all that text.
| nikeee wrote:
| MS Office only has icons for the things that matter most. I
| think MS even had a UI guideline similar to the one that is
| cited from apple in TFA, but I cannot find it.
|
| The author doesn't ask for _no_ icons at all. So I really don't
| get this critique.
|
| Intentionally omitting some icons is a really powerful tool to
| draw attention to the actions that the user wants to do most of
| the time. I think that pattern went away in some places because
| it looks more consistent (that doesn't mean that usability is
| better) and some designers have some kind of OCD. At least
| that's what I have experienced in that exact case.
| wpm wrote:
| Perhaps the solution is to split the menu up instead of giving
| you a long, tedious menu that is unparseable without even more
| visual noise of icons.
| concinds wrote:
| UI designers should prioritize clarity and discoverability,
| not minimizing "tediousness", "length" or "noise". Menus
| group together related functions so you can find them, and
| splitting them would harm that. This kind of thinking has led
| to a lot of terrible UI designs.
| dominicrose wrote:
| I never noticed this but VS Code has almost no icons in menus.
| I'm fine with this though. We aren't supposed to use the menus
| all the time but rely on shortcuts or the command palette.
| klysm wrote:
| Don't agree with this take - it's quick to scan for the delete
| icon.
| pabs3 wrote:
| Probably this should be configurable, so people who want icons
| only or text only or both can make that choice. I like that KDE
| makes that possible.
| iask wrote:
| It has always been so since the dawn of modern desktops. I don't
| see how/why this is noise. This is like a developer at a standup
| insisting we can make the app faster adding some micro services,
| flashy UX, and a few months of work while the - end user will
| still enter 20 order changes in an 8 hour day because that's the
| environment.
|
| What will you gain from removing the icons?
| rustystump wrote:
| There are so many reasons to add icons as many have already
| stated here. One reason i didnt see is for multi lang help.
| Sometimes the icon is enough when i dont know the language used.
|
| However, i think what may be described here is that apps often
| deviate from a "universal" standard or reuse something to mean
| another. This defeats most of the benefits of using icons imo.
| raincole wrote:
| Wow. Icons in Menus are so useful that I absolutely didn't expect
| this article is to complain about them. They help me location the
| item I'm trying to click tremendously.
|
| Come on, could we get back to hating Cloudflare or something?
| AceJohnny2 wrote:
| Somewhat tangential:
|
| > _What I find really interesting about this change on Apple's
| part is how it seemingly goes against their own previous human
| interface guidelines (as pointed out to me by Peter Gassner)._
|
| > _They have an entire section in their_ 2005 _guidelines titled
| "Using Symbols in Menus"_
|
| 2005?? Guidelines evolve.
| itishappy wrote:
| They sure do, and just like biological evolution it is not a
| principled process. Sometimes evolution results in a worse
| outcome.
| rudedogg wrote:
| Here's from 2020:
| https://web.archive.org/web/20201027235952/https://developer...
|
| > Use text, not icons, for menu titles. Only menu bar extras
| use icons to represent menus. See Menu Bar Extras. It's also
| not acceptable to use a mixture of text and icons in menu
| titles.
|
| > Avoid using custom symbols in menus. People are familiar with
| the standard symbols. Using nonstandard symbols introduces
| visual clutter and could confuse the user.
|
| The notable thing here is how recent of a shift this is, and
| how longstanding the prior rule was. Navigating internet
| archive is slow/tedious, but I think the rule/guideline was
| explicitly called out in the guidelines up until a year or two
| ago. So it was probably the guideline for ~20 years on macOS
| and has just now been changed.
| ricardobeat wrote:
| Though styles and capabilities have changed, the same basic
| principles apply when using a mouse pointer and keyboard.
| 0manrho wrote:
| From an accessibility/localization stand point, icons+text
| everywhere seems to be ideal.
|
| Also, I disagree with:
|
| > This posture lends itself to a practice where designers have an
| attitude of "I need an icon to fill up this space"
|
| Sure, that does technically happen, but is in no way preventative
| or mutually exclusive with the follow on thought:
|
| > Does ... the cognitive load of parsing and understanding it,
| help or hurt how someone would use this menu system?
|
| That still happens, because if they mismatch an icon with text,
| that can result in far worse cognitive load/misunderstanding than
| if no icon was present at all. This becomes readily apparent in
| his follow on thought experiment where you show someone a menu
| with icons+text, but "censor" the text. Icons+text is also
| superior to [occasionally icons]+text in the same thought
| experiment. From my perspective, the author just argued against
| their own preference there.
|
| I'd argue that the thought process behind determining an
| appropriate icon is even more important and relevant when being
| consistent and enforcing icon+text everywhere, not diminished. It
| also has the broadest possible appeal (to the visual/graphically
| focused, to the literary focused, to those who either may not
| speak the language, and/or to those who are viewing the menu with
| a condensed/restrictive viewport that doesn't have room for the
| full text). Now, if the argument is predicated on "We aren't
| willing to pay a designer for this" then yeah, they have a point.
| Except they used Apple as an example so, doubt that was the
| premise.
| drdeadringer wrote:
| After my stroke 3 years ago, I find myself in a place meeting
| accessibility. So the icons are helpful. I cannot necessarily
| read the text.
| trollbridge wrote:
| What isn't so helpful though is the classic Google Sheets
| example where it has three different options (Delete Row,
| Delete Column, etc.) but all with an identical "trashcan"
| icon.
| TiredOfLife wrote:
| I immediately see that block as something to do with
| deleting stuff. If I don't need deleting is ski if i need i
| look closer
| petesergeant wrote:
| Genuinely curious if the item types in as shown in the
| article are that helpful though. They seem small, fiddly,
| hard to distinguish between, and not especially intuitive.
| breppp wrote:
| did not undergo a stroke, but I find myself often
| navigating menu by memorizing the location in the menu, I
| also use the icons for memorizing and then I can speed up
| by not reading.
|
| The first time I noticed that is the time I needed to
| operate a Finnish Windows machine and I could get it
| working pretty good by sheer memory
| troupo wrote:
| Then I'd argue that _not_ having icons on every item in
| the menu, and having groups /separators helps more than
| just having nearly indistinguishable icons everywhere
| breppp wrote:
| maybe, but over use of groups can also be confusing
|
| I find icons helpful to visually anchor things in the
| menu. It can be noisy when there are 5 identical "paste
| as" icons but generally I see it as a positive
| jasonvorhe wrote:
| Can you associate the symbols shown in the post with the text
| blurred out to their individual meaning?
| quamserena wrote:
| Yes, I agree. Maybe if you're a fast reader icons don't do
| much, but for people who are illiterate (20% of America) they
| figure out how to use tech by memorizing the icons and
| locations of buttons.
| sbarre wrote:
| Is this just your belief presented as fact, or do you have
| some data to back this up?
|
| (Not the literacy stat but the fact that illiterate people
| "figure out how to use tech by memorizing the icons and
| locations of buttons").
| Arch485 wrote:
| Well, if you're unable to read, you're not going to figure
| out what the buttons do by reading the textual labels :p
|
| Further, if you have difficulty reading, it's easier to
| parse the meaning of an abstract symbol, so you'd use that
| instead of a textual label when available. (I say this as
| someone who is a really slow reader. I use icons when I
| can)
| mercury4063 wrote:
| Watch a small child use a computer.
| inejge wrote:
| There's illiteracy, and there's functional illiteracy.
| They're not the same, and people often confuse the two. A
| literally illiterate person (ha!) wouldn't make headway with
| almost any realistic computer interface, icons or not.
|
| The 20% statistic is about people who have great trouble
| reading and comprehending simple sentences, not discerning
| individual words. It's tragic and debilitating, but such
| people could muddle through a simple interface with textual
| labels. A truly illiterate person couldn't.
| echelon wrote:
| I feel like icons subconsciously turn O(n*m) into O(log n).
|
| Without icons, you have to read many or most of the words.
|
| Without text labels, icons are difficult or even impossible to
| interpret.
|
| But with both icons and text, you have quick visual search and
| filtering that involves the whole brain.
| dmayle wrote:
| I used to manage a team working on the news feed at Facebook
| (main page).
|
| We did extensive experimentation, and later user studies to
| find out that there are roughly three classes of people:
|
| 1) Those that use interface items with text 2) Those that use
| interface items with icons 3) Those that use interface items
| with both text and icons.
|
| I forget details on the user research, but the mental model I
| walked away with this that these items increase "legibility"
| for people, and by leaving either off, you make that element
| harder to use.
|
| If you want an interface that is truly usable, you should
| strive to use both wherever possible, and ideally when not, try
| to save in ways that reduce the mental load less (e.g. grouping
| interface by theme, and cutting elements from only _some_ of
| the elements in that theme, to so that some of the extra
| "legibility" carries over from other elements in the group)
| tvbusy wrote:
| Sounds like me: 1. For new UI/tool, I depend on text to
| navigate. 2. Once I'm more familiar, I scan using icons first
| then text to confirm. 3. With enough time, I use just icons.
| 4. Why the ** do they keep moving it/changing the icons?
| virgil_disgr4ce wrote:
| Hooray, actual user research and data!! This is what I tell
| all my clients: "We can speculate all day long, but we don't
| have to. The users will tell us the correct answer in about 5
| minutes."
|
| It's amazing that even in a space like this, of ostensibly
| highly analytical folks, people still get caught up arguing
| over things that can be settled immediately with just a
| little evidence.
| stronglikedan wrote:
| > Those that use interface items with icons
|
| This is the bane of my existence since icons aren't
| standardized* and the vast majority of people suck at
| designing intuitive ones. (*there are ISO standard symbols
| but most designers are too "good" to use them)
| specialist wrote:
| Cite cliche about the only intuitive user interface is the
| nipple; everything else is learned.
|
| Having done my share of UI work, my value system
| transitioned from esthetics to practicalities. Such as "can
| you describe it?" Because siloed UI, independent of docs,
| training and tech supp, is awful.
|
| All validated by usability testing, natch. It's hard to
| maintain strong opinions UI after users shred your best
| efforts. Humilitating.
|
| Having said all that... If stock icons work (with target
| user base), I'm all for using them.
|
| PS I do have one strong opinion: less is more.
| lopis wrote:
| But also from an accessibility stand point, providing users
| with affordances to remove distractions (animations,
| transitions, and yes, icons) should be an option. But I
| disagree with the author that the default should be less icons.
| coldtea wrote:
| > _For example, the "Settings" menu item (third from the top) has
| an icon. But the other item in its grouping "Privacy Report" does
| not. I wonder why?_
|
| Isn't it obvious? Because compared to "Settings" it is a far less
| important infrequently used setting.
| LordGrey wrote:
| Hilarious: I looked at first two examples on the page, showing a
| menu and contextual menu, and I saw no problem. Icons? What
| icons?
|
| That's when I realized that, much like advertisements on a web
| page, my brain had utterly filtered them out.
| clearleaf wrote:
| My brain first started doing this with online ads as well.
|
| The habit has adapted and evolved very strongly with the amount
| of exercise it gets from UIs, textbooks, signage, and basically
| every other visual medium possible these days. It has actually
| become a problem with how often I overlook important
| information due to it being situated in a "nothing useful will
| ever be here" zone. But it's difficult to consciously control
| that instinct when it's correct 99.999% of the time.
| usaphp wrote:
| I actually like the icons from his example of Google Docs, it
| makes it easy for me to locate an action type I'm looking for
| (add/delete etc) without reading the labels, then once I narrowed
| it down - I can read the label to find the precise action I want.
| someguyiguess wrote:
| Same here. I view the text labels as a more detailed
| description I can read if I don't understand the icon at first
| glance. The icons help with decreasing time spent searching for
| the option I want. Not having to read every single menu item
| saves some number of milliseconds which adds up over time and
| reduces cognitive load.
| netsharc wrote:
| But someone got lazy and all the "Delete" or "Add" icons are
| identical... There's probably a ticket somewhere to "improve
| the icons" being ignored..
| crazygringo wrote:
| But that's the point. The icons help you find the "delete"
| section.
|
| Icons aren't large enough to then also distinguish between
| deleting a row or column or table. That's what the label is
| for.
|
| It's not laziness, it's good design.
| empiko wrote:
| Agreed, compare that to Quit Safari and Force Quit Safari
| below. One is X in a square, the other is X in a circle.
| Very confusing.
| troupo wrote:
| No. It's laziness and bad design. It's the most generic
| trash icon from the most generic icon set.
|
| Same with "add row above/below" or the completely distinct
| action Create Filter/Filter by cell value.
|
| They can be _trivially_ improved with about 1 millisecond
| of conscious thought. Especially given the fact that these
| actions have been around in office software for _literal
| decades_ , and more often than not with their own distinct
| icons.
| crazygringo wrote:
| I don't know how they can be trivially improved.
|
| I vaguely recall seeing some product with toolbar icons
| that attempted to depict a cell as part of a row, or
| column, with an "x" in the corner to indicate delete. I
| could never decipher them. It was all too small. Plus the
| "x" looked just like the "+" at a glance since it was so
| small. Even though every icon was distinct and
| meaningful, each icon was also ultimately a complicated
| jumble that took longer to decipher than just reading the
| label next to it.
|
| So when you say "They can be trivially improved with
| about 1 millisecond of conscious thought," I completely
| disagree. It's actually really hard and there's a good
| reason they choose not to. And maybe don't be so
| insulting?
| troupo wrote:
| > It's actually really hard and there's a good reason
| they choose not to.
|
| No. No, there's no good reason. Google is institutionally
| incapable of making good designs. Forget good, they can't
| make _sensible_ designs.
|
| So they whipped out the most generic icon set. Typed
| "delete" or "add" or "filter" and chose the first icon
| that popped up for all actions.
|
| Top to bottom:
|
| - Insert column before. left arrow, column (three stacked
| squares), green plus sign
|
| - Insert row after: green plus sign (in the same position
| as previous item), row (three squares in a row), arrow
| down
|
| - Insert cells. Doesn't need an icon, since it's already
| in the obvious insert group. Or: a single square, green
| plus sign
|
| -------
|
| - Delete column: column, red cross
|
| - Delete row: row, red cross
|
| - Delete cells: doesn't need an icon. Or: single square,
| red cross
|
| --------
|
| - Create a filter. Same filter icon with a green plus.
| This one is so obvious, that only a moron could think
| it's hard, or there's some reason they didn't do it.
|
| - Filter by cell value. Same icon, or better still a
| square with filter because there are other filters
| elsewhere.
|
| ---
|
| And that's before we actually ask people to think about
| the designs: https://www.flaticon.com/packs/tables-82 or
| https://www.flaticon.com/packs/spreadsheet or
| https://www.flaticon.com/packs/ecommerce-266
| crazygringo wrote:
| You don't need to use language like "moron". It doesn't
| help the conversation and it's not appropriate. Trying to
| convince people you are right because you think other
| people are less intelligent is generally not a strategy
| that works.
|
| And yes, all of the icons you are describing and linked
| to can be drawn. I even described these types of
| combinations myself. The point you're missing is that
| they are nearly impossible to visually distinguish at a
| quick glance. When I look at your first link, I just see
| a ton of icons that look like variations on a grid.
| They're difficult to decipher. You have to stop and think
| about what they actually mean and hope you don't make a
| mistake.
|
| I think you're missing the purpose of menu item icons.
| They are not too distinguish every single item. That's
| what the text is for. They are to help identify either
| the basic type of verb or the basic type of noun or
| adjective at a glance. Without having to think about it.
| Which is why it's a feature, not a bug, even when
| multiple many items share the same icon if they perform
| the same action. At a glance, you can see that all of the
| plus icons mean insert something and all of the trashcan
| icons mean to delete something, and then you look at the
| text to see what is being inserted or deleted. Trying to
| cram all of that information into a tiny icon is bad
| design because it makes it slower to figure out the right
| item, not faster.
|
| Design is full of these kinds of trade-offs. These trade-
| offs are the kinds of things you learn when you study
| design, and a huge part of graphic design is getting the
| trade-offs right in a given context.
| troupo wrote:
| > I even described these types of combinations myself.
|
| Not exactly. Re-read what I wrote
|
| > When I look at your first link, I just see a ton of
| icons that look like variations on a grid.
|
| 1. It was just an example, out of potentially thousands
| of possible variations. And I described a much simpler
| one
|
| 2. You're complaining about "variations of a grid" and at
| the same time praise how Google uses literally the same
| icon for completely different actions
|
| > I think you're missing the purpose of menu item icons.
| They are not too distinguish every single item. That's
| what the text is for.
|
| So why does Google use an icon for every single item?
| It's enough to have just a single icon on the first item
| in the group, the rest will naturally be associated with
| it.
|
| > They are to help identify either the basic type of verb
| or the basic type of noun or adjective at a glance.
| Without having to think about it... even when multiple
| many items share the same icon if they perform the same
| action.
|
| Ah yes, you don't have to think about _checks notes_ that
| "Create filter" and "Apply filter from cell value" are
| actually completely different actions with completely
| different modes of operation, that's why they get a
| single generic filter icon.
|
| > At a glance, you can see that all of the plus icons
| mean insert something and all of the trashcan icons mean
| to delete something, and then you look at the text to see
| what is being inserted or deleted.
|
| Oh, "read text between identical icons and hope you
| didn't misread the action you needed" is good, but "read
| text between similar icons if they are not distinct
| enough" is bad. Got you
|
| > Trying to cram all of that information into a tiny icon
|
| So don't cram it. I literally described the most minimal
| icons that don't cram much info.
|
| Also, there's literally no "crammin of info" in, say,
| adding a plus sign to a filter icon to designate "create"
| and to differentiate it from "apply".
|
| Just a few examples of minimal icons. They are from
| _different packs_ , so their styles and approaches will
| be different, these are just to illustrate the idea.
| Also, as you said, not every menu item needs an icon:
|
| - "insert column": https://www.flaticon.com/free-
| icon/edit-tool_7601880?related... and
| https://www.flaticon.com/free-icon/edit-
| tool_7601881?related...
|
| - "insert row": https://www.flaticon.com/free-
| icon/row_7043663?related_id=70...
|
| - delete can follow the same principle
|
| - create filter can use the same pattern as this remove
| filter icon: https://www.flaticon.com/free-icon/clear-
| filter_6134093?rela...
|
| etc. etc.
|
| Google "designers" literally took a generic icon set,
| searched for terms "insert", "delete", "filter" and chose
| the first ones that came up in search. That's it. That's
| the "hard decision" they had to make.
|
| Which is ironic given that they went out of their way to
| create varied distinct icons for the top-level menu, but
| not for the context menu. Or that Google Docs (not
| Sheets) manages to do all that, and use slightly
| different icons than Sheets (e.g. for _Paste Without
| Formatting_ )
|
| > Design is full of these kinds of trade-offs.
|
| What Google shows is not a trade-off. It's either
| incompetence or non-caring, and I don't know which is
| worse.
| rozab wrote:
| All of the Google Docs icons are really thoughtfully designed,
| with distinctive silhouettes. Instead of making 5 tiny
| illegible variations on inserting a row/column/etc, they just
| use the + symbol. Because the symbol is the same, your eye is
| then drawn to the differing text on the right.
|
| Some of the Apple ones really are ridiculous, like the ones
| around window management and copy/pasting. Even blown up to
| fullscreen size, you wouldn't have a chance of guessing what
| they do. But at display size, they are just plain illegible.
| Having them there is just a visual distraction.
| daemin wrote:
| My biggest design peeve of the examples posted is the
| inconsistent indentation of each section of the menu. Where if
| any single item in the section has an icon it gets indented, but
| if none do it doesn't, and seeing them next to each other is
| jarring. I feel this is especially inconsistent design because if
| a menu item has a check mark it indents all menu items in the
| whole menu. I would have thought Apple would have the taste to
| keep things more consistent across the whole menu than that, as
| it seems sloppy.
| netsharc wrote:
| I imagine Steve Jobs would've asked to see whoever designed
| those menues, picked up their laptop and thrown it out the
| window...
| eviks wrote:
| That would indeed be the myth. The reality is what you see on
| the screen
| netsharc wrote:
| Hard for Steve Jobs to have done this for the changes of
| the last ~14 years...
| eviks wrote:
| but trivial for all the similar changes before that while
| the laptops were still flying out
| mr_toad wrote:
| You've never seen the movie Poltergeist?
| linguae wrote:
| I wonder if part of the problem is the lack of color in these
| examples? I remember Microsoft Office 97 and 2000, which had
| icons in their menus (albeit only for a few actions, not for
| every action). However, those icons were colored and appeared
| visually distinct from each other.
|
| Yesterday I booted my 350MHz Power Mac G4 for the first time in
| 13 years. I booted into Mac OS 9.2.2. I remember the Apple menu
| having icons for every item. Once again, though, every icon was
| in color.
| Pannoniae wrote:
| And the loss of skeuoumorphism. As much as designers chide it,
| skeuoumorphic interfaces are, when done well, a massive
| improvement in usability compared to flat/monochrome ones, both
| for new and experienced users.
|
| It's not really visual "clutter", the shadows / pseudo-3d
| elements help the brain distinguish between different types of
| elements, providing contextual information.
| adamhartenz wrote:
| Written words don't have colour, and you can parse those with
| ease.
| trinix912 wrote:
| Unless you don't know the language well, then icons are very
| helpful.
| Dwedit wrote:
| Isn't the Apple Menu basically a start menu though?
| fuzzy2 wrote:
| Yesyesyes this here. Icons need colors, the smaller the more.
| Otherwise, they might as well be gray blobs. Peripheral vision
| works with colors, but it doesn't do finer details.
|
| rant:
|
| But in the end, user interfaces are mostly "dead" anyway. No
| more structure, no more colors, no more icons. Everything is a
| flat sea of labels and boxes (or sometimes even just lines)
| floating(!) around. And no two user interfaces use the same
| style, even from the same vendor.
|
| /rant
| ChadMoran wrote:
| Interesting take. As a low vision person, the icons help me scan
| menus like this.
| ks2048 wrote:
| The examples he showed, I didn't mind. From the title, I thought
| he might be referring to the emojis in READMEs. Those annoy me
| and don't add anything. (I assume all vibe-coded)
| sho_hn wrote:
| > (I assume all vibe-coded)
|
| I honestly really like that this has a tell-tale and hope we
| maintain this convention.
|
| If the author didn't care about their project enough to write
| the README themselves, I don't usually spend the energy to
| consider the project at that point.
| shadowgovt wrote:
| Former UI guy at Google here.
|
| The explanation for why they do it is pretty simple: localization
| hinting. From country to country, the text will change but the
| icon pictures won't. So if you find some how-tos or guidance
| online that has screenshots but wasn't made in your language, you
| can still follow along by lining up the icons.
|
| There are other reasons too but that's a _big_ one.
| notpushkin wrote:
| You don't have to have icons for every menu item for this to
| work though. One copy icon is enough for the whole block.
| zzo38computer wrote:
| I agree that there should not be icons in menus (with the
| exception of those indicating the status, like is shown in the
| 2005 guidelines). (Arrangements, shapes, etc might also sometimes
| be useful to indicate, but these should be separate from status
| indicators if they are present, and should be a part of the text
| instead in the few cases where they are applicable; in most cases
| they should not be needed.)
|
| Showing a check mark for if something is active can make sense,
| and other status indicators, but then it should also indicate if
| the status is currently absent. (On Windows, some menu items can
| have a check mark, but if there isn't, it does not tell you if it
| is one that could have a check mark or not. Indicating this could
| be useful.)
|
| Another thing that the menus do have, and which they should have
| because it is good to have, is specifying which keys are used to
| operate those commands. Windows also has one underlined letter so
| that you can select it when the menu is displayed, which can also
| be useful (especially since not all commands have keys assigned
| normally, so using the keys to activate the menus can be used in
| this case).
|
| My own programs with menus do not use icons (and do not usually
| use icons outside of menus either).
| zamalek wrote:
| I think that icons hold value so long as they have mostly
| distinct colors (which none of his examples do, so his point
| stands). At least for me, colors make vastly superior landmark
| than words do (once i know the interface).
| cush wrote:
| I like them
| hastily3114 wrote:
| Even worse, Windows now has menus with only icons and no text.
| mvdtnz wrote:
| His example of great icons from Finder is stolen directly from
| the Rectangle app. Looks like Apple shamelessly took Rectangle's
| icons.
| Someone wrote:
| Looking at https://rectangleapp.com/, they basically use the
| same idea, yes, but is there a reasonable alternative?
|
| Also, IMO, Apple's pictograms look a lot better and are
| clearer. In Rectangle, the "left half" icon almost is a dark
| gray rectangle alongside a bright gray one, with the _dark_
| indicating where tryout window will go. In Apple's version,
| there is only one rectangle and the screen border is much
| easier to spot.
| chabska wrote:
| Another article in the category of "I am an able-bodied
| anglophone silicon valley man and I think X should not exist
| because it doesn't serve ME". Ignoring and ignorant that there
| are 8 billion people out there, of varying ethnic and linguistic
| background, with different ableness, of different education and
| literacy levels.
| tengbretson wrote:
| Enough.
| Timwi wrote:
| > _Hey, unless you can articulate a really good reason to add
| this, maybe our default posture should be no icons in menus?_
|
| Challenge accepted. If a user (esp. one whose cognition generally
| prefers visual media) uses a menu item frequently, they can
| remember its icon and that makes it easier to find in the future.
|
| (Doesn't apply to me personally though because I'll instead
| remember the underlined letter and press it next time. My pet
| peeve in menus is not icons, but missing or clashing hotkeys.)
| mikepurvis wrote:
| Almost 30 years ago MS Office 97 was putting toolbar icons in
| their menus, and I think it served the useful function of
| helping users discover when functionality was available another
| way.
| ndespres wrote:
| Those icons were well-designed for the newly computerized
| office employee of the day. The new school of icons are made
| by graphic designers for other graphic designers.
| abustamam wrote:
| I think icons aren't a bad idea, if they are visually distinct
| and make sense. For the longest time, the icon for "link" and
| "attachment" in Gmail looked almost identical.
|
| They changed it recently for attachment to look like a
| paperclip on a document which is much better. But before, I
| almost always clicked on one when I wanted the other (or
| hovered my mouse over it for longer than I'd care to admit).
| alextingle wrote:
| Flat, monochrome icons might look nice, but they are only
| useful if used sparingly.
|
| If you're going to use many icons, then they need to be
| visually distinctive. That means ditching the flat designs, and
| embracing colour again.
| wolpoli wrote:
| Color icons needs to done twice - once for light mode and
| again for dark mode.
|
| It is the reason for removing colors and shadings from all
| icons.
| alextingle wrote:
| So in your opinion, monochrome icons are a sign of
| laziness, rather than an aesthetic choice. Got it.
| eldaisfish wrote:
| Think about what was lost in the quest for dark mode versus
| the benefits.
|
| I would argue that menu icons are more useful than dark
| mode in several situations.
| immibis wrote:
| We don't need light mode and dark mode if we just set our
| monitor brightness correctly.
|
| It seems some monitors now _assume_ dark mode - only the
| very lowest brightness setting isn 't blinding.
| eviks wrote:
| How can you remember the underlined "i" when it's so tiny and
| also positioned in random places? These should be in their own
| column just like a checkmark or an icon (but yes, no single key
| navigation is way worse than bad icons)
| zeckalpha wrote:
| Perhaps we are witnessing a early shift toward ideographic
| writing
| deadbabe wrote:
| This is just rage bait or comment bait. Anyone who designs UI for
| the real world already knows people barely read text, and an icon
| is worth a thousand words. Also results in less cognitive
| fatigue.
| dsego wrote:
| Without text can you 100% decipher what each icon in this
| dropdown menu means and which one you need to pick for the
| action?
|
| https://imgur.com/a/sTycBjc
| trinix912 wrote:
| They didn't say to have no text, they just said icons are
| still helpful.
| dsego wrote:
| They did say that "an icon is worth a thousand words" and
| that "people barely read text". Why is it helpful if you
| still need to read text? I understand that some icons are
| instantly recognizable, but these are really small and the
| black & white shapes look rather similar.
| beeforpork wrote:
| > ... Anyone who designs UI for the real world already knows
| people barely read text ...
|
| Then they are wrong. And are bad UI designers following
| folklore instead of sound ergonomy.
|
| I absolutely hate icons, and parsing and remembering them
| causes great cognitive load on me. Also, icons like to change
| with each revision of the apps, with styles etc., and are not
| uniform across apps. This makes them completely useless to me.
| Maybe I can cope with an '[X]' to close a window, but that's
| about it. Even very common functions like 'Save' or 'Add'
| usually have completely arbitrary and confusing icons. 'Add' is
| not a long text. It works. I need text. Without any icons. I
| want to switch icons off so that the text can have maximum
| space to be reasonably large to be seen and read easily.
|
| People are different is what UI designers should know instead.
| _acco wrote:
| My best guess for the sparse icons in older MacOS versions: icons
| only for frequently-used menu items.
| adamq_q wrote:
| Look how they massacred my boy
| fakefish wrote:
| The disagreement here is interesting. I'm with OP, icons increase
| cognitive load for me if overused but can help a lot if there are
| just a few distinct ones.
|
| I wonder how much variance is driven by zoom level (icons may be
| more distinct when bigger, text is easier to pattern match vs.
| read when small).
| kevin_thibedeau wrote:
| It's extra noise because of the fad for samey B&W icons
| (instigated by the ease of implementing dark mode). With
| judicious use of color, there can be more visual distinction
| where the menus guide you to the intended target by visual memory
| without having to process the text.
| onetom wrote:
| In earlier versions of Apple OSes, you could edit the menus
| yourself, with the officially supplied resource file editor app
| and there was nothing really special about it.
|
| There are `ibtool` and `plutil` CLI commands built-in to macOS
| these days too, but to get some graphical editor, u would need to
| download 3GB of Xcode and u would invalidate the code signatures,
| etc...
|
| Plus there is a huge churn in the application versions, so any
| customizations would need to be applied repeatedly to newer app
| versions.
|
| Sad, really...
| d--b wrote:
| Simply put: icons in menus are helpful to me.
|
| Deal with it.
| itake wrote:
| I think this is true, if you can read in the language.
|
| Its really difficult to help someone on tech issues if their
| device is configured for a language you don't understand. Simply
| changing the language is annoying, b/c then they can't understand
| the workflow I'm showing them in their language.
| crabmusket wrote:
| I think there's a serious related issue which is that icon packs
| (font awesome, feather, material icons, whatever you prefer)
| encourage you to just pick the "closest" icon for a given menu
| item, rather than an icon that is actually what you want.
|
| At work we do sometimes design custom icons for specific things,
| but that's very rare and relatively costly. Most developers on
| our team don't have that capability, and we are left trawling
| through Google's admittedly-large icon library to find something
| that seems plausible.
| jFriedensreich wrote:
| i hope this is a fringe opinion as im usually putting icons on
| every item and found it leads to reduced mental overload and fast
| item selections, for complex menus i would even go so far as
| making it colored to more senses can be used. the icons have to
| be meaningful though, apples guidelines specifically mention
| arbitrary icons not icons at all
| SkyPuncher wrote:
| I want icons everywhere. They can literally be meaningless but
| it's way way easier to find "2nd item in matching icon set"
| than it is to read every item in a list.
| concinds wrote:
| I hope so too, and I agree on the colored icons for pro apps.
| Mac user for 20 years, also using Windows on and off, and I've
| always liked the menu icons on Windows. A move away from
| minimalism that makes sense. The fact that they're not cargo-
| culting their 20 year old HIG is promising, really.
|
| But they really should keep the indentations consistent,
| they're increasing cognitive load for no reason by not doing
| that.
|
| I also like the hotkeys or whatever (the underlined letter in
| menu items and dialog box buttons), and maybe that is a fringe
| opinion among Apple users.
| ndespres wrote:
| I agree with the author. I understand many of the reasons others
| give here for why icons could be beneficial- localization,
| literacy, vision issues, etc. all are great reasons to supplement
| text with icons, theoretically. But I disagree that these icons,
| I mean those shown as examples in the Apple menu, Safari menu, or
| Google Docs menus- actually convey anything useful and really do
| prove the authors point that they're poorly implemented.
|
| I realize it may be generational and privilege based, as I can
| read English and have a good deal of computer literacy. To my
| eyes the icon trend of flat, minimal icons paradoxically ask a
| user to possess a higher degree of computer fluency to
| successfully parse the artistic intent of the icon and map it to
| its function. When these icons don't accurately convey their
| function (the Paste icon is a blank clipboard. What's that do?)
| and when the design language is inconsistent within the same
| application and OS (do cogs mean Preferences? Services? you're
| building a very confusing world for most of the user group types
| you claim to be helping.
| pjot wrote:
| Similar is the save icon, though for a different reason. It
| conveys its function well, but one first needs to know what a
| floppy disk even is!
| qwertytyyuu wrote:
| Nah, people especially younger ones associate the floppy disk
| with the save button
| yokljo wrote:
| A lot of apps people use these days are cloud-first and
| automatically save all the time, so there's not even a save
| button to have a floppy icon for! The icon to say that it's
| synced looks like a cloud, and if you're using a web
| browser it'll probably have a Download button with a
| download icon. No floppy disks in sight.
|
| I wouldn't be surprised if there's computer users out there
| that wouldn't recognise the "save icon".
|
| RIP in peace
| Zardoz84 wrote:
| I disagree. Not all it's "autosave on cloud", and some
| apps keeps having an explicit save something button or
| option.
|
| I recently had a discussion about replacing the "save
| icon" (IE. the old floppy disk icon) for an icon with an
| arrow pointing down, for a button that saves (don't
| download!) a custom query of the user in the system.
| Perhaps it could be replaced with another icon, but not
| by someone that everyone would think is "Download".
| scragz wrote:
| they think it's a soda vending machine
| mr_toad wrote:
| My daughter understood what the Chrome icon was for before
| she could even spell 'Chrome'.
| omnimus wrote:
| It doesn't actually matter that much what the icon is. It's
| impossible to creat icons people would fully understand -
| otherwise you wouldn't need a label at all.
|
| The function of the icon is to have distinct shape so you are
| able to visually distinguish menu items quickly in future (more
| you use the app).
|
| There are other factors like consistent placement that can
| help. This icon approach is good especially if you have common
| shared menu items over the OS or they change their placement
| throughout the app.
| VBprogrammer wrote:
| The IKEA instructions are generally regarded as a triumph of
| simplicity. Yet on more than one occasion I've come across
| cases where a few words in a call out would have prevented
| having to redo some step after later realising that some
| features had to be oriented a particular way - the pictures
| not quite conveying their intention until it was obvious in
| hindsight.
| busywaiting wrote:
| > The function of the icon is to have distinct shape so you
| are able to visually distinguish menu items quickly in future
| (more you use the app).
|
| In theory, yes. But if you look at the examples in the
| article, the shapes are basically all similarly-sized
| circles.
|
| In the Apple example, "System Settings" is circle (A gear
| with barely discernible teeth.) "Recent Items" is a circle (a
| clock.) "Force Quit" is a circle (a rounded! octagon.)
| "Sleep" is...a circle with a line through the bottom third.
| "Log Out" is...a human silhouette _in a circle!_ (Why?)
|
| It doesn't matter what the icon is as long as the icons are
| distinct, and today's icons aren't.
| troupo wrote:
| > The function of the icon is to have distinct shape so you
| are able to visually distinguish menu items quickly in future
| (more you use the app).
|
| I wrote it in a different comment elsewhere: this is exactly
| why you _don 't_ want icons on every menu item. When
| everything tries to be stand out, nothing does. It's much
| easier to distinguish groups and "it's the third item below
| the icon" than "out of these identical looking icons one of
| them points to a menu item that does what I want".
| omnimus wrote:
| Sure! I agree. My comment above probably seems like i think
| this new Apple design direction is good. I don't. Tahoe
| seems like amateur hour.
|
| What i was mainly saying is that the icon does not have to
| describe the label for it to be effective. That doesn't
| mean that usage/quality of the icon suddenly doesn't
| matter.
| ndespres wrote:
| Others have brought up the Office 97 style for good reason.
| Everything has an icon, on an icon toolbar. Every command can
| also be on a file menu but most of them there don't have an
| icon. The ones that do are special or intended to draw your
| attention.
|
| And there's a consistent metaphor: for example the web
| browser is represented by a globe for the world wide web. So
| the "hyperlink" function is a globe with a chain. This the
| "preview as web page" is a globe with a magnifying glass
| (whereas the print preview command is a sheet of paper with a
| magnifying glass.).
|
| This icon language hints at function through its form and
| helps serve as a cue, a reminder, or a visual representation
| of its function.
|
| And it all worked on 640x480 256 color screens. They are
| thoughtful and useful. These plain flat uninformative icons
| are just rude.
| omnimus wrote:
| Sure. There are also icons that are plain flat and don't
| use metaphor and work great. Play, share, hamburger,
| bluetooth, power... i am sure there are more. Icons are
| more about familiarity than anything.
|
| I assume you were very familiar with Office 97. I can tell
| you people born in 97 are probably not. High chance they
| might not like and understand the icons because they aren't
| familiar with them.
|
| It's like when everybody wants to design logo as
| unforgettable as Nike. But in reality anything people see
| 20 times a day people will remember.
| heavyset_go wrote:
| Disagree entirely, pictographs are easier to recognize than text
| descriptions of features and functions.
| thn-gap wrote:
| The real test would have been to use some software that the
| author uses frequently, and see if there's any decrease in speed
| when removing all the icons. I'm pretty sure, even when not
| pleasant, they work as heavy visual cues to find the item
| quicker.
|
| Icons are also very useful if you're trying to use software in a
| language that you're learning, becoming the common language
| bridge.
| culebron21 wrote:
| If I remember Windows 95/98/XP correctly, these icons were in
| menus only if there was the same icon on the panel. This would
| let you see there's a shorter way to do the action.
|
| Right now icons indeed just add clutter.
|
| They also make you think how could the designer depict a concept.
|
| For example, why should "Save" button look like a diskette. What
| if it was Jesus, like the Christ Redeemer statue. That actually
| could be a funny game, like in the post, to invent icons.
| zuminator wrote:
| Seems like something that could be a UI setting per user.
|
| Only text/Only icons/Only icons (with tooltips)/Some icons with
| text
| 1718627440 wrote:
| Exists in GTK+ as a OS per-user setting, I expect in KDE also.
| whstl wrote:
| People at Apple is gonna read this and they will do a man-month's
| worth of meetings but the designer and PM will never agree in
| whether to remove some or add more, the developers are too busy
| adding icons to other random places to get a promotion and the QA
| is filling about missing icons after finally getting around to
| check Tahoe.
|
| People are saying they miss Steve Jobs but they probably just
| miss the product having actual direction.
| Mikhail_Edoshin wrote:
| Pictograms in the interface are not decoration. Their purpose is
| to convey information in limited space. (The information should
| be that could be conveyed this way.) Currently they are often
| used as decorations or these two uses are mixed up. This is a
| mistake.
|
| (It is interesting and saddening to see how years of UI research
| just went down the drain after Apple "resurrection". In my
| impression Apple was the first that started to lose their
| carefully collected UI expertise and replace it something that
| was original for the time, but that was all. E.g. I remember the
| very first ads after Jobs' comeback. They still had the beige
| Macintoshes, but their ads changed. Instead of a typical computer
| ad that showed a computer with a turned on screen and some
| desktop picture Apple's ads pictured turned off computers
| photographed from unusual angles or in unusual positions, like
| keyboard standing on its side leaning on the box, mouse hanging
| on its wire and so on. It was different, indeed, it stood out.
| Thing is, to always strive for that is harmful. Especially for
| user interface, where the motto is: do not make it original, make
| it right.)
| Mikhail_Edoshin wrote:
| So the rule of thumb is that: if the pictogram is always same,
| then as in Shannon's model, it conveys no information, and thus
| is decorative. Discard it.
|
| One of first programs that put pictograms in menus was
| Microsoft Word. But the way Word did it was entirely different
| from what we do now. Microsoft Word had toolbars and their
| buttons, of course, were mostly pictorial. Toolbars could be
| turned on and off and users could assemble their own toolbars.
| Microsoft Word's menus displayed pictograms only for the
| commands that could also be called with currently visible
| toolbars. Have a toolbar visible? Its pictograms will appear in
| the menu. Closed that toolbar? The pictograms disappeared. The
| pictogram did not merely decorate a command, but also provided
| a hint that the user could call the command with a toolbar.
| This is informational. This is the right use.
| thiht wrote:
| > thus is decorative. Discard it.
|
| Or keep it since decoration makes interfaces feel more alive.
|
| Not everything NEEDS to be useful
| bigstrat2003 wrote:
| Everything in a UI needs to not hinder usefulness. Adding
| more information signals (icons) which don't actually
| convey meaning is clutter that makes the UI harder to
| parse. That factor is far more important than whether it
| feels "alive".
| AndrewOMartin wrote:
| Redundancy isn't a dirty word in Information Theory.
| Mikhail_Edoshin wrote:
| Classic Mac OS window headers had striped or dot patterns
| that were kind of similar to rugged parts of various
| physical tool handles. So they were both decorative in a
| way and informational: this is a part you can hold and drag
| around. A typical interface will have a lot of such parts
| that are both functional and decorative, so it will feel
| just right.
|
| Purely decorative parts are also possible (and even
| desirable), but they should be personal. A set of colors
| chosen by the user, a background texture, a picture that
| the user keeps on the desktop and so on.
| thiht wrote:
| That's a very subjective view of design, and I strongly
| disagree with it. I don't want everything to be too
| uniform
| BaudouinVH wrote:
| I tend to follow the "no form without function" design
| philosophy. Your comment makes me rethink that. thanks
| antran22 wrote:
| in that case, they should make it optional. What some might
| find as eye candy, other finds as nuisance (case in point,
| animation).
| incrudible wrote:
| Menus should not feel alive. Because they are menus, at any
| given point they mostly contain things the user does _not_
| want to interact with right now. Menu icons that serve as
| visual anchors are good, they help the task of finding the
| desired action, as well as building a visual memory. Icons
| everywhere achieve the opposite, for the spurious benefit
| of visual consistency. Menu items are not consistent
| affordances, they perform very different actions that are
| at best related, but oftentimes they are there because they
| need to be _somewhere_.
| nottorp wrote:
| > Not everything NEEDS to be useful
|
| ... until the not-useful becomes distracting and/or causes
| information overload.
|
| In the case of Apple, I've been a user of the Accessibility
| menu ever since they introduced the stupid parallax
| wiggling of the icons. Right now i use: reduce motion, bold
| text and reduce transparency. Because I want to see what
| I'm looking for when using the phone and not squint through
| pointless effects.
| strogonoff wrote:
| A decorative element can be fine in a design model, but 1)
| a good design tends to have no _purely_ decorative
| elements, and 2) it becomes problematic when the decorative
| element looks like a meaningful element but does not
| actually carry meaning (or the intended meaning).
|
| We all recognise an icon in a menu as a meaningful element.
| Treating it as a decorative element is wrong and adds
| mental overhead, as we tend to scan every one of those
| icons (putting it at the beginning of menu text, i.e., to
| the left for LTR languages, makes it worse). It is well-
| known we _do_ tend to scan these icons because that is the
| reason icons work: repeated exposure creates intuition. If
| this intuition is not put to use, then all such icons are a
| waste of our attention.
|
| For example, a bullet in a list: fine (differentiates where
| each list item starts), window shadow or the 3D effect on
| window close buttons: fine (meaningful in terms if
| differentiating areas in the GUI, not pretending to do
| more); whitespace to set apart one thing more from another
| thing than from the third thing: fine (if that reflects the
| relationship between those things).
|
| This is all somewhat simplified.
| Y_Y wrote:
| You remind me of my favourite bit of Windows software
| ever[0]. It made the desktop feel really alive with things
| like can-can girls and humanoid fish flying around your
| "living wallpaper".
|
| Then again it was named _Monty Python 's Complete Waste of
| Time_, so maybe it's not such a good idea for the default
| environment of a general-purpose operating system.
|
| [0] https://www.mobygames.com/game/1975/monty-pythons-
| complete-w...
| 20k wrote:
| Pictograms let you parse a lot of information at a glance,
| because you can pattern match a group of differing symbols
| much faster than you can a block of text which all looks
| uniform. It lets you skip reading all the text when you're
| familiar with a dialogue, and you can short circuit what you
| need to click on without having to read
|
| That's the reason why pictographic additions are so useful.
| Its the reason why we distinguish different kinds of UI
| elements at all, because colour and graphics are incredibly
| powerful shortcuts for parsing information
| ACCount37 wrote:
| This. If I'm out looking for a "Save" button, I'm going to
| pattern match "ancient disk icon" without even thinking
| about it.
|
| It's also the reason why some menu entries get icons and
| others don't.
|
| If the icon doesn't convey information by itself (like a
| "move to top" icon example), then it's there as a visual
| anchor - and you don't really need to have 4 of the same
| "delete" icon if a menu has 4 different "delete" options
| next to each other. Just one is enough of an anchor to draw
| your attention to the "delete group", and having just one
| keeps the visual noise low.
|
| Likewise, you don't need visual anchors for every single
| option - just the commonly used ones, the ones you expect
| people to be looking for, and the ones that already have
| established pictography.
| sundarurfriend wrote:
| > "ancient disk icon"
|
| Even though floppy disks were a bit before my time and I
| rarely ever used them, seeing them be called _ancient_
| disk makes me wanna find the nearest coffin and just go
| lie down. :D
| icoder wrote:
| What may be added is that some people have a hard time
| reading words by their 'total shape'. I can imagine that
| for them, the difference between pattern matching symbols
| and strings of letters is even more profound.
| rayiner wrote:
| > Pictograms let you parse a lot of information at a
| glance, because you can pattern match a group of differing
| symbols much faster than you can a block of text which all
| looks uniform
|
| No you can't.
| Levitz wrote:
| I'd disagree but either way throw another factor in: non-
| native speakers and cross-language usability.
|
| If your software is in some language and you are looking
| at docs or a videotutorial or something in another
| language, it's often hard to translate specific terms,
| Icons don't change language. They also help if you have
| to do something in another machine that uses a different
| language for some reason.
| woobar wrote:
| Look at the traffic signs. You have very limited time to
| read the sign. That's the reason they have distinct
| patterns and rarely (except in USA) rely on blocks of
| text.
| sevensor wrote:
| So do I want the button with the three horizontal lines,
| three horizontal dots, three vertical dots, nine dots
| arranged in a grid, the point-down triangle, or the point-
| right chevron? Generally these convey no information and I
| have to try each one to find the option I want. If it
| exists.
| ragazzina wrote:
| > if the pictogram is always same, then as in Shannon's
| model, it conveys no information, and thus is decorative.
| Discard it.
|
| If the text on the button is always the same, then as in
| Shannon's model, it conveys no information, and thus is
| decorative. Discard it. Just use the position.
| wartywhoa23 wrote:
| And if the position is always the same, it is decorative,
| and we'd pretty much rather discard it too and use time,
| which does not stay the same by definition, and make them
| stupids click anywhere spatially but on precise time: t % 2
| == 0 => action 1, t % 3 == 0 => action 2 etc - but that
| would be too much of a disrespect towards users, however
| stupid - and we have no choice but randomize those iconless
| textless positions dynamically.
| scoofy wrote:
| The pictogram is there for people who can't read English, to
| help them get by.
|
| It's the same reason why Ikea's instruction manuals typically
| have no words.
| Perepiska wrote:
| JetBrains products had colorful and useful pictograms on menu
| items and panels. One day they replaced them by B&W versions
| and it was fail. Few years later they introduced purple
| icons. For promoting some internal AI companion.
| vasco wrote:
| I disagree, pictures are easier to remember than words and I'm
| much faster (several hundred miliseconds) at quickly spotting
| an icon in the 12th place down a list and clicking it because I
| memorized it visually than reading the actual words.
|
| So icons make power users faster. It's not "clutter". Your
| argument about "don't use it for aesthetics" is ironic because
| you're making it because of aesthetics. For me it's about user
| speed.
| __del__ wrote:
| an icon for "save" will suffice to help me find the portion
| of the menu with "save as", "save a copy", and "export". when
| all four have the same icon, or slight variations, i'm back
| to reading each one to discern the difference.
| alternatex wrote:
| >I'm much faster at quickly spotting an icon
|
| Using the label-less example in the article with the 10x10
| monochrome icons I doubt many other people feel the same.
| stanac wrote:
| > 10x10 monochrome icons
|
| I don't mind the size, but lack of colors is annoying. If
| common icons where color-coded, like green to save, blue to
| download/print/export, red to delete, UI would be
| friendlier to use.
| swiftcoder wrote:
| > If common icons where color-coded... UI would be
| friendlier to use
|
| As a colour-blind person, this sounds like accessibility
| hell. Don't forget your UIs still need to be friendly in
| what amounts to monochrome
| oracle2025 wrote:
| I think it is important to stress that both, color _and_
| shape should be visible distinctive, and as you say it is
| important that the color palette is chosen in a way that
| even if the color does not stand out for a the color-
| blind person, the contrast stays visible.
|
| Making everything monochrome is surly not more
| accessible, because there sure are people who find it
| easier to distinguish by color than shape.
| kergonath wrote:
| And also in some cultural contexts in which red and green
| do not carry the same meanings.
| carlosjobim wrote:
| Why in the world would colors discomfort you if you can't
| discern between them? Icons have until recently always
| been color coded. That doesn't make them a problem for
| the color-blind. You can look at the shape of the icons
| and read the text next to them. Would a pedestrian
| traffic light be better if it wasn't color coded? Would a
| white car be preferable to a red car?
| swiftcoder wrote:
| > Why in the world would colors discomfort you if you
| can't discern between them?
|
| Because pretty much as soon as one starts colour coding
| items in the UI, people start using the specific colours
| to encode meaning. If your UI requires someone to discern
| between the red and green versions of the same icon in
| your UI twice, congrats, you just lost 8% of male users!
|
| > Would a pedestrian traffic light be better if it wasn't
| color coded?
|
| If they weren't colour-coded, they would have to be
| differentiated by shape, and then when I traveled to
| Canada, I wouldn't have to guess whether the fancy
| horizontal traffic lights are ordered left-to-right or
| right-to-left
|
| > Would a white car be preferable to a red car?
|
| Even fully colour-sighted folks can't see red very well
| at night, so yes, white car > red car
| swiftcoder wrote:
| Personal anecdote re the traffic lights: I thought "green
| light" was a metaphor until sometime my twenties, when a
| friend explained that the 3rd light actually is green to
| other people. It's always been a white light to me
| carlosjobim wrote:
| With that line of reasoning we arrive at the conclusion
| that all graphical elements of an interface should be
| removed, as the blind cannot see icons.
|
| > If your UI requires someone to discern between the red
| and green versions of the same icon
|
| Color coding has never been about this, only when
| implemented wrongly. It is just an extra differentiator
| for GUI elements which are already differentiated by icon
| shape and text labels.
| swiftcoder wrote:
| > Color coding... is just an extra differentiator for GUI
| elements which are already differentiated by icon shape
| and text labels.
|
| In principle, I agree, but I do not believe I have ever
| used a software package that follows this philosophy. In
| practice, once you give people a tool, they are inclined
| to use it, and most projects only try and address
| accessibility concerns post-ship
| vasco wrote:
| Monochrome is a strange complaint, the text is also
| monochrome. Regarding what most people think I don't know,
| I'm definitely faster at spotting a specific pictogram in
| the start of a line than having to read multiple lower
| information-density pictograms (alphabet characters) in
| order (reading a full word or sentence). This seems obvious
| to me, 1 thing is faster to parse than multiple things.
| Propelloni wrote:
| Speak for yourself. I remember words. That disk icon stands
| for "Save". "Save" is what I remember. I also remember
| location, but the spatial component applies independent from
| icons or words.
| vasco wrote:
| > Speak for yourself
|
| >> I'm much faster
| hypercube33 wrote:
| The monotone ones in Windows 11 that jump around in order or
| menu position (I think both of these have been addressed in
| 24h2 or something?) where they hop to the top or bottom of
| the menu or dont show so the order is wrong if they are
| disabled for some object are insanely bad UX.
|
| I say this because I agree, the pictogram icon is much easier
| for me to find. I also like having a word there though, if
| they change the picture on me. If its not color, almost all
| bets are off, since I dont even look at the icon, just look
| for a color and go for it if thats available.
| SmarsJerry wrote:
| There was a point where a significant amount of menus in
| windows and office used only icons. It made it basically
| unusable for anyone over 60.
| eviks wrote:
| > Their purpose is to convey information in limited space.
|
| No, that's only one of their purposes. Another one is faster
| visual parsing of shape recognition instead of reading even if
| space is not an issue (just like with all of these menus, they
| waste so much space on padding they could fit command names 3
| more times)
| Mikhail_Edoshin wrote:
| Right; but this is also information. The Civilization game
| used little pictures of wheat and shields, I think, to
| indicate the production levels. Here the pictures are better
| than numbers because they feel more like actual things and
| allow to express all the details we need. We understand
| smaller numbers differently, three vs five is not just
| arithmetical for us, it is more substantial to actually see
| three vs five items than a different shape of a digit.
| alansaber wrote:
| Nothing more addictive than adding more padding
| JeremyNT wrote:
| Yes, and as much as I hate to defend modern UI designers, I
| believe the icons in the menus here are actually extremely
| helpful (even when duplicated).
|
| In the first example, when I want to find the option to add
| or delete a row in this massive menu, the icons clearly
| convey the purpose. I can instantly filter a huge list of
| possibilities down to a few relevant entries.
| kldg wrote:
| yes; I think it depends a lot on how accepted the icon is.
| Every few months when I have to open ST's CubeProgrammer,
| my brain substantially deteriorates because they don't use
| text and the icons for their main tabs are not always
| understandable to me. (and the thing's otherwise a relic
| from 20+ years ago)
|
| X, volume & mute icon, disk icon, upload/download icon --
| these are all fine and good; you don't need to spell those
| out for me because their use is so widespread that even if
| I didn't know what they meant, it'd be very useful to
| learn. I have no idea what a generic "integrated circuit"
| icon means, though, and I doubt anyone will use it
| elsewhere to mean the same thing, so I just click around
| randomly until I find what I'm looking for, like I'd do
| with the previously-unlabeled 6-switch panel in my living
| room where the positioning of the switches have no obvious
| relation to the physical placement of the ceiling lights.
|
| I think Apple's menu actually shows exactly what I want and
| expect; show icons if it'll help me, don't show them if
| they wouldn't; though in come cases, I think Apple could
| apply some _more_ icons (like for "Stop", there are a few
| good choices for that).
| j45 wrote:
| Limited space seems like a surprising thing to lean on,
| especially when put next to a text label, with the increase
| pixel count/resolution on devices over the last 5-10-15 years.
|
| Words create better beginners than icons alone.
|
| UI/UX can evolve as the baseline digital literacy of users
| evolves usually very slowly, to remain maximally inclusive.
|
| One thing that I'd consider is start with text labels, and the
| more they are used, start showing an icon. Just hold a left bar
| for them to start appearing so that learning can happen.
|
| The screenshot where there was only some menu items with icons
| feels more memorable for that reason.
| hypercube33 wrote:
| I hate the monotone ones - I get it, its easy to tick the box
| that they are colorblind safe or whatever, and its modern
| design, but man the colors really help me identify what the
| hell I'm going at in the menu. Brown thingy (clipboard) is
| copy, black square is save. I'm a simple creature.
| mopsi wrote:
| Same. Most people identify a blob of color far earlier than
| they distinguish one monochrome shape from another.
| illiac786 wrote:
| > the motto is: do not make it original, make it right.)
|
| Agreed. It just doesn't sell.
| mock-possum wrote:
| It really depends. If it works it works, if it doesn't it
| doesn't, like everything else.
|
| But I do feel like he's hurting his case here:
|
| > You know what would be a fun game? Get a bunch of people in a
| room, show them menus where the textual labels are gone, and see
| who can get the most right.
|
| That's an excellent example of how effective icons actually are!
| I can mostly read that menu at a glance with no text lables,
| because good use of iconography doesn't assign "arbitrary" icons
| to options, jt fields well-known icons that are easily
| recognizeable. Take for instance the 'save' icon - everybody
| knows what the floppy disc means, _even if they have never seen,
| touched, or used a floppy disc IRL_. A 15 year old born in 2010
| knows what the 'save' icon is. My nearly 70 year old mother knows
| what the 'share' curly arrow icon means.
|
| They're not arbitrary at this point - they're _standard_.
| yakshaving_jgt wrote:
| > A 15 year old born in 2010 knows what the 'save' icon is. My
| nearly 70 year old mother knows what the 'share' curly arrow
| icon means.
|
| Ok, but not by intuition. This is _learned_ pattern
| recognition, which started with seeing those icons adjacent to
| text labels.
| diimdeep wrote:
| Io-moio, this is really bad, I am so glad that I never upgraded
| to Tahoe.
|
| Can we just stop endless design churn and resists urge to
| innovate in a fashion industry manner in software UI ? This is
| ridiculous.
|
| And f. the product managers that pushing for this, f. the SIP,
| lets reverse engineer the crap out of this and reverse all this
| changes with easy to use system level patch.
| yard2010 wrote:
| Off topic but I could use some help here - what icon would you
| use for "prevent screen for sleeping" toggle button? I thought
| about an eye (open or closed if it's on or off), but I think
| there's a better option I can't see
| dkdbejwi383 wrote:
| Cup of coffee
| eviks wrote:
| The general point holds - there is no universal solution, to some
| people some icons will be noise, to some the same icons will be
| instant visual parsing replacing reading, so the solution is
| obvious - easy user customization (ideally at an OS level where
| every single File-Open menu action can only be renamed/icon-
| added/removed / keyboard shortcut changed). But that's just a
| dream
| foobarbecue wrote:
| You're lucky they still have text labels!
| iamcalledrob wrote:
| I'm bracing myself for losing ellipses in Apple's menus too.
|
| At least based on the trajectory of macOS's design decline.
|
| For those who might not be aware, a long-standing design pattern
| on macOS is for menu item labels to have a "..." at the end when
| a click will take you somewhere, rather than taking immediate
| action. So you can click more confidently.
|
| It's an example of the subtle quality and attention to detail you
| get with native UI, that gets lost when you build a web app and
| re-invent the wheel.
|
| Most "web" UIs don't include this detail, as evidences by the
| screenshots in the article.
| tobyhinloopen wrote:
| I have never known! On my web apps, I _try_ to give buttons
| that perform an irreversible action a different color, like
| saving, updating, creating, deleting etc
| michaelevensen wrote:
| Designer here. I agree that sometimes there is an over-emphasis
| of sticking to the rule of icon - title (if it's already been
| defined) and finding icons for features that are very hard to
| describe through a simple pictogram, thus leading to non-helpful
| visual cues for menus and menu items. But, icons to me has never
| been about being a perfect encapsulation of the meaning of the
| feature, it's more of a visual anchor, eg even the examples in
| this article without icons require me a couple more milliseconds
| to scan just to find the menu item I'm looking for. It's a visual
| anchor first, a descriptor second.
| kvirani wrote:
| I do like how in some MacOS examples we see icons for some of
| the more important or commonly used menu items, but not the
| others in the same list. The absence of icons has meaning
| ("it's likely not what you want")
| yakshaving_jgt wrote:
| I've heard this kind of reasoning from a number of designers,
| and it strikes me as post hoc justification for aesthetic self-
| indulgence.
|
| So, with the greatest of respect, I don't believe you. It does
| not take you "a couple more milliseconds to scan", since a
| couple of milliseconds is well below human perceptible
| thresholds for almost every sense.
|
| There is no accessibility improvement here -- you just _like_
| the consistency.
|
| https://pubmed.ncbi.nlm.nih.gov/18465408/
| immibis wrote:
| If you have an icon next to every entry and they all look the
| same on first glance, you don't have visual anchors.
| BaudouinVH wrote:
| mixed bag of reactions :
|
| - the part where the reader is invited to guess what a menu item
| does based on the icon alone was very interesting
|
| - how come the floppy disk survived as as "save" icon when floppy
| disk use is not the default save medium ?
|
| - has there been any global study (dis)proving that icons and
| emojis are truly understood and carry the same meaning everywhere
| on the planet ?
| nusl wrote:
| I don't feel that this is clutter. It's actually helpful to
| quickly locate the spot you're looking for, or understand the
| purpose of something better without having to know exactly what
| it does. Listing text with separators and nothing else makes the
| experience worse unless it's already obvious where's-what.
|
| In terms of accessibility, too, icons are a win. Colors on top of
| this also help with that.
| kevin061 wrote:
| Very cool analysis, I never thought of that. I was actually in
| the camp of "icons everywhere" because it seemed inconsistent to
| have icons only sometimes, but I never stopped to look at
| indentation especially when mixing in checkmarks, thanks for
| sharing!
| rohmanhakim wrote:
| I think the best approach is to separate between frequent and
| rare actions. Frequent actions like cut, copy, and paste usually
| have recognizable icons that allow people to scan them easily
| when in need. Rare actions should use text only to prevent noise.
| Having an icon (which is most likely not as recognizable as the
| frequent actions) won't help
| ifh-hn wrote:
| I think visual signs are an amazing way to impart immediate
| information at a glance. Take road signs for example, at speed I
| can know what to expect around the corner.
|
| However it is another language to learn and as such needs
| standardisation to be useful. If I go to another country and
| start driving the road symbols mean something else.
|
| Its the same in the GUI. The symbols should allow me to move
| quicker around the interface, even if I've not used the software
| before.
|
| The issues I see are each OS/App can, and does, use their own
| symbols for the same functionality (sure there are some
| universals like cut/copy/paste). And like the article these
| symbols now appear to be getting used as bullet points, so each
| item needs it's bullet points.
|
| In my opinion, and like the greyed out keyboard shortcuts over to
| the right of some menu items, these symbols should only be there
| when they denote actions that can be done by clicking a button.
| They should be imparting the mouse equivalent or those keyboard
| shortcuts, a way to navigate and do actions; not as some
| decoration. Imparting the language of the GUI.
|
| So yeah I agree with the article. Function over design aesthetic
| every time.
| graemep wrote:
| > However it is another language to learn and as such needs
| standardisation to be useful. If I go to another country and
| start driving the road symbols mean something else.
|
| A lot of countries seem to standardise on similar signs. I have
| not had a difficulty driving in different countries and
| visiting more.
|
| Cars are even more standardised. The controls vary very little.
|
| There is a definitely problem with GUIs and the problem seems
| to be aesthetics and branding trump function.
| albert_e wrote:
| Even cut copy paste are not used consistently.
|
| In many AI chatbots ..i see the "paste" icon used for the
| function of "copy"
| 1718627440 wrote:
| This problem only shows that these corporations can't see beyond
| their own nose. Yes modern GTK is crap, but in GTK+ 2, there is a
| global per-user setting, whether you prefer only icons, icons and
| text or only text. All native applications respect it, because it
| is of course handled in the UI toolkit. I expect QT to be the
| same, this is typically even more configurable. QT and GTK+ also
| have interop for such settings.
| damieng wrote:
| I remember when these first started appearing in Windows was
| around the time toolbars became popular.
|
| I think the idea was the most common ones had icons which matched
| the toolbar button so you could start with the slower-but-more-
| comprehensive menus and then notice the quicker toolbar
| equivalent through their matching icons.
| bryanrasmussen wrote:
| I have sent them one of these
|
| https://cdn-icons-png.flaticon.com/512/565/565524.png
| z3t4 wrote:
| Do we even need menus? They are good for feature discovery, but
| could be replaced by a search!?
| albert_e wrote:
| Back in the day MS office applications had toolbars (instead of
| ribbon)
|
| Toolbars could be customized. You could select any item from any
| menu and place it on toolbar for quick access. So unique icons
| for every menu option were useful.
|
| Even now i think MS office has a quick access toolbar on top that
| can be customized that way. Tad limited.
| alansaber wrote:
| I agree with this. Consistency > immediate design beauty
| rpns wrote:
| This is what the Windows Vista/7-era UX guidelines say/said on on
| the matter:
|
| Consider providing menu item icons for:
|
| - The most commonly used menu items.
|
| - Menu items whose icon is standard and well known.
|
| - Menu items whose icon well illustrates what the command does.
|
| If you use icons, don't feel obligated to provide them for all
| menu items. Cryptic icons aren't helpful, create visual clutter,
| and prevent users from focusing on the important menu items.
|
| From: https://learn.microsoft.com/en-
| us/windows/win32/uxguide/cmd-...
| Bengalilol wrote:
| The first Google example is a nice one: You could have only one
| icon for each group (one trash for all the 'delete' actions', one
| share icon for all the 'share / download' actions, etc). That
| would be really helpful, for what it is worth.
|
| Globally, I had a pleasant time reading this article which was
| way too dedicated to something that is almost invisible in its
| current state (ie: I don't notice those icons and surely think
| they aren't _that_ helpful for any type of user unless used in a
| rare way).
| pacifika wrote:
| Yes menu item group icons would be a much better anchor: third
| icon under such and such icon
| yakshaving_jgt wrote:
| Designers insist on "consistency", meaning if something applies
| in one place, it must apply in every place.
|
| This is misguided.
| KronisLV wrote:
| I wouldn't have an issue with _every_ menu item having an icon,
| _if_ we could make every single one different enough to be
| distinguishable from the others.
|
| The problem is that you only have so many ways to draw the shapes
| and at your average resolution it ends up looking like "this
| group of squares with squiggles in them" and "this other group of
| circles with squiggles in them".
|
| In some cases like a power menu or window snapping menu (like in
| the Mac Rectangle app) they can be insanely useful, though maybe
| those are easy to do because the count is kept to a reasonable
| amount. Maybe there are exceptions where the same icon can be
| used for multiple items, like in the insert/delete action
| groupings, to make the group distinguishable from the other
| options.
|
| But in general, it just seems like the menus have perhaps too
| many items in them.
| Tade0 wrote:
| I had a professor in college explain to us that we shouldn't even
| be colouring buttons, as it always ends poorly. That being said:
|
| > In so many of these cases, I honestly can't intuit why some
| menus have icons and others do not.
|
| I understood this the first time I had to explain to a non-
| technical user how to get to a certain menu item. Fortunately
| whoever made the Wordpress admin dashboard nailed the design so
| icons are sufficiently visually distinct.
|
| You can only have so many of them though, so you use icons to
| draw attention to the most important features from a non-power
| user's perspective.
|
| Of course not everyone places them with sufficient care and I
| think that's what's lacking at Apple, but it's not like they're
| there purely for decoration.
| ChrisMarshallNY wrote:
| Personally, I don't like to use icons in menus. I do like them in
| tab bars and toolbars. I've learned (the hard way) to be sparing
| about using icons. Way back in the 1990s, I designed a scanner
| driver plugin that used an almost purely iconic interface. Looked
| great. At the time, I was gaga over Kai's Power Tools[0].
|
| Our customers _hated_ it, and it was quickly taken behind the
| woodshed, and buried in a shallow grave in the desert.
|
| Icons are really difficult.
|
| Designing icons is _really_ hard. They need to be immediately
| recognizable, when very small, and also, retain coherence, when
| made very large. They need to be recognizable, when displayed as
| transparent, monochrome templates, and they need to be culturally
| relevant.
|
| In some cases, there may be legal ramifications for icon choices.
| For example, branding. I remember someone complaining about Apple
| rejecting their app submission, because they changed the tint of
| the Sign in with Apple button to match their color theme.
|
| Selecting from a set (like SF Symbols) takes a lot of thought. I
| have to be careful not to use one that is already a common icon
| for something other than the feature I'm attaching it to. I often
| see apps that make weird choices.
|
| One of the apps I wrote, uses a "long press to learn more"
| feature. If you long-press on almost any item in a screen, you
| get a haptic, and a small popover appears, displaying the
| accessibility label and hint. Works nicely. Ensures that I have
| good accessibility support, doesn't interfere with other
| gestures, and also forces me to be thoughtful about accessibility
| text.
|
| Kind of a pain to implement and maintain, though. I don't do it
| in most of my apps.
|
| [0] https://mprove.de/script/99/kai/2Software.html
| immibis wrote:
| Windows 95 really was peak UI.
|
| IIRC that standard was to put the toolbar icon next to any menu
| item that was also a toolbar button. Otherwise, don't put one.
| alkonaut wrote:
| I think this, as with many user interfaces, comes down to the use
| case.
|
| A rarely used UI needs to be easy to navigate. Remove clutter,
| place the often used feature front and center and the rarely used
| features behind multiple navigation steps. The user primarily
| _navigates_ this UI, they don't _memorize_ it.
|
| A constantly used UI such as an application that a professional
| uses from 9 to 5 five days a week (An IDE, a Cad Program, a video
| editing thing) is a completely different beast. The speed of
| accessing a feature is more important than the discoverability.
| The user internalizes the UI and the UI needs to aid the user in
| doing so. Icons in menus means the user eventually doesn't need
| to read the text label.
| cladopa wrote:
| I like them, for whatever reason icons are a good thing for me.
|
| I believe different people literally see the world different and
| there should be an option to remove icons if they prefer this
| way. It used to be this option at least in some programs.
|
| But of course this person doesn't like it, and it wants everyone
| to follow his taste.
| nticompass wrote:
| I don't understand why removing menu icons is a good thing.
| Firefox did it and I absolutely hate the change:
| https://blog.mozilla.org/ux/2021/06/content-design-considera...
|
| I actually use Zen browser and thankfully someone made a "mod" to
| bring them back: https://github.com/SivanTechDev/zen-
| themes/tree/main/BringBa...
|
| Maybe it's just me, but the icons are NOT noise or a distraction,
| they actually make it quicker and easier for me to find what I
| want. Yes, I can read the words, but sometimes things blend
| together, such as "unload tab" and "unpin tab". The icons make it
| easier to tell them apart. Also, again maybe just me, but I
| remember the icon for the action I want and it's much quicker for
| me to scan the menu to find the icon than to have to read every
| piece of text.
|
| Anyway, lots of people don't like the removal of icons, me being
| one of them, and I think the icons are nice and should stay in
| the menus.
| sunaookami wrote:
| Agreed, icons make it way faster to scan menu items, also hate
| that Firefox removed them. I'm constantly searching for the
| correct entry.
| masswerk wrote:
| I'd suggest a simple test: remix menu items and icons and test,
| if this has significant impact on usability. If not, the icons
| are just arbitrary decoration and ultimately add clutter.
|
| Referring to the examples provided in the article, I'd suggest
| that the impact on the Safari app menu should be minimal (so
| these are non-functional icons), while the impact on the Move &
| Resize submenu would be devastating and should result in
| confusion (so these are essential).
|
| If you can remix with minimal impact, don't do icons. (In the
| case of the app menu, these are apparently meant to add
| structure, which is already established by other means like menu
| separators, so you have now two - or, including indentation,
| three - systems of structure and visual hierarchy that are
| fighting each other.)
|
| Moreover, if you put icons everywhere, you're forgoing the
| facility to convey state, like active state checkmarks, since
| these, instead of standing out and signalling change, would be
| just drowned in the decorative clutter. (So what's next? Add
| color and/or animation, like swirling checkmarks?) And this, BTW,
| is also why the icons in the Move & Resize menu are effective:
| they are conveying and illustrating state (in terms of a
| preview), while most of the other menu icons (mostly referring to
| activities) do not. So, as a rule of thumb: icons referring to
| state may be useful and even desirable, while icons referring to
| activities are probably better left out. (And, if you feel the
| need for something like bullet points to mark your most important
| menu items, there's probably a deeper problem with your menu
| structure.)
| Nemi wrote:
| Slightly off topic, or at least tangential, Zapier has one of the
| most user-unfriendly interfaces I have seen in a while. When you
| log in, they have a left hand toolbar that runs down vertically,
| and it is icon only. I understand why they do this, being on the
| left hand side you don't want to take up much space. But unlike
| other user interfaces that employ this type of toolbar, you CAN'T
| see what each item is by expanding the toolbar or even hovering
| over the item! The only way to see what each one is is to click
| on it. This is a pinnacle of terrible UX. I love Zapier, but it
| makes me question their product offering if they can get this so
| wrong.
| thunderbong wrote:
| In most elevators around the world, there are buttons to keep the
| doors open and also to get them to close. I've only seen symbols
| on them. Once, however, in the US, one gentleman got in, and
| instead of pressing the close button, pressed on the open button.
| So the doors, which were just going to close, opened again.
|
| He complained - Why do they have these symbols, why can't they
| they just write Open and Close?
|
| I've wondered about this every since - is it an American thing to
| have an expectation to have text everywhere? I have never heard
| anyone complain about those symbols before or since!
| wl wrote:
| The open button looks like closed doors and the close button
| looks like open doors. I have to look at the symbols carefully
| and interpret the arrows every time. Or tell myself that the
| buttons do the opposite of what they look like at a glance.
| "open" and "close" would be easier.
| matty22 wrote:
| Call me crazy, but those icons are not different enough to be
| quickly readable. If the open and close icons on the elevator
| were distinct from one another words wouldn't be necessary, but
| the exact same icons rotated 180 degrees are indeciperable at a
| glance.
|
| It takes noticeable processing time to know which is which.
| Especially with a button that you need to hit as quickly as
| possible to hold the door for someone, those icons should be
| widely different from one another. I can't count the number of
| times I've meant to hit the open button to hold the elevator
| for someone only to accidentally hit the close button just in
| time to make eye contact with the person we've left behind.
| mrcino wrote:
| The UI/UX design is not about standards and guidelines but about
| what the manager currently likes. There is no discipline because
| senior managers don't care until Excel cells turn red.
|
| Steve Jobs was forcing design discipline across Apple products
| with furious determination because he actually cared.
|
| That's how it ends, everything becomes an unmanageable,
| constantly changing mess because every manager likes something
| else and big firms are rotating their personnel every 3 years.
|
| Because the above products of the same company are losing
| cohesion and consistency even if they are in the same product
| line which results in bad UX.
|
| Design departments are not disciplined enough...
| c-linkage wrote:
| The Mythical Man-Month calls for a single person to be
| responsible for the design of a system. Steve Jobs was that guy
| for Apple. But once he left, there was no one strong enough to
| define the system across the whole company.
| _kidlike wrote:
| putting aside accessibility, I believe that the usefulness of
| icons boils down to brain efficiency.
|
| Considering that the brain has hard-wired neurons (since birth)
| to automatically count/recognize up to 3 objects, we need some
| icons as anchor points. With emphasis on some.
|
| You can have max of 3 icons in a row, and a max distance of 6
| items without icons.
|
| Then you can VERY quickly find any menu item, by doing "+/-3 from
| X anchor" math, which your brain does extremely efficiently.
|
| Further, this means that an action is represented by a relative
| path (e. g. save as = 1 down from the save icon). This further
| helps the brain to store these associations, because it's also
| extremely efficient at storing relative paths. So, long time
| users automatically become more and more efficient at using your
| software.
| ggregoire wrote:
| Emojis in comments, terminal logs, git commits, documentations,
| everywhere... Send help
| praestigiare wrote:
| One thing that I think is demonstrated in the Safari "file" menu,
| the most common things you might need under that menu* have
| icons, which means you can scan to them very quickly.
|
| * Note here that most common things you need under the menu are
| not the same as the most commonly used commands. New tab and new
| window are surely the most commonly used commands, but those you
| would almost never go to the menu for.
| wraptile wrote:
| I really dislike how minimalism took over the world. The brain is
| pretty awesome and more information does not always equate to
| longer processing time. Sometimes more is simply more.
| hadlock wrote:
| This blog post was written by someone who speaks/reads english as
| a first language.
| culanuchachamim wrote:
| Maybe im a weirdo and maybe I'll get dowvoted... But I only feel
| gratitude to the UI designers and the digital artists that they
| only think how to make it better for the user both in terms of
| creating a communication that uses less symbols per word and a
| more pleasent view for our eyes.
|
| I also learned here that no matter your intentions and how much
| good you are going to do,and how many people like it, you always
| find someone not confortable (with his right point of view).
|
| The fact that millions of users and millions of designers choose
| this style,for a long period of time now, it means that for most
| of them it make sense.
|
| (Sometimes millions of users are screw up by bad designs, but
| usually is for a short period and by a handful of developers).
|
| Things that consume energy and don't help life don't have a long
| life, that's what we learnt in biology.
___________________________________________________________________
(page generated 2025-12-09 23:01 UTC)