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

Re: [zzdev] [zzdev] Query: Technical description for key binding actions?


At 01:56 PM Friday 02/15/2002, you wrote:

Hi Jan,

Jan Theodore Galkowski schrieb:
> First time here.  I'm interested in building a version of ZigZag
> for Windows using Dolphin Smalltalk.

Great!

Are you interested in cooperating with us, the GZigZag
<http://www.gzigzag.org/> team? We're working on an implementation in
Java (the most ambitious implementation of ZigZag so far), and we are
trying to fix some basic interfaces independently from implementation.
If you do a new ZZ implementatation, it would be nice if we could agree
on something there.

Benja,

Yes.  I had a look at http://www.gzigzag.org/ug/newug.html: Very
nice.  Much of what I wanted is there.

[Long warning on.  Flame warning on.]

I agree that all ZigZag implementations should try (very hard)
for a common interface, even if different capabilities are
supported deep underneath and at the frontiers, the latter
being primarily interfaces with other systems and software.

Indeed, I propose having something like an SUnit standard
set of test cases which validate that an implementation
conforms to a predefined standard.  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.

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.)   But learning to use ZigZag is 
learning to type with a typewriter before touch typing was
invented. 

The typewriter was first invented in the 1830s, and after
the first two inventors went broke, a model was manufactured
consistently until the 1870s but hardly got any orders at
all.  The guy who pointed this out to me, Harlin Mills of
the structured programming genre in its heyday, said he
wondered about it because he noticed that a letter from
Secretary of War Stanton to Lincoln was written in Stanton's
longhand.  Touch typing wasn't invented until 1870-1880 and
the typewriter wasn't widely accepted until turn of the
century, when it became de rigeur for business correspondence.
Naturally, orders took off.  Even then, it had problems,
particularly with some of the public.  Sears got an irate
letter from an Iowa farmer about the notice they sent him
typed using these new machines.  The farmer complained
"There 'tain't no need to print your letters.  I can
read writin'!".

Anyway, because ZZspace is a new place and we're just getting
used to new ways of encoding knowledge in it and stuff, I
should think the interface will be something that'll be growing
up for quite a while, and ways of teaching it will come, but
will be even slower.

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.
This is because we need to control risk there so we can
let the interfaces be malleable and, with usage and
experience, we can easily change them to accomodate other
presentations and views. 

To me, this means using a Model-View-Presenter (MVP) triplet
for each of Menu and Event windows, using the common Model,
of course.  It means keeping options open, avoiding premature
limitations on design.  So, in a Windows context, that
means cell contents should be Rich Text.  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.  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." 

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.

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.

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.

I forsee lots of things to do.  After a couple of standard
implementations that work the same for the most part, available
on a wide variety of hosts, there needs to be a Web repository
where people can see ZigZag being used for all kinds of things.
Integrated into that could be tutorials and things.

Nothing will, in my opinion, bring the maturing of the interface
and of ways of teaching it better than heavy usage.  Once the
interface is there, ZigZag afficianados should use it as much
as possible.  I think there should be a kind of a personal pledge,
too, to maximize the usefulness of that experiment:  That the
temptation to escape out of ZigZag and do something elsewhere
not be followed.  Afficianados should keep diaries and journals
about their experiences and summarize and share these.

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.

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.

So, that's a bit of my mind.

Oh, I'm allergic to coffee. (;-)}  So, if you don't mind,
I'll fight to keep whatever I do 100% compatible on the
interface level, but I like my loose methods. (:-)}

[Flame warning off.  Long warning off.]

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

Initially, because of this, I'd be more in favor of having
key bindings that were attached to different "skins" people
could choose.  One reason is that I think that that way
we all would understand better which skins worked better
than others and why.  The interface would then be programmable,
but what the interface did could be subjected to constraints.
This isn't because I or anyone should control what anyone
does with ZigZag but, rather, that we are all ignorant, and
to learn the full lesson users are trying to teach us, we
can't use a going-in-all-directions-at-once approach.

[snip]

> However, I want to
> capture and preserve the experience of Ted, Marlene, and everyone
> with ZigZag as codified in the functions and actions that have been
> found to be useful.

Have you taken a look at GZigZag 0.6.0 (do not use 0.6.1; it will
probably not run correctly) available at www.gzigzag.org? If not, you
should do so; its key bindings are close to the Perl version but contain
some additions, and they have proven quite useful so far.

I have not.  I will check this out.


> Thanks for any pointers.

Would be nice to hear more from you.

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

Good to here from you.

  --Jan

[snip]