[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: Implementing ZigZag (Re: Query: Technicaldescription for keybinding actions?)

At 01:15 PM Saturday 02/16/2002, Tuukka Hastrup wrote:

Hi Jan,
There was actually some more I wanted to comment on, included here. But
don't get afraid of the amount of information and design issues, as you
can get far without taking every thread into account. As you probably
know, things like ZigZag are really connected to everything, and we
all have to concentrate on something - preferably not the same things :-)

On Fri, 15 Feb 2002, Jan Theodore Galkowski wrote:
> At 06:01 PM Friday 02/15/2002, B. Fallenstein wrote:
> >Yes. Basically, any highly interconnected data can benefit from ZigZag.
> >Usually, any structure that's not a list or table or tree is
> >particularly well visualized in ZZ.

Which is not to say that lists and tables and trees wouldn't be well
visualized in ZZ ;-) For a reference, if Jan hasn't seen this yet, I'd
like to point you to a couple of views that essentially visualize
hierarchies:
http://www.iki.fi/asko.soukka/temp/zigzag/

Yes, Tuukka, but that's exactly what I meant.  That's
exactly why I'd want to use a ZZ representation all
the time, to preserve the possibility for breaking out.


By the way, these views will be included in the GZigZag 0.6.2 release
(happening right now I think!).

> BUT, IMO, a structure that's a list or table or tree some day and
> in some way might WANT to be visualized as something other than
> a list or table or tree.  Without ZZ one forecloses that possibility,
> sometimes intellectually, by limiting the views of the people
> seeing the data, sometimes pragmatically, by making the resources
> needed to do something other than a list or table or tree too big
> to be feasible.  With ZZ the possibility is not lost.

But what's unique, really? I'd say the MVP model you referred to would
always allow this, no? Maybe the point in ZigZag is that having one model
is not having models: you can use any view to look into any data, and
underneath, you can connect any data to anything else, which is not
possible in case of several models.

Yes, but these models have different purposes and applications.
The Model of MVP is a proper name, referring to a specific albeit
conceptual part of a design pattern.  In applications for ZZ I
entirely agree one would prefer not to be bound to a model.
Some people think, however, that we cannot see anything without
using a model, if only an implicit one.  ZZ is important, however,
in that it can allow a change of view, model, or representation
more easily.

But, as I said in a response to Benja, I think it's a mistake
to try to build the ZZ implementations using ZZ concepts.  Instead,
I believe we should use the best we can from software engineering
of today, so the design is changeable and risk is controlled.
My point is we really don't know what we're doing with ZZ yet.
It's also not true that to build a completely open and flexible
framework one needs to use completely open and flexible means.
Indeed, my opinion is doing so makes realizing the framework
harder.


> Agree on the former interconnection.  An issue for the Community
> down the road, 'though, is whether all interconnections are equally
> valuable and, so, should be displayed by default.  This is more
> complicated than public versus private interconnections:  There's
> no reason why interconnections shouldn't be qualified in indefinitely
> subtle shades of gray.

I'd take the position that whenever the user makes a connection, it must
be important enough to be shown. Generated connections are another matter.
There are several features already which help stop cluttering: usually you
don't view but a few dimensions at a time, and you can have most two
connections on a cell along any given dimension. The latter ensures the
space is always "sparse" with respect to a limited set of dimensions.

I guess I need more experience.  One of the issues I'd like to
learn about, for instance, is how to organize groups of cells into
clumps that can, however briefly, be thought of as a unit.  Does
that always involve creating a new dimension?  I don't mind if it
does, but I can't think of another way, so that's a thing to test
to see if my understanding is correct or not.


I'm not saying weighting connections is a bad idea, not at all! But I'd
say it's not important with respect to ZigZag paradigm. As a sidenote, I'm
sure it's important to have every object in the system be first-class. 
Tuomas has a specification for handling connections as first-class objects
(in ZigZag, that is cells :-) which enables weighting no problem.

Well, this comes up in qualitative data analysis, too.  One begins
with a text of some kind.  The text is the subject of analysis.
It is fixed and read-only.  Think of the Torah, the Koran, or
Shakespeare.  One then marks up the text, creating annotations,
links, cross-references, and networks of all these.  There's a
purpose to analysis.  But the most important insight from this
work as a discipline is that the analysis eventually begins to
tell its own story, that that story becomes metadata of an
important kind.


> I don't know about Floating World.  I really don't know much
> about Xanadu.  But I believe I understand ZZ and it is very
> important.

Maybe you'll find time to read Ted's homepage some time. Or his books, if
only you can get your hands on some.

I've recently purchased LITERARY MACHINES, but it'll be
a few weeks before it arrives.


[snip]

So what we do at the moment is to have ZigZag Space as the Model.  An
update loop generates a VobScene around a view cursor from the Model for
every window whenever something changes. A VobScene can be directly
rendered into a bitmap, but it understands identities so we can animate
between consequent scenes and ask it about the object whenever a mouse
click arrives. So VobScene is pretty much the V of the triplet.

User actions (key press like "Ctrl-Left" or mouse action like
Click1-somecell) are passed to a Clasm function (a cellural language)
which modifies the structure as it sees fit. This is something like the
Presenter, don't you think? Just that it doesn't really know about the
VobScene, it reads the mode and all from the structure.

I need to think about all this some more, and maybe play
computer with it.

[snip]


This looks very similar to what we've had. We have the cell identity as a
String though, because what good is something else?

Oh, why can't pictures or music or movies be identities of
cells?


>...
The semantics can
matter, yes, like having it interpreted as an URI, or a Mediaserver
Globally Unique ID as it's in GZigZag at the moment. I'd say you'll want
to think about IDs a lot, because that's a very powerful and complex
matter.

Yes, I can see URIs, although I'm not happy with the stuff the
W3C has dreamt up:  Too many compromises.  That's another
reason why I want almost any Object to be an identity:  If it
is, then the link can be to almost anything because if, say,
I send #value to the object, it can be a string, a picture,
a movie, a Web reference, or any procedure.


> This design is really off the top of my head, so I apologize
> for its weaknesses.  I try to apply some of the ideas from
> relational database design when I do these classes.

I'm looking forward to hearing what kind of results you find after
thinking about this and maybe looking how the design has evolved in other
implementations (take GZigZag Java/ (0.6) and the new src/ (to become 0.8) 
implementations for example).

Yes, I'm going to have a careful look at the Java, after taking
a lot of Benadryl first, of course. (;-)}


> > > There should be a means of deciding when something gets into
> > > the official releases, although nothing says that if there is
> > > a difference in opinion a tree structured release organization
> > > might not serve.  Quaker consensus was used in the design of
> > > APL and served that well.  It might work for ZigZag.
> >
> >Well, this is certainly something that each implementation needs to
> >decide on its own.
>
> I have no standing here.  Personally, I think it's too important
> to be left implementation dependent.

I think here we have to make the difference between ZigZag and ZigZag
implementations. Release management isn't a ZigZag specific issue, it
depends more on the implementing organization. But right, for overall
ZigZag concept we need to build a system which works building on top of
the current implementations and in Ted's control and which allows as much
co-operation between the implementations as is possible.

Yes, I agree, especially the "in Ted's control" part and the
compatibility part.


> > > In addition to being a Smalltalker and database programmer, I
> > > also have done knowledge engineering in support of the
> > > so-called data warehouses.  In that I use ATLAS.ti, one of
> > > several software packages available for qualitative analysis.
> > > (See http://www.scolari.co.uk/atlasti/atlasti.htm.)  ZigZag
> > > is wonderful for that world, and the need for and success of
> > > qualitative analysis software suggests there is at least a
> > > business niche for ZigZag, as unimportant as having such a
> > > niche is now.
> > >
> > > Naturally, because I'm into database applications, the idea
> > > of using ZigZag structures there tantalizes me.

Me too. ZigZag dimensions are simply one normalization of a relational
database, right? And knowledge management concepts like Conceptual
Graphs and Topic Maps have that something in common with ZigZag, just
expressed in a different way.

The most important thing that Normal Form provides is the ability
to structure a set of information so that if it is changed in
the outside world, it only needs to be updated in one place.  It's
amazing to me many RDBMS users and devotees don't appreciate this.
Even many folks in AI work and knowledge engineering didn't appreciate
for a long time that this was a solution for a lot of thorny
problems they encountered. Folks tend to think of Normal Form as some
kind of aesthetic ideal, something not to be found in the "real world".
You rarely encounter databases normalized up to Fifth.

But Normal Form isn't the answer to everything and it does take
quite a lot of work to organize information in that form.  Doing
that organization also loses something about the original information
which, for instance, the qualitative data analysis folks and
the Grounded Theory folks want to keep.

And I do agree that it's more natural and human to organize
95% of a body's schedule or diary so it's recorded in identical
units, but letting the entries for Auntie Em and that gorgeous
curly-haired brunette at the pizza parlor be different.


> >It also seems to me that this is the best way to improve on the
> >interface: have different people try out different things. I don't think
> >there is anything to gain in interface development through *not*
> >allowing people to try out things.
>
> I didn't say that.  I said they then needed to bundle their
> change into a skin or, obviously, an amendment to an existing
> skin.

Maybe you'd say the modes we have in GZigZag are like skins. They are
groups of key bindings. The point in user configuration is that it should
be simple, isn't it? A great idea you see in some conventional programs is
that you can edit menus the same way you access them (eg. hover over an
item an press a key, and a shortcut is assigned). That is really needed,
otherwise little configuration will happen. The same with skins: if you
have to work a lot to change a little thing, you just won't do it.

Yes, I see that.  Cool.


> I agree that dimensions should be anything users want them to
> be.  I do not agree that key bindings should start out undefined.
> I agree that key bindings should be changeable.  I don't agree
> that a lot of effort should be devoted to building a macro
> system for making key bindings.

Actually, we're not talking about "a macro system" but a scripting
language. A complete programming language and environment that can be used
inside ZigZag, will also be used to define key bindings. In its simplest
form a binding will simply be a call of a predefined function - but it can
be anything the user's programming skills allow.

But by 'scripting language' I hope you mean something more
creative than inline LISP code -- to use an extreme instance --
or something which is as much as a throwback to shell script
as Microsoft's _vbscript_ or script for Word is.



I know scripting is a delicate issue, but I'm completely for it. And not
with some crappy macro system but with a real programming language. At
least we developers are programmers and can appreciate the power. And Ted
has been saying how programming is something everybody should know at
least a little, just that programming must be made easier for this to be
achieved. Maybe you mean we could go with some existing language instead
of making some of our own? That's a good question, and we've made
a decision to this direction for GZigZag. I think you could well use
Smalltalk.

Or Smallscript.  I can give you a reference there if anyone
needs one.  It's new.

But I'm not saying it shouldn't be.  I'm saying we need to
tread carefully here, that's all.  I'm sure it can be done.



Excuse me my inelegant language. I appreciate the conversation,

WHAT inelegant language??  I like this stuff, too.
 
  --Jan

[snip]