|
|
|
|
|
|
|
|
|
|
|
12 Sep 2005
[First published 11/02/1003]
Dan Hon has written a very interesting article about the limitations of the filing cabinet metaphor of computer filesystems, and the about the finality of saving a document.
He touched on a number of things that bug me on a regular basis. I speak – as usual – from a MacOSX viewpoint here.
Representing files in ways that give cues to their content. Icons should tell you what kind of file it is, not what application last opened it (or what the default handler is). PDF files might have an Adobe icon or a Preview one. Of course, I can set one or the other to be the default for *.pdf files, but that sets what application will deal with the file. I want to choose what I open it with, but some standard, application-independent icon would make the files visually more distinctive. Dan mentioned having an icon change to reflect how many pages were in the document, how old it was, and so on. I think this is a great idea: Tinderbox already does this with its notes. Notes containing a little text have an icon with one line, those with a lot of text have an icon with many lines. New notes are subtly darker shaded, then fade gradually lighter over time (see screenshot). Something like this extended to the whole filesystem would be great.
The problems of finding files. This is a tough one. I have a reasonably tidy filing system – compared to those who spray their desktop with files willy-nilly – but I still spend time trying to find stuff I’ve stored. Very often, files need to appear in two folders to fit in with the categorization. Sure, I could use aliases, but that’s rather a clunky way to do it. Creo have a nice application called Six Degrees, which deals with email, contacts and attachments. They make the point that recognition works much better than recall: find files which match whatever you do remember about the one you’re looking for (the recipient, part of the name, the rough date) and you’ll most likely recognize it immediately. As Dan points out, this kind of metadata is very useful in searching, but harder to implement with less structured data.
Rolling Undos. Now we’re talking… We’ve all been there: you edit, save, then think “Doh! I wanted that previous version, but now I’ve saved, and it’s gone". A “timeline†which you could scrub through to view previous versions of the document sounds like a fantastic idea. As someone who also writes a lot collaboratively, a facility like this could also allow merging of edits made by other people (otherwise known as reverting to your own version when a colleague makes a pig’s ear of it). Some way to highlight changes (like Word’s Track Changes, but better) would be important, and might also be useful even when you’re looking at your own edits. I’d love to be able to abandon the whole ‘what to name the file’ problem. ‘Paper v4′, ‘Paper v5′ and so forth gets clumsy very quickly, and how do I remember what I added in each one? I also always get bitten by the ‘Paper final’ filename. Never, ever name a file final anything – kiss of death. Oh, and one more thing (I’ve watched one too many Jobs keynotes) – all of this should work with any application in which you edit text.
2
On the part of rolling undos: apparently you are looking for a CVS, a concurrent versions system, which is quite common among people doing collaborative programming. The problem here is the integration with non-plain-text files and non-*nix OS. For Windows a good manual can be found here: http://weblog.cemper.com/a/200307/28-cvs-version-control-on-windows-in-10-minutes.php
3
Gideon: Yes, that's an interesting idea. The Unix compatibility problem (including the whole issue of specifying a path) would be a problem though, as you mentioned. Sometimes I find tags wildly useful, and at other times I find them unhelpful. I haven't quite worked out why under which circumstances each occurs, but there's definitely an issue with evolving the right kind of tag s; if they are too specific, you can't remember what you might have tagged it as, and if they are too general, there'll be too many items under each tag.
Mr. D.: :-D Oops. That's what comes of doing this kind of stuff at the last minute when you're trying to think about packing.
1
imnho Apple (and others) should dump the hierarchical filesystems and use a kind of "tags with namespaces" instead.
Lets say that a file can have many tags. Let's also assume that tags are an ordered list. The first could be taken as the "name" of the file, the seconde one as the "folder" inside Documents, etc. A separate mime-type could be used to set the file type.
The "folders" Pictures and Music will then contain all files anywhere with in your namespace which contain a music or picture tag. The layout of these folders may contain other folders which are then subsets of all files.
This requeres some knowledge of set theory and graph theory but it should be do able at cocoa level. The only problem I see is backward compatibility, especially for the bsd-subsystem and XWindowSystem apps. What is the meaning of cd in tag space? What should ls show?----- So, this was first published over a thousand years ago?
Didn't have you pegged for being quite that old...
{;¬)
by Mr.D. @ 13/09/2005 10:09 am • Permalink •