[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Idea: the All Clones view
- To: ZZ Development <zzdev@xxxxxxxxxx>
- Subject: Idea: the All Clones view
- From: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Date: Sun, 28 Jan 2001 18:21:43 +0200
I've just remembered a nice view idea I had some days ago, which I
didn't think of talking about when still in Finland. I'd call it the
_all clones_ view.
What got me thinking on it is that Ted is talking about clones as
transclusions. Now, a ZigZag cell clone is of course something different
than a Xanadu text transclusion -- most notably, the text transclusion
will not change when the "original" it was transcluded from changes.
(You could also say that the original can't change, because it's on a permascroll.)
So what's the similarity? Well, obviously, the point is that clones
enable us to have the same thing in different contexts. For example, a
person might have been in different partnerships in the genealogy
applitude. We can always have the same cell in different contexts if
these contexts use different dimensions; but if they use the same
dimension (e.g., d.marriage), we'd be doomed without clones. So in a way
we're here using clones to connect the same cell to several other cells
in the same direction on d.marriage.
That's a cool thing, but the view of it often isn't quite what we'd like
it to be. Let's suppose we're using the person cells from the genealogy
app also in a scheduling app, where we make different appointments with
the same person by -- guess what -- cloning that person cell into the
different appointments. Let's say we actually have a lot to do with that
person and have several dozens of appointments with them. To our
knowledge, though, they've only been in, say, four longer relationships
Now if we're viewing on d.marriage and d.clone, what do we get? A lot of
cells on the clone dimension which aren't connected otherwise. Why?
Because they're actually connected on d.appointment -- just, we aren't
viewing d.appointment at the moment and aren't interested in it at all.
Going back to the earlier realization -- we have clones so that we can
simulate multiple connections in the same direction (or, more to the
point, that's one of their most prominent uses...) -- why don't we view
them like that?
What I'm proposing is: a view that works like an ordinary structure view
-- Vanishing view, but that happens to be able to show multiple
connections in one direction, _whenever on ALL clones of this cell,
there is more than one connection in that direction_. So in our example
above, the original cell would have multiple connections on d.marriage.
(If we view d.marriage on the horizontal axis (X), we'd get the
different connected cells over each other in the vertical axis.) We do
not actually show any clones of the original cell; we only show the
connections, accumulated from all clones.
It is a logical extension that when a clone is connected on that
dimension both poswards and negwards, these connections should be shown
on opposite sides of the original cell -- so that we could draw a
straight line through the centers of these three cells. This is basicly
one of the "one thing is in many places" views which Ted has mocked up frequently.
So it's of course not an entirely new idea :), but in this specificness,
it hadn't occured to me yet.
Looking forward to having some time to implement it in the unfortunately