On Tue, 2005-06-28 at 14:32 -0700, Karsten Wade wrote: > On Tue, 2005-06-28 at 19:21 +0100, Stuart Ellis wrote: > > On Sat, 2005-06-25 at 10:28 -0400, Paul W. Frields wrote: > > > > > There may in fact be no need to index a short tutorial, which can be > > > read in its entirety quickly. Indexing is more important for longer > > > works that a reader is not expected to digest in one sitting. Indexing > > > can still be good in a smaller work as long as it is used judiciously. > > > There is no need to be concerned about indexing every topic that appears > > > in a section. Do not index redundantly against the table of contents. > > > If you have a section that entitled "Using Application XYZ," you should > > > not make an index entry for "XYZ, using." > > > > Indexing does feel slightly redundant on the HTML builds on individual > > tutorials, and I've tended to index more with an eye for future-proofing > > for other formats. If/when all of the tutorials are shipped together as > > part of the distribution then help viewers and document search may make > > use of the DocBook index tags, and so users may not start with the ToC > > and read forward as they do with the current HTML format. > > As much as I cringe at it whenever I do it, I do think there is some use > in having an indexing term that closely resembles the section title. > This may help with Google ratings, and as Stuart points out, it helps > make documents more modular as the project grows. > > I think the key is that doing the close resemblence indexing is less > than a bare minimum. There needs to be more meaningful indexing, as > well. > > For example, I've been using "how to" and "what is"/"what are" whenever > a section addresses something like that. This can build quite an > impressive list in the index. Yeesh. Well, I will yield graciously if outvoted on this one... I will also make an effort to back out my CVS changes on the yum tutorial on which I've been working, to restore those <indexterm>s. > > > Keep in mind that the Introduction should include a section for each > > > major technology discussed in your tutorial. A tutorial should not have > > > more than two or three major technologies involved, or else you should > > > consider splitting it. > > > > I tried this and found that I wasn't entirely happy with the result in > > one tutorial, although it has worked for the other. The problem I found > > was that the information presented relies on understanding a set of > > concepts that are familiar to experienced Linux users, but require > > explanation for others. By moving the concepts out of the Introduction > > it was possible to present them without making the Introduction lengthy, > > and allow the experienced reader to skip a clearly defined section of > > the document after reading the whole Introduction. > > I think you are both discussing slightly different things and are not > that far from agreement. > > The main focus of a document should be on one or a few closely related > technologies. > > It seems reasonable to cover any additional concepts that need > explanation to help support the overall topic. > > For example, an Apache PHP Tutorial might include various pieces about > how to update httpd.conf without explaining everything about that conf > file. > > A guideline might be, if a topic threatens to grow from a <section> to a > <chapter> and the topic is mainly out of scope for the document, it > deserves its own document and a reference. > > I like the idea of moving content to separate background/concept > sections for skipping by the knowledgeable. Like Karsten says, we actually agree on this more or less. It's difficult right now to split out those concepts sometimes -- for now -- because we currently have a paucity of material to which we can refer readers. Part of the growth of the project will be demonstrated in how often we can pare down our tutorials since material is covered better separately, like for instance being able to refer people to a Bugzilla Tutorial to file bugs. :-) > > The ideal fix for this might be to have a central document of concepts, > > so we can explain "packages", "repositories" etc. once rather than in > > individual tutorials. > > Good idea. We could have a standard section of references, customizing > it per document for whatever external concepts might need better > understanding. We currently have a jargon-buster that could stand some juicing up... it might make an ideal place to put some explanatory material. What say you guys? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-docs-list
