Mailinglist Archive: opensuse-wiki (174 mails)

< Previous Next >
[opensuse-wiki] Re: Category structure
  • From: Mike Gentry <mike.h.gentry.lists@xxxxxxxxxxxxxx>
  • Date: Wed, 23 Dec 2009 02:43:27 +0000 (UTC)
  • Message-id: <hgs04f$7to$1@xxxxxxxxxxxxx>
On Tue, 22 Dec 2009 00:14:01 -0600, Rajko M. wrote:

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

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.


Hard to read, I can agree with, but hard to manage I'm still not entirely
sure about. I guess I would just naturally assume that
'compartmentalising' things according to subject makes it easier to keep
track of things using automatic generation of links, housekeeping, macros
and such. But then I suppose if those can be worked well enough through
the 'category -> subcategory' relation, the 'page -> subpage' relation on
top of that doesn't add anything.

Try this
http://en.opensuse.org/Standards/Rpm_Metadata section Metadata Signature
and Checksum. link Metadata Signature. It will lead you to
http://en.opensuse.org/Libzypp/Metadata_Signature that has up link to
Libzypp ie. http://en.opensuse.org/Libzypp .

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.


I take your point, but presumably we will be using subpages - I guess I'm
just wondering what specifically about categories makes it desirable to
avoid them entirely.

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.


I often delete the last 'branch' of a url to look at the 'parent' page,
or use a FF extension to do the same - but then I concede that we're so
steeped in computer thought patterns, it's hard to know the extent to
which that is the sort of thing average users would think of.

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 properties.


Mediawiki includes subpages as part of its structure. I completely agree
that overreliance on that would create a mess - I'm just concerned that
we could be overcompensating.

It will be with back links right below title. Example for being on
subpage sub3:
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.


This makes sense - but isn't it configurable in the 'style'? Is it
actually impossible to impose some degree of structure without creating a
mess of unnecessary links?

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.


I suppose it boils down to a balance between readability and
maintainability. Oversimplification can make things harder to maintain,
and thereby ultimately damage readability as well.

Surely
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.


So if we made a Category:Bigcategory/Smallcategory, and a corresponding
Bigpage and Smallpage included in the Bigcategory and Smallcategory
respectively, would that require Smallpage being a subpage of Bigpage?
That would certainly be restrictive.

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.


This is something I've not used wikis enough to have seen - but I can
understand the desire to avoid it.

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

--
Regards Rajko,


Thanks for the comprehensive answer. As I said, I haven't used wikis
much, so this is an attempt to understand, rather than to criticise.
You're close enough to convincing me that I'll take your word for it. ;)

Mike.

--
To unsubscribe, e-mail: opensuse-wiki+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-wiki+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References