Lo,
I took advantage of travelling a lot by train this week to read
carefully alexander mail.
1) happy to see that you follow the way i've already begun with , ie
style 1 +2 ;)
2) context-sensitive help would need that the team had chosen a "help
browser" and have ertainly done sone modifications in the core to allow
this. For the help browser (which scribus has for example), we could use
yelp that is nearly fully docbook compliant but the question many oppose
to that is how would it work on other OSs. This is a big problem and
until we find a solution, the only easy way would use web browser and
have some "html name rewrite" from an ID that could be used as context
reference. We cannot go further this way without talking aboutthis with
other guys of the core-team.
From that, what can we thing of grouping elements in the TOC?
Grouping is a common task for any author. It tries to organize the needs
to help the reader to understand. In the actual manual, you may see that
in most part, it describes menus one by one, and in more thematic way
some more complex tools or concepts. Why this ? Because if you think of
the manual as a help sensitive system, you guess that the reader would
read from the beginning to the end but will browse it in search of a
specific info (for ex: what means mass in Calligraphic tool and how it
is made for).
Sure there could ne many ways in grouping elements, but at least we can
simply do link to other parts if needed so, the place of one is less
important that it can be in a book. hypertext navigation is not a space
navigation so it doesn't change anything for the reader if we use in one
part a page that is written in another.
An example of this. In your Proposal, Alex, have a specific part for
Preferences. right. But some tool need to be set in preferences quite
often, for ex 3d tool) so that preferences is in this case a real part
of the tool usage. HAving a complete reference to the page related to
this is a must in this case, and would be a gooduse of non-linear reading.
Thinking of some special elements like Color management or icon preview,
I'm just wondering if it would not be usefull to have some part about
specific usage of Inkscape. I'm thinking of :
- Inkscape for press
- Inkscape for theme design
- inkscape for web design
ans so on.
Having fill'n'stroke in colours is also something strange especially for
stroke settings which can be considered as object properties.
I'm not sure if we should map all this to visualize the several
relationship that can be set between pages.
We also need to define a basis structure of each pages. Is the one we
already have good enough
(title+screenshot+Intro+Activation+Procedure+Additional infos+Links) ?
Alex, i'm also wondering if it would not be better to split much than
you did. I would do : One file per TOC entry. I didn't follow the new
gimp's process, but that was what they had some years ago when i
contributed. Roman could be open to help us in a reasonable way, he
always answered my mails ;)
A+
