Re: Action icons in menus
This is a very interesting concept, but not necessarily for context menus. Imagine this design proposal as a first step towards merging window menu and toolbars, not too disimilar from the Microsoft ribbon. One weakness with the ribbon is that it limits the amount of functionality by what can graphically fit in the ribbon interface. Instead of going pure graphics, you could merge frequently used tasks (graphics) with extended functions and features (text menu items). This would preserve the amount of functionality in an application (Microsoft stripped out some features or moved them to different places in order to fit them in the ribbon). At the same time, we would have an updated look and feel to our windowing concept that maximizes common interactions. I think something like this could also be an interesting alternative to what IE7 does by providing minimal toolbar buttons and menu items, and hiding everything else. In this design, additional functionality would be on a true second layer of disclosure rather than hidden away. Anyway, just some thoughts. I don't want to discount the design simply because of a few minor issues, because it is still in the conceptual stage. We don't want to shoot down ideas like this too early in the design process, otherwise we will never innovate. Just some thoughts. On Mon, Dec 13, 2010 at 2:56 PM, Miha Čančula miha.canc...@gmail.com wrote: I have recently come across an idea on KDE Brainstorm. [1] The proposal is to change the common actions in menus (cut, copy and paste) from text lines to icons, like in application toolbars. It is currently the most popular idea there. Someone posted a proof-of-concept example of how this can be achieved, and I used it for Dolphin's popup menu. [2] Code-wise, this change is very simle (5 lines of code at most). Qt can embed custom widgets to menu via the QWidgetAction class, and this class can contain a KToolBar. It has to be done for each application, but there's very little work involved. If the idea is accepted, a convenience method or two would be added to KMenu and/or KStandardAction, so there could be a global settings to fall back to current mode. However, it is a major change for user interaction. So I'd like to start a discussion whether such a change is desired for KDE applications or not. The pros and cons I can think of right now are: Pro: 1. Biger clickable area = less chance of misclicks 2. Icons, when they are intuitively identifiable with an action, can be recognised by humans faster and much easier. I think the above makes it better from a usability standpoint, but as a programmer I wouldn't know much about that. Con: 3. For actions that are not easily identifiable by an icon, this is very bad. This is the reason only some of the actions would be converted to icon display, as you can see from the mockups and screenshots. 4. It looks (a little) like the ribbon UI. I personally believe such a change is a good thing. However, there must be limits. Using it in right-mouse-button menus is one thing, using it in the File menu is another. I would very much like to know how you feel about this. Thank you, Miha Čančula [1]: http://forum.kde.org/brainstorm.php?mode=ideai=89969#anchormain [2]: http://www.flickr.com/photos/noughmad/sets/72157625584527238/ -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org
Re: Action icons in menus
This would also be a great topic for a developer to work on during a UX sprint :) 2010/12/24 Celeste Lyn Paul cele...@kde.org: This is a very interesting concept, but not necessarily for context menus. Imagine this design proposal as a first step towards merging window menu and toolbars, not too disimilar from the Microsoft ribbon. One weakness with the ribbon is that it limits the amount of functionality by what can graphically fit in the ribbon interface. Instead of going pure graphics, you could merge frequently used tasks (graphics) with extended functions and features (text menu items). This would preserve the amount of functionality in an application (Microsoft stripped out some features or moved them to different places in order to fit them in the ribbon). At the same time, we would have an updated look and feel to our windowing concept that maximizes common interactions. I think something like this could also be an interesting alternative to what IE7 does by providing minimal toolbar buttons and menu items, and hiding everything else. In this design, additional functionality would be on a true second layer of disclosure rather than hidden away. Anyway, just some thoughts. I don't want to discount the design simply because of a few minor issues, because it is still in the conceptual stage. We don't want to shoot down ideas like this too early in the design process, otherwise we will never innovate. Just some thoughts. On Mon, Dec 13, 2010 at 2:56 PM, Miha Čančula miha.canc...@gmail.com wrote: I have recently come across an idea on KDE Brainstorm. [1] The proposal is to change the common actions in menus (cut, copy and paste) from text lines to icons, like in application toolbars. It is currently the most popular idea there. Someone posted a proof-of-concept example of how this can be achieved, and I used it for Dolphin's popup menu. [2] Code-wise, this change is very simle (5 lines of code at most). Qt can embed custom widgets to menu via the QWidgetAction class, and this class can contain a KToolBar. It has to be done for each application, but there's very little work involved. If the idea is accepted, a convenience method or two would be added to KMenu and/or KStandardAction, so there could be a global settings to fall back to current mode. However, it is a major change for user interaction. So I'd like to start a discussion whether such a change is desired for KDE applications or not. The pros and cons I can think of right now are: Pro: 1. Biger clickable area = less chance of misclicks 2. Icons, when they are intuitively identifiable with an action, can be recognised by humans faster and much easier. I think the above makes it better from a usability standpoint, but as a programmer I wouldn't know much about that. Con: 3. For actions that are not easily identifiable by an icon, this is very bad. This is the reason only some of the actions would be converted to icon display, as you can see from the mockups and screenshots. 4. It looks (a little) like the ribbon UI. I personally believe such a change is a good thing. However, there must be limits. Using it in right-mouse-button menus is one thing, using it in the File menu is another. I would very much like to know how you feel about this. Thank you, Miha Čančula [1]: http://forum.kde.org/brainstorm.php?mode=ideai=89969#anchormain [2]: http://www.flickr.com/photos/noughmad/sets/72157625584527238/ -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org
Re: Action icons in menus
2010/12/24 Celeste Lyn Paul cele...@kde.org This is a very interesting concept, but not necessarily for context menus. Imagine this design proposal as a first step towards merging window menu and toolbars, not too disimilar from the Microsoft ribbon. One weakness with the ribbon is that it limits the amount of functionality by what can graphically fit in the ribbon interface. Instead of going pure graphics, you could merge frequently used tasks (graphics) with extended functions and features (text menu items). This would preserve the amount of functionality in an application (Microsoft stripped out some features or moved them to different places in order to fit them in the ribbon). At the same time, we would have an updated look and feel to our windowing concept that maximizes common interactions. I think something like this could also be an interesting alternative to what IE7 does by providing minimal toolbar buttons and menu items, and hiding everything else. In this design, additional functionality would be on a true second layer of disclosure rather than hidden away. Anyway, just some thoughts. I don't want to discount the design simply because of a few minor issues, because it is still in the conceptual stage. We don't want to shoot down ideas like this too early in the design process, otherwise we will never innovate. Just some thoughts. I've just setup a trunk kdelibs build on my home computer so I can show some examples of how this would look in both popups and applications menus. However, I won't be home for the holidays and I won't be able to work on this this year.
