On Wed, 11 Oct 2006, Bryce Harrington wrote:
Date: Wed, 11 Oct 2006 19:26:30 -0700 From: Bryce Harrington <bryce@...961...> To: Alan Horkan <horkana@...44...> Cc: Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: more stuff in Help menu
On Wed, Oct 11, 2006 at 08:50:26PM +0100, Alan Horkan wrote:
I would be concerend that Command line arguments should not be needed by most users
They are needed by some, that's enough. We get questions on how to use Inkscape in scripts regularly.
Might just mean the command line arguments are not very user friendly.
Oh please. Are you arguing just for argument's sake? ;-)
I was almost done with the discussion but I cannot let that go. Usability applies to command line argument as much as anything else, some are better than others, as I said compare how easy it is to convert using imagemagick versus the gimp.
- if many people are using them then batch features of the GUI
would need to be improved.
No, the GUI use and the command line use are quite orthogonal. Both are being improved but they will never converge or replace one another.
Perhaps I should have phrased that differently, there will always be a place for command line features because it allows inkscape to be pipelined together with many other command line utilities. However I dont think anyone would disagree that it might be useful if the user interface provided a way to achieve a batch task like exporting each layer of a document as a seperate image.
Given this comment, I can tell you don't have strong insight into what people running inkscape from the commandline are using it for. Many of the people whom I've spoken to that are using it in this fashion are doing so in a web environment. There is no X server, and thus a GUI batch function would be inadequate.
Again I didn't deny there was a place for command line arguments but that there were cases were some might say use the command line instead of makign the user interface easier for batch tasks. There is certainly room for both, but some users will never want to use the command line if they can avoid it (not much of a GUI app if they haven't any choice).
In fact if running inkscape headless is a frequent use case you might want to look at the "server mode" command line options for abiword. Essentially it keeps abiword open for repeated commands rather than requiring a new copy of the application be run each time you want to do a conversion or some other back office task.
I understand this use case better than you think ;P
I think you may be conflating these issues with scripting, which is yet another (quite separate) use case, and takes the discussion too far afield to address further.
The areas overlap and scripting is another way of exposing the same underlying functionality but I hope you have a better idea of what I was getting at.
- Release notes for the current version
I would think people (adminstrators?) would read the release notes before or while downloading the new version. The Changelog and News files provide even more information.
You probably missed that the developers decided to cease maintaining a Changelog, and evidently have missed that the NEWS file and the Release Notes are one and the same.
(bulia already replied saying the same thing. this is all getting quite confusing, apologies if I'm repeating myself but I've entirely lost the order of this discussion)
given the amount of new features in our versions, and their detailed descriptions in the release notes, this menu item will certainly be consulted more than once.
It is great that the release notes are of such high quality and provide good descriptions but shouldn't this information really be in the manual and tutorials?
It is. I don't think you understand the way documentation works with Inkscape.
(again in the other message I accept the differnce between the ideal and the practical, the information is provided and expecting it to be further processed into detailed documentation is impractical and expecting too much)
Inkscape actually has one of the best documentation writing flows that I've seen in open source projects.
Inkscape has its own way of doing things and has produced an excellent collection of useful information, especially the tutorials and it is certainly better than what many other project provide.
Traditionally, developers are very resistive of writing documentation, and documenters are very resistive of "just read the source code", so as a consequence many FOSS projects suffer along with little or no docs at all.
I thank $deity inkscape is better than that but ...
In return, documenters can use those comments as a springboard from which to create more extensive, proper documentation and tutorials.
... as with the other suggestions i was just suggesting there was an underlying problem to be solved and ideal we were aiming at such as nice tutorials but that release notes are the reasonable practical solution.
In a way, because the developers *don't* take responsibility for writing the docs themselves, this has opened a great niche for writers to fill, and we've all benefitted greatly as a result.
Intersting way to look at it, I think it is bit much to claim there is particularly a niche create for writers to fill but ...
The Release Notes are a crucial piece of this workflow, and its importance cannot be underemphasized. They are the authoritative source of knowledge about the program, and well worth being included in the help menu.
... that inkscape has set things up in such a way that developers do provide good "documentation" in the form of release notes which makes the task of writing documentation much easier for the many enthusiastic contributors.
Bryce has said before "contributors" are possibly the most important group. The tendency then is to think of contributors in the narrow sense of developers contributing code and Inkscape becomes increasing about techincal drawing. It is much harder to make things easier than to just make them possible.
Hold on there. If you re-read any of my screeds where I speak of the value of contributors, I ALWAYS follow with a long dissertation about how contributions come in many forms, and that even non-coders can bring extensive benefit to Inkscape through translation, documentation, PR, and so on.
Sorry if that sounded like I was taking a jab at you Bryce, you always follow through those ideas and carefully balance them.
You're also making a jump that programmers only care about technical drawing features. Boy I wish that were true. ;-) The evidence in Inkscape shows that random external code contributors care about a huge range of features, especially including artistic features.
I still do think there is a bais, maybe I consider things techincal drawing that others do not but there are plenty of requests for AutoCAD like tools, measurment, plotting and mathematical tools other features that an artist could certainly make use of but I think are more technical drawing features.
Much as I might love to have experts and testing on large samplings of live users...
Alan, this can be done quite readily through listening to the users who are posting questions on mail and irc. ;-)
You missed the iterative usability part the other bit was somewhat spurious ;P
(Seriously, I recall you had done this approach a few times in the past, and your well researched information was fairly convincing.)
Trawling through the request tracker does tend to show things recurring but in terms of usability I should probably sit down again and review HIG complaince, especially since I missed a few really obvious things like the lack of any close button at the bottom of the Preference dialog.
There is an issue of with the "clones" terminlogy I really should bring up but I'm postponing that indefinately because I know it is going to be a pain to change it, or at least until I gather lots more evidence about why it really is a problem.