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

Re: [zzdev] Re: Query: Technical description for keybinding actions?

At 06:01 PM Friday 02/15/2002, B. Fallenstein wrote:

Hi Jan!

Jan Theodore Galkowski wrote:

[snip]


> Indeed, I propose having something like an SUnit standard
> set of test cases which validate that an implementation
> conforms to a predefined standard.

Well, as our implementation is in Java, our testsuite is in JUnit.
However, I'm sure we can work something out that works for different
language bindings.

Ah.  Astonishing symmetry there.  Wonder why.

So, you agree the idea is a good one?  That is, a self-executing
suite of test cases establishes conformity to a definitive
ZigZag implementation and that, therefore, can be in some sense,
an operational (but nothing else) definition of that?

Yes, that'll work.

> The test cases could
> be CMed and they, in addition to prose description, could
> serve as a touchstone for what some "official" ZigZag
> should behave like.

Sorry-- what does 'CMed' mean?

Sorry: CM = "configuration management".  It's a bad habit of
an earlier era.


> My personal view is that ZigZag is very (I mean really very)
> important, a crucial idea.  And using it and ZigZag ideas
> in the context of a spreadsheet-like tool or a PIM-like tool
> is barely scratching the surface of possibility.  (I'm thinking
> of structures with trillions of cells and using zz operations
> in place of SQL.) 

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.

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.


In my opinion, the most important thing about ZigZag is that everything
can be interconnected, so humans can structure everything to their
convenience. In many ways, a good ZZ implementation can ease a
programmer's life (for example, by taking care of Undo and versioning on
the system level), but the most important benefit is that you can always
connect everything that belongs together.

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, for one, am highly skeptical of pushing paradigms beyond the
domain they can work in.  My main reason is it is, unwittingly or
not, one way of forcing the paradigms to fail to achieve what they
might.  Many are very good and very valuable.  But if you use them
to beat a nail, they won't work.  One thing at a time.  If we
can do a small thing perfectly, everything is possible.


(snip)

> To me, one consequence of not really knowing what we are
> doing yet is that I think the internals of any zz implementation
> needs to be done using the best of what's available of
> existing software design and technology, as limited as it is.

Yes, but the degree to which this is possible varies between ZigZag
implementations, because they have different goals. For example, Les
Carr's ZigZag on the Web (http://www.ecs.soton.ac.uk/~lac/zigzag/) uses
WWW standards heavily, for example XML, XSLT, _javascript_, and HTML's
multimedia capabilities. GZigZag, on the other hand, can use much less
current software, because it tries to do many things that current
software cannot do; ultimately, we aim for an implementation of Ted's
Floating World design (see <http://xanadu.com/zigzag/fw99/>). This
includes, for example, Xanadu-style linking and transclusions, and these
are simply not possible with today's widely used software.

And, I agree.  I agree in the sense that compromising in
fundamental ways simply to avail oneself of "what's out there".
For one thing ZZ breaks rules that many of these other
systems assume.  That doesn't automatically mean they are
useless, for ZZ or anyone else, but it does make their
contribution suspect.  For another thing, we'll never know
what we can do with Xanadu-ZZ unless we push the fringes.
It simply is not likely that major improvements are going to
be had by making minor changes, as much as CEOs hate the
idea.

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.


So we have to take care that some ZZ implementations can leverage the
power of existing software, and others can go beyond that.

> To me, this means using a Model-View-Presenter (MVP) triplet
> for each of Menu and Event windows, using the common Model,
> of course.

MVP? I know Model-View-Controller; what exactly is the difference to
Model-View-Presenter? (Or was that just a typo?)

MVP is an improvement upon MVC made by Taligent for C++ originally.
It's a cornerstone of the Smalltalk dialect I'm fond of,
namely, Dolphin Smalltalk.  The change is subtle in many ways,
but basically the Model component is the same, but Views know
about Presenters and Models, and Presenters about Models
and Views.  The Presenter is key.  This does not sound like
an improvement, but it is.  The problem is that, in MVC,
interaction with a user is cleaved between incoming requests
and screen updates, and that cleave is not natural.

I know that doesn't say a lot. Check out

  http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm


Currently, the system GZigZag uses (and all other existing ZZ
implementations use) is to have the ZZ space as a Model, and completely
re-create the View each time the user interacts with the system. This is
probably the most simple and robust way to go about this. However, for
speed we're currently adjusting GZZ to support a Model-View system with
multiple Views, so that we only have to re-create the View when the part
of the structure changes that the View shows. (Like most modern systems,
we do not use an explicit Controller.)

Thanks.  That helps a lot regarding the architecture.
As a side note, the MVP pattern tries to overcome the problems
which motivate many systems to exclude the Controller.


[I'm capitalizing the terms here because 'view' has a different meaning
in the ZigZag context-- it's a scheme for showing a ZigZag structure on
the screen-- and the double meaning has lead us astray before.)

Yes, thanks.  I dig.


Do note that Ted's more advanced designs for ZigZag include an arbitrary
number of windows, not only the Control and Data window (as Menu and
Event have come to be called).

Yes, I wondered about that.  It should be that way; at least
it feels it should be.  The only problem it poses to me is
one of how to refer to all these objects, and how to do
it consistently and uniformly.


> It means keeping options open, avoiding premature
> limitations on design.  So, in a Windows context, that
> means cell contents should be Rich Text.

This is fine as a design decision for one implementation, but it would
be far too limiting for all implementations. Most ZZ implementations use
arbitrary strings as cell contents. The GZigZag implementation actually
does not have cell contents at all "under the covers": on the screen, a
cell can contain text or an image, but internally, these are determined
by the connections of the cell, and references to Xanadu-like media. The
point here is that all of these contents are actually stored outside the
ZigZag spaces, and have permanent addresses, allowing them to be linked
and transcluded in a Xanadu-like manner.

Oh, I don't know about all this.  I'm ignorant of Xanadu implementations
and I think that ignorance could be valuable to you and to the
entire Xanadu effort.  It's so, so easy for implementors to
confuse the design layers in their implementation with those that
are more properly at the user interface.  To make that mistake
is why many projects turn out so badly.  Because one has
operationally and pragmatically made an assumption does not mean
that assumption _must_ be so.

For example--and I apologize again for being long-winded here--a
quick design of a ZZ Model to me would involve several different
classes.  There'd be a ZZCell, of course, having an ZZIdentity
and contents.  There'd be a ZZDimension, which would be, to me,
a subclass of Dictionary.  The identity of ZZCells would be the
key to the ZZDimension, and each Association in the Dictionary
would have as its value a subclass of Pair, perhaps named
ZZCellLinkage (not happy with that), with a PosWard and NegWard
component, each being a ZZIdentity.  Now, ZZIdentity would be
completely internal, not being something a user would ever see.
If there were to be a default identity for a cell, it would be
carried in the ZZCell object as well.  I'd create a ZZCellNames
class, a subclass of IdentityDictionary, which had in it a
ZZIdentity and a ZZExternalName, the latter being a sublcass
of Object.

With this scheme, any ZZCell object could be in any or all
ZZDimensions, even although, conceptually, it is in all of
them all the time.  There would, in this scheme, be a need
for a ZZDimensionDirectory class or some such, to collect
all the dimensions together in one place.

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.


Basically, we want the permanently addressable text to be pure content
without markup, for easy handling in transclusions etc., which puts rtf
out of the question. We want to have parallel markup: the markup is
attached to the text structurally inside the ZigZag space.

(1) What's a "transclusion"?

(2) Why can't RTF text have markup attached to it?  I'm sure
    you have a good reason, but I just don't see.

(3) I want RTF because it's the gateway to arbitrary and
    specialized character sets, like the Asian ones and
    stuff like the Elvish Runes of Middle Earth as well
    as hieroglyphics.


(Of course, on the common interface level, you can get and set the text
in a cell as a string.)

> Names of cells
> should, at least in the internals, be allowed to be any
> object, not merely a name or string, even if the internal
> reference to a cell is an internal key.

Fine, though I think cell names must at least be representable as a
string, so that they can be serialized easily. Some time ago we had a
standardization discussion on zzdev; one idea (of mine) was to use URIs
to identify cells and dimensions globally. I still hold that this would
be the right way to go about it, as we want to be able to exchange data
between ZigZag systems and then the identifiers need to be permanent and
world-unique. (And it seems foolish to try to make all ZZ
implementations agree on an ad-hoc format, when there's an internet
standard for world-unique identifiers.)

Oh, I'm not saying anyone else should do this.  I'm saying this
is what my implementation is going to do.  I agreed that interfaces
should be the same.  I said nothing about the way I represent
the Model.


> And there should
> be nothing which limits the number of cells or dimensions
> to any particular size:  That should be the limit of machine
> memory, not "This implementation accomodates a maximum of
> 65,536 dimensions."

Of course.

> I haven't looked at the GZigZag implementation, yet.  So,
> I have no idea if this is the kind of thing it does.
> I apologize if I offend anyone.  I do not mean to.  I'm
> just stating my view.

No, I'm sure you haven't offended anyone, though opinions may differ ;-)

> I also think this open source way of going about it is the
> right way. I see nothing to be gained by applying market
> pressures prematurely.

For your information: Everybody on the current GZigZag developers team
believes strongly in Free Software, though many people in the ZZ
community and on this list do not. So for us on the GZZ team, it's a
matter of principle, not just pragmatism about the current situation. :-)

Which shouldn't stop us from cooperating, of course; just so that you
understand the situation.

Yes, it should not.  IMO, the freeware vs GPLware vs payware vs
shareware has gotten very tired and really is propagating itself
rather than dealing with reality.  The problem is that corporate
capitalism has a hard time dealing with complicated, technical
issues, whether software, privacy in an electronically connected
age, health, or the environment.  Its problems are simply not
addressed, let alone solved, by a discussion regarding copyrights
and software.  Its flaws are ones of valuation:  It cannot,
because of systemic reasons, accurately assess the value of
things whose true value are only know 50 years in the future.


> I also think trying to develop a "ZigZag way of programming"
> and using it to implement ZigZag is a wrong way of going
> about this.  Such a means of programming is important to
> pursue and can be rolled in later.  But we don't know
> what we're doing and that kind of approach would compound
> risk, not control it.

Well, a cell programming language for user-level extension of ZZ is part
of the Floating World design we aim to implement, and in fact we have
already implemented a number of those. Currently development is underway
to implement the key bindings themselves in one of them. Writing GZigZag
in itself is far from being a current issue, though.

Good luck with that.  A cell-level programming language sounds
interesting, although I won't focus on it soon, possibly not for
years.  Other things are important.  I would object, however, if
supporting that was made part of an interface standard.


However, now this is really something implementations can easily choose
to do differently without losing any interoperability.

(snip)

> 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.


> 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.

Would be nice to see you start using it for that. ;-)

Great.  Yes, it would.


(snip)

> > One thing that is especially important is to make the key bindings
> > configurable inside the ZZ space. In the end, this is more in the
> > spirit
> > of ZZ than any specific set of key bindings can ever be.
>
> Yes, I understand that.  However, the entire matter of
> designing programmable interfaces is a perilous area,
> even if all ways are moved by a desire to be accomodating,
> flexible, and open, not just convenient for the implementer.
> It's kind of like the keyboard macro vs no keyboard macro
> issue within emacs.  Sure it has it, but there's some doubt
> recorded in the Manual about whether they are a good idea.
> Think of a typewriter with keys that are removable and
> replaceable to allow people to put them where they want
> them to be: Touch typing doesn't make sense in that world.
> Facility with a particular configuration of keys can't be
> developed if they don't stay put.

Sorry, but I can't follow your reasoning. If people can put the keys on
the typewriter where they want to put them, who says they'll put them in
a different position every day? This isn't what's happening with emacs
either, is it? You can configure them as you like, then you can develop
facility with that configuration, then if something nags you about it
you can change it.

And having different skins fails to support that how?


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.


In any case, I maintain that not allowing users to configure the key
bindings *is* going against 'the ZigZag way.' Not being locked in by
somebody else's structures, interfaces, keymaps etc.pp. is the whole
point of ZZ. It's like Ted doesn't say, "okay, I give you 20 dimensions
with predefined meanings and also 5 you can customize on your own."
You're supposed to be able to look into everything and change everything
down to the very bottom of the system.

There is a limit to which anyone can support arbitrary choice.
Even incredibly fantastic systems will, eventually, run into
the ramifications of their own choices.  I don't see hiding
those consequences from users as doing them a service.

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.

The set of key bindings should change, but change _slowly_.
I don't know how one engineers that.  The set of key bindings
is the language we speak in, both to ZigZag and to each other.
Change it too fast and noone will understand you.  I absolutely
embrace the need for allowing it to be changed.  But if it
changes so much that ZigZag fails, users can't change what
they want either.  I know:  It's a risk, and, for most situations,
the balance between safety and risk should be decided in
favor of risk.


(Still, of course, you can do this differently in your implementation if
you do not think this is the right way to go about it...)

> Is that tome back there what you wanted?  Sorry it didn't fit on
> the back of your calling card. (;-)}

Discussions are fine with me. :-)

One side note: When you start your own ZigZag implementation, remember
that ZigZag is a trademark of Ted's. You can either try to settle into
an agreement with him for using it, or you have to call your software
something else. Ted has proposed the terms 'hypergrid' and 'orthoplex'
as non-trademarked alternatives; both terms have found supporters in the
ZZ community, so it seems these are 'the' two terms now.

Yes.  Indeed, that was my first concern.  I pursued that
using another channel.  I firmly believe trademarks and
copyrights should be respected, primarily for the reason
artists want them to be.  That'll be resolved before I
make anything public.  That doesn't mean, however, that
I'll make anything public when it is resolved.


[snip]

P.S.: We, the GZigZag developer team, are also using the #gzigzag
channel on IRCNet. If you like, you can also join us there besides using
this list.

Hey, Benja, that's a great lead.  Thanks.  I've always
thought IRC should be used for lots of things besides RPG
(any DND players out there?), and I have this underutilized
mIRC sitting on my Desktop.  I have tried, but don't dig AIM
and stuff _at_ _all_.

Ciao, all.  It's always a great pleasure....