links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Alternative UI rant
Last updated at 10:59 am UTC on 11 November 2006
The following notes are from April 1999 and somewhat dated. See Customizing the Squeak UI for more current information.

(posted on the Squeaklist by shaping@bigfoot.com and shamelessly pasted here w/o any sort of permission by DanielVainsencher)

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- and Ctrl-Shift- being used typically for text editing, can we instead use Cmd-Shift- 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...