BattleTechWiki:Subpages

I've decided to write this essay, in order to not having to re-do research into the subject every time the topic of creating article sub-pages is revisited. I will provide some support for sub-pages, as well as my arguments against them. However, my central thesis is to express doubt as to the value using sub-pages brings to BattleTechWiki (BTW).

Aside[edit]

To be clear, I do believe sub-pages have a (limited) role on BTW, just not on the mainspaces. I use sub-pages extensively 'under' my User Page, to archive my talkpage, list projects I am working on (but are not ready to "unveil" to the mainspaces, save CBT-focused essays I admire and track specific areas, such as awards I've granted. Recently, with the release of the new Fanon policy, a branch of the conversation allowed, to a limited extent, users to transfer their fanon off the mainspaces to their user sub-pages. This essay does not address usage such as that.

Support of Sub-Pages[edit]

  • Sub-pages help link together related articles, especially those that have a hierarchical nature. For example (used only for convenience), the Jump Jet article could have subpages of each of the major brand names, such as Chilton, which could itself have sub-pages for each of the types of jump jets it produces, such as Chilton 360 and Chilton 365.
Counter-argument: this can also be done with categories, but now Chilton, the brand name, would not be limited as a sub-page of Jump Jet, especially if Chilton is known to produce equipment other than jump jets. If sub-pages are allowed, then whomever created the sub-page first has locked it in to that hierarchy. The only additional options, in that case, is either create a second Chilton article in the other hierarchy or unintentionally promote the first one as the primary method of categorization (where currently BTW does not prioritize categories for the reader).
  • Structure-wise, using sub-pages creates an easily understood relationship on a parent page, when it provides a link to a "main article for more information" (the sub-page).
Counter-argument: That ease of use really only exists for the creator of the two articles and probably only applies to a user new to wikis. The use of categories has been the primary (and only) way to relate related articles (other than via links within another article) for the length of the existence of BTW and by introducing an alternative method now, each and every writer after this will have to take the time to decide which method is more appropriate in that specific case. Additionally, because the decision is individually made, some articles may not be included in existing categories, reducing the effectiveness of categories, as they are now understood.
  • Subpages can also be used to create automatic links from the child to the parent; these links, appearing in 'breadcrumbs' at the top of the page, stand out and provide a useful, yet non-obtrusive, reminder to the reader of the "main" connections for the current page.
Counter-argument: An added value, yes, but limited. The same could be said to exist with the categories displayed at the page bottom and the fact that the breadcrumbs are automatically created is a small gain, compared to the relatively extensive coding that goes into the creation of any valued article page. Additionally, as the parent article should at a minimum be mentioned in the opening statement of the sub-article, there exists a wikilink right there.
  • Subpages can be renamed just by the renaming parent page.
Counter-argument: Again, of dubious value. This is an advantage only where sub-pages are used and the complexity of re-naming a whole series of pages is created itself by the use of sub-pages. As the founding admin of this site, I am not alone in having to go through many series of articles to bring them up to the standards of a new policy. Re-naming articles does not constitute a large part of that task and I don't concede the value in using sub-pages just to do this.

Opposition to Sub-Pages[edit]

  • The 'hierarchy advantage' of sub-pages restricts the proper categorization of an article that could conceivably (and often does) fall under multiple categories and could lead to unwanted redundancies. For example, a Titan DropShip falls under the categories DropShips, Aerodyne DropShips, Clan DropShips, Transport DropShips, Fighter Carriers and Military DropShips. If the primary article DropShip utilized sub-pages to create a hierarchy, conceivably the writer may choose to categorize all DropShips as aerodynes or spheroid, creating articles devoted to both of those types. From there, in this example, the writer may choose to write sub-pages on each of the aerodyne models. However, if in the parent article another writer wrote a small section on the differences between Inner Sphere and Clan DropShips, leading to a sub-page with more extensive information, he may not easily realize the Titan class has already been addressed in its own sub-page under the aerodyne branch, or may argue that that specific sub-page should focus only on the aerodyne nature of the Titan, while his sub-page would focus on the Clan nature. But, more realistically, now the additional writers have to seek out each and every possible version of Titan, to ensure they are either not duplicating previous efforts or are properly linking to the right one.
  • Sub-pages open up the possibility that more than one article exists on the same subject. Right now, only one article can exist with the same name. If someone does not follow the existing naming conventions, more experienced editors have their eyes caught and (generally) will end up merging or redirecting the second effort to the existing article. Under sub-pages, observing editors will have to decide whether or not the context of the parent warrants an additional article, so less guiding re-direction will occur (as many editors will assume the writer knows best what he is attempting to accomplish). BTW does not want a user to have to find multiple articles that are focused on the same subject. Conversation for example: "Sarna says Thomas Marik didn't have any children of his own." "No, no...you need to go to the Thomas Marik sub-page off the House Marik article; there it lists all his children, including the illegitimate ones."
  • Sub-pages change the naming structure from the familiar (ex: "Article Name") to a system with exceptions that will be hard to keep consistent (ex: some are "Article Name", others are "Parent Article Name/Sub-page Article Name"). Using the structure of sub-pages is an organizational method we've adopted in the computer age (1980s onward), but it limits cross-organization, which is important to a wiki.
  • Article standards would still require that articles built on sub-pages be written as complete pieces, not abbreviated because it had been introduced already in the parent article, as sub-pages could still be reached through methods other than its parent article. As complete articles, the introductory statement should have a link back to the parent article quite clearly available. For example, think of the medium laser's relationship to the laser article; it doesn't need a hierarchical relationship to get the reader back to the laser article.
  • Slashes within the title of an article drastically reduce what I refer to as 'easy linking', wherein a writer wikilinks to another article with what he presumes to be the most likely name of that article (ex: Medium laser vice Laser/Medium laser). Yes, redirects can solve this problem, but in the case of sub-pages and their inherent slashes, redirects must be used every time, something I don't foresee each and every writer of a sub-page doing. Readers will be frustrated by the lack of re-directs and/or sub-pages will be neglected (both by readers and editors) in favor of the article that develops out of a redlink.

Summary[edit]

It should be clear I see a lot of disadvantages to utilizing sub-pages as an alternative to main page articles. Additionally, what value I can identify in their use seems to be enormously overshadowed by those disadvantages and cannot foresee any occurrence where BTW would need to utilize them in order to make article creation more efficient or information retrieval easier for the reader.