I recently included the following aside in an e-mail to Reinier.  I wonder
if anyone has any thoughts in this area.

.........

Aside:  This is prompted by my frustration with Squeak and something I think
Alan Kay said about how he uses the keyboard and mouse together (which is
similar to what I do).

I've been using computers for more than two decades, and I've noticed that I
spend much time using the abilities the UI gives me, even when they don't
help me do my work.  Most notably, the UI lets me resize and move
overlapping windows.   I do a lot of this, but I don't want to do it; I just
want to see my work area so that I can read it now, understand it now, and
change it now.  As I get closer to "now" on all three phases, I become
mentally and emotionally more resonant and happy with my work and computer.
I can't remember the last time I felt that way.

So, I ask:  do we really need these overlapping user-movable, user-resizable
windows to contain and display our work?  I'd like to see some form of
intelligent, dynamic tiling that makes all of my work maximally visible and
tractable nearly all of the time.   That project windows are auto-aligned
with each other when minimized is a step in this direction.  The way the
flaps work is great, too.  We need more of this sort of thing.

We're given to many choices in the UI (not just Squeak--windowing systems in
general).  I think we give up real working efficiency for so many degrees of
feedom, most of which are not needed in most working situations.  At any
given moment in my work trajectory on a graphical desktop, there are only a
handful of operations I'm contextually
likely to do next.  If I'm in a browser looking at code, the browser, as
part of its self-adjusting design, should know that I'm using it, and should
show me as much as possible in all of its panes, so that I don't develop
tunnel vision while I'm solving a problem, but not so much that I can't
clearly see and work on the one thing that now interests me.  If the method
names are too long and truncated at the pane's right edge or the method text
doesn't fit completely in the method pane, then the individual panes or
browser as a whole should auto-enlarge (or the user should have the option
to make it so behave) until text visibility is maximized or the browser is
the size of the screen.

If you want to track other visual happenings while browsing, and your
browser is full-screen, another approach is to use alpha
blending/translucency to drop other morphs into the background, behind the
browser.  Use command-key/mouse-click combos to tell morphs to fade-out
behind the browser or slowly fade-in through the browser until they are more
opaque, visually consuming the browser as they fade-in and restoring it as
they fade-out.  At some point they would become nearly opaque and,
consequently, tractable via keyboard and mouse, like the browser just was.
We'd have to indicate visually how/when this transition happens, but I think
it can be done in this analog fashion, instead of suddenly and
discontinuously, giving the UI some warning about forthcoming context
changes and how it should reinterpret keyboard and mouse inputs.  Strongly
coupled UI components (like the panes in a browser) would be organized
areally, as usual.  Less tightly coupled, but likely related projects and
morphs would be organized sagittally.  I'm wondering about the practical
limits of sagittal stacking.  That depends on how well the graphics are
done, but perhaps five levels might be attainable without confusion.  Only
one level at a time could have input focus.  Maybe we could tint each level
a different color.  I have to think about this.  If the sagittal layers are
discrete, not continuous, we could use a quick-pick flap to jump to a
specific plane, fading it in and all others out.  Is anyone working in this
direction?

The value of the sagittal stacking seems to lie in the fact that you can
preserve the positions of all of your morphs/apps, and take adavantage of
kinesthetic memory to improve fluency--a kind of  "I alway have my mouse
about here when I do this particularly thing in this app in that pane"
familiarity.  I'm trying to determine acceptable ways of increasing UI
density and reducing mouse movement (moving to the border to get something
from a flap) and disorientation as the destop changes (one morph or window
occludes another when it becomes active).  Occlusion can be good and bad; so
can translucency.  Balanced properly, both can be useful.  Any thoughts?

I don't like scrollbars, either.  I remember, though, when I thought they
were really cool.  :-)  Why must I use a scrollbar to view text?  Usually,
we're looking at text when we drag the thumb, right?  Sometimes we're
looking at a graphic we're drawing or a bunch of icons.  If I'm viewing
text, and all of the text is not visible, and the text in the pane is
editable (browser, word processor), then the text pane would "know" that my
hands must be on the keyboard if I choose to edit.  Better, the text pane
should assume, worst-case, that editing will occur, and therefore not
require that I move one of my hands to a pointing device, so that I can move
the scrollbar's thumb to see what I want.  The browser should instead let me
move the pane's viewport on the text with a command-key/arrow-key combo.
But this should be done only after the browser has attempted pane resizing,
browser resizing, and text reformatting or, at minimum, word-wrapping.
Shift-<arrow key> and Ctrl-Shift-<arrow key> being used typically for text
editing, can we instead use Cmd-Shift-<arrow key> to do this?  Bottom line:
if I'm just using my system browser, I shouldn't have to take my hands off
the keyboard until I'm done using it.

Just some thoughts...