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