Making the wiki easier to use for both new users and wiki administrators by using sub pages.

See also: FacetedClassificationInMoin, FacetBrowsingTheme, HierarchicalWiki, MoinMoinPatch/HierarchicalACL

Contents

  1. The Problem
  2. The Solution
  3. Using subpages
  4. Discussion

The Problem

A wiki is a big mess. Its hard to find information by browsing, although a wiki has several indexes and other aids. Its hard to update an existing wiki with a new MoinMoin version.

Few example:

The typical comment you hear from new users is "I can't find anything" In Hebrew people say they "can't find their hands and feet".

The Solution

The wiki structure will be clear. The design will help the new user to answer these questions:

How to do this in an easy way for both the wiki admin and users:

Using subpages

We have to tool to make this situation much better: sub pages. Here is how it can be done:

System Pages

System Pages - the same on every wiki. They could be actually be in data/__system__/lang_iso_code, or in a wiki farm, at the roof of the wiki farm, all immutable. Then you can upgrade your wiki easily.

...

Maybe Navigtaion would be better then Find? Eg.

The idea is to have one stating point when you want to find something, and the simple search box on every page is not enough. There two ways to find: searches and browsing. The Find page can have both search form, and links to all kinds of indexes, like this page: http://nirs.dyndns.org/nirs/NewFindPage.

Wiki Specific Pages

Wiki pages - change for each wiki. They would live in the wiki instance directory.

Here a quick list for this wiki, just for the example:

...

The main difference from the current system is that the structure is revealing itself without the need for configuration. We can let the users and administrator to override the default structure, as we do today.

User Specific Pages

The pages the user want to bookmark - will show on the same place on every wiki. These could be the last pages you visited, or the last pages you edited, or a list you define. We can give all options, the user will use what best fits.

Pages that belong to this part:

Location Line

On the top of each page, probably just above the page title, we can have the navigation line:

MoinMoinWiki: MoinBugs: WikiMarkup: < OtherBug | PreviousBug | SpecificBug | NextBug | YetAnotherBug >

When you are at a very big part of the wiki, the siblings links are not so useful, but if you are in a smaller part of the wiki which have 3-5 pages, the siblings are very useful. Maybe this can be automatic or controlled by the page editor.

Wiki Main Parts

On each page, we will have the wiki main parts:

FrontPage | RecentChanges | Find [____________] [?] | Help  MoinDevelopers | MoinPlaning | MoinTranslation | MoinOhterMainPage...

This could be implemented in the top of the page like we do today, but will be much better in a side bar:


FrontPage
RecentChanges
FindPage
[____________] [?]
HelpPage

Content

MoinDevelopers
MoinPlaning
MoinTranslation
MoinOtherMainPage...

MyHomePage
MyPreferences

This maps directly to the urls of this wiki:

At the side bar, this list can grow according to the wiki or user needs. Since page content display is useful only at 400-600 pixels, due to readability rules, (number of words in a line), this leave us plenty of space around the text, which is generally used in each well designed site.

Automatic Sub Page Listing

we can list the sub pages automatically, without any user or admin extra work.

We can just put a [[Children(depth=2, description=1)]] macro to get a list of this type:

...

The description line could be the first line of the page, which also appear in search results both in the wiki and on Google. We can put a description line field on a new page creation form, then put this line in the wiki page like this: 

## Description - every page should have a one line description at the top of the page:
The text that the user entered in the create new page form...

## Content
...

Creating New Pages

Read the section "How to create a new bug report?" on MoinMoinBugs. Do we really need 6 steps to do this simple task?

Now this could be the new "How to create a new bug report?" section:

And this is the new "How to create a new bug category?" section:

Technically, the new bug category could be a MoinBugsSubPageTemplate, and a new bug report would be MoinBugsSubSubPageTemplate or another similar system.

Using this system the user does not have to select a template, because the template is selected for him by choosing the wiki part he is adding a page to.

Discussion

I am going to build this system with or without changes in moin code, for my own needs at MacMac -- NirSoffer 2004-06-19 18:43:46

Hi Nir. I'm thinking like you:

Hierarchies only help if the data is hierarchical (== tree-like) - and often it isn't (because it is a full graph, not a tree).

If you try to fit everything in a hierarchy, you will get new problems because:

IMHO a better solution is using some kind of facets, but this is not a current option, maybe rather a long term goal after having put much more thoughts into it.

-- ThomasWaldmann 2004-06-22 16:51:44

I agree completely with Thomas. Not only the information in a wiki is a (aciclic) graph, but the need to categorize in a hierarchy makes the creation and evolution of content more difficult and rigid, by forcing choices that are not always clear (where does this node "belongs"?), that change over time (now "belongs" here but tomorrow maybe not), and not unique (this node should be in the categories a, d, g, l, and m also).

The idea of facets is powerful, and in the meantime, maybe we could start using more the wiki categories we already have.

For example, we could list the categories in the navigation bar (separated from the main nodes). This would give the user an overall idea of what is here, and a few big groups to start at the same time.

This possibility balances the idea of grouping (powerful and known for the user) with multiple categorization and a mechanism that we already have working.

-- EduardoMercovich (2004-06-24)

I didn't even know about the CategoryCategory page till i read this thread and did a search. I think categories are very powerful in wiki, allowing for non-tree based information systems. However, at work were we are also implementing Moin as an intranet, i need to follow / implement a basic top-level layout to please the "boss" ;). This dosen't prevent one from still using the fluid nature of wiki and categories to allow for flexible "placement" of nodes. JosYule

Its true that information is usually more complicated then a simple tree. But you can describe any information as a tree. The description does not have to the best representation of the information - the purpose is to make it easier for people to understand your site. You do the same with a book or an article, when you break it into chapters and paragraphs. You do the same in a site when you break it into some parts, and those parts into other parts. My idea is to show this internal structure of the wiki automatically.

The major problem with my idea is the death of the WikiName. All links would be PartName/PageName of worse PartName/SubPart/PageName. I'm convinced that we need a clear structure and it should show without special effort, but it seems that creating it with sub pages would make more harm.

We can use subpage for help pages and general system pages. Using Help/FormatText, Help/CreateLinks and Find/TitleIndex Find/OrphanedPages or similar system would not have the bad effect Thomas and Eduardo describe, and the wiki specific pages can use single name space.

So the basic structure for every wiki can be:

The specific structure can be exposed by other means. For example, by showing the name of pages that end with RoadMap. Let say in a wiki about linux you will have a lot of HowToDoThis pages, and a page named HowToRoadMap describing these pages. We can show all the names of the road map pages in the wiki specific pages list:

This list can show automatically - the wiki will be self documenting. Today we can do the same by adding page names to the navigar page list in config. This will help wiki admins to create easier to navigate wikis.

-- NirSoffer 2004-06-24 17:38:10

I was very interested in the possible application of facets in wikis in general and Moin in particular. But even if the discussion spawns from here, it deserves its own page. So please take a look at FacetedClassificationInMoin.

-- EduardoMercovich (05/07/04).

This appears all well and good. However, I think that the solution can be explained very simply (as many of you have above):

What not add a #parentCategory Parent1,Parent2 preprocessor?

Alternatively, since I see that no solution yet exists :(....

Why not reserve a special page (eg WikiNavContents) that is automatically displayed on the left of each wiki page? You could then edit WikiNavContents in any way you like?

-- C (2005-10-4)

MoinMoin: PagesHierarchy (last edited 2010-07-13 15:17:01 by wp)