Rookie Category Mistakes

Just because, as George Lakoff points out, every human being thinks in categories, doesn't mean that every human being is good at categorizing for other people. I've come into a few situations where the ontology/category structure/whatever is already in place, and it's my job to fix it or extend it. Every time I train a new person or look over these legacy systems, I see similar mistakes.

For the purposes of this little rant, let's assume that you're building a category structure that will serve as a user interface to data and an organizing system for data management, rather than as a back-end set of rules and axioms that will add meaning to data.

1. Everyone Has an Area of Expertise. This is Dangerous.

The problem with smart people is that they know a lot about how things are Rightly Done and classified. That's fine if you're playing trivial pursuit or working on the Wikipedia.* It's not fine if you're trying to organize something at a level that people who don't know a lot about the topic can access. One very specific mistake that I've run across more than once is the urge people who know linguistics have to organize languages by family. Great idea, right? Sure. It's a great idea, it's correct, it can be used to impart meaning up and down the hierarchy - But it doesn't help someone who doesn't know the first thing about what these families mean. A linguist or student of language knows what these families mean, and might be annoyed to see them arranged alphabetically. However, their needs are subsumed in this case by the person who needs to find their language quickly. I've seen this language-by-family classification in crazy places, like in a drop-down menu for a job application.

There's what's Right and there's what Works. Usually the two are compatible, sometimes they are not. If you're using a taxonomy as a user interface, it has to be usable above all things. If someone who knows nothing about the topic can browse to a simple goal (in the example above: Find the English Language), you've done it right.

This particular mistake leads into the second one:

2. Just because you know about it, doesn't mean it needs to be called out

Let's say you're putting together a category structure for "European Languages" to be used for a travel site that is compiling some commonly used phrases in multiple languages.** You already know that you shouldn't go to crazy with the language family parents, because your users are business travellers who need to find the bathroom, not linguists. Here are some categories you DO NOT need: Romany. Basque. Corsican. Faroese. C'mon, stop showing off.

Time and again I've seen exhaustive, over-granular category structures in specific places while other areas suffer from too-little differentiation. I worked on one taxonomy that had gone to the level of detail of calling out every chip that Intel had ever worked on, but didn't even mention AMD. You need breadth before depth. You need a plan before you dive in. Just because you can build something doesn't mean you should.

*even then, have you ever stumbled across a 46-paragraph cross-referenced article on some bit of pop culture and can't find a single thing about, say, Boise, Idaho? That's a minor weakness of asking a community to work on a project. The project will reflect what the community is interested in, rather than what the community needs more information on.
**I love convoluted examples.