'Type Manager' The File Manager of Tomorrow?

IceFox writes "In the past few years many of us have been introduced to a new type of application, the Type Manager. Most of us are familiar with iTunes, but there are many other Type Managers out there that are gaining market share and a rabid fan base of users such as digiKam and amaroK. Type Managers seem to have that magic combinations of features that makes users love them. I have been taken a closer look at the Type Manager, what makes them so usefull, what they really provide for the user and came to some surprising results. After creating a list of all the traits of a Type Manager I was able to define exactly what a file manager should be and discovered that there are in fact many partial Type Managers out there now that implemented only half of what makes up a full Type Manager."

Comments

STOP THE PRESS!

[sg_oneill]

New must-have! metadata!

Coming soon! The macintosh.

Type Manager

[FooGoo]

This is article is idiotic and totally misses the reason why these types of applications are a success. It's not about the type of data being managed it's about ease of which you can share that data with other people who have the same interests. It's about building a community of simiar interests.Microsoft Word is the "type manager" of doc files but I don't know that many people who sit around trading doc files and discussing the differences between how Word 6 rendered text versus Word 95.

The author should dig a little deeper...it's not about the data stupid.

Re:Type Manager

[kurtmckee]

Microsoft Word is the "type manager" of doc files

No, Word is the "editor" of doc files, you see the difference? Windows Explorer is the current "type manager" of .doc files.

It's not about the type of data being managed it's about ease of which you can share that data with other people

Good job, you saw the word "iTunes" and thought he was talking about music. In the article, the author concludes with further examples of what he's talking about, such as Valve's Steam (game manager), many MAME frontends (ROM manager), as well as others.

Yes, people love to share, but that's not the same thing as managing. I want to have all of my music categorized and tagged. I want all of my photos organized with captions and tags. I want all of my email properly filed and readily accessible. There is no way a file manager can properly manage all of those different file types (not even you, Emacs). Thus, the author seems to be suggesting that specialized file managers, each appropriate to the types of data it's designed for, are a better management interface than a simple file manager with applications to edit individual files.

As for your statements about sharing, I would argue that sharing is an example of exporting. Exporting, meanwhile, is something that happens in a management interface. I can export my songs to an audio, MP3, or data CD; my photos can be exported to CD, to Gallery, to Flickr, etc. I wouldn't want my file manager to handle all of those possible export options; it would be a mess (I'm looking at you, Konqueror).

It is about the data, stupid.

Your standard file manager *IS* a "Type Manager"

[MasterC]

The author's "Type Manager" is nothing more than a manager utilizing more metadata than normally.

Your classic file manager *IS* a type manager because the file name is a metadatum and the parent directory is a metadatum: neither are direct data (such as what I'm typing now). So organizing, say, a code base on a directory hierarchy that may include module names or library names or file types (docs go here, man files there, source files over there, etc.) *IS* feeding metadata to your filesystem to organize your files.

The "Type Manager" has existed from Day 1 when files were given names. (Punch cards are before my time but I suspect the punch cards that represented a program were stored together and each program was stored separately. At this point, *you* are the metadata organizer.) Since then, it has only progressed from a flat file system (the likes of Apple IIc) to a one-level deep filesystem to a multi-level filesystem (no linking) to a multi-level graph filesystem (includes linking). Now apps are taking it to the next step by merely using more metadata. That's it, nothing new.

In the end, the bits that represent your actual data is a long string of bits (losely stated) and your filesystem is just a type manager organizing your bits by file names and parent directories. bash, Windows Explorer, Finder, etc. are all just wrapping your metadata organizer (your fs) and some (previously and now) are using file-specific metadata for further organization.

Big whoop.

From the article:
Type Manager applications are not new, in fact you probably have been using one since you got an internet connection.

It appears the author doesn't even fully understand the concept of metadata (*ahem* "Type") and it's usage has long existed before your email client and long before your internet.

Seriously, nothing to see here! In fact, I want my time back for reading it...

Re:Excellent choices of hackneyed responses.

[electroniceric]

Couldn't agree more. I thought this was a thoughtful, well-organized essay, and definitely merits a discussion on Slashdot (which discussion, of course, is shaping up to be neither thoughtful nor well-organized). I also think a base "Data Type Manager" is an interesting idea that merits some thought and experimentation, and to the extent that this treatise and discussion encourage that, it's a great thing.

One of the subtle ideas this (Activity) Type Manager approach brings up is the difference between task-based and activity-based software. Back when I was on the KDE usability list, we did a lot of talking (and a lot less acting) on the subject of task-based start menus, control panels, and applications, in an attempt to get away from content-based ones. You very quickly run into the problem that there are a lot of tasks, and some of them are used in a variety of ways. But an activity ("deal with music using your computer") is big enough and happily amorphous enough that it just might bridge that gap. Another nice idea about the Activity Type Manager is that it can take on the job of figuring what metadata is important for that activity (and associated tasks) and deal with capturing and organizing that metadata.

There are some big drawbacks to this approach, namely that it requires grouping things into categories again ("activities"), and that produces a whole new set of cross-activity aspects that people have to work with, which vastly increases the complexity of the software.

Nonetheless, it's an interesting idea and worthy of discussion.