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."
its a file attribute manager. not a type manager. adobe type manager is a type manager.
who the fuck gave this guy a license to make up new technical definitions on the fly ?
...should learn to Type Type Manager Less.
Move along, nothing to see here. This is nothing but shameless self-promotion from a guy who can't even spell "useful" correctly.
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".
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
...and then the KDE-ers complain KDE gets too little traction in the market compared to Gnome. Feh.
(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>
Go somewhere random
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
I think a better name would be MIME Manager
.. but I really dislike all the "managers", picasa, nero, hell, I _stopped_ using ACDSee when it became to cluttered (in favor of irfanview ofcourse).
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.
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.
...another name for a keyboard designer.
Adobe Type Manager 3.0 Easter Egg:
Open Help/About, double right-click on it and will see the designer's photograph. FUN!!!
He who knows best knows how little he knows. - Thomas Jefferson
From the website :
Check out KimDaBa Demonstration Videos for details
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.
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;
Maybe I'm the only one who sees some irony in people using the Comic Book Guy style of response to mock and belittle an interesting work. The small minds living in Mom's basement can only denigrate a reasonably well organized treatise on an interesting subject. Commenters have pointed out that "there's nothing new here", "this guy chose a bad name", "this is only novel to someone who hasn't thought of this before."
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.
Not A Sig
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.
When it manages basic spelling and grammar, count me in.
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.
Maybe it's because I'm just weird, but many of my files have implied metadata based on how I organise the filesystem they're in.
:(
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...
Game dev and music blog
Just kidding.
I agree....instead of criticizing the guy, maybe people could add some insight on to how to quickly and easily manage their own files besides using iTunes?
C:/DOS/RUN
http://www.actionfig.com/simpsons/cbg_dos.jpg
He who knows best knows how little he knows. - Thomas Jefferson
Hi all,
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.
The only difference between a file path and, say, keywords is that the former is thinking in terms of the computer (sort of like C), whereas the latter is thinking in terms of the data (sort of like Java).
That's wrong. Paths are not just metadata, they have specific semantics associated with them that, say, tags don't. Furthermore, paths have semantics that users grasp easily and that they rely on.
Now, people have been attempting tag-based, non-hierarchical, database-based and other file management and navigation strategies since the 1960's. UNIX itself used to be graph-based, not path-based. All such attempts have been failures. Paths seem to combine power, usability, and correct semantics in a way that no other system has managed to do to date. There are specific applications (like MP3 jukeboxes) where other approaches are better, but for organizing all the stuff on a computer as a whole, sooner or later, you end up with paths and path semantics again.
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...
If you think imaginary property and real property are the same, when does your house become public domain?
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
There's no confusion... there's just resentment at such a blatant attempt to shove a meaningless buzzword down our throats.
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.
ClutterMe.com - easiest site creation on the Net. Just click and type.
OS/2's folders were highly configurable and extendable far beyond anything you see in Windows or even the Mac OS X 10.4 finder.
One extreme example of exactly what this article is talking about was RexxMail. From what I understand, instead of having a mail program with a dedicated custom interface, the developers of RexxMail simply extended the standard folder to list files of type email so that you can see the To: From: Subject and so-on in the view. When double clicking the file, it would open it in an appropriate editor and provide different options. This way you could use all the power of the Operating System's file system and folders to manage your email without having to learn some completely different interface that insisted that your email go in some specific place. Very cool.
Signatures are a waste of bandwi (buffering...)
- Location has been used for decades (flat filesystems are not that common today)
- Content type is used to associate actions but BeOS live queries shows the way to spread its use. Nautilus specific views is another form
- Properties is the ability to query based on some properties included in the data (Exif, MP3 tags,
...) Already available but only for certain data. There is not yet a general way to deal with properties.
- Tags have prove themselves usefull for links (del.icio.us) but could be used for any file
- Computed values are special values that are maintained from the data (thumbnails,
...). They are similar to properties but are computed instead
- Full indexing (Google desktop, Beagle,
...). Also include the transformation of data to text (Google images)
- Recommandations is the way to ask other people their opinion about a specific chunk of data
There is no single way. All of them seem interesting and I try to implement them in JDistro. However, support from the filestystems (inotify and al.) or from the databases (triggers) are required to make them viable. In summary: I don't think Type Managers are the future, Data Managers are.Million Dollar Screenshot
My personal assistant manages all my typing thanks.
useless sig advice - Read Nabokov.