Hi Ross,

On Fri, 6 Jul 2001 23:16:33 -0700 Ross Boylan <RossBoylan at stanfordalumni.org> wrote:
>Pretty cool.  It's very slow on my machine though (viewing my morph),
>and it's a pretty fast one (700Mhz Athlon with Matrox Millenium G200
>card).  However, the morph I made, which is essentially a giant table
>made of rows made of cells, is suspiciously slow on its own.
>
>I just did my first profile; nothing glaring came out.  Given my
>complete ignorance of Morphic performance issues, I may have done some
>very unfortunate things.

Why not send me the profile? I may be able to spot something.

>On the StoryBookMorph itself, some initial reactions (aside from Cool!).

The general answer to the items below is that the SBBM is an experiment. Various approachs were tried and the current configuration is simply one that seemed useful at the time. Other approaches may be as good as or better than the current depending on what you want to accomplish. Feel free to change it to suit your needs.

>* There's a little square on the bottom giving magnification and
>position (?).  One can pull little images of the bigger window out of
>this.  I kept wanting to do things, like click there to reposition the
>larger window.  It didn't have any effect.

There is an item in the red halo menu 'Go to this mark'. You could make it do that on a simple click if you wanted. What it provides now is the ability to synchronize the visual display with a musical score. If you have a PianoRollScoreMorph that plays a piece of music, you can drop the scale/position images into the score and the image will be panned and zoomed in sync with the music.

>* left/right panning in the blue area worked, but moving up and down
>didn't seem to have any effect (it did with the keys).

There are 3 variables being controlled here: x and y for the camera plus a zoom factor. How each is controlled was simply a matter of what felt more natural to the user at the time. We did have two values controlled by the mouse for a while, but moved one of them to the keyboard. Feel free to try another combination.

>* I was able to remap the keys and get them to work for pan/zoom.
>* The zoom seemed to require intermittent taps on the blue area with
>the mouse to keep working.

I can't say that I have seen that. Were you doing more than one thing at a time? Could the mouse have strayed out of the blue area?

>* The zoom also stopped at places where I wanted to drive it further
>(e.g., no smaller than occupying the whole screen).

There are two limits in place: 
- zoom in stops at 10:1. This is purely arbitrary, but memory requirements may increase at larger zoom factors.
- zoom out stops when the edges of the content are reached. This was to prevent accidental overshoot which would show some boring border area. Purely aesthetic for the intended demo.

>* I really wanted the whole thing to be larger, but dragging resize on
>the outer book morph doesn't do anything.  I finally selected the page
>morph and managed to resize that, with the book following suit.

That's the way book morphs work, but it certainly could be nicer.

>* The metaphors and modes of interaction seemed mixed, e.g., keys vs
>mouse pointer.  Manipulation of visible controls (the cross hairs in
>the blue box or the sliders underneath) vs. non visible (keys to zoom,
>or clicking up halos on just the right submorph to achieve other
>effects).

Granted. I'm not sure, however, that there is an obvious, natural solution to controlling 3 variables (5 if you count the scaling factors the sliders represent) with just a mouse or keyboard alone. Counter-examples readily accepted. ;-)

>* Any reason to start the green story board so small in relation to
>the window holding it?

This has to do with the decision to limit zoom-out to the extent of the content. If the green area were larger initially and your graphic did not fill it completely, then you would see the excess green area when you zoomed out. Since this didn't look so nice for the demo. I made it start small and then resize to fit whatever you  dropped in.

>* I wanted to be able to type in, e.g., the magnification factor (by
>clicking on the number giving it and typing in a new value).

You're right - it doesn't do that, but it shouldn't be hard to add.

>* Another metaphor I've been playing with is one where the mouse is
>the camera.  So if I move it off center to the right the image scrolls
>left under me.  I'd never need to leave the thing I'm interested in to
>move around over it.  As far as I can tell, StoryBookMorph doesn't
>operate this way.

This sounds to me like it might be over-responsive, but feel free to try it.

>Soapbox: Some of these issues are more general.  Smalltalk, and squeak
>particularly, seems prone to hidden interfaces: you have to click, or
>shift click ... to bring something up to do an operation.  If you
>don't know the secret handshake, you're out of luck.  It's like some
>of those computer adventure games where you spend all your time
>clicking things randomly to see if anything will happen.  I know it's
>hard, but it's better to have more obvious clues about how to do things.

I would say that it is more the experimental nature of what we do with Squeak rather than Squeak itself that causes these gaps in clarity. The SBBM explored a concept and then got placed on the shelf (I imagine that very few have even tried to play with it). If the SBBM became an important part of the user's experience, I imagine that more attention would be paid to making the controls obvious.

Cheers,
Bob