User:Bigstones: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
Line 18: Line 18:
I know some Java programming and I'm used at the fact that a class can extend ''only one'' other class<ref>This is not the case in other languages like C++.</ref>, thus you clearly know what kind an object belongs to; this is not happening in the wiki: I see that articles have categories in the same way that tags are used, that is, they're combined so that by looking at them one has an idea of what it talks about.
I know some Java programming and I'm used at the fact that a class can extend ''only one'' other class<ref>This is not the case in other languages like C++.</ref>, thus you clearly know what kind an object belongs to; this is not happening in the wiki: I see that articles have categories in the same way that tags are used, that is, they're combined so that by looking at them one has an idea of what it talks about.


However this is not helping in finding the articles, let alone having an overview of them. In fact, see this: [[Airport data (apt.dat) update]]. This article will be lost in [[Category:Core development projects]] and more so in the totally flat [[Category:Scenery enhancement]].
However this is not helping in finding the articles, let alone having an overview of them. In fact, see this: [[Airport data (apt.dat) update]]. This article will be lost in Category:Core development projects and more so in the totally flat Category:Scenery enhancement.


I'm not sure if the wiki allows for more independent categorizations to exist for one article,<ref>Please keep reading and you'll see what I mean.</ref> but in general I think that a tree structure would fit and help in maintenance. A tree structure would force all (most?) of the categories to be a subcategory of another.
I'm not sure if the wiki allows for more independent categorizations to exist for one article,<ref>Please keep reading and you'll see what I mean.</ref> but in general I think that a tree structure would fit and help in maintenance. A tree structure would force all (most?) of the categories to be a subcategory of another.
Line 34: Line 34:
In general, one should be able to have an organic view of current category tree and do some "drag and drop" and "rename" with articles and categories as you would with files and directories. One could create temporary categories, where to put things that look similar, then maybe finding they need some sub-categorization or that those articles should all have the same category. Slowly things would get the shape of a tree.
In general, one should be able to have an organic view of current category tree and do some "drag and drop" and "rename" with articles and categories as you would with files and directories. One could create temporary categories, where to put things that look similar, then maybe finding they need some sub-categorization or that those articles should all have the same category. Slowly things would get the shape of a tree.


The main categories are already there. The current organization of the portals is an excellent guideline. I've recently seen [[Category:Scenery enhancement]] where the subcategories are just ready, only they're done "by hand" and not yet applied. That's doing the right thing with the wrong tools. Many categories suffer from this flatness, probably because of the already mentioned use of categories as tags. Another noticeable example is [[Category:Howto]], but again, there are many.
The main categories are already there. The current organization of the portals is an excellent guideline. I've recently seen Category:Scenery enhancement where the subcategories are just ready, only they're done "by hand" and not yet applied. That's doing the right thing with the wrong tools. Many categories suffer from this flatness, probably because of the already mentioned use of categories as tags. Another noticeable example is Category:Howto, but again, there are many.


==== Isn't one category per article a too strict limitation? ====
==== Isn't one category per article a too strict limitation? ====
Yes and no. In fact, some articles might be useful in a couple of far related categories. An example is given by [[Modeling - Getting Started]] and [[Howto:Lightmap]] (as most of the effect/animation related articles). These articles clearly belong to a couple macro-categories: [[Category:Aircraft enhancement]] and [[Category:Scenery enhancement]]. But there's also [[Category:Modeling]] and [[Category:Effects]] (well... pretend it exists).
Yes and no. In fact, some articles might be useful in a couple of far related categories. An example is given by [[Modeling - Getting Started]] and [[Howto:Lightmap]] (as most of the effect/animation related articles). These articles clearly belong to a couple macro-categories: Category:Aircraft enhancement and Category:Scenery enhancement. But there's also Category:Modeling and Category:Effects (well... pretend it exists).


This is the problem of orthogonal (i.e. independent) categories. On one axis, there seem to be the area of application (scenery, planes) and on the other particular technologies and techniques (Nasal, effects, modeling, ...). If the wiki allowed a "cartesian product" between chosen categories <u>''when searching''</u>, we could actually "tag" the articles, one tag per axis, and there would be means, when browsing categories, to see directly articles that have these tags combined.
This is the problem of orthogonal (i.e. independent) categories. On one axis, there seem to be the area of application (scenery, planes) and on the other particular technologies and techniques (Nasal, effects, modeling, ...). If the wiki allowed a "cartesian product" between chosen categories <u>''when searching''</u>, we could actually "tag" the articles, one tag per axis, and there would be means, when browsing categories, to see directly articles that have these tags combined.
573

edits

Navigation menu