Agreed, absolutely.

The other thing is that full-color, textured icons help a great deal with immediate recognition as well. It's easy when the "open" icon is a yellow folder.

Sadly, the move to flat design with monochrome icon outlines destroyed that entirely. I'm still waiting for full-color icons to come back in style again. They can still be flat, but being filled with color (not just colored outlines) helps immensely with fast recognition.

I absolutely despise color coding. I'm red-green colorblind but that affects all colors that have red or green as part of the mix.

What the GP is asking for does not affect the color blind. They are not suggesting there should be multiple folder icons of different colors. They just want color included in the existing icons. My understanding of color blindness means that that would be better for people with color blindness as well.

Particularly with this example, because even with the not-the-same-yellow that a colorblind person would see, it would still end up closer to the object the icon is based on: https://www.amazon.com/AmazonBasics-File-Folders-Reinforced-...

I’m deuteranomolous myself, but I disagree. Color, shape, labels, and location can all combine to be useful for recognition. Using color alone is definitely a mistake, or making color the only difference between two icons. But combine distinct shapes and distinct colors (informed by color-blindness awareness) for the best results.

Why does the folder color matter? Is it just because that is what you are used to from a specific OS?

Color helps for some people but when making an accessible design you have to account for color blindness and other vision issues. Which means the icon needs enough contrast and can’t rely on just color to convey meaning, unless the icon is paired with a text label that also conveys the meaning the color was trying to convey.

So while I agree that color iconography can be extremely helpful for the average user, unless it is supplemented by other techniques it can make a product completely unusable for a subset of users

The commenter did not say yellow was important per se, or that the color yellow was the most important property of the icon.

The commenter said that adding distinct colors to icons help users tell them apart.

Folders were always yellow on Windows because people were used to Manilla folders.

In the example, the folder is recognizable as such from just its shape. The color merely makes it more recognizable (because folders are yellow on Windows — it reinforces that the icon depicts a file folder).

For accessibility reasons, you shouldn’t rely on only the color, but that doesn’t mean that color isn’t a very useful property to apply.

In your first example, my intuition tells me if some elements are more important than others in away that's worth distinguishing with icons, it's better to think on providing easier access to them (priority at the top?) or hiding the rest.

There's 17 options there, where only 5 are deemed important.

The second example is bad for different reasons. There's no apparent rime or reason to the options other than "places you might want to check", no grouping and no priorisation. It would be a hard to parse with or without icons.

The brilliant thing about the first example is that differentiating "important" items with the icon actually allows multiple forms of categorizing items in the list, whereas your suggestions only allow one. The items in the list are grouped by topic, and important/common ones are highlighted with an icon. Hiding the less important options makes them needlessly harder to find if/when you do need them. Moving important items to the top breaks the topical grouping. In both cases, the application becomes less discoverable.

+1 it would be silly to ungroup all the save actions

In the first example the items are grouped by topic (such as “printing”), which I think makes sense. When you go select a “frequent” action, it’s useful to see which “less frequent” but related actions exist nearby. And the icons not being all grouped together but being (partially) isolated actually helps in better recognizing them.

It’s from Microsoft Word ('97, I believe), by the way. A later version had “expandable” menus that by default only showed the most frequently used options, and on expansion (or by global setting) then also showed the other options. Many users didn’t like that, however, either because they missed that the menu could be expanded and thus didn’t find the item they were looking for, or because the expansion changed the relative locations of the items, meaning they were at an unexpected position depending on the expansion mode; or just because the expansion required an extra click.

I’m just noting this because Microsoft deemed the topical grouping of items within the menu important enough that they kept it, orthogonal to the expansion mechanism. And they doubled down on the grouping with the later ribbon interface — which I personally dislike because it’s not linearly greppable and feels jumbled, and they felt the need to give every item an icon there, whether memorable or not.

> it's better to think on providing easier access to them (priority at the top?) or hiding the rest.

Microsoft tried it. Hiding things doesn't work. Because what is unimportant to you is important to someone else.

See Why the UI https://web.archive.org/web/20080316101025/http://blogs.msdn...

--- start quote ---

There was no way to get the default "short" menu right. Although conventional wisdom holds that "everyone only uses the same few features in Office," the reality is that people use an amazingly wide range of functionality. So, one person's ideal default "short" menu was exactly the wrong thing for someone else.

--- end quote ---

This is essentially the problem that the average user uses only a few features, but no actual user only uses those features.

Hiding parts of the menu hinders discoverability when those options are needed, creates a need for one extra action to show all the available options, and messes with the users' spatial and muscle memory. This particular mistake was already made a quarter of a century ago, in Office 2000.

The easy access is that there is an icon next to them. Providing a collapsible menu just breaks muscle memory and adds an extra click to the other items. Microsoft tried this once.

I prefer every item having both text and an icon. If I don't know what the icon mean, there's text there to explain it. If I do know what the icon means, i can scan just the icons and find what I need faster. In my opinion it's the best of both worlds. That being said, your first example might be even better, because a lot of those things like "close" or "versions" I'm not going to be clicking often, so if they had an icon I'd have to read the text to figure them out every time anyway

Same for me.

In case it’s useful to someone, in many native Mac apps you can get the main toolbar to show both. Try right-clicking on the toolbar -> Customize Toolbar -> Icon and Text. Doesn’t work everywhere though, but still super useful to me, I enable it whenever I can.

But it's not as compact as icons only, which to me is the main advantage of icons. All icon buttons should have hover text with the command name of course.

This is an example for something I have always troubling arguing with in technical discussions: Sometimes a solution only works if you apply it partially, "in good measure".

I can imagine the discussions on the issue above with the outcome being either no icons, or icons on every item, but nothing in between.

How go about convincing a group of people about this?

When it comes to quantities, point to https://en.wikipedia.org/wiki/Subitizing. Simply put: "1, 2, 3, 4, many". Designers should be conscious when quantities might cross this (approx) subitizing threshold, and consider increasing the dimensionality with nesting or other techniques, rather than allow the size of simple visual sets to become overwhelming to users.

Whether intentional or not, the Windows example has exactly 4 icons in that column, and the rest are blank space. This makes it easy to visually navigate to, and identify, those emphasized options.

The first example was used together with a toolbar. Commands that had buttons on the toolbar also had icons in the menu, so the user could make a connection between the menu and the toolbar.

The second example uses icons merely as a decoration. This is a wrong usage.

Aside from that toolbar example menus normally should not have icons at all. A good use of icons is a list that may have items of different kind, like a list of files that displays a pictogram for each file type or maybe a tiny preview of the file's contents.

I am wondering why I agree with you!

I think because the shape creates landmarks. This is why some cities are easier to navigate than others. You need some stuff to be different.

The icons are also used on the most commonly used items.

"Groups" on that Git forge probably isn't used as often as "issues" but they both have vague little grey icons.

"Issues" should just be an icon of a bug

Yes, it’s the non-uniformity. The icons being colored and having high contrast also helps. They furthermore highlight the most important functions.

The thing is you should structure your interface the way a good craftsperson would structure their tools.

That means a single-digit number important tools should be directly accessible, ideally in the order in which you usually need them. Other tools sbould be organized in sections that make sense, even if you don't make these sections explicit.

For example in the shown gitlab sidebar you put milestones and activity next to each other as they both are related to project managment. Projects and Groups maybe should just become something like "Dashboard" or "Overview" as having separate pages for them is probably not the most efficient way to get you where you want etc.

Just putting everything in a menu is thr lazy option, the good option is to tbink long and hard how to organize the tools and create good defaults that suit many people

Should have done BitBucket's menu. Every entry has an icon and they are all some variation on arrows pointing at dots. Completely useless.

I don't think its too bad (assuming you mean this one, I can't find a higher-level one) https://i.imgur.com/V06bwjJ.png There are a few similar arrow-and-dot ones, but at least they're directly connected to the related git action. The gitlab one... milestones are a clock, but activities are a clock running backwards? Projects and issues are just sets of rectangles in a different rotation. I feel like part of the problem is these concepts are not themselves super coherent already, but they didn't do a great job either. (how about an actual mile marker for mile-stones?)

To me the icons in the first are not useful and they are also distracting, I immediately only scan the text while ignoring the icons.

I also immediately ignore the icons and scan the text on the latter one.

I guess it's mostly from not trusting icons, the only ground truth comes from the text where there's no possible alternative meaning.

I wonder if the earlier Windows 95 style with a few choice icons was a deliberate design decision, or just a budget limitation? I'm thinking it's probably the latter. Funny how a limited budget often leads to better results.

I think the convention was that if the same command was activated by a menu item and a toolbar button, you put the icon from the toolbar button next to the menu item. This also tells the user that they can access the command more quickly in the toolbar, and doesn't force the user to only learn the toolbars by hovering the cursor over every icon.