Making the wiki easier to use for both new users and wiki administrators by using sub pages.
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.
Where should one create this page? in the root level? under MoinDev?
Is HelpOnGibberish a system page or a user created page? should I update this page from the new wiki version?
- What are the main parts of this wiki? where do you find this information when you visit a new wiki?
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 wiki structure will be clear. The design will help the new user to answer these questions:
- What is this site? - they may land in the site right from Google
- Where am I in this site?
- What are the other pages in this part of the wiki?
- Where can I go from here?
How to do this in an easy way for both the wiki admin and users:
- The structure will be displayed automatically - without configuration or user added parts like macros.
- Each page at the root level will be displayed in the wiki pages list
- System pages that every moin wiki has, will be displayed at the same location and order on every wiki
- Wiki specific pages will be displayed at the same location on every wiki.
- Some or all the pages in a wiki part will be displayed in the same place in every wiki.
- The complete path to the page you are in will be displayed in the same place on every wiki.
- System page will be separated from the wiki specific pages, with other ACL rights
We have to tool to make this situation much better: sub pages. Here is how it can be done:
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.
FrontPage - default front page for new wiki
- Help - main pages for help
- Find - main page for find pages
- Find/Other find related pages...
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:
FrontPage - Each wiki will have its own front page, overriding the system front page.
- Other developers pages...
MoinBugs - index page for all bug pages
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:
- The user home page
- The user preferences page
- Last pages
- Specific pages
On the top of each page, probably just above the page title, we can have the navigation line:
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:
This could be implemented in the top of the page like we do today, but will be much better in a side bar:
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:
- To create a new bug report, go the category page and click the "Create New Bug Report" link at the top. A new bug report will be opened, add the details and save the page. The page will automatically be listed here.
And this is the new "How to create a new bug category?" section:
- To create a new bug category, click on the link "Create New Bug Category" and the top of this page. A new bug category page will be opened, add the details and save the page. The page will automatically be listed here.
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.
Hi Nir. I'm thinking like you:
- At my work i just have had a great discussion about "Unscalability" of a Wiki-Documentation-System:
One from my colleagues would prefer to use plone for the documentation in my section, because Plone easily provides a folder-based hierarchically storage area. And he believes, that everybody of my section would need a folder-based Clipboard for storing informations.
If we would be able to realize a more simple structure in the wiki, i think, some potential users would like wiki too.
And if we would be able to present information in a folder-based hierachy like the Windows-Explorer, other users would find informations much easier.
I don't say, that the structure of the wikipages is bad. But i would say, that some people need a menu-based or a folder-based presentation of the contents of a WikiWikiWeb... -- KlausHeinisch (2004-06-21 20:41)
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:
- it often isn't clear how the hierarchy should look like, often there are multiple ways to do it and it is unclear which is better
- the place in the hierarchy new content should be put in is unclear, especially if there are multiple thinkable pathes.
Furthermore, using subpage hierarchies can be painful to address as you can not simply say look at ThisPage, but you have to say look at FirstLevel/SecondLevel/ThirdLevel/ThisPage.
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):
- Pages are not always hierachical
- Pages belong to one or more parent categories.
Not everyone believes that 'automatic' solutions such as FirstLevel/SecondLevel/ThirdLevel/ThisPage
What not add a #parentCategory Parent1,Parent2 preprocessor?
Alternatively, since I see that no solution yet exists :(....
-- C (2005-10-4)
This is a very good idea, I have already thought about implementing it. -- AlexanderSchremmer 2005-10-04 15:14:12