Dmitry Jemerov's Weblog

Segusoland, and categories in OmniaMea

Just stumbled across a link in the More Theory blog pointing to segusoLand, a file browser with "some truly revolutionary ideas behind it". And since I always try to keep track of innovation in all areas related to our project, I was curious to see what was so new about it.

But in fact, while segusoLand is indeed innovative, I don't think it really improves on the existing solutions.

I'll start with discussing a problem with which we've had first-hand experience when developing OmniaMea: categorizing information. Initially, when I designed the interface for working with categories in OmniaMea, I was greatly influenced by the paper "User Interfaces for Supporting Multiple Categorization" by the developers of Haystack. My reasoning was that, since we give the user the possibility to assign multiple categories to each resource, she will use it to create independent category hierarchies (for example, one for company products and another for departments - development, testing, marketing and so on). Then she will naturally find the category intersections - "IDEA Marketing" or "OmniaMea testing" - very useful.

However, when I got initial feedback from users trying to figure out the implementation, I quickly saw the problems with that implementation. First of all, it was tremendously confusing for the users. The categories were presented in a tree, and by expanding a categories node you saw all the categories intersecting the one you have expanded. And the users couldn't really understand how the tree worked, why it could be expanded in so many directions and still show the same items everywhere, and what was actually shown when a node was selected.

Second, we immediately tried to convert the folder structure that our users had into the new category structure. The result was that the all the user's folders (up to 200 on real databases we used for testing) were presented as a single alphabetically sorted list. Since expanding nodes was reserved for showing intersections, we couldn't also show the folder hierarchy in the same tree, so the list had to be linear. As a result, it was much less manageable than the original tree, and many folders which made sense in the context of their parent folders were confusing when shown at the top level of the tree.

And third, most of the folders actually existing in the users' databases couldn't possibly fit in the independent hierarchy system I described above, and the intersections between them were mostly random. It was mildly interesting to see that Ben Laurie posts both to the OSAF dev list and to python-dev, but the value of such an intersection for me personally was zero.

(Not to mention the problems with implementing fully correct updates of the intersection tree when categories are added or removed from resources, which can cause nodes to disappear from the middle of the tree. I never actually solved this - my implementation didn't update correctly in some cases).

Thus, we eventually decided to go with a much more conventional implementation - a resource can still belong to multiple categories, but the categories are shown in a simple hierarchical tree, and the intersections between categories can be built through standard mechanisms of advanced search or custom views.

The segusoLand implementation of file organization suffers from many of the same problems - except that the number of folders in my filesystem is not 200 but closer to 20 thousand (and is probably still greater than 1000 if you count only the folders that I actually work with). Showing them in a linear list instead of a logical categorization will seriously cripple my ability to work with them. And even if you look at the screenshot provided (where the list of folders is very short), you will see that very few of the possible folder intersections make sense. How many cartoons on C# or configuration files authored by Douglas Adams do you actually have on your machine, after all?

I'll briefly mention other problems with segusoLand. For example, the Time column makes sense for very few operations (the mainframe batch job era has ended some 30 years ago, and there is no need for me to schedule printing of my PDF files hours in advance), but for the sake of uniformity, it is displayed for all commands, and takes up quite a lot of the UI space. (Looks like I can hide it, but why create it in the first place)?

Another problem is that, while I have quite a lot of programs capable of viewing pictures installed on my machine - IE, Firebird, Opera, Paint, the standard image viewer and so on - I always use only one of them, namely ACDSee. Making me choose the program I want to use every time I want to view a picture is a complete waste of time. (But of course, assigning the default application breaks the principle of uniformity - namely that the actions I use 50 times a day and actions I use once a year must be equally hard to do from the UI).

However, these problems have little to do with OmniaMea, so I'd better stop now and leave segusoLand alone. :-)