-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I was hoping that you developers were thinking about implementing snap to grid? Thus allowing you to move images around and have them line up in an orderly fashion. Another thing is what do you think of the current user interface? Just wondering what you were doing with that. I know that you are talking about making a layers menu. That will be real helpful. The export and save options are really archaic at the moment as well. Overall the program has allot of potential. I was using Sodipodi allot but now that I found out inkscape I really like the direction you want to take it. If there is anything I can do to help let me know. ;) - -- Jonathan C. Sitte <jcsitte@...67...> Digital Arts & Computer Technology http://www.staticnull.org/jcsitte/ 917.414.2559 M-F 8AM-10PM
Public Key: http://www.staticnull.org/jcsitte/0x40E69A47-pubkey.asc
On Mon, 17 Nov 2003, Jonathan C. Sitte wrote:
I was hoping that you developers were thinking about implementing snap to grid?
Actually snap to grid should already be in there. Go to Dialogs->Editing Window and click on Show Grid and Snap to Grid. Also peek at the guidelines, which also are snappable.
Thus allowing you to move images around and have them line up in an orderly fashion. Another thing is what do you think of the current user interface? Just wondering what you were doing with that.
Expect some pretty radical changes here. We're trying out some new interface approaches in the development version right now, and sorting out what to include in the 0.36 release. I posted a quick screenshot showing Mental's progress with this to the website for folks to review. The work Bulia's done marks some very significant changes but are more "Feel" types of things, so you'd need to actually play with the code to notice them.
I know that you are talking about making a layers menu. That will be real helpful. The export and save options are really archaic at the moment as well.
Several developers have been hashing out what to do with the export and save dialogs; it may take us a few releases and feedback from users before we get this fully sorted out, though.
Overall the program has allot of potential. I was using Sodipodi allot but now that I found out inkscape I really like the direction you want to take it. If there is anything I can do to help let me know. ;)
We can definitely use your help. Look at the Wiki section of the website and join in some of the discussions there. In Wiki we try to work out concepts and plans for how things should work, and getting user feedback can be invaluable. Using a Wiki is pretty easy - find a page you wish to add a comment to, click the edit link at the bottom of the page, type your thoughts, and save.
From the Wiki you'll learn about other things folks are working on,
planning to work on, or needing help with, so let your curiousity and interests draw you from there. In particular look at the RoadMap in wiki for things we need help with (both technical and non-technical); it gets updated frequently so check back from time to time.
Bryce
On Mon, 17 Nov 2003, Bryce Harrington wrote:
Date: Mon, 17 Nov 2003 09:53:31 -0800 (PST) From: Bryce Harrington <bryce@...1...> To: Jonathan C. Sitte <jcsitte@...67...> Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Snap to grid
On Mon, 17 Nov 2003, Jonathan C. Sitte wrote:
I was hoping that you developers were thinking about implementing snap to grid?
Actually snap to grid should already be in there. Go to
Sorry to always be criticizing, I only hope that it is helpful but users failing to see existing features suggest that they might be better brought forward.
I tried to use Sodipodi for quite a while and it struck me how much functionality was there but that it was harder to find than I felt it should be (deeply nested submenus are bad, even 3 deep is to be avoided).
Basically I'd be looking for "View -> Snap to Grid" or something pretty similar.
Dialogs->Editing Window and click on Show Grid and Snap to Grid. Also peek at the guidelines, which also are snappable.
There are only three programs i can think of that have a 'Dialogs' menu: The Gimp (which has a lot to blame for); Sodipodi; Dia.
Dialogs is a fairly arbitrary and not particularly helpful grouping and is quite different from the groupings used by almost every other application (I find it very hard to convince people of this but please let me try if you dont believe me and look at every other appliction out there, ask a usability expert if you can or just think very carefully about it and try to think of it from the point of view of a beginner).
I know that you are talking about making a layers menu. That will be real helpful. The export and save options are really archaic at the moment as well.
Layers will inevitably have a Layers Dialog but I would suggest putting it in the View menu or in a seperate Layers Menu.
I could be wrong (but i doubt it ;) so questions are appreciated.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On Tue, 18 Nov 2003, Alan Horkan wrote:
On Mon, 17 Nov 2003, Bryce Harrington wrote:
On Mon, 17 Nov 2003, Jonathan C. Sitte wrote:
I was hoping that you developers were thinking about implementing snap to grid?
Actually snap to grid should already be in there. Go to
Sorry to always be criticizing, I only hope that it is helpful but users failing to see existing features suggest that they might be better brought forward.
Well right now since we're redesigning the interface for the next release, this kind of critique is absolutely needed in order for us to make really good improvements.
I tried to use Sodipodi for quite a while and it struck me how much functionality was there but that it was harder to find than I felt it should be (deeply nested submenus are bad, even 3 deep is to be avoided).
*Nod* The drop-down buttons are another area where there's cool functionality but it's hard for people to find.
Basically I'd be looking for "View -> Snap to Grid" or something pretty similar.
Mental is looking for feedback right now regarding how the menus are laid out. Take a look at the screenshot linked on the homepage. You can help us a lot by going over it with a fine toothed comb and listing your detailed thoughts on it.
Dialogs->Editing Window and click on Show Grid and Snap to Grid. Also peek at the guidelines, which also are snappable.
There are only three programs i can think of that have a 'Dialogs' menu: The Gimp (which has a lot to blame for); Sodipodi; Dia.
Dialogs is a fairly arbitrary and not particularly helpful grouping and is quite different from the groupings used by almost every other application (I find it very hard to convince people of this but please let me try if you dont believe me and look at every other appliction out there, ask a usability expert if you can or just think very carefully about it and try to think of it from the point of view of a beginner).
You'll see that in Mental's redesign the Dialogs menu is gone.
I know that you are talking about making a layers menu. That will be real helpful. The export and save options are really archaic at the moment as well.
Layers will inevitably have a Layers Dialog but I would suggest putting it in the View menu or in a seperate Layers Menu.
I could be wrong (but i doubt it ;) so questions are appreciated.
Let us know what you think about the proposed redesign.
Bryce
On Mon, 17 Nov 2003, Bryce Harrington wrote:
<snip>
Mental is looking for feedback right now regarding how the menus are laid out. Take a look at the screenshot linked on the homepage. You can help us a lot by going over it with a fine toothed comb and listing your detailed thoughts on it.
</snip>
I live to critize! I love this stuff as do many others, so if there are specific things that I dont like but you disagree then there are plenty of people far more expert than I am willing to give an opinion if you mail usability@...45...
http://www.inkscape.org/screenshots/new_interface_0.png
First thing that immediately strikes me, the Inkscape menu. Please don't I dont have a top level menu named after the program, very few programs do this (Sodipodi being the only one I can think of immediately, some programs do replace the file menu with a Game menu or something else program specfic but generally developers) try to keep things as consistant as possible.
I'd add a Help menu, even if you only have the About dialog to put there.
I'll try and give more feedback soon, this message has been languishing in my Drafts folder for days already so rather than leave it any longer I'm sending it now with the following hopefully useful link to two files http://www.maths.tcd.ie/~horkana/inkscape/ containing the menu layout structure for Adobe Illustrator http://www.maths.tcd.ie/~horkana/inkscape/illustrator-menus.txt and the top level menu structure of various applications several vector graphics programs http://www.maths.tcd.ie/~horkana/inkscape/menus.txt (please dont pay too much attention to my semi-random comments in the files).
You'll see that in Mental's redesign the Dialogs menu is gone.
WooHoo! Nice work Mental!
Hopefully I'll have time this weekend to take a more rigourous look at the proposed redesign.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On Thu, 2003-11-20 at 14:04, Alan Horkan wrote:
First thing that immediately strikes me, the Inkscape menu. Please don't I dont have a top level menu named after the program, very few programs do this (Sodipodi being the only one I can think of immediately, some programs do replace the file menu with a Game menu or something else program specfic but generally developers) try to keep things as consistant as possible.
The rationale is that the items on the application (Inkscape) menu relate to Inkscape globally, as a whole. i.e. they operate on the "application" object rather than a "document" object as the File menu does. I've also had very positive experiences with this organization on Mac OS X.
That it's not GNOME HIG-compliant is a strike against it in my book too, but for the present I think the cost/benefit analysis comes out in its favor:
I'd add a Help menu, even if you only have the About dialog to put there.
1. That's part of the reason too -- I think having a Help menu, but no actual help is perhaps a bit cruel to the newbie.
2. Also, given we're somewhat tight for space on the menubar, I have a hard time justifying a menu if it's only going to have one or two items on it for the forseeable future.
The application menu isn't set in stone, and maybe as the menus evolve it'll eventually succumb to rule #2 itself.
But for now it seems better than adding another misleading and almost empty menu, then putting the remaining entries in the other menus which are heavily overburdened as it is.
(...you know your menus are too large when you're running at 1280x1024 and regularly get menu scroll arrows...)
-mental
On Wed, 26 Nov 2003, MenTaLguY wrote:
The rationale is that the items on the application (Inkscape) menu relate to Inkscape globally, as a whole. i.e. they operate on the "application" object rather than a "document" object as the File menu does. I've also had very positive experiences with this organization on Mac OS X.
Hrrm. Care to run it past usability@...45...? I dont know as much about the Mac as I would like, I'd like to hear an second (expert?) opinion on this.
I'd add a Help menu, even if you only have the About dialog to put there.
- That's part of the reason too -- I think having a Help menu, but no
actual help is perhaps a bit cruel to the newbie.
At a minimum Inkscape will need a manpage to get into Debian and we can link to that to start with. Initially you could just link directly to the WIKI or something. Inkscape will definately need to have help documentation (maybe we could manage to share some of the generic work with Sodipodi).
I'd be prepared to write a few simple introductory pages to get things started, explaining Vector versus Raster graphics for one thing. Is there a convient way to export FAQ and other help information from the WIKI?
- Also, given we're somewhat tight for space on the menubar, I have a
hard time justifying a menu if it's only going to have one or two items on it for the forseeable future.
Tight for space? In the mockup screenshot you have plenty of room for even three or more top level menus. I'd expect Inkscape to have about seven or eight top level menus, you can pretty safely assume 500 pixel width as being available for menus even on extremely small screens.
Once you decide to have a menubar you may as well use a good amount of it and not have too much dead space.
I must be misunderstanding you I totally do not at all understand the suggestion that space for the menubar is limited.
But for now it seems better than adding another misleading and almost empty menu, then putting the remaining entries in the other menus which are heavily overburdened as it is.
I'd argue that is not misleading, users expect an About dialog in the Help menu (albeit not as much as they expect actual help documentation).
(...you know your menus are too large when you're running at 1280x1024 and regularly get menu scroll arrows...)
I despise those scroll arrows, i might prefer menus that start a new column.
Sincerely.
Alan Horkan http://advogato.org/person/AlanHorkan/
On Sat, 29 Nov 2003, Alan Horkan wrote:
On Wed, 26 Nov 2003, MenTaLguY wrote:
The rationale is that the items on the application (Inkscape) menu relate to Inkscape globally, as a whole. i.e. they operate on the "application" object rather than a "document" object as the File menu does. I've also had very positive experiences with this organization on Mac OS X.
Hrrm. Care to run it past usability@...45...? I dont know as much about the Mac as I would like, I'd like to hear an second (expert?) opinion on this.
After playing with it a bit, I think I tend to agree that a more traditional menubar layout may be preferable, with File being the first item, and with the About Inkscape and About Modules moved to a Help menu. My mousing muscles take me to the first menu to get to Open or Save, so it feels odd to have this not be the File menu.
Regarding the 'Inkscape' application menu, I can see the value of having an application-level menu in general, but do we really need it for Inkscape? Aside from the About menu items, this menu contains only Preferences and Quit, which traditionally are found on the Edit and File menus, so if we needed an alternative place for them, those would seem to be the least surprising locations.
I'd add a Help menu, even if you only have the About dialog to put there.
- That's part of the reason too -- I think having a Help menu, but no
actual help is perhaps a bit cruel to the newbie.
The argument that we shouldn't have a Help menu because we don't have enough items to put on it doesn't really seem like a strong enough reason. Clearly between the different efforts going into the doxygen docs, wiki, and the User Manual, coming up with stuff to put into the Help menu should not be a problem. It may not appear until M3 or M4, but since we're deciding interface layout at this point, I'd say assume the existance of a Help menu, and we'll leverage the newbie expectations to motivate us to fill in that menu. ;-)
Many, many open source apps have nothing available from their Help item, so even if we did nothing, we'd at least be in good company. ;-) But again I think once we make room for the docs, they'll get made. It would not be proper for us to do otherwise.
At a minimum Inkscape will need a manpage to get into Debian and we can link to that to start with. Initially you could just link directly to the WIKI or something.
There actually is a manpage being installed for inkscape. However, I just took a look at it and it appears to have almost nothing to do with Inkscape. It's mostly just a list of commandline options, nearly all of which are invalid. My guess is that this was auto-generated some time long, long ago in the distant past, and hasn't been maintained.
Anyway, I've rewritten it. All the commandline args are now accurate (shamelessly stolen from 'inkscape --help'), and I've filled in other sections including the description, authors, history, examples, etc. I'll post to the list for review, directly.
Inkscape will definately need to have help documentation (maybe we could manage to share some of the generic work with Sodipodi).
In fact, we're doing this now. There's a user_manual module in Inkscape CVS with a copy of the user manual that Cedric has developed. There's a french and english version; the French version is far more complete than the English. The French version needs to be translated into English; I found that even though I don't know French, it can be done via Babblefish and a little creativity.
I'd be prepared to write a few simple introductory pages to get things started, explaining Vector versus Raster graphics for one thing. Is there a convient way to export FAQ and other help information from the WIKI?
Not really, other than cut-and-paste. Wiki stores the page as a set of diffs, so isn't really usable directly from the backend, and there's not really any mechanism I know of to render a page sans the header/footer, although presumably that could be done with some simple scripting.
The approach I generally find preferable when involving Wiki in documentation processes, is to use Wiki for the initial brainstorming and hashing out, but once it's mature I like to pull it *out* of Wiki and put it into CVS, where it can be maintained in a somewhat more 'production' oriented approach. Usually you will want to markup the docs with DocBook or the like, and generate the output via make, so moving it to CVS for ongoing maintenance seems sensible at that point.
Bryce
I going to both comment on the below and make some suggestions on the most current user-interface implementation.
1.) Inkscape Menu - I agree with Bryce in that it should totally be removed as the normal inclination of power users is to go for the File menu. Most apps adhere to this, and it is majorly only OS X that uses this type of menu'ing system. It seems from a usability standpoint that this Inkscape menu should be integrated into a Help menu item at the end of the main menu bar. Really, is this the place to innovate? I will help out with some docmentation/help files and writing and whatnot as I'm sure other newbies to the project would contribute and help stitch this area together. Keybinding and basic help could be placed here for the time being.
2.) Secondary Toolbar + Annoying Canvas Moving - I really think that the secondary toolbar should never go away. Every time a tool is selected without options, the entire canvas moves, jarring whatever you are doing. This is just not good for plain ole users. I wonder if the secondary toolbar could just be gray space if no options are selected. Also, I think that the tools in the secondary toolbar need to be differentiated as options extending from the primary toolbar's selected tool. One way to do this might be to give more space on the left of the secondary toolbar. Maybe the secondary toolbar should have a darker gray underneath the buttons, or should be a smaller size.
3. Tool from Toolbar, Selection Not Obvious - It is not obvious once a tool is selected that it is selected, visually. Maybe the tools are too close together, but I honestly can't tell from the interface once I've clicked a tool either primary or secondary. The bevel might not be enough, or the shade of gray is too light. FIX: Upon selection of a tool, the shade of the tool selected should be much darker.
3.) Editing Nodes - When selecting objects and nodes in illustrator and other programs, you usually can constrain whatever is selected by pushing the shift button. Then when you move the items selected, they are constrained to 90 degree angles or whatever the preference is set to. While this works for selected objects in Inkscape and Sodi, it does not work for nodes in either program. I strongly think this needs to be enabled for editing nodes. Also, this functionality is offered for objects only using the CONTROL key in Inkscape, but is most commonly the SHIFT key in most major creative applications (closed and open source apps). I really think these preferences need to be changed.
These are just suggestions, but I think fixing these usability flaws will severely increase Inkscape's everyday usefulness.
thx jon2
On Sat, 2003-11-29 at 14:28, Bryce Harrington wrote:
On Sat, 29 Nov 2003, Alan Horkan wrote:
On Wed, 26 Nov 2003, MenTaLguY wrote:
The rationale is that the items on the application (Inkscape) menu relate to Inkscape globally, as a whole. i.e. they operate on the "application" object rather than a "document" object as the File menu does. I've also had very positive experiences with this organization on Mac OS X.
Hrrm. Care to run it past usability@...45...? I dont know as much about the Mac as I would like, I'd like to hear an second (expert?) opinion on this.
After playing with it a bit, I think I tend to agree that a more traditional menubar layout may be preferable, with File being the first item, and with the About Inkscape and About Modules moved to a Help menu. My mousing muscles take me to the first menu to get to Open or Save, so it feels odd to have this not be the File menu.
Regarding the 'Inkscape' application menu, I can see the value of having an application-level menu in general, but do we really need it for Inkscape? Aside from the About menu items, this menu contains only Preferences and Quit, which traditionally are found on the Edit and File menus, so if we needed an alternative place for them, those would seem to be the least surprising locations.
I'd add a Help menu, even if you only have the About dialog to put there.
- That's part of the reason too -- I think having a Help menu, but no
actual help is perhaps a bit cruel to the newbie.
The argument that we shouldn't have a Help menu because we don't have enough items to put on it doesn't really seem like a strong enough reason. Clearly between the different efforts going into the doxygen docs, wiki, and the User Manual, coming up with stuff to put into the Help menu should not be a problem. It may not appear until M3 or M4, but since we're deciding interface layout at this point, I'd say assume the existance of a Help menu, and we'll leverage the newbie expectations to motivate us to fill in that menu. ;-)
Many, many open source apps have nothing available from their Help item, so even if we did nothing, we'd at least be in good company. ;-) But again I think once we make room for the docs, they'll get made. It would not be proper for us to do otherwise.
At a minimum Inkscape will need a manpage to get into Debian and we can link to that to start with. Initially you could just link directly to the WIKI or something.
There actually is a manpage being installed for inkscape. However, I just took a look at it and it appears to have almost nothing to do with Inkscape. It's mostly just a list of commandline options, nearly all of which are invalid. My guess is that this was auto-generated some time long, long ago in the distant past, and hasn't been maintained.
Anyway, I've rewritten it. All the commandline args are now accurate (shamelessly stolen from 'inkscape --help'), and I've filled in other sections including the description, authors, history, examples, etc. I'll post to the list for review, directly.
Inkscape will definately need to have help documentation (maybe we could manage to share some of the generic work with Sodipodi).
In fact, we're doing this now. There's a user_manual module in Inkscape CVS with a copy of the user manual that Cedric has developed. There's a french and english version; the French version is far more complete than the English. The French version needs to be translated into English; I found that even though I don't know French, it can be done via Babblefish and a little creativity.
I'd be prepared to write a few simple introductory pages to get things started, explaining Vector versus Raster graphics for one thing. Is there a convient way to export FAQ and other help information from the WIKI?
Not really, other than cut-and-paste. Wiki stores the page as a set of diffs, so isn't really usable directly from the backend, and there's not really any mechanism I know of to render a page sans the header/footer, although presumably that could be done with some simple scripting.
The approach I generally find preferable when involving Wiki in documentation processes, is to use Wiki for the initial brainstorming and hashing out, but once it's mature I like to pull it *out* of Wiki and put it into CVS, where it can be maintained in a somewhat more 'production' oriented approach. Usually you will want to markup the docs with DocBook or the like, and generate the output via make, so moving it to CVS for ongoing maintenance seems sensible at that point.
Bryce
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2003-11-29 at 18:07, Jonathan Phillips wrote:
1.) Inkscape Menu - I agree with Bryce in that it should totally be removed as the normal inclination of power users is to go for the File menu.
Already done in CVS as of this writing.
2.) Secondary Toolbar + Annoying Canvas Moving - I really think that the secondary toolbar should never go away.
Also done in CVS now. It actually never went away, just shrunk to zero size because there was nothing in it, so I set a minimum size of ~28 pixels.
Also, I think that the tools in the secondary toolbar need to be differentiated as options extending from the primary toolbar's selected tool. One way to do this might be to give more space on the left of the secondary toolbar. Maybe the secondary toolbar should have a darker gray underneath the buttons, or should be a smaller size.
There are separate #defines for the main toolbox button size versus the auxiliary toolbox button size in toolbox.c for just this purpose.
- Tool from Toolbar, Selection Not Obvious - It is not obvious once a
tool is selected that it is selected, visually. Maybe the tools are too close together, but I honestly can't tell from the interface once I've clicked a tool either primary or secondary. The bevel might not be enough, or the shade of gray is too light. FIX: Upon selection of a tool, the shade of the tool selected should be much darker.
This is because Sodipodi rolled its own button widgets instead of using the standard ones; hopefully someone will be motivated to switch us back. It's on my list of things to do, but I have bigger priorities at the moment.
Coders wanted. Patches welcome.
-mental
On Sat, 2003-11-29 at 07:11, Alan Horkan wrote:
Tight for space? In the mockup screenshot you have plenty of room for even three or more top level menus. I'd expect Inkscape to have about seven or eight top level menus, you can pretty safely assume 500 pixel width as being available for menus even on extremely small screens.
Please remember i18n. In some scripts/languages, the horizontal size of each item can more than double.
-mental
participants (5)
-
Alan Horkan -
Bryce Harrington -
Jonathan C. Sitte -
Jonathan Phillips -
MenTaLguY