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
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
> > > 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
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
> > > > - 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
> > 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
(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
Inkscape actually has one of the best documentation writing flows
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
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
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
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
... 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
> Bryce has said before "contributors" are possibly the
> 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
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
> Much as I might love to have experts and testing on large
> 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
(Seriously, I recall you had done this approach a few times in the
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.