Self-assembling help index
Self-assembling help index
- Would the following scheme work?
- Move all Help pages to a special Namespace (e.g., the Help Namespace)
- Now the Help index is simply a (specialized) list of all pages in that namespace. The index is specialized in that it would:
- at a minimum, strip the name of the namespace from each entry. For instance, the index entry for the page named "Help:Bold" would appear in the index as "Bold"
- could also add additional formatting. For instance the index could have formatting like a category page, with entries organized under a letter of the alphabet, put in columns, an alphabetical index appearing at the top of the page.
- Note that in this scheme, you create additional index entries that link to an existing help page is simply to create a redirect page. For instance, if there's a page named (and indexed under) "Bold", and you also want an index entry for "Formatting, bold" that points to that page, you create a new page -- in the Help Namespace -- titled "Formatting, bold" which simply redirects to Bold.
- Cross-reference index entries work the same way (they are just redirects).
- Entries that point to sections of pages work the same way (they are just redirects).
- Advantages of this scheme
- It is automatically complete. I.e., there is at least one index entry per help page. I think this is big deal:
- Manually trying to figure out whether the index is complete takes forever, and isn't guaranteed to work.
- It's automatic. There's one less step to complete (or forget to complete) when someone adds (or deletes) a new help page.
- Adds more organization to help pages. Makes them easier to find. So it would be easier to eliminate or redirect the many pages that are duplicates, empty, or whose substance is covered more completely elsewhere.
- Could benefit the larger wiki community if the scheme is transportable to other wikis.
- It is automatically complete. I.e., there is at least one index entry per help page. I think this is big deal:
- Disadvantages of this scheme
- It takes some development effort. But as it ends up looking much like a Category page, I suspect it's not hard to develop.
- I don't know if I can redirect off-site. This is a big deal.
- The source that creates the entries cannot be edited in one place. In the hand-built index, I can see the source text for the entire index just by editing the HelpIndex page. In the self-generating index, the source is distributed over many pages - one page per entry.
- Harder to fix typos? You would have to re-name a page.
- Theoretically raises the bar to community participation. In the current hand-built index, you can create a new entry with knowledge only of basic editing and wiki formatting. The scheme would require knowledge about Namespaces and Redirects, which requires deeper knowledge of MediaWiki. But, this problem could be ameliorated by appropriate help pages (e.g., how to add a new entry to the help index). Also, I don't know how significant this problem is; how many casual users will try to modify the Help Index. If none or few, we can live with this disadvantage. (We can get a feel for this by seeing who is modifying the current hand-built index.)
- Cannot create custom entries, may lose some information that's currently built in by hand. For instance, where the entry points off-site, I currently add something like "(metawikipedia)". This would disappear. I don't know if there's a work-around. And in the hand-built index, entry text in the form [url] would appear in the hand-built index with a dashed underline. But that information would disappear in the self-assembling version as the entry would point to a page in AboutUs (which re-directs off site).
Discussion
Wow, Joe. Lots to think about here. I have a couple of thoughts right off, and then I'll come back and be more thorough. TedErnst (talk) 08:42, 24 January 2008 (PST)
- We've struggled with the idea of the help namespace because we don't know what goes in it. Maybe this doesn't matter? For example, Bold could redirect to Help:Bold and we get the best of both worlds. I'm not sure.
- Response -- Joe Cohen | Leave me a message 17:36, 24 January 2008 (PST)
- I don't think namespaces generally should matter to site users. And I don't see any problem in the kind of re-direct you mention. But namespaces could have an administrative use that's invisible to most users. Under the proposed scheme the namespace matters only to people who create help pages.
- My larger goal is a help index that assembles automatically (or semi-automatically). Maybe there's a better way to do it. My knowledge of the inner workings of MediaWiki is rudimentary. Maybe someone more knowledgable can propose an alternate scheme.
- Response -- Joe Cohen | Leave me a message 17:36, 24 January 2008 (PST)
- I'm not sure the automated way using the help namespace actually does save a step, because someone still has to know to put the new article in the help namespace. If they mis-name, it's lost, just as in the situation where someone forgets to add a new page to the hand-generated HelpIndex.
- Good point that a help page after implementation of this scheme can still get lost if it's created in the wrong namespace. But -- if it's in the right namespace -- then creation of the help page and an index entry is one step. In contrast, creating a hep page and an index entry under the current scheme is always two separate steps. -- Joe Cohen | Leave me a message 17:36, 24 January 2008 (PST)
- I've thought more about the issue of bold having it's own page, by the way, and am coming more and more to the conclusion that it does, even if it also lives on the BasicWikiFormatting page. See watch and my watchlist for examples. These aren't quite right yet, but maybe it shows the idea I have? This is seperate from your automated idea, but might make things easier in any event. We'd no longer need to use anchors in the manual list, and if we decided to do the automated one, we'd be forced into this scheme anyway, I think. I do like the idea of redirecting for cross-references. We could actually start doing that now. One problem with this is that double-redirects don't work, so if the destination of the redirect moves, we'll have to manually fix all re-directing pages, which is always true.
