So, in the beginning, I expect Tabbles to deal with _two_ classes of objects: files and tags. Instead, categories were introducing a _third_ logical level, with which the user was forced to deal from the start.

Categories are groups of tabbles; but they could also be thought of as tags that you give to tabbles. Since tabbles are themselves tags that you give to files, this means that categories are tags that you give to tags. In other words: Tabbles allows you to tag files, but also to tag tags! I can almost hear the new user think: “I just want to create a damn tag. Why should I have to give a “category” to my tag?” Or, equivalently, “Why should I have to give a tag to my tag?“

To sum up, the first problem is the following:

The problem of grouping tags is a problem that arises only later, when the number of tags increases. The user must not be forced to deal with this problem at the beginning, when she is starting to use Tabbles. (And even when the problem arises, there are better ways to solve it than creating and managing groups of tags.)

2.

Categories had names — just like tabbles — but were different from tabbles in subtle ways which were invariably confusing to the new user. For example, you cannot add files to categories; you can only add files to tabbles. You cannot combine two categories, but only two tabbles. And you cannot see all the files in a given category (at least, not all at the same time).

Very often, the user was puzzled whether it is best to create a concept as a category or as a tabble. For example, should I create a category “comics”, containing tabbles “spiderman” and “batman”, or should I create just three tabbles (“comics” , “spiderman”, and “batman”) ? You might be tempted to reply that the first option is more logical, because spiderman and batman are, after all, _kinds_ of comics. But then, what if you need to see _all_ comics at once? You can’t. It would have been better to create “comics” as an ordinary tabble, and file into it all files which are either in “spiderman” or in “batman”.

3.

Another problem with categories was of _cognitive_ nature. Our brain works in such a way that ideas seem to “pop out of nowhere” into our consciousness. For example, the idea of “Carla” pops out of nowhere in my mind. I realize I want to see a file related to “Carla”. When this happens, I want to be able to specify just that: Carla. That is, I want to specify the concept “Carla” directly; I don’t want to be forced to click an intermediate concept, such as “friends”, before I can see “Carla” and click it. If I am forced to enter “friends” before I enter “carla”, then we have simply rediscovered folders! We haven’t really improved the situation as compared to how it was before Tabbles. I mean, if we accept that the user can only reach a concept by first specifying an intermediate concepts, we might as well stick with Explorer and navigate through folders. That would defeat the whole purpose of using Tabbles.

So, that cannot be good. The correct behavior is to allow the user to specify just what he has in mind. When the idea of “Carla” is formed in my brain, I must be able to specify just that (Carla), instead of passing through an intermediate concept such as “friends”. But that’s exactly what was happening with categories: before I click “Carla”, I was forced to locate the category “Friends”, defeating the purpose. What if I don’t remember the category? I just want to specify the damn name I have in mind.

You might reply that, though categories are a burden when you are trying to locate a tabble whose name you already know, they are useful when browsing, i.e. when discovering what tabbles are available in someone else’s database. For example, having a category “friends” is useful when you are browsing someone else’s database. But why wouldn’t a tabble “friends” (maybe much bigger than the average tabble) work just as well, or even better? We are planning to make tabbles scale according to their size.

__

There are other good consequences of dropping categories. The code is much lighter, and cheaper to extend and mantain. Previously, it was a maintenance nightmare. Every slight modification involved so many quirks and subtle traps which were causing a lot of bugs and wasted hours which I could have spent writing new features and adding real value to Tabbles.

All this is now gone, fortunately.

__

What’s the drawback of removing categories? Frankly, none that I can see. in particular, without categories, it does not mean you have no way to group tabbles as you please. You still have ways to create visual groups of tabbles: you can either drag them around with the mouse, arranging them into clusters as you please, and possibly even recreating the same arrangement they had when they were grouped into categories. Or you can assign colors to tabbles, so that tabbles with the same color can lie far from each other, and at the same time stick together visually. (Update: now you can also give name to colors and arrange tabbles by color name, thus producing a layout which is visually very similar to the old category view.)

__

Update: I have received the first complaints about removing categories. (Fortunately, nothing that can’t be fixed in a better way, and without reinventing folders, which is what categories were).

Update #2: I received another expected complaint: “don’t remove features; leave users the choice whether or not to use categories”. Choice is good.

This argument would make sense if giving users the choice were costless. Unfortunately, keeping categories has a cost. It is: 1) forgone users due to the increased complexity (you can give tags to files, and you can also give tags to tags); 2) increased cost of mantaining the code, adding features, testing the code, and avoiding bugs.