'Type Manager' The File Manager of Tomorrow? 321
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."
Re:Move Along (Score:3, Insightful)
-Jesse
Note to software developers (Score:2, Insightful)
(especially KDE developers) For the love of God, it's not cute to insert arbitrary uppercase Ks into app names anymore. Yes, it's called KDE. Yes, there's that big K where the start button ought to be. You really love K. We get the idea. Now name your apps sanely instead of making them sound like they were named by 13-year olds trying to be cute.
<grumble>
</grumble>
STOP THE PRESS! (Score:5, Insightful)
Coming soon! The macintosh.
Re:type manager ? WTF ? (Score:3, Insightful)
Re:Type Manager? What? (Score:2, Insightful)
I think a better name would be MIME Manager
I might be old and grumpy (Score:3, Insightful)
Frankly I just dont see the advantage of having one heavyloading utility for each aspect of your work. Explorer does it's work, if I wanted more power on my workstations I'd be slapping Linux on them where I have amazing powers at my tooltip with some help by perl and bash.
And for the shameless plugging of his own article I can only say: tsk tsk.
Type Manager (Score:4, Insightful)
The author should dig a little deeper...it's not about the data stupid.
Re:'Type Manager'? Worst. Buzzword. Ever. (Score:2, Insightful)
Content Interface
Topic Manager
Type Organizer
Theme Manager
There are no good choices, trust me I looked.
-Benjamin Meyer
Excellent choices of hackneyed responses. (Score:3, Insightful)
So what, people? A refinement is a refinement. It's stepwise by nature. This is news because someone's aggregated their perceptions of the world and the ideas they sparked into one place. One of you complained about, "why didn't he publish an actual piece of code with an api for plugins?", and I suggest that maybe someone who reads this, who hadn't thought of all this before, might take this as a launching point and actually write something useful.
Let's enjoy the journey. If we happen to visit a few points along the road more than once, it's no big deal. Seeing the same vista from a different viewpoint can be refreshing.
Re:Assumes Type-based work (Score:2, Insightful)
Music applications use multiple file types: music file types, image file types (album art), playlist file types, and probably more (I don't listen to music on my computer so I'm not up-to-date).
I like organization by project. I use R (www.r-project.org) for statistics, and its package organization lets you keep all relevant file types in a single directory, keeping your data, description and help files, scripts, and analysis histories in predictable places.
I think these examples (and the above posts) together suggest that "Type Manager" is a misnomer. They're really all project managers.
Implied metadata (Score:3, Insightful)
MP3s are in directories of the form Artist - Album, file names are TrackNumber - Title. I've been doing this ever since an early version of iTunes for windows screwed my id3 tags, but since my MP3s are all tagged as a matter of course when I rip them, it means there's a level of redundancy in there. However, should something else wipe the metadata again, I still have the filesystem-level organisation to fall back on. I even have a tool which can strip this information out and refill the id3 tags with it, so it'd take me less time.
I'd be concerned that letting a manager program handle all of this might result in a hodge-podge of files outwith my control, then if something should happen to the organisational data, I'd have a pile of files with little, no or maybe even unintellgible organisation...
Re:Move Along (Score:4, Insightful)
Re:Note to software developers (Score:3, Insightful)
the author thinks outside the geek box, can you? (Score:3, Insightful)
No doubt Slashdot geeks will scoff at this article. Geeks want to discover for themselves the best way to do anything and everything on their computer. They shun having all related functionality served up to them on a silver platter as a coherent piece of software, which geeks been trained to distrust because slimy corporations usually make them (and contain slimy commercial intrerests over user interests).
The author is suggesting "hey geeks, why don't you be the ones to make the pan-functionally coherent software"? Then there will actually be alternatives (from a novice user, non-geek perspective) to, say, Windows Media Player, which does not expose your ripped files to the filesystem at all (a slimy corporate tactic)!
The author is suggesting that all the little tools laying around like "grep" or "awk" (that novice users will never learn) be combined into larger software that is easy to use by novice users. A few nice Open Source programs are pioneering this effort, like K3B, and the author is suggesting, "hey, now do that everywhere, for everything, and Open Source will win the day." Which I agree with.
Yes, it is far more fun to nitpick his choice of the term "Type Manager", but there is a big lesson here for geeks, who often times have a hard time understanding what novice users want. Novice users (ie. the other 98% of computer users who are not geeks) want software that beautifully presents them all the best choices in a coherent application for a given activity. Open Source Geeks have the opportunity to do this and win, by doing it and leaving out the corporate slime that nobody wants.
Re:wrong (Score:2, Insightful)
Re:wrong (Score:4, Insightful)
How is a file path different than "music/albums/Irresistable Bliss" or "C:\My Documents\Soul Coughing\Irresistable Bliss\"? They're both descriptions on how to locate a series of files, one being through information about the disk structure and one through information about the categorization. They're both aliases for a bunch of inodes on the filesystem, which is a bunch of clusters on the disk.
Re:Move Along (Score:4, Insightful)
Much like the example in the article of Nero ripping CDs, burning CDs/DVDs, making ISOs and browsing ISOs, you seem to want to do a lot of stuff that is related to music, but which aren't directly related to one another. Displaying the tablature is related to the music, but is largely unrelated to displaying the lyrics and both of those are largely unrelated to the date when you last played the song live, but it's all information which is directly related to the music itself.
As far as images and text, it sounds like the "type" you need to manage is "project" -- I've found myself in a similar boat, lately. Doing 3D renderings which go along with 2D Photoshopped documents which together go with a text document specifying which part goes where and which figure should be consulted for what part of the specification. All of this could be organized by project, and then I could search through my projects for everything using LEDs or everything that makes use of PIC microcontrollers or everything that required woodworking or all of the projects I did before 2004, or whatever. I've wanted, for a long time, such a "project manager" type of application.
I don't think you understood the scope of what a "type manager" really is. The idea is like a database using the primary format as the key, but the database can store more than just the primary format. In the case of a "music type manager" the key would be a music file itself, but the associated data would be the lyrics, the musical notation, tablature, performance notes, and so on. The same way that a dictionary is indexed on single words but contains many words in the definition; or that an encyclopedia is indexed on ideas or concepts but contains more than just that in the article (ie, a wikipedia article contains images and audio in addition to ideas and concepts).
Just because iTunes doesn't do what you want for your music doesn't mean that a type manager wouldn't satisfy your needs. It sounds like you may need something more akin to a "musical performance manager" or some other "type" but don't discount type managers out-of-hand because iTunes doesn't float your boat and is the primary example of the article.
Re:wrong forever? (Score:2, Insightful)
I think everyone who has filed stuff in a hierarchy has lost a file at least once.
The problem with a hierarchy is that only one "attribute" can be assigned to the file: that is the file path. Any other attributes the file may have are within the file, not the file system, and result in a click on the "find files" button which iteratively reads all files in the selected path looking for matches.
If on the other hand, at file-save- / -creation-time, multiple tags could be associated with it, and this stored in a (relational) database, then finding like-files would be a database search...much quicker.
So the question remains: Will it ever really work? not sure. The key reason it works for MP3s is the existing database of songs + tags, with legions of people updating it with new data ... no such database can exist for custom documents I create, or my organisation creates. These tags must be created either by the person authoring the file, or by me when I receive the file, and this is much more time-consuming than clicking Save-As and dumping it a folder...
Your standard file manager *IS* a "Type Manager" (Score:5, Insightful)
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. (Score:2, Insightful)
Re:Type Manager (Score:5, Insightful)
No, Word is the "editor" of doc files, you see the difference? Windows Explorer is the current "type manager" of
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 [menalto.com], 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.
Re:Calm it down. (Score:3, Insightful)
Sorry. If it's a file manager, call it a file manager. Is the article talking about software that manages types? No? Then why call it a type manager? Just to try to add to the list of buzzwords? Trying to launch a new meme just to stroke one's ego for being able to say "I started that"?
If the author had anything meaningful to say, he should be able to say it without repeating "Type Manager" (capitalized, no less) seven times in the article summary alone.
Re:Excellent choices of hackneyed responses. (Score:5, Insightful)
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.
Re:Assumes Type-based work (Score:3, Insightful)
No this guy who wrote this article is not stupid or talking about old news, he's setting down exactly what everyone knows but placing it all under an 'idea' this is a very powerful brain tool that allows developers to move their projects towards such goals because they can quickly adapt the projects aims to incorporate the ideas without having to do the leg work of converting a music projects functionality into a photo projects functionality.
Once again slashdoters miss the boat on why this article is usefull.