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
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.
Action icons in menus
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/ signature.asc Description: This is a digitally signed message part.
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.
