Am Montag, 12. Dezember 2005 11:58 schrieb Arttu Manninen: > Tarjei Huse wrote to Bergie: > Be> The problem is that now we're in a wiki, which inherently doesn't > Be> have a tree structure. Maybe > Be> something like categorization there could help, but I'll have to > Be> think about this. > > TH> That is true, but the wiki format does not demand that all links are > TH> within a paragraph as they are written today. Actually separating out > TH> the links of higher value would help. > > net.nemein.wiki has the option of 'show item in navigation' or such, > which I think should be used more to fetch the important collective > pages to navigation. > > I also have found out that navigating in flat hierarchy of Midgard Wiki > can be quite confusing and one big thing could be collection pages. I > don't yet know the best way of doing this, but I was thinking that in > the beginning we could be having either a multiselect field to choose > loosely named conceptional categories (eg. 'howto', 'tips', 'getting > started' just to give the idea, someone wiser could throw in some good > pointers) or then using similar keywords as tags. > > Categories would be possible to make collection pages and to help > semantic searches. Even with this there is a problem, which is that we > sort the data it can be very chaotic. > > Categories would help searching when it would be possible to filter > loads of unwanted data out. > > With tags then again we come to the problem of semantics, when one > meaning can have many different words. Controlling the tags somehow > seems like an impossible task.
Mediawiki has a category system which is quite nice IMHO. You can simply add one or more [[Category:name]] tags at the end of a given page, when viewing the page, it contains a link to an auto-generated but editable category page, which has an alphabetical listing of all items in this category. Solving the semantic problem is of course still the responsibilty of the content author, but one could imagine a hierarchy like [[Category:Howtos]] [[(Sub)Category:Style Editing Howto]] or better yet [[Category:Howtos|Style Howtos|Beginners' Tutorial]]. I used this partly in my wiki and it indeed helps to structure the information. If the e.g. Howtos category contained all start pages of the respective howtos, they could be displayed in the right side navigation. When you select one, the individual pages in this category (as well as a link to the parent) could be displayed. Example (for right nav): ==Category: Howtos== -Style Editing (Start Page) -Schema Editing (Start Page) (...) => lists all pages which have [[Category:Howtos]] defined ==(Sub)Category: Schema Editing== -Schema Editing (Start/Category Page) => this page has [[Category:Howtos]] and [[Category:Howtos|Schema Editing]] -Introduction -Page 1 - x -Further Reading => these have [[Category:Howtos|Schema Editing]] -Parent Category => Taken from the category "path" of the current page Of course, if you define multiple categories for a single page which are not in the same part fo the category "tree", the parent link gets more difficult, but this doesn't have to be supported from the start. Bye, Andreas > > One of the big issues is crosslinking. There will always be - in theory > - one page that refers to a new page. The rest is left on the writer and > if he doesn't go and search related articles and edit them to point to > his new article. This way we end up having lost articles unless we are > strict and go and edit many other articles to point to our new articles. > > Bergie made some good changes when he was rearranging the front page of > documentation without using Midgard glossary as key reference. For > example for a developer it is self-evident that MidCOM related > information is under MidCOM, yet it might not be so for someone who is > searching for answers for a problem. > > I will try to write something also for end-users who need help with AIS > or the basic questions that people have when they lay hands on component > configuration, schemas (more on the side that you actually _can_ affect > on what kind of information can be saved), design patterns and more on > the lower experience levels. > > It should be quite clear that in a project like this the main priority > is always clients who pay. So if documentation isn't advancing, it > probably is so due to heavy workload with the hand that feeds. -- Adding sound to movies would be like putting lipstick on the Venus de Milo. -- Mary Pickford, 1925 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
