Slashdot Mirror
'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."
I hope I'm not the only one that had to wonder what iTunes and amaroK had to do with Adobe Type Manager and Suitcase.
Adobe Type Manager Light
Next time, check prior art before appropriating a phrase and giving it whatever meaning you feel like.
Not to mention, "Type Manager" is a terrible name for "application that manages files of some type".
A couple of pages of rambling is far from "news". This might be an interesting read for someone who has never thought of content or contextual organization before, but it's really old hat.
Now, if this goober had coded up a new manager which integrated all the functions he talked about, or had an extensble base manager to replace the native file system, with a defined api for plugins that would allow you to customize the environment, that would be news.
Is it just my observation, or are there way too many stupid people in the world?
New must-have! metadata!
Coming soon! The macintosh.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Could he come up with a more generic and confusion-prone buzzword than 'Type Manager'?!
- For the complete works of Shakespeare: cat
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.
People who bite the hand that feeds them usually lick the boot that kicks them
My friend had basically created a Type Manager-like approach. I thought it was crazy because the engineering projects that we did used multiple files of multiple types. On his system the files of any given project were scattered across all these type-based of folders.
My point is that Type Managers can be very useful if a given activity only uses one application or type of file (e.g., rip/mix/burn/listen with music). But when the activity spans multiple types it drives the user back to using a general file manager. In such situations, existing Type Managers fragment the user's access to files and become a hinderance if the project's files are scattered across an email client, a photo manager, a sound file manager, etc.
Two wrongs don't make a right, but three lefts do.
The best (and only) way to deal with a mime is with a gun.
Be a real patriot: Question authority. Think for yourself. Formulate your own conclusions.
They're cromulently embiggened of course.
"In the game of life, someone always has to lose. To me, if life were fair, that someone would always be Oklahoma." -DKR
What's needed is a class library which speeds the creation of Type Managers. It should have a Document base class which applications could extend to contain document info, and a View base class which would abstract the user interface. Both would have base methods for all the common stuff, and you'd extend them with the specifics of what you're trying to do. There'd be Views derived classes based on common widgets, like dialogs and lists.
Additionally, there'd be a way for software components to register as viewers of file types in some global database, so that they could integrate with the default shell and display previews. They should also be able to open the type manager or print, perhaps integrating into shell's context menus.
Yup, welcome to Windows 95 with a bunch of MFC applications, COM components and the registry.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Do you have to use a silencer on the gun?!?
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
who the fuck gave this guy a license to make up new technical definitions on the fly ?
Those responsible have been sacked.
Mynd you, møøse bites Kan be pretty nasti...
This tagline is copyrighted material. Please send $10 for an affordable replacement.
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...
:wq
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.