Template talk:Navlist/Top

Re format
Some perspective on how I ended up choosing the format I did, and alternatives to it.

My original plans were much more grandiose. For each page there would be links on the left to all ancestors of the current page, and links on the right to all of their successors. This would have been technically feasible, but I ultimately didn't do it for two roughly co-equal primary reasons, with at least one secondary reason also figuring into the equation. In the end, I devised the "split mode" option on Navlist/Link so that I could simultaneously provide only two links (one predecessor and one successor) and yet fully clarify the hierarchical structure of the book, if any.
 * 1) Not all books have "parent" pages, and not all that have them use the same conventions for naming them.  It just happens that the Conlang book, on which I primarily work, is organized with a hierarchy of pages, each of which has a complete set of ancestors named by removing suffixes of the path &mdash; Conlang/Intermediate/Sounds/Phonotactics has ancestors Conlang/Intermediate/Sounds and Conlang/Intermediate (and one might or might not count the book's main page as an ancestor).  In contrast, though, Using Wikibooks has pages of the form Book/Chapter/Section, but not Book/Chapter; and in that situation one might reasonably either have no parent, or count the first section of a chapter as the "parent" of the other sections of that chapter.  If I was going to make the tools applicable to a maximally wide range of books, without presenting a bewildering array of optional parameters (which I was hoping to avoid), it seemed advisable to try not to build into the tools too many structural assumptions about how the book is organized.
 * 2) The full-blown top navbox, with all ancestors and their successors, would have been harder to use because it was so complicated.
 * 3) There are some awkward organizational questions that would have to be given somewhat arbitrary answers (either by the template designer, or by the book designer if a battery of optional parameters were provided to support different choices).
 * 4) * One might reasonably put all ancestors in a column in the center of the box, with the current page at the bottom of the column and the book's main page at the top of the column; but then, what goes over on the left? Just the predecessor, at the bottom left?  But then, what if the predecessor is the parent &mdash; should that go at the bottom left, or one line up from that?  Or if the ancestors go in the left column, what happens when the predecessor has several generations of different ancestors from the current page?  The vision of a whole matrix of links in the top navbox was pretty strong reinforcement for the Keep It Simple, Stupid approach (2).
 * 5) * What about successor links when the current page has descendants? A single successor would be the first child, but if you've got mulitple ancestors, wouldn't it make sense to have the next page at the same level, as well as the first child?

A side consequence of all this is that the format I finally settled on probably should be called something other than "long" &mdash; because compared to some alternatives, it's really quite compact.

It occurs to me that one might provide a "mode" option on this navbox that would be passed on through to Navlist/Link, so that split mode can be disabled on books that have no deep structure. (I think that was probably what I had in mind when I deliberately gave the Navlist/Link parameter a name that I didn't think would collide with anything else in the navbox templates.) --Pi zero (talk) 15:07, 22 February 2009 (UTC)