Talk:Rules/Categories/March 2005

From MozillaZine Knowledge Base
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Archived talk from Talk:Rules/Categories. --asqueella 16:07, 7 Apr 2005 (PDT)

Articles in multiple categories

Should we put [[Category:Firefox]] (or any other category with subcategories) on all articles? Perhaps put it only on uncategorized ones - others are accessible via subcategories? If we decide to use templates as I suggested above, there's no need to put [[Category:Firefox]] on each article anymore, since the blurb is generated from template params, not from category information. That way we can keep the Category:Firefox less cluttered.

I think, though, that we should put articles about Firefox issues, both in Category:Issues (Firefox) and more narrow subcategory. That's needed because our categorization abilities are not perfect. Same goes for other subcategories.

Any comments? --asqueella

As you say, I don't think we need to put [[Category:Firefox]] on any articles, except uncategorized ones. I see [[Category:Firefox]] merely as being a holding place for its subcategories and uncategorized articles. I would actually say that no article properly belongs to [[Category:Firefox]]; editors who are unsure where their article belongs can put it there to begin with, but that article should be refactored into an appropriate subcategory at a later date (probably by a different editor/maintainer).
On the other point, articles which can be thought of as "issues" should definitely be categorized twice, once in [[Category:Firefox issues]] and again in the appropriate semantic category. (Eg, an article on installing extensions belongs in (some subcategory of) [[Category:Firefox issues]] and also properly belongs in (some subcategory of) [[Category:Firefox extensions]]. This latter category will contain articles which are not "issues" as well as those which are. See my comments in the section above.
--Mozcerize 02:38, 28 Feb 2005 (PST)

Comments from Mozcerize

I agree with the basic idea of this tree, but I have a couple of points to make.

  • Firefox issues is a good idea, but we should emphasize that it is semantically separate from the other categories. Other categories cover the entire contents of the KB (including issues) and it should be organized like a book's table of contents. To find out about customizing toolbars, I look in the Firefox category, then the UI subcategory, then … (If the MZ Forums were organized in this more granular manner, we would be less likely to get 20 thousand repeated questions being asked, since the user would quickly be able to find more relevant areas to search ;-). The Firefox issues category (and its subcategories) will contain all articles in the KB which can also be thought of as "issues" in addition to their normal categorization (and so such articles will belong in two categories). Hence the choice of useful subcategories for "Firefox issues" is completely independent of the choice for "Firefox". Your tree describes this well, but I thought it important to check that we agree on this so we know where we're going.
Yes, we agree here. This needs to be articulated on the resulting Rules page, though. Let's start putting together rules on using Categories on Rules/Categories. A few examples should be included. --asqueella

Agreed. --Mozcerize

---

  • I don't like the generic subcategories suggested above. Generic subcategories of "Firefox" such as "Firefox general" and "Firefox basics" seems to me to defeat the whole point of having categories. A category name should unambiguously describe its contents. Imagine I'm looking at the "Firefox" category. Is the answer to my question about 'mouse shortcuts' inside the "Migrating", "Profile", or "General" subcategory? Well, presumably it's in the General one (but shouldn't this then be called Other, referring to the fact that it's not in any of its more specifically named siblings?). So I go into "General", and I'm faced with "Configuration", "Visual customization", "Basics". Well, presumably it's in "Basics". But "Basics" doesn't actually describe the category. Again, it should be called "Other" if it is intended to hold any article which doesn't belong in the sibling categories, or it should be abandoned in favour of "Using Firefox" or "Tabbed browsing". Note that I'm not complaining about your choice of names, asqueella, because obviously these have not been finalized yet. I'm really talking about the more fundamental issue of the semantics of this database. IMO, generically-named categories solve nothing; we must use specific ones instead.
ok, I'm not going to defend "Firefox general", let's move categories from that to Category:Firefox directly. I just didn't occur to me that the contents of Tips/FAQs pages can be listed in main category page.
I would like to ask you to think again about Category:Basics (Firefox) though. It's not a generic catch-all category. It's intended to be rather small category that describes using basic but powerful features built in Firefox. It should contain pages that show the new user the power of Firefox.
As I wrote above, it would contain articles on Tabs/Search Bar/keyword searches. A few more: customizing toolbars, send link (well, it's not exactly powerful feature, but it's basic), using popup blocker etc. Probably, mouse/keyboard shortcuts, an introductory article on themes/extensions.
Things that should not be included in this category: disabling autocomplete, moving tabbar, about:config...
Perhaps "basics" is a bad name, but it's not a generic category. After reading your comments, I agree that generic categories are bad and should be avoided. Let's note this in Categories guidelines too.
--asqueella

Ok, perhaps I misunderstood the purpose of "Firefox basics". It seems that this category covers all the things that one can do with the browser by using the menu items, etc. (In other words, no "tricks"!) So perhaps "basics" isn't such a bad name, so long as the meaning of this category is explained on its supercategory page (which will be "Firefox"). --Mozcerize

Maybe this discussion is already dead (I haven't been able to keep up), but anyway, IMO a category like Basics is not needed for this knowledge base. I was just looking at the Knowledge section at blogger.com, which is divided up into the three levels of Blogger Basics, Working with Blogger, and Advanced Use. In the case of blogger.com, this setup works OK because they don't have any other How-to or Help pages, and thus the Basics section functions to get new users acquainted with basic blogger.com features and capabilities. The mozillazine knowledge base, on the other hand, doesn't fill this same niche. Firefox basic features/usage are already covered in the mozilla.org product page for Firefox, in Firefox's own Help viewer, and in the mozilla.org FAQ for Firefox (not to mention in the nidelven tutorial). The mozillazine kb is a supplement to these other sources of basic, introductory-type information. For this reason I don't think a Basics category will truly be helpful to the vast majority of users, and because it is ambiguous it might actually make the kb more cumbersome to navigate. Wintogreen 20:48, 7 Mar 2005 (PST)
Oops, missed your answer. If we don't have such articles, we won't create this category, but I thought there are such articles already in the kb. asqueella

---

  • So some productive suggestions! Underneath "Firefox" we need Installing, Migrating, Profile, UI (perhaps renamed so that non-technical users know what it means), Plugins, Themes, Extensions, Settings (=configuration?), Security, Websites. Where do things like cookies, passwords, Javascript fit in? "User data"? "Web content"? In fact, a good place to start is to look at the current Tips, FAQ lists and copy the headings used therein, although we might choose to place some of the "headings" at different depths in the category tree. We should ensure that, in a given category, the immediate subcategories have an approximately equal level of specificity (ie, we don't want Category:Cookies sitting next to Category:Settings, since cookies are not as general as settings. (Cookies belong in "User data" which might in turn belong in "Profile". "Profile" is about as equally general as "Settings" so these should be at the same depth in the tree.)
  • Phew! Hard work ;-) But better to get the design right now than have to change it again later.

--Mozcerize 03:18, 28 Feb 2005 (PST)

Reply from asqueella

  • Categories names should include application name in it, so that we don't mix articles specific to different application in one category. To be able to use templates, they should be called "{appname} {subcategory name}", e.g. "Firefox issues". Suggest real category names, please.
Agreed. Just a misunderstanding here; I didn't include the appname in my examples because I intended the name to be preceded by the relevant app (there may be more than one, eg Firefox and Thunderbird), giving rise to two complementary categories for different apps. --Mozcerize

Well, IMO, Firefox and Thunderbird should use completely different categorizations (wintogreen, could you post a draft for Thunderbird categories here?) --asqueella

Not for the next couple of days, at the earliest. "Real life" is calling... --wintogreen
No problem, it's not very urgent. I may be busy too, but I'm going to have some free time next weekend. (got your PM btw) --asqueella
There really is no issue here; I was just being lazy and not bothering to type the word "Firefox" in front of my suggested names. Different types of category may well be required for other apps. --Mozcerize

---

---

  • UI is a bad name, it's not clear what one can find in such category (maybe Visual customizations is a better, though not equivalent, name).
Things like mouse and keyboard shortcuts, tabbed browsing, context menus, toolbar customization. In other words, the way you interact with the application. (I guess toolbar customization is an example of what you mean by visual customizations?) Perhaps these should be divided between basics and visual customizations instead. (What else do you have in mind for visual customizations?) --Mozcerize

That's what I don't like - everything is piled up in one category. Tabbed browsing is a basic concept, toolbar and context menus customizations (+themes and things like move tabbar to the bottom) are "visual customizations", keyboard shortcuts is a separate thing.

I would agree if "UI" category had explanation of Firefox UI - ie. what does each menu/keyboard shortcut/button does. Making it a "we couldn't categorize this better" category is a bad idea, imo. --asqueella

Well, things wouldn't be piled up in it because it would have subcategories! I don't think that makes it a "we couldn't categorize this better" category; it's just a logical unit containing other more specific subcategories. Things like keyboard shortcuts have to belong somewhere. But if you don't like this and you prefer to divide most of the UI stuff between "Firefox basics" and "Visual customizations" then, as you suggest, "Firefox UI" could be a smaller category at the same depth as these other two which simply explains menu items, shortcuts, etc. I'm equally happy with this. --Mozcerize
  • I don't understand what "Websites" might be used for. Links?
Not sure :-P. It's just that articles belonging in "Firefox:website issues" need a real home too. Where will they go? --Mozcerize

Why do you think Website issues need a "real" home? If you think it's really necessary to have each article from Issues to belong in at least one more category, we can put website issues somewhere on Gecko pages.--asqueella

Because everything does have a real home! An issue is just a normal piece of information rephrased as a problem. If I'm interested in knowing something, I expect to be able to find it using a semantic table-of-content-like structure like the one we are in the process of creating now. Hypothetical example: I believe my Fx to have a bug which prevents new tabs opened from links from being selected, despite my ticking the correct box in the Options dialog. I navigate to the relevant semantic category (eg "Firefox" -> "Firefox basics" -> "Firefox Tabbed browsing") and discover that the info I wanted isn't there. I don't *then* want to have to examine everything in the relevant subcategory of the Issues area just in case there's something there that hasn't also been filed in the "Firefox Tabbed browsing" category. This has been my whole problem with the KB so far: to find a piece of info, one has to look in more than one place, because there's no obvious home for something. I think the motivation behind the proposed new structure should be to resolve this!
To summarize my point as succinctly as I can: after creating an article, regardless of whether you word the article in the style of an issue or as a FAQ or as a tip, it should be filed into the category which is appropriate to what the content is about. For example it might be about keyboard shortcuts (belongs in "Firefox basics"), Javascript (belongs in "General concepts"). If the content happened to be a solution to the problem of not being able to send mail in TB, then the article is about sending mail, and belongs somewhere in "Thunderbird basics". However, in should also be put into the "Thunderbird basics issues" category.
Thinking about this has really made me realise that I don't much like the "Issues" category at all! What problem does it solve? Who does it help? We would hope that before asking a question in the forums, a user will visit the KB to see if it has the answer. If he browses the Issues area and his question is not answered there, do we expect him to come straight back to the forums and ask? No, because it's clear to us that the answer to his question might well exist in the KB, but it simply wasn't regarded by its original author as an "issue" and so wasn't categorized under "Issues". Instead, we expect him to also navigate through the logical categories ("Firefox" -> "Firefox basics" -> "Firefox Tabbed browsing") to see if he can find anything relevant there. So why bother making him look at the issues area first, if he's then got to look in another area anyway?
Now I'm not saying issues should be abandoned completely. But I do think that they should be regarded as just a generalization of the "Frequently encountered problems" concept. The user should not be led to believe that browsing "Issues" is a replacement for browsing the KB by semantic category. A bit like how browsing the "Most popular extensions" section of update.mozilla.org is not a replacement for browsing the entire extensions database using the semantic categories provided there.
Well, I've finished my rant now :-P. BTW, "Gecko" seems a good home for some website issues!
--Mozcerize

(asqueella's reply to Mozcerize)

  • First, I wanted "basics" to be a small category that has a few articles on the essential application features, not a large category with subcategories as you suggest (talking about "tabbed browsing" subcategory). Firefox "tabs" category needs another home.
  • Next, I disagree that an issue is just a normal piece of information rephrased as a problem. It's a description of a specific problem with suggested fixes, and as such it is different from other pieces of information, like tips or concepts/terminology explanations. Therefore I think it is ok to make the "Firefox issues" category their home.
  • Hypothetical example[...]. First, if you have a problem with Firefox, it would make more sense to look in the list of problems, i.e. "Firefox issues" category. Second, I believe that any given article should be included in as many categories as possible.

This means that you can find a given piece of information in a few different ways, but it is good, because the probability of user finding the information he needs is higher. If user was unable to find an existing article by navigating related categories ("issues" and "tabs" in you example), it means that that article needs to be included in more categories, not less. That's the problem of current KB - articles not listed on pages where it would make sense to list them.

  • To summarize my point[...]. Agreed with you here. But if an article doesn't have an obvious home, then perhaps it may be filed in "issues" only (and probably in "firefox" as uncategorized one (?)). As for "websites", it doesn't make sense to put that as a subcategory of "firefox". Gecko indeed sounds like a better home.
  • What problem does it [Issues category] solve? Imagine I have an issue with Firefox. I go to Firefox section of the knowledge base and I see a link to "Firefox issues" page. Hooray! I click the link and I get a list of articles in this category. I do a search in this category and - voila! - here's the page I've been searching for. I don't have to go three semantic categories deep trying to guess their meanings and I don't have to filter out all articles-not-about-issues manually.

It is most useful for articles that don't have an obvious home on the Firefox page itself, like websites issues. (e.g. people who don't understand that we put (jsut an example) the keyboard shortcuts in UI category will still be able to find their issue of CTRL+ALT+F4 not working in linux on Issues pages).

Perhaps we shouldn't use subcategories for "issues" as much as we'll use them for "firefox" category itself, but still having an "issues" page is better than not having it.

Ok, perhaps I'm being too much of a purist when it comes to forcing everything into a "real" home. I'm happy with your idea that issues which really are hard to categorise (eg "Websites", "Fx won't start up" should also be placed in the top of the "Gecko" and "Firefox" categories as well as being in the "Issues" category. I also think that keeping the "Issues" category fairly flat would be useful.
To help with keeping "issues" category flat, I removed the "plugins issues" category and put a Category:Plugins in "Firefox" directly instead. I suggest that we put all plugins pages in "issues".
However, I still see "Issues" and "Firefox basics" mainly as views of certain bits of the database rather than semantic categories in which the data is stored (the "main Firefox tree"). As a result, I think we need to really emphasize to editors that they should try hard to put articles intended for those two places in part of the main Fx tree as well. It's just that it would be better to have every article relating to eg. tabbed browsing in the "Tabbed browsing" category (wherever that ends up being in the main tree), even if some articles also feature in the "Issues" or "basics" categories. It just seems "tidier" that way. --Mozcerize 09:36, 1 Mar 2005 (PST)
Agreed! --asqueella


  • Anyways, we (well, I) don't expect users to browse the KB using categories much. Most advanced/intelligent people will do a google search and find the kb page they need (our quality pages are ranked high in google). KB is also a resource for posting short replies to support questions.
Well, I would expect a reasonable percentage to browse using categories. I also think that many will do searches using the built-in search feature. --Mozcerize 09:36, 1 Mar 2005 (PST)

That doesn't mean we shouldn't try to make navigation using categories easy. --asqueella

Certainly. --Mozcerize 09:36, 1 Mar 2005 (PST)
  • Should "Plugins" category be shared between Mozilla Suite and Firefox? Are there any differences there?
I don't know. It sounds possible to share them. --Mozcerize

ok, let's call it Category:Plugins for the time being. --asqueella

Great --Mozcerize

---

  • I like "Firefox configuration" more than "Firefox settings"
fine by me. --Mozcerize

---

  • There are few articles on themes, so perhaps we shouldn't create a separate category for that? Just put an intro page on "basics" and "visual customizations".
Ok, yes there won't be many articles on themes outside of the dev area. So putting them in visual customizations seems reasonable. --Mozcerize

---

  • Where do things like cookies, passwords, Javascript fit in? "User data"? "Web content"? — a good question. I think cookies/passwords should be in Category:Profile (Firefox) and there should be a notice that all user data is stored in user profile.
Agreed. --Mozcerize

---

Agreed, but it needs a home outside of the issues area too. Issues must be a duplicated subset of the whole content.
[Additional comment] Javascript seems to belong in "General concepts". --Mozcerize

right. --asqueella

  • In fact, I find most of articles in FAQs/Tips poorly categorized. We shouldn't blindly copy categorization from those pages.
Agreed. They need a lot of reorganizing.
[Additional comment] Actually, I've had another look at these, and they don't seem that bad. It's very clear from the sections on these page where to find the information you're looking for (apart from the "misc" section, of course). Of course, the sections would be split apart into different categories when we implement the category tree. But would you explain what you dislike about the divisions used in FAQs, tips? --Mozcerize

I like:

The rest are either poorly named (imho) or intersect with each other. --asqueella

What others are there?! This covers everything except the articles in Misc, which will obviously have to be rehomed. (Nothing should ever be categorized as misc in our new structure. It should go in the deepest category which makes sense, and should then possibly be moved deeper at a later date by a more experienced editor or when a enough related material accumulates to justify a new subcategory.) The only other things you didn't mention have already discussed by us here, such as shortcuts and visual customizations. --Mozcerize
Usability, Display/Customizations and the fact that categories are listed on both pages. Looking at those pages carefully, I see they are not horrible, but they certainly made a bad impression on me. --asqueella

---

  • I don't think "user data" is a great idea. It's almost synonymous to "profile" category.
Yep, your comment above covers this. We just need a notice directing people to the right place. --Mozcerize
  • Agreed that immediate subcategories should be of equal level of specificity.

--asqueella

Categories names: Firefox {subcategory} vs. {subcategory} (Firefox)

Shall we use names like "Firefox issues" or "Issues (Firefox)". The main disadvantage of the former is that alphabetical listing of subcategories will be broken, unless we provide a sort key for each category (see metawiki help on categories).

The latter method is consistent to our articles names and will get the subcategories sorted correctly without any effort.

atm, I think the "Issues (Firefox)" is a better naming convention. --asqueella

I agree that Issues (Firefox) is better, for the reasons you give. An example of the problem you describe is at the the Category:Development where a lot of things listed under "D" (because their title begins with Dev : " should have sort keys applied. [That's most definitely not a gripe at you, btw! I've seen how much work you've been putting in to clean that area. This is something that we can do bit by bit. It doesn't all have to be done immediately.] --Mozcerize 09:36, 1 Mar 2005 (PST)
Applied the changes --asqueella

Would about:config-related pages fit under Category:Configuration (Firefox)? I am considering starting more verbose preference explanations (one page per expanded pref); how would everyone recommend fitting those into the hierarchy? Unarmed

That sounds appropriate to me --Mozcerize 01:21, 22 Mar 2005 (PST)

Category:Firefox and Firefox

What relation these two pages (and similar) will have? If it worked, I'd just move Firefox to Category:Firefox. But for some reason, mediawiki doesn't allow to redirect to categories pages. So, what are your suggestions?

asqueella

I prefer your first suggestion too. I really dislike the very existence of the "Firefox" article and others like it, and I would be very happy to see them go. The category pages are more appropriate. I would also love to see the headings on the Main Page lose their linkiness. I've never seen this used on the web apart from here, and it's both confusing and inconsistent. (Is the heading blue because it's a link or because blue is the style for headings?!) Instead, we should have a paragraph under the heading which showcases (ie links to) a couple of the most useful articles, and then has a sentence saying something like See all articles in the Firefox category. --Mozcerize 00:38, 31 Mar 2005 (PST)
The problem with that is it's harder to type [[:Category:Firefox|Firefox]] than just [[Firefox]] --asqueella
[update] Let's use templates for that, e.g. {{Firefox}} expands to Firefox.
Great. Nice work --Mozcerize


Category pages vs. arbitrary listings pages

This talk is much older than the rest of this page --asqueella 16:07, 7 Apr 2005 (PDT)

The proposals above are looking really good. The beauty of this approach is:

  • The user is informed from the start which applications the article applies to;
  • only one copy of the content is maintained (with the downside that editors must make more effort to make the wording of their articles more application-independent);
  • related pages are accessible via the categories which will appear at the bottom of each article;
  • you don't need to get rid of the Issues/FAQs/Tips pages (although personally I seriously dislike having both FAQs and Tips—an FAQ is just a tip or issue rephrased as a question, and so these divisions do not help the visitor find what they need). Since article titles no longer need to be product-specific, you are free to combine links in any way you see fit. The way I prefer to find information is in a table-of-contents-like manner: if I want to know about keyboard shortcuts for Firefox I would expect to visit the Firefox category, then the UI subcategory, etc. When the templates idea is implemented, I shall probably make an attempt at creating such a table-of-contents link structure, to complement (perhaps replace) the current Issues/FAQs structure.

--Mozcerize 11:19, 27 Feb 2005 (PST)

Mozcerize, please see my "Categories Tree" proposal above. I think we should sketch the categories structure before starting to implement it. asqueella

Indeed! I wasn't talking about the category structure in my post above; rather, I was talking about moving contents of Firefox : Issues-like articles into the editable part of Category:Firefox issues, at which point we can clean up (ie implement a true table-of-contents link structure to augment or replace) the subsections of the Firefox : Issues page. This is a separate issue from—although related to and possibly overlapping—the choice of categories. --Mozcerize 02:23, 28 Feb 2005 (PST)

wintogreen, Mozcerize—
When I talked about removing Firefox : Issues-like articles, I meant moving their contents into editable part of Category:Firefox issues. That way you get a "back to Issues page" for free. (The category page contains articles both categorically and alphabetically sorted, though). That's how it's done on Wikipedia sometimes. My proposal above ("Categories Tree") is to move Firefox : FAQs and Firefox : Tips to Category:Firefox general or whatever better name you can think of. Having both Tips and FAQs is just plain stupid IMO. --asqueella
So you mean that the current content (as is) of Firefox : Issues would exist at the top or bottom of Category:Firefox issues? Or do you mean that a page with the same contents, but organized differently, would be created via Categories?
I'm completely in favor of getting rid of Tips. It never has made sense to me for this kb. It worked OK at the old texturizer.net pages (now at mozilla.org/support) as a way to avoid overwhelming new users with too much techie information. It was a good idea in that context, but I don't think the kb plays the same kind of role and doesn't need that kind of scheme. Wintogreen 20:51, 27 Feb 2005 (PST)

Yes, I think asqueella means that a Category page contains two types of listing: firstly, in the editable section, a user-created organised structure of links, probably similar to (or even a direct copy of) the contents of eg. the "Firefox : FAQ" page. Underneath that would be the system-generated alphabetic list of all articles in that category. This gets us the best of both worlds: the automatic alphabetic list ensures that no article is "left out" (as used to happen in the current Firefox : FAQ" page); and we also get to implement a usage-centric description of (at least some of) the articles (as "Firefox : FAQ" currently presents) which will make it easier for the user to find the information he is looking for. (In KBs which primarily exist for support purposes, alphabetic lists alone are not ideal; the user may not know the correct phrase for the information he seeks, or there may be multiple appropriate phrases.) --Mozcerize 02:28, 28 Feb 2005 (PST)

Right. I propose copying the contents of listing pages as it is to the top of category pages. When we get to creating subcategories, they will also be put on the category page, so user will be able to use them for navigation too.
An example: we currently have a Dev : Extensions : Example Code page that is similar to Firefox : FAQs (it's a list of pages from Category:Example code (sub)categorized manually).
I moved its contents to Category:Example code as I plan to do with other such listing pages, look at the category page to see how it's going to look like. One thing left to do is to redirect the Example Code page to the Category:Example code page.
--asqueella

Great! That's exactly what I had in mind too. It follows that while categories are fixed, articles can be moved into new, more specific subcategories if and when they become needed. Also, the table-of-contents structure in the editable part of the category page can be reorganized at will, without affecting the underlying structure of the database. --Mozcerize 03:49, 28 Feb 2005 (PST)

Thank you both for the clarification. Sounds good! Wintogreen
Retrieved from "http://kb.mozillazine.org/index.php?title=Talk:Rules/Categories/March_2005&oldid=15098"