On Wed, 2003-12-24 at 22:27, Bryce Harrington wrote:
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.
Maybe I'll understand this argument better once the context menu contains more special items. :) Right now it's only the default Cut&Paste or Undo stuff and I doubt that any advanced user still has to learn them. ;)
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.
Well, the GNOME HIG was created in part based on "usability tests with real users", so it's more than just a standard. :) Here is a script SUN used for one of such tests: http://developer.gnome.org/projects/gup/ut1_script.html This might give you a good idea how such a tasklist could look like. Then you'd have to find some real people and put them in front of your computer and Inkscape, seeing how they manage (or fail) to complete the different tasks. Useful tasks could be things like "Draw a curved line between two arbitrary points" and everything else a user should be able to do with the application. :) Then you'd have to try to get as many people as possible to do that and watch them carefully, so you can understand where they have difficulties or are unsure about something. Of course it should always be considered that there is no chance that a new users will immediately understand all parts of a complex development oriented application like Inkscape, so it might make sense to include some bits of documentation in the script (even though that's cheating, considering that we don't have real documentation yet ;)).
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.
Agreed, also there isn't really any natural order. It doesn't matter which button you press first and I'm pretty sure that not everyone presses Ctrl, then Shift, then the key. Also many people (like me) have a keyboard where control actually is located above shift. So this argument is weak IMHO. :)
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.
Hmm, I meanwhile think that Bulia is right actually. Saving the size only for "real" documents leads to a nice document oriented behavior. And if it's easy to make the current size of the window the default size for new documents, then everyone should be happy. I'd say as long as we keep the document oriented behavior (opening a new document always opens a new window, so a window _is_ the document), this is sane. In fact, we should have a real spatial application right now. :) That's very nice from a usability perspective.
Daniel