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@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org