Re: [Inkscape-devel] User Interface(was: save confirm dialog)
I left these because I'm still undecided on whether we want the Initial
Caps
style. To me it sounds old-fashioned and clunky, I would like to change everything to First cap only. But it's not something I feel too strongly about, so if HIG mandates Initial Caps without exceptions, I can live
with
that.
Yep it does. And to me, being used to it, everything else looks like an oversight and thus unprofessional. :) It's described here: http://developer.gnome.org/projects/gup/hig/1.0/layout.html#layout-capitaliz...
OK, then please go ahead and unify that.
- 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.
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 :)
If the former, well, OK. Otherwise, I like Ctrl-Shift better, because it seems to be standard on Windows, and besides it's more natural because
it's
Is consistency with Windows more important than consistency with GNOME? That would be a mild disappointment for me. :/
They are equally important. Winning users from Windows or Mac is of major importance, simply because it's by far the biggest source of new users. Given that Linux was feeling all right without a good vector editor for many years is an indication that the core users of Linux may not need such an application all that much. On the other hand, I'm an example of a person who've been rebooting into Windows for the vector editors (in my case, it's mostly Xara X) until I found Inkscape and spent some time on making it usable for me (with much help from others, of course - something that makes Inkscape very different from e.g. Sodipodi). So now I do simple designs in Inkscape, although I still have to reboot into Windows for more complex tasks.
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.
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?
Key names: actually I wrote a special function (sp_key_name in interface.cpp) to translate from the ugly GDK names to normal ones.
Mostly
it replaces monsters like "asciicircum" by its character, i.e. "^", but
also
changes Page_Down. Reason: (1) it's overly long and unwieldy, (2) the
"_"
character is not really meant for user consumption, it's a programmer's device, and (3) PgUp/PgDn is standard on Windows. So I would like to
keep
this as is.
Hmm ok. Again, the break of consistency kinda irks me and the "is standard on Windows" irks me even more. ;) But right now this a minor issue anyway...
I needed a shorter variant for Page_Down, and Windows has one. Why not use it?
"base" is the namedview. I think we can drop it. But the digit must be
kept,
it the number of the view (call View/New view, it will show the same document with ": 2").
Ok. How about showing the ": x" only when it's two or higher?
Good idea I think.
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
Which one, primary or secondary?
Secondary.
OK, you could work on it too, see SecondaryToolbar on wiki for the plans :) The difficulty with it is that we want to put both buttons and other kinds of controls there (spinbuttons, lists) and it may not be straightforward to combine them neatly.
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.
- Storing window size when a window is closed and restoring this size
when a new window is opened. Currently new windows open way too small for my resolution. Would that be ok?
Done yesterday :) see my message "namedview news"
Oh, great! :) I missed that. But this doesn't work for new documents, right? I mean without using a template. It would be nice if a new document would always open with the size of the last window I closed.
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?
Alright, I'll have a look at the preferences dialog then, this was interesting me anyway. :) For everything else I'll wait for the conversion to Gtkmm, as I'm really looking forward to that. Is there any estimate already when this switch will occur? I couldn't find it in the roadmap. Is there anything I could do to help with this?
I think Nathan Hurst or Mental are the right persons to ask this question.
_________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
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
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
On Wed, 2003-12-24 at 19:36, Daniel Borgmann wrote:
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. ;)
Well, that's true only if you're not right-clicking on an object; right-clicking on one will give you additional menu items relevent to that object.
Hoepfully that'll be a little more evident now; I just comitted a fix to move those object-specific items out of the submenus where they were sort of hidden to the manu menu.
-mental
On Thu, 2003-12-25 at 01:55, MenTaLguY wrote:
On Wed, 2003-12-24 at 19:36, Daniel Borgmann wrote:
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. ;)
Well, that's true only if you're not right-clicking on an object; right-clicking on one will give you additional menu items relevent to that object.
Hoepfully that'll be a little more evident now; I just comitted a fix to move those object-specific items out of the submenus where they were sort of hidden to the manu menu.
Yeah but those don't have shortcuts (yet). ;)
Daniel
On Thu, 25 Dec 2003, Daniel Borgmann wrote:
On Wed, 2003-12-24 at 22:27, Bryce Harrington wrote:
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.
Ooh, cool. Doesn't look like it'd be difficult to create a script like that for Inkscape usability testing. I think we'd want to be more detailed.
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. :)
We could even provide bitmap pictures of what they're to draw, that they could strive to follow.
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.
The fun part. ;-)
Bryce
Bryce Harrington wrote:
Ooh, cool. Doesn't look like it'd be difficult to create a script like that for Inkscape usability testing. I think we'd want to be more detailed.
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. :)
We could even provide bitmap pictures of what they're to draw, that they could strive to follow.
Michael is a guru at this sort of thing - he's been doing research into how people handle diagram drawing and things like that.
njh
participants (5)
-
Bryce Harrington -
bulia byak -
Daniel Borgmann -
MenTaLguY -
Nathan Hurst