| |
  |
| Liquid File System Breaks Down Hierarchical Barriers |
|
 |
|
posted by Editor on Friday October 12, @08:57AM
|
|
|
|
|
One problem with the hierarchical file system that is inherent in most current operating system designs is that the organization of files is modeled after physical metaphors. In virtual space, though, characterization by physical location becomes inefficient, since place is only a matter of presentation. Although some mechanisms exist that let information be in multiple "places" at the same time (i.e. symbolic links, aliases, and shortcuts), these can become lost or broken easily, and are hard to keep track of, so that they becoming quickly separated from the files they reference. The Liquid File System overcomes this limitation by applying categories to documents, files, and database records and indices, instead of limiting them to a physical location inside a directory. In effect, the LFS "takes the files out of the category, and puts the category within the file". Files can then be displayed in any combination by category, showing their relationship to each other, and the parameters of that display can be transformed by the user at any time. The LFS remains in the idea phase, but here is a concept screenshot demonstrating how categories might be applied to a file.
|
|
|
|
< Open Source Stroke Translation Library | World Building 101 > | |
|
|
|
Don't have an account yet? Go Create One. A user account will let you customize the site's content according to your preferences. It will also allow you to moderate the comments of other users.
|
|
|
|
|
|
This discussion has been archived.
No new comments can be posted.
|
|
|
| |
|
|
|
|
by Anonymous Coward on Friday October 12, @11:32AM EST (#2)
|
|
|
|
|
I've been working on this basic design for a long time -- except that I coincidentally called my system a 'fluid file system'. Interesting. I also emphasised making its user interface able to work like a traditional FS's interface (with folders appearing to contain files and so on).
-Billy
|
|
|
|
|
|
|
|
|
|
|
|
|
...it's in definition.
There have been many experimental implementations of systems similar to this. The problem always becomes: how do you assign the keywords.
It's hard enough for people to categorize mail messages into a single hierarchy and then find them later.
Requiring that people come up with an independant category schema that is going to match other people's schema is very difficult,if not down right impossible.
(It's easy to find a drinking glass in your kitchen, but practically impossible in someone elses.)
Jared
Jared M. Spool
Founding Principal
User Interface Engineering
jspool@uie.com http://www.uie.com
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
It will take a little effort from both people and applications. For example, most people start an e-mail from an e-mail program, then type in the subject, body, etc. Nobody wants to categorize it so the recipient can sort it. What if each 'workspace' or 'virtual screen' was also a category and each document created was stamped. So, if I was working on a project called 'Project X' and initiated an e-mail to a contact, it would be tagged with 'Project X'. Now the recipient not only has the sender and subject, but the category. The e-mail application could sort this automatically, maybe tell the system which folder this really goes to, then each one with that category gets routed without any help from you. It should also store a link in the contacts folder, and the new messages folder. Of course these aren't really links as the categories are tied to the file.
So the hot topic I believe is the scope of a document, it should know where it goes when you create the document. I think workspaces should replace the 'floating window' metaphor. It is much easier to work with a task per workspace, and have all the applications and documents related on one workspace. For example, maybe I'm making a proposal for a new VPN solution. I have contacts, web sites, phone numbers, notes, e-mail, presentations, etc. I would like to encapsulate this into one workspace. But as we know, virtual items are not limited to one space. For example, one workspace could work on one section of a document, while another could be working on a different section of the same document. I have a simple example of 'tablets & workspaces' at:
new-workspace.jpg
Some other small examples:
popup-applet.html
Mike's Programming Center v0.7
Berlin windowing system
I never found it very useful to use 'Create a New...' in windows, because you have to navigate to the folder first, and then you had to launch it after you named it! With workspaces, you could simply change to the workspace and select 'New Contact', 'New Message' or 'New Note'. I find it more task based and easier to manage. I am very interested in UIs, if you have a comments, post 'em.
Mike
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the end, it is all about Analogies. I don't think that we will ever rid ourselves of the Hierarchy Analogy. In the book Otherness, David Brin has a number of insightful essays. One of them found here on the web, lists Brin's ideas of the Five Major Memetotypes waging war in our minds. One of these is Fuedalism, which was based heavily on hierarchy. Perhaps this is the reason Hierarchy is here to stay. Or perhaps, as I use myself, a Tree is a very provocative metaphor for most of our programming concepts.
Understanding the underlying analogy is a good means to bettering the underlying analogy. I don't think that things should be quickly scratched, because there are plenty of reasons why Hierarchical systems have flourished and others floundered.
The real trick to using such things becomes in combining the two. Using the underlying mental accessibility of the Hierarchical analogy, we can then use keywords to bind it and make it work better. My Dad uses the Find function in Windows more than most, and advocates the use of indentifying keywords in names (such as, on shared computers, Author Initials). This kind of keyword searching allows us to take a complex Hierarchical system (such as the Internet) and make it more accessible. Search engines are just as useful as knowing the URL, and serve very different purpouses. Why shouldn't we use both?
Now, as for the idea of workspaces, I have been thinking about similar lines for sometime now. Just as I sort things onto different shelfs, allowing some form of "human"-logical organization is almost a necessity. Especially in Persistent-State (which OS/2 almost had, and Windows tries to have) Operating Systems. Squeak has what it calls "Projects". This, again, doesn't mean the death of the Hierarchy... OO almost demands it. (On a seperate topic, I think OO programming becomes even more interesting when placed in a directory-style analogy ("/engine/console/->dump();").)
--WorldMaker--
|
|
|
|
|
|
|
|
|
|
|
|
|
Hierarchies with multiple parents does a great job of cataloging. Combined with meta-data and time-based attributes, you should find what you are looking for.
I just installed Squeak, I like it. I've played with Dolphin-Smalltalk, but Squeak is more free-object based and fun. The 'Projects' in Squeak are exactly what I had in mind. It could be organized a little better, maybe with a side toolbar. If I send an e-mail from a project, it should be tagged with that project's name as a category. Now when the recipient receives the message, it can automatically be filed when read. It's too bad Squeak looks so kiddie, it would be hard to use for professional apps. The pastel colors, the inconsistencies, the speed, etc. I've been working on a simple 3D engine in OpenGL which would include a UI, and also toying with a new language similar to python. Hmmm.
Mike
|
|
|
|
|
|
|
|
|
|
|
|
|
Hierarchies with multiple parents does a great job of cataloging.
Yay! Someone else has discovered the power of the polyhierarchy.
A (mono)hierarchy is a structure in the form of a tree: the root node has no parents, all other nodes have exactly one, and there are no cycles, i.e. a node cannot be its own ancestor. A polyhierarchy, by contrast, is a structure in the more general form of a directed acyclic graph: cycles are still forbidden, but nodes can have any number of parents (though often there's the additional constraint of a single 'root' node that has no parents).
The thing is, in most user situations where monohierarchies are used, a polyhierarchy would be more appropriate. This is partly because the subset relation forms a polyhierarchy, and our mental categorising forms sets of things, more or less.
The alternative is the heterarchy, in which connections anywhere are allowed and cycles are not forbidden. This may be 'directed' (one-way links) or 'non-directed' (all links work both ways). This follows the 'association' model of mental organisation.
Which is better? I prefer the polyhierarchy for organising 'my' data on my computer, though like pretty much everyone else I actually have to deal with a monohierarchy fixed up with aliases ('soft links' to you Unix people). It's just easier to find things if I know they're organised by various mental categories. But the real innovation, if this is what LFS does, is to have the precise place in the polyhierarchy made a function of various properties of the 'object', or equally, to have the UI deal with 'objects' that include enough metadata to file them automatically. Want to move something? Adjust its metadata. A really clever UI might automatically adjust metadata attributes in response to dragging operations.
|
|
|
|
|
|
