Icons have to mean something somewhere. for example:
The save icon above will be seen on the toolbar without the text and users could use it to map it to the action of saving.
Typescript files have the icon in your finder or file system to map it to type script.
The ones like:
Export to BOM
The general practice ...
Icons are effective inversely proportional to their frequency.
If everything has both text and icons, the interface becomes crowded. I would only add icons to common actions.
IMHO, both your submenu and the menu in the SQL Developer example are too crowded.
Each design/development team will have their own criteria for doing this, and hopefully it is aligned to some kind of design system or convention that they have established for their product/service.
Briefly speaking, there might be a number of reasons and it is most likely to be a combination of them, some are design related while others are probably more ...
I don't think there's an "official" methodology for this, but I've noticed a pattern across a number of programs. Many programs - especially IDEs - have a number of commands that can be accessed both through drop-down menus and through toolbar buttons. An icon is required for a toolbar button, and the same icon is usually used for that command in the drop-...
Simple answer, "Yes".
They chose to provide icons to ubiquitous actions and where applicable they used icons which can be pulled from existing use such as file icons.
There is no need to iconify actions which have esoteric meanings and would differ between one app and another.
Check out Oracle's SQL Developer for more examples on not iconifying everything:...
There are a couple of reasons:
If there is a generally accepted icon for that feature. Examples, save, cut, copy etc.
If the feature is borrowed from another application which has an app-icon. For example, sharing on facebook can use the Facebook icon.
Context of use, if a lot of the similar icons are displayed together, the icons will lose their purpose. ...
One problem with your first example is in deciding which message to summarize.
In your example, there appear to be two messages (one informative: there's an update available; one error/warning: connection issue). By showing an summary of the informative message, you are actively hiding the presence of the warning message (the user might not want to update ...
Gives more details, but not a quick overview of the amount of things present
Is more interesting to the user, since he can quickly assess how interesting this information is for him and decide if it is worth it to click on it at all
Provides general overview, but without any context
Depending on frequency of the notifications, users ...
There's a third option similar to the one used on this page: the message tray icon that is only activated when it has some content with the corresponding number.
The message tray can contain any type of message or alert: not just a type but any
It doesn't disappear when there is no any alert, it simply occupies the same place, it's a way of ...
I think your first option provides more context to the user. Gives a clearer idea of what is happening and I would suggest dropping the icon and instead, go for a coloured label to indicate something. Like Sketch do here...