On Wed, 24 Dec 2003, bulia byak wrote:
- Removed shortcut labels from the context menu. This is according to
the HIG to reduce clutter.
Disagree. "Reduce clutter" is not a strong enough argument for me. The sooner the user will learn shortcuts, the more productive he will be, so
I'd
like to use any opportunity to remind the shortcuts.
Hm ok, I'll revert the change. However, to be honest I don't understand the reason and I really don't believe that it is a strong enough reason to break consistency.
To me, it's more consistent when all menus show shortcuts, no matter context or not.
I can see both sides of the argument but think Bulia's arguments hold the sway on this. Let's leave the shortcuts in all the menus. But perhaps we should re-review this some time in the future once we've had time to get additional feedback from users? Perhaps a task could be put for 0.41 or so to review having shortcuts shown in context menus?
Users can learn the shortcuts from the main menu and users who use the context menu usually do that because they want to have quick access to a certain function, not because they want to see the shortcut.
Exactly BECAUSE they want quick access, they will be glad to learn that there's a still quicker access, via the shortcut :)
Maybe, although I suspect there's going to be a subset of the userbase that are going to be strictly mouse-only... In any case, I think we do want to push use of the keyboard shortcuts, because so much effort has been put into getting them right.
To summarize, neither Windows nor Gnome are the final authority for us; but both are worth consulting. Where HIG is in minor disagreement with Windows or Mac practices, we should follow HIG (unless doing otherwise brings some sizable benefits). But where following HIG literally might seriously alienate or confuse Windows users, we must be extra careful.
Ideally each decision should be taken based on usability tests with real users, but lacking that, we need to put forward convincing arguments in addition to references to standards or conventions.
Is there ideas we could consider for arranging usability tests with real users? I've never done such a thing but would be willing to try to organize one if there's some good ideas how to do it.
the order in which most people actually press these keys (Ctrl, then
Shift).
So I'd like to leave this as is unless there's some strongly worded and convincingly argued standard on this.
Again, I don't think that this is a good reason to break consistency. There is also a good reason for Shift+Ctrl+X: Most shortcuts are Ctrl+X, Shift+Ctrl+X is usually only used when this one is already taken. So putting Shift on the left side will make the items align better: Bounce Ctrl+B Frobnicate Ctrl+F Foobar Shift+Ctrl+F as opposed to: Bounce Ctrl+B Frobnicate Ctrl+F Foobar Ctrl+Shift+F
That's a counterpoint, but still I'm not convinced. I think following the natural order of pressing buttons is of major importance for the shortcut to be easy to memorize. Anyone else has an opinion?
In GUI's I'm used to the "Shift+Ctrl+F" style myself.
Consider that the way that you set up the keyboard shortcuts, "Shift" is like a modifier. E.g., Ctrl-Z is "undo", and Shift-Ctrl-Z is "unundo" (i.e. redo), which maps in my mind to "Shift-undo". This approach is used with others, so the style feels like, "command"/"Shift-command". Putting the Shift first in the list is consistent with thinking of it in this way, I would argue.
Primary is fine. Though the HIG mandates that if a vertical toolbar is used, the user should be able to make it horizontal. Probably not very important, but I wonder if we could make it possible to also dock it at the top when it's dragged around?
May be relatively easy to implement, although now I don't see an urgent need for that.
I have an ongoing bet with Mental that we'll ultimately have to make them draggable so the user can arrange them as they wish. ;-) There's opinions on both sides of the issue. If its true that users wish to drag them, then it follows that we should see multiple requests for it. Thus I agree we should wait and gather feedback from users.
I think this is wrong, because if I have several documents open with different window sizes and I quit Inkscape, the size of the new one will depend on which was closed last, which is almost random (from user perspective anyway). So this behavior might be confusing. I think it's better to decide once and for ever that "I want new documents to be this large" and put this into the template.
Again, anyone else has an opinion on this?
Can we make it settable in Preferences? I think that this would be the "right" solution. Most users may not care, but those who do probably have a specific size in mind they'd like to see it started with, and not have it change based on how they're using the app.
Bryce