| 
View
 

JustGo

Page history last edited by Richard Karpinski 16 years, 6 months ago

JustGo - a simple way to interact with computers using just the mouse

 

We are descended from tens of millions of years of ancestors who made it back to the nest, or we wouldn't be here. One consequence is that navigating geographically, that is turning left and right while moving around comes very naturally to us. We don't have much trouble finding the fridge or the couch, except maybe in the dark.

 

Jef Raskin, in his seminal "The Humane Interface" described a hospital information system which used a mouse with the two main buttons dedicated to ZOOM IN and ZOOM OUT. With the screen filled with a lot of information. To fit it on the screen some of it had to be written smaller, or even much, much smaller. To see the stuff written smaller, you go there and zoom in. What was really remarkable, in my mind, was that absolute novices were comfortable and competent with the system in less than a single minute of training. Even computer experts learned the system in less than two minutes.

 

Since that sounds wonderful, why change it? The zoom buttons are velocity based devices, like joysticks, as opposed to displacement based devices like computer mice. Thus you must pay close attention and stop pressing the button at just the right time so that the text there is the right size to read easily. How could that be improved? Make the zooming automatic and keyed to the size of the text in that location. Put a visible border around the stuff which is written smaller, and use roll-over, or mouse-over (moving the mouse pointer into that region) to trigger the zoom in. Make zoom out happen when you mouse out of the region.

 

The designer of such a zoom world would arrange that the parts of that world are easy to locate and identify. For instance, one might use captions below thumbnail images much the way there are signs identifying "Mens Clothes" in a deparment store, or "Condiments" in an aisle of a super market. Of course, the designer, (architect?), of such an arrangement should also see to it that there is enough space between these regions so that you can get to the one you want without "falling" into some other contained sub-space. It's not hard.

 

This idea must be verified by user testing. There will be many ways to implement such auto zooming worlds, but any one will likely suffice to see if such a system is as pleasing to use as I hope. My current candidate for a convenient system in which this can be built is Sun's Lively Kernel. Online videos of two talks about Lively Kernel are available as a Google talk and as a session of EE380 at Stanford. Can you find another convenient way to implement such a scheme?

 

Notice that the thumbnails amount to links but navigating among them is as simple as possible if one's hand is already on the mouse. We might also provide a way to navigate by keyboard. Suppose that each thumbnail had a one or two letter key, perhaps shown as semi-transparent large letters covering the thumbnail image. Then by using a meta-key, perhaps called LEAP, and possibly located below the space bar for convenient access by one's thumb, one might type the one or two letters thus moving the mouse cursor to the thumbnail and auto zooming into it. If one's hands were on the keyboard already, this would eliminate the 1.7 (?) second cost of moving a hand to the mouse.

 

===================================

 

<< Past here is an extended discussion with Nat Fast who is thinking about actually implementing a JustGo world. My comments are in italics. rhk, Nitpicker >>

 

<< For this first version I want to do as much as possible with only the mouse and no keys, buttons, or even mouse induced scrolling. If what I want to zoom into is bigger than the window at its natural, readable size, then bust it up and put the pieces in their own thumbnails. It's OK if that takes 57 pieces and four levels of zooming before you can see the actual content. >>

 

 

Navigation

 

<< All done by mouse-over with immediate auto-zooming. >>

 

Document Selection - TBD

 

Document Arrangement - TBD

 

Content Types and Related Behaviors

 

Content Addition - TBD

 

Content Editing - TBD

 

Navigation in the Zoomed Interface - Single document, multiple resolutions

 

The basic interface has three elements: a master background, document thumbnail and the arrow cursor.

 

  • Master Background is the highest level of the application. It is a static layer that provides positional cues to content management, allowing a zoom back for any document which is in focus.
  • Document Thumbnails are representations of content silos. On the master background they would represent entry points into various document domains. Since the master background does not scroll, the master domains would be limited to a top set of navigable icons that fit upon visible space. << Yes >>
  • Arrow Cursor is a users reference within the view and it's movement and placement initiate document behaviors. << Yes >> At times, the cursor is fixed and the document moves around relative to the center of the screen. << Hold that thought. We can try it if the other stuff sucks mud. >> At other times the cursor moves in a normal mouse interface fashion. These changes are dependent upon the relationship between the screen and the document resolution. << How far can we go before we absolutely need this? >>

 

 

 

 

When we first transit the border of the document thumbnail the related document zooms to the extent of the screen. In the above example it zooms to the height extent, keeping the rest of the document proportional. The document is fixed on the screen and the mouse moves normally against the document and interface. If the mouse were to move outside of the document, the page would zoom out and we would be back to the previous view.

 

<< OK. But you only showed a part of the three or four page long content. I'd like to see the whole thing, skinny, on the left, with six or eight thumbnail pieces on the right which will be at natural size and readable when zoomed into. They can be loosely stacked on the right so you can even mouse between them if you want. For even longer skinny documents, there could be a column of big pieces each containing a chunk of the whole and another column of smaller pieces to the right of each. This preserves the simplicity of the mouse motion meaning. >>

 

Located on the bottom of the document is a Zoom icon. This icon represents the next level of magnification for the document. When the mouse moves the arrow cursor into this icon, it will zoom to the next level of magnification.

 

 

The next level of zoom brings us to the next extent, or for this document it is the width. When we zoom to an extent that has the document overflow the master background the mouse behavior changes. Since we can see the edges of the right and left side of the document, the mouse moves normally right and left. If we were to transit across the right or left border of the document we would zoom back to the previous zoom extent.

 

However, since the document flows beyond the top and bottom edges of the master background, when we move the mouse vertically the page will scroll under the mouse; scroll down with downward mouse movement, scroll up with upward mouse movement. When we scroll to the extent in that direction, the document becomes fixed and the mouse moves normally against the screen in the directions of visible extent. In this case above the center of the screen, right and left. When the mouse moves the arrow down transiting to the vertical middle of the document view, then the cursor will stop moving down while the document will scroll underneath.

 

Attached to the extent that becomes is the zoom icon, if greater resolution is available for the document. Transiting into the icon will zoom to the next level.

 

<< I think we can avoid this complexity for now. Never any scrolling. >>

 

 

In this final view we have the document at full resolution. There are no more Zoom icons. The page appears initially at the upper left of the document. Two extents would be visible at the top and left of the document and the cursor would move to the right and up in a normal fashion. If the mouse moved down or to the right, when the center line in each direction was hit, the page would scroll in those relative directions. At this point it is possible to have none of the master background visible, if the resolution of the document is greater than the size of the master background. The user would have to scroll to an extent to be able to fix the document to allow for a transit to the master background and thus zoom out.

 

An option would be to have a right click option that has basic zoom and return type functionality to allow for navigation without visual transitions. This could also support moving the cursor to the menu bar or any other static command space, if required.

 

<< It looks both sensible and clever, but I hate the complexity to explain it. I first want to try with no scrolling and always having all four sides of the thumbnail frame still visible when zoomed in. Never lost. Always can see how to zoom out on every side. >>

Comments (0)

You don't have permission to comment on this page.