This is only a minor topic, but I think the default style is very important for users: Currently the first thing I do is go to System Settings and disable icons in menus and in buttons, because

1.) in menus icons are chosen very inconsistently and do not exist for some actions
2.) the icons in buttons do not look particularly good, it creates kind of an asymmetry and creates more problems than it solves (just think of arabic languages that read from right to left, the icon position is not flexible as far as I am concerned).

I think in menus the icons can be discussed, but in buttons the default should be without icons in my opinion.

In menus the icons can really make sense for complex applications like a CAD program when you want to create different shapes etc., so they should definitely be provided. What I would like to see: Monochrome icons, as the colored icons in menus only distract without adding any value, neither design wise nor from a usability point of view for most cases.

To conclude I would leave icons in menus (but monochromatic, or at least using a minimum set of strong distinct colors), but disable icons in buttons.
What is your opinion on that?

I do this too, as a matter of fact Nitrux OS has this disabled by default because I never liked icons in the contextual menus (I don't like contextual menus at all anyways). I do think however that text labels on buttons is acceptable.

Now, when you say buttons do you refer to buttons like: Accept, Cancel or "buttons" like the toolbar widgets in the windows: Back, Forward, New tab, etc.

For your #1: That's strictly a topic of the icon theme in use.
For your #2: Locale aside, it makes the buttons feel cluttered.

The new icons will be monochromatic, so there's that, but I'd just remove icons from contextual menus and from the buttons altogether.

Ok so I'd love to be the devils advocate here. The one upside with icons in contextual menu's is when its a large and complex application with difficult menu choices is that they can guide you in the beginning. I'm thinking of applications like Inkscape and Kdenlive for example.

Making them monochromatic seems good but replacing them with text tend to be tricky in these larger applications.

(as an aside and when not talking about such a large project like Plasma, I agree with Uri 100% - contextual menu's are a massive pain)

I don't think context menus as such are a pain. They're actually helpful as shortcuts. The problem is that many applications rely heavily on context menus as the main way to do something, and that's always a bad idea.

jensreuterberg wrote:Ok so I'd love to be the devils advocate here. The one upside with icons in contextual menu's is when its a large and complex application with difficult menu choices is that they can guide you in the beginning. I'm thinking of applications like Inkscape and Kdenlive for example.

Making them monochromatic seems good but replacing them with text tend to be tricky in these larger applications.

(as an aside and when not talking about such a large project like Plasma, I agree with Uri 100% - contextual menu's are a massive pain)

These softwares often display the same items that they have in their menus on their toolbars. I know Inkscape does. Inkscape has a File menu, the items on that menu are also in the toolbar, not all of them, but most of them are, the same with Edit and Tools and the others. They're prone to redundancy.

I do like the icons in menus usually, but sometimes I dont. Why it is nice that I can disable them when comes to timeperiod I like to see plain GUI.

The icons in buttons is important usability feature, as people much quicker recognize the button what they want to click without searching or thinking it. And thats why it is so terrible when you see when people use different GUI (Windows, KDE, GNOME, OS X) at their workflow and they mistakenly click wrong buttons because the order just was reverse. Or they don't simply notice the plain button at bottom because buttons are same color range/brightness as background is and there are just enough white space between buttons and the contrasty content.

The icons in menus does same thing, and I have found that the icons should be there only in most important functions, what either are most used or then requires differetation between types (like the CAD example above, or check Inkscape menu for different object combination etc). A small icon brings contrast, fast recognition and clarity what the action does.

But add there too many, too similar icons and you have a problem in your hands.
Why longer time ago I made design for digiKam editor application "showFoto" to simplify the workflows.

That was done simply re-organizing the most common tools what photographers / editors need quickly to sidebar. Most common type were located on top, most often used to left. And same time the button size was enlarged or kept normal based the typical need.




With that kind situation the icons were impossible to use in buttons. They would have bought clarity to functions but because changing layout and button location just caused huge problem there. So if that kind would follow the user settings, those who would have icons enabled for buttons would see huge mess.

I wouldn't condemn icons so much. They support orientation by fast identification of common functions (e.g. scissors for Cut), and make sense at least in extended menus. For just Copy/Paste/SomethingElse it obviously clutters the menu. Therefore we wrote in the HIG about context (and main) menus "Provide menu item icons for the most commonly used menu items.".

In respect to push buttons (icons are imperative for toolbar buttons) the guideline was adopted from the previous page: "Prefer using icons on buttons only for OK, Apply or Cancel like actions. Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons."
In my opinion that's an 80th style and I agree with your idea. At least the Okay/Cancel group does not need icons.

PS: Beside the aesthetics of monochromatic layouts, color can be used as additional indicator, e.g. design icons in red to identify disruptive functions or think about a couple of icons concerning one type of functionality with blue decoration.

I think keeping icons in menus would be best but change them to black & white (as suggested already), they make the more common functions easier to find when their icons are easily recognisable (like the scissors icon for 'cut' etc). I like the idea of simple black & white icons but with the odd coloured one to draw attention to a very important command like the red cross for 'delete'.

When every menu item has an icon then the menu will look cluttered and those commonly used items won't stand out anymore. I think we should only have icons on the more common actions, then they'll help guide more casual users to pick out the common items they're looking for & help our menus seem less intimidating at first glance.

You can configure the hell out of KDE! And, of course, you can switch on/off icons as well...

Heiko Tietze wrote:You can configure the hell out of KDE! And, of course, you can switch on/off icons as well...

Sure. I think this is again pretty much discussion of details and defaults. Personally, I think icons on buttons are great. GNOME did away of icons in buttons by coloring important buttons red or blue, which is also something to consider instead of icons. It looks really sleek.

Like others have said, icons in menus is bad idea if there are too many of those. Having nice monochrome icons for practically universal commands (new, open, save, save as, undo, redo, cut, copy, delete, paste) on the other hand would be nice and bring KDE menus a bit more in line with look&feel of Chrome and Firefox menu.

Other thing now that we are talking menus... Those keyboard shortcut cues which are visible in menus should be of different shade than name of command. I'd use #5C5C5C for that purpose.

Heiko Tietze wrote:PS: Beside the aesthetics of monochromatic layouts, color can be used as additional indicator, e.g. design icons in red to identify disruptive functions or think about a couple of icons concerning one type of functionality with blue decoration.

Isn't there already a way to actually change the button / group header font color based the button / group meaning?

Like having green/blue "OK", red "Cancel" and then green "Apply".

Or in some cases get the button colored with the color, giving it a really dangerous meaning when "Apply" would have red background and font being white. And in those cases if the background would blink in same rate as the text input cursor (the one what is shown when writing like this), it would really be serious warning.

Oh, forgot to add, of course as there is required to be a usability setting for color blinds, the setting would correspond to those button colors as well.

Fri13 wrote:

Heiko Tietze wrote:PS: Beside the aesthetics of monochromatic layouts, color can be used as additional indicator, e.g. design icons in red to identify disruptive functions or think about a couple of icons concerning one type of functionality with blue decoration.

Isn't there already a way to actually change the button / group header font color based the button / group meaning?

Like having green/blue "OK", red "Cancel" and then green "Apply".

Or in some cases get the button colored with the color, giving it a really dangerous meaning when "Apply" would have red background and font being white. And in those cases if the background would blink in same rate as the text input cursor (the one what is shown when writing like this), it would really be serious warning.

Oh, forgot to add, of course as there is required to be a usability setting for color blinds, the setting would correspond to those button colors as well.

Have you just made a really really extreme suggestion or are you mocking us?