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.
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
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.
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
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.
> 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
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.
I concur that the icons aren't just decoration. I have sat down many times in a foreign country at a computer with localized settings and felt quite helpless to do even trivial things.
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.
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.
hamburger icon: originally, in older Android UI guidelines, provides access to a list of items that can be used to navigate between parts of a large UI. But at this point, pretty much evolved to mean "click to access a menu" on UIs that don't have a menu bar.
Three vertical dots: "More stuff that doesn't fit on a toolbar because the display on your current device isn't wide enough".
Three horizontal dots: click this item to access a dialog.
Point-down triangle: Select an value from a list.
There may be slight variations depending on the UI guidelines for the platform you are using (or designing for).
All enormously useful icons that provide specific context and meaning. I can't say that I've ever seen a piece of serious software that abuses those conventions.
> 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.
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.
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.
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".
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.
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.
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).
... 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.
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.
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.