IDEA: Visual FileSystem

[Perry Mowbray]

After looking at http://labs.live.com/photosynth/ the other day and thinking about the various applications that are springing up around GoogleMaps, I started thinking of different ways to visualise the filesystem.

http://www.visualthesaurus.com/ does a neat job in doing that with words, but I wondered about visualising the filesystem based on different groupings than files and directories.

First Thought
Start menu could be graphically rendered to show the programmes... linking from the programmes could be the files that that programme reads/writes... hovering on the files could produce links like the windows context menu links (send to, etc).

WHY? FARR does a great job when you know something about the name of the file, Recent Documents does a good job for recent docs, the filesystem does not a bad job depending on how you file your stuff... I thought something like this could produce a web of relations (and maybe what relations that are used could be changed, so that maybe author, dates, etc could be used.

So I'm thinking it's like a dynamic search (based on file properties) in a graphical interface.

Another Thought
Then I wondered if something similar could be done with web pages, which would be like a dynamic link index I guess?

I guess I didn't know if it was just rehashing existing functionality (search, weblinks, etc) in a graphical format or it could be really useful? Sometimes expressing something in a visual framework can be quite intuitive.

Thoughts?

- Perry

[Perry Mowbray]

Following VisualThesaurus through I found http://www.thinkmap.com/ which is the engine that drives it: amazing (and cheap at $5K)!

[jgpaiva]

I see what you mean. Visual filesystems already exist. Not much time ago, i saw a 3d filesystem in which you navigated and used in a similar way to a video game.
I played with it for a while, and my current opinion about it is: DON'T GO 3D!!
It's awful. Slow, hard to use, confusing, etc, etc.

Improving in that kind of well-stabilished ideas isn't that easy, i think.

[Rover]

Coming up with a 3D file viewer would be fairly trivial in some respects.

The big problem to me is coming up with a 3D metaphor.  What object/icon would you use to represent a file?  Would a Word Doc be different from a PDF or a DLL?

The next challenge is how do you contain those 3D objects?  We still need to establish some hierarchy or tree to organise the stuff.

Did you have something in mind?

[Perry Mowbray]

Thanks for reminding me about those 3D Desktops (I'd forgotten, but it does explain why the idea seemed familiar): I played with them about a year ago I think. At the time I thought they may have been nifty, but not a lot of use (they seemed to be appearing in films a lot at the time).

I don't think I was actually thinking of 3D like render, but just the creation of a model that displayed links and groups that increased functionality and user experience.

Obviously the more dynamic the link creation is the better. It's just another view of what's already there on the harddrive, I was wondering if it would be a more functional view?

I think the answer is in how the links are created and how they can be used to adjust the display and any possible actions.

Say for example a view was created by the search term 'Work', I guess some of what could be displayed is files/folders that have work in their meta data somewhere, and they could be displayed in a net of files in their directory structure (I'm visualising the http://www.visualthesaurus.com/ example here). Clicking on different nodes creates a different view.

If 'Work' could be defined by subgroups of some sort (apart from the filesystem) by the meta data, maybe 'Work at home', 'Issues at work', etc then those subgroups become the nodes that redefine the search. Once in the subgroup, those files could be "selected" no matter where they are on the filesystem and acted upon in some way.

You're right Rover: the hierarchy and how to generate it, is the crux here.

- Perry

[NeilS]

This is something I've been looking at on and off over the years. In fact, I actually wrote one a long time ago which used a "2D disk" metaphor to represent a directory hierarchy. Imagine a segmented ring, where each segment is a file/folder in the root directory. The next level down in the hierarchy is represented by the next ring outwards, where the contents of each folder are contained within the same angular section of the ring as their parents. The result looked a bit like a fractal. It's hard to describe without a picture, but hopefully you get the idea. I can't remember what the folder traversal metaphor was, but I think it probably involved rotating the disk and moving up and down the folder levels by moving in and out along the radius of the disk.

Although it was a while ago now, I seem to remember it actually working quite well. One of the big advantages was that you could see several levels of the hierarchy and adjacent folders all at the same time, and it also gave you a reasonable sense of some kind of spatial structure to the contents of your hard disk. It also supported stuff like distributing the amount of angle (= size) given to a segment based on the size of the files/folders, or how many items they contained, etc.

Downsides were that the geometry of the disk tended to waste space as you went down the hierarchy (again, hard to describe - I wish I had a picture of it), and you could only really visualise the folder hierarchy as found on your disk (which is a fundamental problem with any hierarchical metaphor).

I also looked at a recursive "boxes within boxes" metaphor at the time, again with the ability to see inside boxes while also looking outside them (basically flattening a hierarchy into a big, zoomable space). It wasted a lot less space than the disk metaphor and probably had even better spatial awareness properties, but I think it lost out to the disk at the time because the disk's traversal metaphor seemed nicer. Plus the disk looked way cooler.

Anyway, neither method would really support the kind of arbitrary linking being mentioned in this thread (e.g. link all MP3s together), or rather, not as I've described them so far. I did have a few ideas about that though, but I've bored you enough for the moment.

Oh, and I agree that 3D visualisers don't really work (yet). The main problem is the input metaphor, although the display metaphor doesn't really seem to have been solved yet either.

[Perry Mowbray]

The disk does sound amazing!

I agree that one of the real benefits of something like this is being able to "see" a lot further, and depending on what basis the rendering is constructed, get a lot more functionality.

When I was showing my manager the ThinkMap was obvious that that type of system offers a great deal more than standard searching models because you see some of the structure.

I've also installed at various times applications that map your drives and give you a visual display based on filetype. Not bad, very pretty though; seemed to be based around size: somewhat similar to your disk idea.

I like the boxes within boxes thought, especially if the box that is a file contains stuff as well! which is does: size, date stamp, etc. That would enable "grouping" by what the "box" contains. Picasa does that with its Timeline view.

- Perry

[JavaJones]

A few thoughts occur.

First, what is the expected value from this? I think the biggest thing noted so far is improved context for navigation and searches. That seems fairly worthwhile to me so it would be useful to look at practical existing examples of this to see how useful it is in practice. Some of that has been discussed above but more deliberate practical experimentation is in order.

Second, this sort of thing is precisely why I want a database-driven file system so badly. Such a thing would make this fairly trivial - merely a visualization of database info, like outputting a bar graph or pie chart, just a different visualization.

Third, along those lines it seems what we need is a hard drive cataloging application like Locate, Google Desktop, X1, etc. but open source and consisting mostly of the underlying searching, cataloging and database storage functions, upon which other developers can then build plugins for data interpretation and searching. With this sort of underlying system you could rapidly prototype these kinds of advanced file navigation schemes without reinventing the wheel. All of the search and visualization methods could use the same underlying database and info. Search by keyword, browse with a ring visual metaphor or a tree, group by file type or size or creation date, sort by whether it has a thumbnail or not, or whether there is an associated application, etc, etc. It could all be built easily and quickly with a robust data cataloging system. So where's the open source HD search tool?

Oh yes, and 3D navigation systems: the missing question seems to be *why*. People are working on this stuff but I really have seen *no* compelling examples of it being *more* functional than the current systems. Simply going 3D "because you have a whole new dimension to work with" is not reason enough.

- Oshyan

[Rover]

JJ - I think one answer to why is that some people cannot relate to the virtualness of the filesystem.
Most folks don't really know how to file things in the physical world, so the metaphor breaks down a lot for some.

The tree view helps a little, but there still isn't a good visual for storing data.  To me, that's more the issue than need for a 3D fs viewer.

I agree with you on the whole DB FS.  Let's write one this afternoon.

[JavaJones]

Agreed Rover, it's the storage/organization metaphor that is lacking, not necessarily the 2D/3D paradigm. The question is what works consistently in the real world, if anything, and is it applicable to a computer interface? If so the familiarity would probably make it a very popular system. What you want to avoid is duplicating a bad system, like the demo of a "virtual desk" with sophisticated stacking functionality that was shown here a while back. Some of the features looked cool, but I really wasn't convinced by the whole organizational metaphor of "order within chaos" on your desk.

- Oshyan

[Perry Mowbray]

Actually Oshyan, I think the "real world" examples is what is breaking down in our digital environment. What did we use to catalogue before computers? Card Files and cross references?? Isn't that where GMail has freed people from having to put emails into folders??

I think that the underlying data is the very crux here. What we need is a database that holds the definitions and links between the filesystem objects. how that is used is upto the developers.

Document management systems vary a llittle, but generally what they are doing is adding keywords, tags, labels and indexes to files, and give a way to find things again (hopefully).

I guess what I was originally getting at is that on my computer the method of categorising my files is limited (by the file structure I guess) and I thought that a slightly more fuzzy way of getting at the files (including grouping and actions) would be helpful.

You know I have graphic files in my Photos folder, in my graphics folder, in my HTML folder, etc. Picasa (and others I guess) give me a nifty timeline, but there is a whole lot of other data there in those photos and jpgs that could be used. Other file formats also support information about the file, as does the filesystem. Being able to group or display by author, subject or any of the other metadata would be helpful... wouldn't it??

- Perry

[JavaJones]

Absolutely. That's what I was getting at with the "database driven file system" - essentially universal, comprehensive meta data that is accessible in *every* file and maintained at the OS/file system level. Any program could read or write it, the file manager could do the same, and thus you could sort on any tag, field, or other piece of info in the meta data. You could search on it too, or use it in a more specialized app to organize. Mass tagging, etc. would be possible as well. Bottom line is I agree that more "fuzzy" methods are necessary and I think the only real way to do that *properly* is with a database-driven file system. The current approach is basically to bring *some* of this functionality to *some* file types, and usually only relevant and viewable when accessed through specific applications. Think of how many programs use the Windows GUI libraries, or DirectX. Now imagine if there was a similar set of hooks and data exchange components and whatnot that dealt with universal meta-data. It would be trivial for any application to support and deal with and be enhanced by such data. It's up to Microsoft to take the lead on this unfortunately and all indications are they dropped the ball with WinFS.

- Oshyan

[Perry Mowbray]

It's up to Microsoft to take the lead on this unfortunately and all indications are they dropped the ball with WinFS.

I think this is where there is a real opportunity! All that we have to do is a proof of concept and get a significant ground swell for the idea and MS will buy the idea and incorporate it into the OS 

Borrowing from another thread (bloat)... is it possible to implement the DB part of the file system outside of the filesystem with push and pull functionality. I'm assuming that the best functionality is when it is part of the FS because the data collection is controlled by the FS, but it could be collected by pulling the data (which is how cataloguers do it now I guess)?? So that would mean functionality could be provided for programmes to hook into so that they could push their data into the database, but because initially (and because not all programmes would add that functionality anyway) the same methods could be used to pull data into the database??

What's the best storage format? XML?

- Perry

[JavaJones]

Yes, that's correct, it could be implemented in for example one of the current hard drive indexing tools (Locate, Google Desktop, etc.). It's really a matter of determining the best approach to this, considering all the existing meta data solutions (id3 tags, IPTC, EXIF, etc.), and then implementing it. The trade-offs between a centralized database accessed by all apps and separate files or actual embedded data need to be weighed. I would tend to favor a database approach with some export functionality. That way you don't need to always keep pairs of files together (file and meta data) and you don't need to get everyone to change the underlying format to include the meta data format, you just need to get people to support your DB. That's still a hard problem but if you make it indespensible and universal it will be supported. I think the way to do that is first to make it totally free, if not open source, then to have capability to import and index all existing meta data and translate back and forth between the (more expansive) DB-based meta data and whatever embedded meta data a given file/format might allow (mp3 with id3, etc.). This way people can leverage their existing tagging and meta data. You would also want to have importers, if not full exchange systems, for all the popular apps out there like Picasa, iPhoto, etc. Basically if you make it virtually effortless for people to incorporate it into their existing systems and at the same time offer significantly more functionality then it will have a high adoption rate.

I think you would need the following to really make it work and make people love it:
Excellent import/export support
A good plugin/hook system so that other apps can work with it, both reading and writing meta data and other info
A really fast, easy way to edit any meta data, transfer meta data around seamlessly, mass edit, etc.
A built-in "explorer" replacement that incorporated all the meta data, search functions, etc. - better yet an actual explorer replacement/addon that allowed this seamlessly in a familiar UI
A really fast database engine and low resource use

I think it's quite possible to do this with an application working above the file system, using its own DB. I'm frankly surprised no one has done it yet. But I imagine there's a lot of overhead, which is why the file system approach may be needed. For now a proof of concept based around an existing open source HD indexing system would do just fine.

I only wish I was a decent programmer...

- Oshyan

[Perry Mowbray]

I only wish I was a decent programmer...

Ditto, so who's putting up their hand???

Interesting site:
http://www.seekafile.org/

- Perry

[JavaJones]

Interesting indeed! But .NET. Not ideal IMO. But maybe worth something...

I have money on this if there are any takers. Seriously.

- Oshyan

[Perry Mowbray]

Interesting indeed! But .NET. Not ideal IMO. But maybe worth something...

It's a start? Also, SeekAFile doesn't grab all the metadata that I'd like to get

I have money on this if there are any takers. Seriously.

I only dabble, but I'd love to contribute in some way too.

- Perry

[Perry Mowbray]

Interesting indeed! But .NET. Not ideal IMO. But maybe worth something...

It's amazing what you find when you start looking (and a bit embarrassing how old some of this stuff is)...

Without realising it what I think I was meaning was Topic Maps. For those who don't know, Topic Maps are an XML standard. There are quite some well matured Java tools for creating and manipulating Topic Maps but not many on Windows (at least that I've found). Of interest:

• TM4J is an open source topic map engine project in Java.
• The Omnigator is a free topic map browser that can display any topic map. There's also an online demo.

I also found quite a few posts about Windows FileSystem and Topic Maps and how they'd missed the boat (for example this post) which echo's Oshyan's statement:

It's up to Microsoft to take the lead on this unfortunately and all indications are they dropped the ball with WinFS.

So, to my surprise, there has been a lot of thinking across most of the platforms about this topic already and quite a few implementations; unfortunately not a lot on Windows (is that an opportunity or what??).

But I guess the good news is that if an XTM format was to be used there are already lots of source code out there demonstrating the use of that data in various ways (not necessarily Topic Maps either I guess?) and tools around to help.

- Perry

[JavaJones]

Good info you've dug up there! I'm really not surprised to see a lot has been discussed and some even done in these areas. Frankly I'm surprised (and a bit dismayed) that *more* hasn't been done, on the Windows side especially. I'm also a bit surprised that this thread doesn't have more interest, but maybe it's a topic name thing. It seems like a lot more people would be interested in "next generation file browsing"! Maybe change the name to that.

Edit: These "topic maps" seem interesting, to be sure. But I wonder, how do you create them without tremendous amounts of work? Is it suggested that this would somehow be automated in a file system?

- Oshyan

[Perry Mowbray]

These "topic maps" seem interesting, to be sure. But I wonder, how do you create them without tremendous amounts of work? Is it suggested that this would somehow be automated in a file system?

They are, or at least they can be. There is already quite a bit of metadata floating around your computer, it just needs to be pulled into the Topic Map. In some ways there is more opportunity to add metadata than there is data added. For Example: do you add data to all the fields that MSWord allows? Or even what Windows allows? Do you fill out your MP3 tags and all your EXIF and IPTC fields?

I'd think that the software should assume that if the fields are not filled out then the user doesn't want to know.

But there is a lot of fuzzy stuff that can be gained by keeping a look at what's going on:

• who wrote what when
• what filetype was used
• what programmes read/write those filetypes
• how many times has a file been read or written
• etc.

If methods were exposed so that software could update their own records then that is an option as well. But that has been noted elsewhere (I think about MS, IFilters and indexing) that that is not the best option.

TinyTim has an example of creating a Topic Map from filesystem information: which would give the base structure component.

Once some sort of structure is in place some sort of Edit functionality could be provided to allow editing of the Topic Map, say by drag and dropping files onto descriptors, etc.

Here is some more interesting bits:

• Topic Map Solutions for Kodak Digital Camera Accessories
• Building a Topic Map Repository
• TMview

I think I'm at the point that I've got to install something and start playing 

- Perry

[JavaJones]

Please do so and report back! I'm not at a place where I can really delve too deeply into this but it does sound very promising.

As far as the lack of use of existing meta data fields, yes that's true, but I think that's partly because the interfaces to putting in such data are not really easy to deal with, not at all automated, and seldom work on a mass scale. Even if one application implements a great interface for editing meta data, it probably only applies to the media type that app deals with, and often the data won't even persist to other applications. That's why universal meta data of *some* kind is very important IMO.

Does anyone have any suggestions, just for example, on the best photo organizer that uses tags well? A simple example of what I'd want: Put in my digital camera card with a few days worth of captures on it. It auto-starts (or asks me if I want to take pictures off) and first copies all the photos to a temp location (so it can work on them faster), then examines dates, looks for periods of inactivity (explained in a moment), and looks at other meta data like general exposure range, ISO, and shutter speed. From this data it makes some educated guesses about the number of locations involved (significant gaps in picture taking, especially combined with notably different exposure or shutter speed ranges), the number of "sessions", and other possible desirable categorization. It then auto-suggests some tagging, either generally or specifically, and gives you the groups it has made guesses about (groups by location guess) which you can easily refine for accuracy. Then you can quickly name the groups, and the photos are automatically tagged as a result. They could also optionally be tagged with me as an author and any personal data I wanted based on a profile in the photo program. There are lots of these kinds of functions I can imagine. The real key is that it's somewhat intelligent and it tries to help you do effective and quick tagging (optionally of course). So, any intelligent apps out there?

This is an example of the kind of thing I would want to have based on (and plugging in to) an underlying meta data and database file system. It wouldn't be particularly more difficult to do without this underlying framework, but *data interchange* would definitely be more of a challenge. Especially where the file type does not have an existing meta data standard defined. Perhaps that is quickly becoming a thing of the past though what with EXIF, IPTC, ID3, etc...

- Oshyan