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