If indeed files are obsolete, as another article tells us, what is the solution? One of the projects I am involved in is building GZigZag, which is an implementation of a new systems paradigm from Ted Nelson. In ZigZag, everything is in cells or in their interconnections.
Files are indeed obsolete. In fact, they are a bad design perpetuated by geeks bearing gifts: people like me and you. If we want to find an answer to the problem of organising data we should not look at ourselves, the geeks, the techies to whom hierarchy and technology are the answers. No, we should turn ourselves to dreamers, idealists - designers who may not be able to understand object constructors but whose designs are conceptually sound and free of distracting technological artefacts. I am fortunate in being able to work under the direction of Ted Nelson, who is such a person. Our team is building an alternative software paradigm from ground up, called ZigZag, which has no files and no directories. It looks very promising, but like all good things, it requires some getting used to.
Ted Nelson's computer religion, or paradigm if you will, rejects metaphors altogether. Ted gives an example: I've never seen a desktop that was vertical, or where you could poke the corner of a piece of paper that was under something, and have it jump to the front. [*, Section "The folly of 'Metaphors'"] Metaphors restrict us to things that previously were - unnecessarily since we could have much more. For example, the WYSIWYG paradigm should actually be WYSIWYGOP - What You See Is What You Get On Paper. One of Ted's points is that computers are not paper and should not be restricted to simulating paper.
ZigZag is Ted Nelson's design for managing data. It's in principle at the level of a file system, or more to the point at the level of a persistent object system. In ZigZag, (almost) all we have is cells and connections between cells. These are the primitives of a ZigZag space. Cells contain unstructured data and can be understood as the rough equivalent of atoms in LISP systems. Connections between cells are directed (the directions are called negative and positive), but you can always go along a connection in both directions.
Cells and connections sound like graphs. ZigZag has one twist which makes it a little different: all connections are along dimensions, and we can have an unlimited number of dimensions in the system. In fact, the initial space in GZigZag (our implementation of ZigZag) contains over a dozen dimensions. Dimensions are used to structure the space: any cell can be connected at most to one cell posward (in the positive direction) or negward (in the negative direction) along a given dimension. Additionally, if a cell A is connected posward along a dimension to a cell B, then cell B is necessarily connected negaward along that same dimension to cell A. Thus, cells form ranks along dimensions.
The ZigZag structure is easy to visualize. The ZigZag system (such as GZigZag) usually shows only a subset of the space at a time: using some algorithm, it positions cells on the screen. Usually, only two or three dimensions are shown at one time. And we can switch the algorithm by pressing a key. The vanishing view (screenshot, 13kB) is a good example of an interesting way of visualizing the stucture. Another screenshot (10kB) shows the same tree structure in two views: the left window (the control window) uses vanishing view, and the right window (the data window) uses a horizontal tree view.
We can build any structure on top of the ZigZag space. For example, the system itself uses the structure to model much of its internal state, including cursors (which are cells which point to other cells using a three-dimensional reference structure) and parameters (such as colours and keybindings). The cells and their connections are persistent: to the user or to the programmer the separation between memory and disk is a nonissue. Thus files and directories are also a nonissue.
GZigZag is already useful: Ted Nelson has used it as a genealogy system by modelling his Norwegian heritage within it. We have demonstrated functionality that allows GZigZag act as a useful database frontend. Tuomas Lukka has used GZigZag to build and draw (some of) his presentations, using a custom view of the structure; see a screenshot (8kB) where both windows show a presentation, with a subslide from the left window in the right window, and another screenshot (10kB) that shows on the left the ZigZag structure that produces that presentation. We have also demoed a personal information management system built inside GZigZag, and an organizational finder (organization chart, employee list, project list all in the same structure). Our tests indicate that GZigZag can even handle large amounts of data.
The current prototype of GZigZag is written in Java and runs okay in Kaffe (modulo one nasty Kaffe bug) and in other Java VMs. We are building a set of programming languages in the ZigZag structure, and when that's done, we hope to be able to bootstrap the system. The finished system should be able to run both standalone on top of bare metal and as an application within another operating system.
References
Shameless plugTed Nelson gives lectures in Jyväskylä, Finland 2000-08-29/31. Talk to me if you're interested in attending.
Admittedly, I didn't look a lot at the background papers you provided links to, but I've look at ZigZag in the past, and one thing that struck me then, and again now when reading your article, is really: What's the reason for the "each cell can link to one cell in the posward and one cell in the negward direction per dimension"? I see how this makes it possible to sort stuff into neat cells and dimensions, but I'm not sure what benefits it offers me as "the guy who just wants to organize his information", over, say, a standard free floating object graph. Could you elaborate?
The easy answer is, "why, we wouldn't have dimensions then". However, I doubt that's what you were looking for.
Having dimensions is essential to having any structure in the space: they allow us to build substructures. In a generic graph you can't define easily how for example lists or hierarchies can be represented. In ZigZag it's easy: a list is a rank along a dimension, and hierarchies are composed by having a cell's children on a rank along one dimension and connecting the rank (ie. the headcell of the rank) to the parent along another dimension.
Since dimensions allow substructuring, they also allow building custom views. The tree view (see the screenshots) is a good example: it renders the hierarchical substructure mentioned above as a nice tree. The presentation view (also in the screenshots) is another, possibly better example.
If you like "standard free floating object graphs", why, you can have them. Just define a substructure inside ZigZag (using dimensions!) that represents such a graph, and write a view algorithm (currently using Java) that displays the substructure as a standard free floating object graphs.
Allowing 'references' from both persisent and non-persistent objects to bits of persistent 'memory' is a far more general solution. I wrote about it in a response to the Are files obsolete? article
As for ZigZag, I'm inclined to let the ghost of the Xanadu project rest in peace.
Can you describe how this works without making up new words like "posward" and new definitions for existing words like "dimension"? This would help clarify the system for normal, non-technical people.
Please describe the system clearly in a paragraph. A sentence would be nice.
How many lines of code (in what language)/function points is the main functionality (sans errorchecking)? The way I figure, the more code it takes you to describe the system, the more rules the end user has to memorize in order to understand what's going on. This is why creeping featuritis is bad.
Also, I disagree that dreamers are the best choices to design intuitive interfaces. I would recommend asking normal people who have work to do what they want. They have legitimate, practical concerns. Otherwise, you're setting yourself up for bad MeatBall:FeatureKarma.
Without "posward", yes. Posward is shorthand for "toward the positive end". "Positive" is a label for one of the two directions along a dimension.
Without the word "dimension" it'd be much harder. But its usage is analoguous to its use in more traditional situations, such as vector spaces, or in our daily lives.
This would help clarify the system for normal, non-technical people.
No, actually I think using the system or seeing it in action would clarify the system much more easily than any words I could give you. I have personally shown ZigZag to an almost completely computer "illiterate" friend of mine, and he grasped the idea quite easily.
Please describe the system clearly in a paragraph. A sentence would be nice.
Okay. However, the clarity depends on what you consider clear. Here's a paragraph from a paper I'm writing:
The ZigZag structure consists of cells, cell content and connections between cells along dimensions. Each cell has content (either a string or a span), and cells are connected along dimensions. Dimensions have unique names. Dimensions have two directions: the positive direction and the negative direction. A cell may have at most one connection along a dimension on a direction. The term posward means the positive direction and the term negward means the negative direction; in English text they are used analoguously to such terms as rightward and upward. A particular instance of the ZigZag structure is called a ZigZag space.
How many lines of code (in what language)/function points is the main functionality (sans errorchecking)? The way I figure, the more code it takes you to describe the system, the more rules the end user has to memorize in order to understand what's going on.
I don't think this metric is a good one, since it favours models that are close to the underlying model of the implementation language.
However, all you need to implement the basic ZigZag space is cells (at the simplest level, a pair mapping a cell ID to a string), and an associative array mapping dimension names to dimensions. A dimension can be implemented as a pair of associative arrays mapping cells to cells, where one associative array maps negative-to-positive connections and the other mirrors the first by mapping positive-to-negative connections. Given these, I think you can estimate yourself how much effort it would take to implement the basic operations "connect this cell along a given dimension to that cell", "insert this cell on this dimension between these two cells" and "disconnect this cell from that cell".
I would recommend asking normal people who have work to do what they want.
Well, that wouldn't work. See, normal persons normally don't know what they want until they are shown what's possible. If you ask a traditional typist what features he'd like in a word processor, the answer would most likely be, "it should behave exactly like a typewriter". Should we throw away search&replace?
The ZigZag system is very much a product of practical need. The whole system is designed by people who want the system for their daily work. And Ted Nelson's motive for this all is AFAIK that he'll finally get a useful computer system.
By the way, I think the title was misleading. I didn't intend it to be sarcastic. I was trying to come up a word for "non-technical," but couldn't (non-technical would have sufficed!). I just didn't grok how your description was driven by non-technical concerns and was curious. I apologize.
It's hard to conceive without running it, I agree. I think I understand the basic structure, though. It's kind of a hyper-multidimensional-crossword puzzle, isn't it?
I'm not sure what you mean by "string or span." Do you mean as in a character string and an integral range?
[lines of code/function points]
> I don't think this metric is a good one,
It's hard to say. I find, though, that when it takes many lines of code to describe how a system works, it's going to take the user a long time to understand it. But that's all relative. For instance, reparenting a window in X is much more difficult than in Windows, but it's a trivial thing to understand dragging a frame out of a parent window into its own floating window.
I'm not saying that ZigZag is necessarily complicated, but I'm trying to get a feel for how small or big it is. For instance, if you look at the original WikiBase, it is about 500 lines of Perl4 (not using modules). Wikis are dead simple.
> normal persons normally don't know what they want
> until they are shown what's possible
That's a tough call. I think normal people have normal problems. If you want to dream, you dream a little to solve those problems. Often one can get ahead of oneself with large goals. What is possible isn't necessarily what is best. But then again, I'm just being conservative.
Whenever I read about how we should chuck out fundamental metaphors for interacting with computers, I shudder. Most alternate metaphors tend to be unweildy, badly thought-out, or incompatible with the hardware humans use. The current metaphors for computer interaction may not be perfect (far from it), but they have also been refined over many years and serve very well under a broad range of circumstances. It's pretty telling that heirarchical file-trees are still around after nearly fifty years; no one has thought of a better way to implement them on the media and memory systems used by digital computers.
Just remember: different isn't necessarily better.
My pet project, ThoughtStream is somewhat like ZigZag, in that it aims to free users from the limitations of traditional computer models. I agree with the opinions expressed in this thread about the suitability of the N-dimensional grid model (I don't think the average user is capable of wrapping their brain around the concept of N-dimensional space, and therefore it's not a good model to build an application around). ThoughtStream doesn't try to fit things into a grid, which also means it is free of the 1-posward/1-negward limitation. If you're interested in this sort of thing, I encourage you to check it out.
ZigZag does not try to fit in a grid. The two connections per dimension limitation does not require a grid, it only makes the space locally comprehensible (while it allows pseudoparadoxical global structures). There is no requirement, for example, that by going up-left-down-right you should end up in the same place. In fact in ZigZag, you usually don't.
However, ThoughtStream seems to me (after reading the docs; I could not make the software work) to be a mindmappish thing that restricts the user to a tree-like structure with some subordinate connections outside the tree outline. I find that severely restricting.
Ah. I see now. I'm still not sure I like it, but it sounds promising enough to warrant a hands-on trial. Unfortunately, I couldn't get the latest release to compile (using Sun's JDK 1.2.2 on Linux)
However, ThoughtStream seems to me (after reading the docs; I could not make the software work) to be a mindmappish thing that restricts the user to a tree-like structure with some subordinate connections outside the tree outline.
ThoughtStream is a mindmappish thing, but it does not restrict the user to a tree-like structure. The docs perhaps overemphasize the tree-like structures that can be built with TS, both because these structures are more likely to be familiar to users and because they are useful, but TS can be used for arbitrary networks of nodes. Maybe it's the parent/child/jump terminology that's confusing you; just substitute posward/negward for parent/child; jumps are for symmetric links where posward or negward would be meaningless. You are not limited to a single parent.
The "release" is severely outdated. I suggest you try out the CVS version (there are nightly prebuilt snapshot jars). If you have problems, contact me at <gaia@iki.fi>, or the developer mailing list at <zzdev@xanadu.net> (subscribe by sending mail to <zzdev-subscribe@xanadu.net>).
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank
