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. > > 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. > 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. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
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
