Mailinglist Archive: opensuse-wiki (174 mails)

< Previous Next >
Re: [opensuse-wiki] Category structure
  • From: "Rajko M." <rmatov101@xxxxxxxxxxx>
  • Date: Tue, 22 Dec 2009 00:14:01 -0600
  • Message-id: <200912220014.01890.rmatov101@xxxxxxxxxxx>
On Monday 21 December 2009 19:07:49 Mike Gentry wrote:
Jon pointed this page out on the forum;

One thing I don't fully understand; we are trying to avoid page names
like YaST/Tutorials/Simple YaST Module/Using the Access to the
Configuration Data, (and so we should! Cripes!), and using categories as
part of the strategy to get there. This, and things like the tree view
function do look like they'll help a lot.

Article title with all that slashes looks like URL, not real title and contain
a lot of information that is not necessary to see.

So we have a Category:YaST, and a subcategory Category:YaST_modules (made
a subcategory simply by putting a link to Category:YaST at the end of the
page, if I'm following...)

Yes; below is example with Category:YaST development
This is used to list articles related to YaST development (and nothing else).
It belongs to category YaST.

<categorytree mode=categories style="float:right; clear:right; margin-
left:1ex; border:1px solid gray; padding:0.7ex; background-


Double square brackets are just wiki markup for internal link.

"Category:" is name of namespace and it is always only one at the begin of the

YaST is name of the article.

<categorytree mode= ... is the tag that will end up as nice list of
categories on right side of the screen.

My instinct would be to make Category:YaST_modules a subpage of
Category:YaST, as well as a subcategory.

It is possible, but then instead of
Category:YaST development
we will have

Which as a single subpage does not create a lot of problems, but with more
nested it will become mess that is hard to read and even harder to manage.

Try this
section Metadata Signature and Checksum. link Metadata Signature.
It will lead you to that has
up link to Libzypp ie. .

Now, if you want to go back to Standards without browser back button that
would be end of story. That is not the way how internal links should work.
First make user used to them, then lead to to different places.

This may be exactly what you were referring to when you spoke of people
carrying the filesystem hierarchy mentality into the wiki with them - but
to me it seems logical, and perhaps makes navigating fractionally easier
- you can, for example, tell your browser to go 'up' to parent, and it'll
take you to the more general category.

That will work with Konqueror.
Firefox, and the rest of browsers that I know, in default configuration don't
have Up arrow. That functionality is typical for file system browsers, and
Konqueror due to its dual nature, web and file system browser, have it.

In this case word "logical" you have to replace with "I'm used to" :-)
Logical is to use software (Mediawiki) properties to achieve clarity, not to
force structure that is used somewhere else and in the Mediawiki is nothing
better then a patch that should close gap between our habits and software

It would presumably also put a
hierarchy of links at the top of the page, something like
which you can use to navigate around in - and it might make macros to
search or list child pages, for example, available to us.

It will be with back links right below title. Example for being on subpage
Category:category/sub1/sub2/sub3 <= title
category < sub1 | sub2 <= back links

Then one day we decide to rename sub3 to sub3a and top of the article sub3a
will have one more link.
Category:category/sub1/sub2/sub3a <= title
category < sub1 | sub2 <= back links
redirected from sub3 <= redirect link
add to that Flagged Revisions links, top navigational bar that connects group
of articles, and you end up with half page of links, and below that comes our
introduction to article that must exist.

The end result: user has to scroll to see first line of text he is looking
for, and that for every page, because we are going to unify look and feel.
We put a lot of effort to keep top portion of the article slim, and anything
that adds lines we don't like.

Even pages full of advertising, that people don't like, give to visitor the
article beginning in a bottom half of the screen.

Now I suppose that page name is pretty ugly, but then most people aren't
going to spend much time looking at the categories, but the pages.

Yes, and when user don't find information in current article then he needs
overview of the topic, something that is easy to browse.

the purpose of the categories is precisely to abstract this structural
information out of the pages, and present it clearly; making the category
pages highly structured would not necessarily entail making the actual
pages follow that structure too.

The categories are automatically created from pages and categories, so
articles, if properly included will follow the structure. Lost pieces where
author did not use category will always exist, but that is not big problem if
it doesn't happen on hundreds of articles.

Presumably there aren't going to be all
that many levels of nested categories, so I think the problem might be
manageable - if there are, that may be an indication that the categories
haven't been thought out properly.

Wrong category name, or inclusion in wrong tree will happen.
First can be cured by changing name to better one, second by editing the
article. In case of subpages changing title leads to mess of back links.

I see that wikipedia also does it the way you're proposing, and
presumably they've thought about it longer than any of us could... I'm
just wondering what the reasoning is, and have possibly misunderstood
everything completely... ;)

Wikipedians had much more time to thinker how to sort out articles and I
believe that they did good job. Similarity of my proposal with Wikipedia
practice is not accidental :-)

Thanks, Mike. (you maybe start to understand why I called myself
confuseling, and have a bowl of petunias for an avatar...)

Hopefully this Late Night Answer will not make more confusion :-)

Regards Rajko,

openSUSE Wiki Team:
People of openSUSE:
To unsubscribe, e-mail: opensuse-wiki+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-wiki+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups