[opensuse-wiki] Category structure
Jon pointed this page out on the forum; http://en.opensuse.org/openSUSE:Wiki_structure 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. 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...) My instinct would be to make Category:YaST_modules a subpage of Category:YaST, as well as a subcategory. 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. It would presumably also put a hierarchy of links at the top of the page, something like opensuse.org/ Category:[Category]/Category:[subcategory]/:Category:[subsubcategory], which you can use to navigate around in - and it might make macros to search or list child pages, for example, available to us. 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. 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. 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. 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... ;) Thanks, Mike. (you maybe start to understand why I called myself confuseling, and have a bowl of petunias for an avatar...) -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
On Monday 21 December 2009 19:07:49 Mike Gentry wrote:
Jon pointed this page out on the forum;
http://en.opensuse.org/openSUSE:Wiki_structure
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.
True. 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- color:white;">YaST</categorytree> [[Category:YaST]] ----------------------------------------------------- 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 title 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 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. 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.
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 properties.
It would presumably also put a hierarchy of links at the top of the page, something like opensuse.org/ Category:[Category]/Category:[subcategory]/:Category:[subsubcategory], 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 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.
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.
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.
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: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
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
On Tuesday 22 December 2009 20:43:27 Mike Gentry wrote:
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. ;)
As you mentioned few times it is matter of balance between readability, simplicity and maintainability. One level subpage is not a problem, specially if the purpose is related to its root page and no other pages. In all other cases it is counter productive. For example, you want to refer in your text to "YaST development" by creating link to that topic with [[YaST development]], but "YaST/development" is actual article title. Your nice [[YaST development]] will be red, in other words it will point to non existing article. No surprise as Mediawiki software doesn't consider / as blank space, like it considers underscore. Now you have to search for the article, find out that it is "YaST/development" and use different form of the link [[YaST/development|YaST development]], because you don't want your readers to think that / in the middle of the text is typo. Three and more levels of subpages are salt on the wound, it will worsen readability, make linking to other topics adventure for user, like in example with Standards and Libzyp, and present maintenance nightmare. Simple article renaming, which is in Mediwiki done by moving article to new one, with new title, and leaving redirect on original, so that links from web (other sites, forums and mail lists) don't break, creates flare of links at the top of the page. BTW, similar problem with linking is with capitalization. Titles in the Mediawiki software are case sensitive, with exception of the first character. If we want to refer to article about "Kernel development", we can write [[kernel development]] in the middle of the sentence, or [[Kernel development]] on the beginning and it will point to the same article "Kernel development". In a case that we use book style capitalization the article is "Kernel Development" and previous simple link will not work, we have to use [[Kernel Development|kernel development]] on each and every place we need link. Book style doubles effort to link other articles in you text. -- Regards Rajko, openSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
participants (2)
-
Mike Gentry -
Rajko M.