User:AJim/extensions
|
|
Extensions is a place to collect my thoughts about how to extend the utility of the wiki software.
| Contents |
|
1.1 Why I like this wiki |
Motivation
Why I like this wiki
I have begun to use the Wikimedia software for a private project. I have been looking into the whole area of knowledge management, collaborative software, content management, or whatever you want to call it, for a while. I am aware of some successful products in this general area that have been going for 10 years now. My interest and involvement has been increasing rapidly as I saw greater and greater value in the techniques and as it became clear that I could use them, now. I began using Wikipedia a few months ago, and rapidly became hooked, this thing is fun! It is very rewarding to work on and with. I chose this software because of the power of the tools, the maturity, the depth of support, general high quality, and the fact that I could use it almost immediately.
An Objection to Wikis
So, in my first attempt to create a convert, I ran into the objection that "customers" expected a manual in Word format. Could the work on the wiki contribute to the writing of a manual? Surely they do expect a Word file, Word is probably all they see. I suggested that perhaps pdf could be produced, and pdf is OK, it seems. In the end, I expect that once people become aware of the power of interactive, collaborative software like this that demand for fixed formats will fade away. In the meantime, there are lots of purchase evaluators with simple-minded approaches to software selection, mostly concerned with avoiding mistakes, who use simple checklists to exclude as many choices as possible. I think this is one of the springs driving "featuritis". In any event, I pointed out that each page could be printed, and that settled the matter for the moment.
Aha, something wikis need
But, in thinking about the issue, some ideas emerged that could be useful. The fact that a document has to be printed in some fixed order has never been too much of a problem because most documents have a structure that works well that way. Call it a narrative structure, a story. Story telling seems almost built-in to people, in fact. For technical documentation though, this structure is sometimes a bit arbitrary, there are often several ways to tell the story, depending on the interests and backgrounds of the readers. Sometimes this leads to multiple, partly-redundant documents.
Hyper-linking, of course, is a way to break out of this one-way restriction. This is similar to what conventional books do with cross-refrences and indexes, although the change in speed and ease of use creates something new.
There is still a benefit to linking articles into a narrative thread at times. In fact, it would be nice if several threads could traverse a set of articles, each in it's own order, as appropriate. some documents also have hierarchies, and this can be useful as well. It would be nice, I think, if one could choose which thread links were visible, to reduce clutter. I guess what I envision is something like the navigation links I see on so many online documents today, next, previous, up. I think this reflects a tree structure and provides a way to traverse this tree.
looking to share
In any event, I am writing this here because the lesson is clear that I will benefit if I share these ideas with others, and that these ideas may benefit the wiki software itself, and others with whom I might collaborate. I have begun searching for existing and related work, and I will note here what I find.
Existing Wiki Work
Category seems to be the key term. There is a discussion in wikipedia, a related discussion in meta and in the mediawiki-l list, and ongoing experiments in the development head and on the test wiki.
I found some historical stuff at other wiki sites too. It seems that other distinctions have been tried, for example, between category and topic, but the distinction did not take. Another important concept emerged too, a roadmap, which seems to be primarily a tutorial kind of structure.
articles in wikipedia
User:Zocky/Bottom-up categorization has some interesting ideas about how to allow categories to "create themselves". Perhaps this could simplify the work of creating narrative threads.
One difference between the syntax in this proposal and the syntax being implemented is that the sort key, as implemented, is not going to appear as the item in the category list, the page name will still show there. See the discussion in wikitech-l or the code.
articles in meta.wikipedia
Most of the discussion seems to be in the meta wiki. It is clear that this subject is of concern to many others besides me.
The main starting point seems to be MediaWiki development (http://meta.wikipedia.org/wiki/MediaWiki_development). From here there is a link to the specific topic Categorization (http://meta.wikipedia.org/wiki/Categorization).
There is also a proposal for a more general kind of tag in two linked pages Categorization with field-value pairs (http://meta.wikipedia.org/wiki/Categorization_with_field-value_pairs) and Field-value pairs (http://meta.wikipedia.org/wiki/Field-value_pairs). In this proposed system, the field name can be something other than category.
The categorization with field-value pairs page has links to other proposals, Technical categories in Wikipedia (http://meta.wikipedia.org/wiki/Technical_categories_in_Wikipedia).
I guess the most unusual thing I am asking for, so far, is a definite order. On the one hand, this would, clearly, be hard to maintain. On the other hand, this is sometimes what a reader wants, a story to follow. Maybe that is what roadmaps are.
Well, perhaps not so unusual. I just found a discussion of a way someone has already found to do it Series of Articles (http://meta.wikipedia.org/wiki/Series_of_articles) using the existing software and transclusion, a new term for me.
Finally, Offensive content (http://meta.wikipedia.org/wiki/Offensive_content) is a recent discussion of another set of reasons for wanting to classify elements of the encyclopedia and allow selective control of their display.
test wiki, development
There is work ongoing to implement a category system in media wiki:
The current syntax is explained in the test wiki main page - category section (http://test.wikipedia.org/w/index.php?title=Main_Page&action=edit§ion=7)
- Assign a page to a category by using [[Category:Foo]]. The categories will be displayed in the top bar, below the subtitle. Click a category to get its category page, where you can view all articles in that category, and describe the category itself. You can also add subcategories to a category.
- '''Test area:''' [[Categories]]
In the example in the test wiki, I think the way the category links are used appears similar to the practice of including keywords in articles, or in web page headers. It appears that one might search for articles that were in the intersection of several categories. Now what I am talking about, ordering, seems different, but it is a good sign, I think, that the basic mechanism has many uses.
wikitech-l discussions
The category term appears in discussions on the wikitech-l list.
Recently a discussion started about introducing a separate links table, so that a page with a category link would not automatically become part of the category. The latest version of this idea supports a useful extended syntax. Besides [[category:Some Category]] , one can write [[category:Some Category | Some Sort Key]] .
The category links table contains a field, cl_sortkey. By default this is filled with the name of the page the link is on, but this value is overridden by "Some Sort Key", if it exists. There is also an index to the category links table, cl_sortkey, based on cl_to (the category name) and cl_sortkey, so the items in a category can have a definite order in this index if each article has a distinct sort key. The sort key names would have to be constructed in a way that created the desired order, but this may not be a big nuisance.
Outside Work
A google search turns up some other likely links, and the related, important idea of a roadmap, like this one in meatball wiki:
Categorize Everything (http://www.usemod.com/cgi-bin/mb.pl?CategorizeEverything) There are hints there of even better solutions, such as roadmap outlines that authors fill-in incrementally.
and another discussion on C2
about articles that resist categories (http://c2.com/cgi/wiki?PleasePleaseDontCategorizeEveryPageOnWiki) I think that a single rigid structure is likely to break. Apparently this wiki allows multiple category links on single article. An interesting insight is that categories and roadmaps go together, categories helping to build roadmaps.
C2 has a Road Maps (http://c2.com/cgi/wiki?RoadMaps) page. They have a Categories Discussion (http://c2.com/cgi/wiki?CategoriesDiscussion). There is also a Category Category (http://c2.com/cgi/wiki?CategoryCategory) page.
Producing a Static Version
Also, about producing the output, in some static, serial order, there are some projects:
WikiPDF (http://sourceforge.net/projects/wikipdf/) - wiki-to-PDF converter - this seems like the final step needed for the objection that started me thinking. For this to work though, there needs to be a thread to follow through the articles, alphabetical only works for encyclopedias, and maybe not there.
offline reader (http://meta.wikipedia.org/wiki/Meta:Babel#New_software_project_to_read_Wikipedia_offline) is a proposal to start a project to enable reading offline, say from a CD. This seems like another form of static content, one aspect of what people are used to now. I suppose, though, that one could allow editing the offline version using extension files, but the changes would not be shared or moderated.