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.
Re: Action icons in menus
Am Montag 13 Dezember 2010, 23:42:37 schrieb Dan Meltzer: If common actions were all handled in this way, then it might actually lead to more consistancy, and ease of access. I don't know.. how do I know whether I need to look for a large toolbar button at the top or for a regular menu entry below? Who decides *what is a common action*? (For instance, I usually remove cut/copy/paste from toolbars, since they waste space - come on, who uses the mouse for those actions??) Actions are not particuallarly consistant across applications, It depends, in particular the cut/copy/paste set is typically found in (roughly) the same space, in the Edit menu. That's a matter of UI style guide and I don't think we suffer from this w.r.t. those common actions. (Please give concrete examples if you disagree.) and so it becomes necessary to read the entire list to find the item you are looking for. ..yet I find it easier to read through one long list than to a) first, read the toolbar items at the top, and then b) read the list below, which is in a totally different formatting. I think that's my main problem with M$'s ribbons: I feel it takes me more time to locate actions which I know to be there (somewhere). If cut/copy/paste were always found as icons at the top of the menu in applications that support them, it would probably lead to accessing them quicker. But only if the set of icons does not change from app to app, no? Then, what's the difference compared with a predefined section in the edit menu (possibly requiring the actions to be at the top)? Just my critical 2 cents, Hans
Re: Action icons in menus
On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our shortcuts where documented in some menu anyway. Probably half of KMail's shortcuts do not correspond to any menu entries (but of course KMail is a bit special). And in Konqueror I had to lookup the shortcut for Force Reload under Configure Shortcuts. A third argument against is that people using the menu will most likely continue doing so. So for them the shortcut is totally irrelevant. In fact, it's superfluous information that clutters the menu. And for those that are really interested in the shortcut it's also superfluous information as soon as they have learned the shortcut. I agree that it's often nice to see the shortcuts, but given my first two points I don't think it's a serious problem if the shortcuts are missing. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Action icons in menus
On Tue, December 14, 2010 2:52 pm, Ingo Klöcker wrote: On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our shortcuts where documented in some menu anyway. I doubt if many inexperienced users will know about Settings-Configure Shortcuts. Personally, I rely on menus to provide me with the information when I want to learn a new shortcut - I wouldn't normally go to the bother of looking in Settings unless I felt very motivated. So yes, I think this is a significant problem, since it raises the barrier to inexperienced users learning shortcuts. Note that this proposal addresses common actions only, so the fact that some shortcuts are not documented in menus isn't really relevant. A third argument against is that people using the menu will most likely continue doing so. So for them the shortcut is totally irrelevant. In fact, it's superfluous information that clutters the menu. And for those that are really interested in the shortcut it's also superfluous information as soon as they have learned the shortcut. As I mention above, I don't think they necessarily will ever learn the shortcut if they first have to discover a Settings page, and then open it up each time they want to find a new shortcut. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Action icons in menus
On 14.12.10 15:52:39, Ingo Klöcker wrote: On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our Thats not easy thats cumbersome. Especially with bigger plugin-based apps that have a few dozen shortcuts. shortcuts where documented in some menu anyway. Probably half of KMail's shortcuts do not correspond to any menu entries (but of course KMail is a bit special). And in Konqueror I had to lookup the shortcut for Force Reload under Configure Shortcuts. A third argument against is that people using the menu will most likely continue doing so. I disagree. If I approach a new app the menu is what helps me find my way to the things I need. At the same time I'm able to learn the shortcuts easily so at some point I'm using the shortcuts more and more instead of the menu. In particular I can learn the shortcut while doing the work, instead of sitting down and staring at the configure-shortcuts dialog for an hour. You're right though for people not willing/used to use shortcuts, those will always go through the menu no matter how often they read or get told about the shortcut. Andreas -- A day for firm decisions! Or is it?
Re: Action icons in menus
Dne torek 14 decembra 2010 ob 16:08:42 je David Jarvie napisal(a): On Tue, December 14, 2010 2:52 pm, Ingo Klöcker wrote: On Tuesday 14 December 2010, David Jarvie wrote: On Monday 13 December 2010 20:32:30 Albert Astals Cid wrote: 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) IMO, this is a very important drawback. There would then be no easy way for users who didn't know the keyboard shortcut for these actions to discover it. Is this really a serious problem? Looking up a shortcut is really easy via Settings-Configure Shortcuts and it's not as if all of our shortcuts where documented in some menu anyway. I doubt if many inexperienced users will know about Settings-Configure Shortcuts. Personally, I rely on menus to provide me with the information when I want to learn a new shortcut - I wouldn't normally go to the bother of looking in Settings unless I felt very motivated. So yes, I think this is a significant problem, since it raises the barrier to inexperienced users learning shortcuts. Perhaps showing the shortcut as a part of the tooltip? I know this is getting off-topic, but it's one idea. This could also be beneficial for actions in normal toolbars, which many people use without knowing the shortcut. I have no solution for DBusMenu, as I don't know how that works. I agree that it is very important that this should works for all menus. Maybe it can be worked around, maybe not. As some of you said before, we really do memorize positions of actions in menus. For example, Firefox 4 reversed the positions of Open in New Window and Open in New Tab, and I remember having many problems with that. However, is this really necessary? Memorizing always takes some iterations, and we do remember pictures easier and faster. Regarding consistency, the actions are consistent with the ones in toolbars. I don't see a good reason why menus should be treated completely different, because they're both just containers of actions. signature.asc Description: This is a digitally signed message part.
Re: Action icons in menus
A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure: 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. Does this break keyboard navigation in the menu? 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. 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) Albert 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/
Re: Action icons in menus
Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid napisal(a): Does this break keyboard navigation in the menu? Yes, unfortunately it does, I just tried. The elements displayed this way are not selectable by keyboard, even thought other actions in the same menu are. signature.asc Description: This is a digitally signed message part.
Re: Action icons in menus
A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure: Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid napisal(a): Does this break keyboard navigation in the menu? Yes, unfortunately it does, I just tried. The elements displayed this way are not selectable by keyboard, even thought other actions in the same menu are. That's a no-go if you ask me. Albert
Re: Action icons in menus
A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure: 2010/12/13 Albert Astals Cid aa...@kde.org A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure: Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid napisal(a): Does this break keyboard navigation in the menu? Yes, unfortunately it does, I just tried. The elements displayed this way are not selectable by keyboard, even thought other actions in the same menu are. That's a no-go if you ask me. Well, it is a menu which pops up with mouse-clicks... My keyboard has a nice context menu key between AltGr and Ctrl that pops the context menu in Dolphin, so no, it's not something that pops up with mouse clicks only ;-) Albert Anyway, I'll try to see if support for that can be added by reimplementing some event handlers. Until then, thanks for pointing me to the problem :S
Re: Action icons in menus
On Mon, Dec 13, 2010 at 16:26, Miha Čančula wrote: 2010/12/13 Albert Astals Cid aa...@kde.org A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure: Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid napisal(a): Does this break keyboard navigation in the menu? Yes, unfortunately it does, I just tried. The elements displayed this way are not selectable by keyboard, even thought other actions in the same menu are. That's a no-go if you ask me. Well, it is a menu which pops up with mouse-clicks... As someone who uses KDE on a computer without any pointing device, I rely on my keyboard's context menu key [1] quite a bit. Parker [1] http://en.wikipedia.org/wiki/Menu_key
Re: Action icons in menus
On Monday, December 13, 2010, Dan Meltzer wrote: If common actions were all handled in this way, then it might actually lead to more consistancy, consistency with what? certainly not with the menus, where we will now have items that behave differently. (as a side note: this will break with dbusmenu; so it can't find its way easily into the system tray icon menus, for instance) and ease of access. i still have reservations about this given the introduction of a second axis of freedom within the menu. Actions are not particuallarly consistant across applications, and so it becomes necessary to read the entire list to find the item you are looking for. If cut/copy/paste were always found as icons at the top of the menu in applications that support them, it would probably lead to accessing them quicker. if they were always in the same place in the menu, regardless of presentation, it would help. the questions that remain would be: * are they important enough to always be at the top of the menu in all applications? if not, which applications / use cases does it make sense to do so? * what is the actual amount of time / effort spent locating these items in menus as it stands now? Of course, I'm not sure how many people would do this vs. the shortcuts that are also well known, but if this was done for other actions as well, perhaps it would be beneficial? The putting the most common actions at the top of the menu is useful regardless of layout. icons should probably always be at the top of the menu, to add that consistancy, and I'm not sure if there are enough actions out there to merit the additional code path, but I think that this might actually be able to develop into something unique and useful. i'm happy to change my mind in the presence of compelling demonstrations :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Action icons in menus
Am Dienstag 14 Dezember 2010, 00:01:54 schrieb Aaron J. Seigo: (as a side note: this will break with dbusmenu; so it can't find its way easily into the system tray icon menus, for instance) If it breaks dbusmenu, all the work on the Global Menu Bar front would go to waste as well.
Re: Action icons in menus
In principle I like the idea. But can the execution also work in other areas? How many items can be grouped together in a feasible way? Currently I have KWrite open. When I look at the Edit menu, I see: Find, Find Next, Find Previous, Replace, Find Selected, Find Selected Backwards. Those are six items. It may work for three items like Cut, Copy, Paste and maybe even four (New, Open, Save, Save As) but six? Markus
