In the old days, computers worked
with words and numbers, which was fine if your business was
words and numbers.
Today, computers express themselves
in pictures, as well as words, which
makes them easier to understand, especially for visual thinkers.
But the picture isn't always perfect.
Sometimes there's something you need
to know that isn't visible on the screen.
What happens if I type backspace right now?
Take a moment to think about this one.
There are many possible right answers.
Here's the most likely answer.
Typing backspace deletes the return
at the end of the previous line, causing the two lines to join.
But maybe there are spaces at the end of the previous line,
or maybe there's a space at the beginning of the line,
or maybe the previous line is right-justified.
Or maybe nothing happens because this is not
a word, but a picture.
You can't tell by looking at the screen.
That's because the real picture is stored off-screen,
where you can't see it.
In this videotape, I'm going to show you Viewpoint,
a pixel editor I built at the Xerox Palo Alto Research
Center.
Viewpoint looks like an ordinary text and graphics editor.
You can type, and you can draw.
But there's a difference.
In Viewpoint, the pixels on the screen
are literally the state of the system.
The computer looks to the pixels on the screen
to figure out what's going on instead of referring
to some secret, invisible variable stored somewhere
in memory.
So what you see on the screen is not only what you get,
it's also what the computer gets.
I call this condition visibility.
Is visibility a good idea?
Is it practical?
The purpose of Viewpoint is not to answer these questions,
but to play with possibilities, to see
what would happen if we built an editor to be totally visible.
Before I demonstrate Viewpoint, I'd
like to introduce the equipment.
Viewpoint was programmed in the Cedar program environment
on a Dorado computer.
The Dorado includes a color screen,
a black and white screen, a keyboard,
and a three-button mouse.
Moving the mouse moves the cursor on the screen.
Notice, the colors are transparent.
That's so the cursor never hides what's underneath.
When I type a key, the corresponding key on the screen
lights up.
Different types of information appear in different colors.
The cursor and the key highlights are red.
The solid square, called the selection, is green.
And everything I draw or type is black.
The blue lines divide the screen into square cells.
Each cell is 10 pixels wide by 10 pixels high.
Now I'll explain what the three mouse buttons do.
Pressing the left mouse button turns the cell black.
If I move the cursor, I continue to draw black cells.
Notice that a black circle appears inside the left mouse
button to remember what color we're drawing in.
If I let up on the mouse button, the circle disappears.
If I move the cursor to a black cell
and press the left mouse button, I turn the cell white,
and a white circle appears inside the left mouse button.
If I move the cursor, I continue to draw white cells.
If I click on a cell that is partially black and partially
white, the rule is the cell turns black.
So a convenient way to turn, say, this cell white
is to click twice--
once to turn it black and once to turn it white.
Pressing the middle mouse button selects the cell at the cursor.
The selected cell turns green and appears magnified
in an area called the puff box.
Any cell can be selected, even a border cell.
Drawing inside the puff box changes
the pixels in the selection.
I'll move the selection so you can see their change.
Any cell can be redrawn, even a character on the keyboard.
Let's do a bit of font design and make
the C really, really bold.
Pressing the right mouse button copies the selected cell
to the cell at the cursor.
We can use copying to create an ocean
or to fix up broken lines.
Notice that copying is very much like drawing.
If we had a black and a white cell,
then we could always use copying instead of drawing.
So far, we've seen drawing, selecting, and copying.
Now, let's look at typing.
When you press a key, three things happen--
the key is highlighted on the screen,
the character inside the key is copied to the cursor,
and the cursor is moved one cell to the right.
Notice that the red flash happens in two parts.
I'll do that slower so you can see it.
The first part shows that the key just went down,
and the second part goes away when I lift my finger.
Backspace moves the cursor back.
If I type a space, it overwrites the previously-typed
characters.
Let's go back and finish our diagram.
What you see is what you get and--
I want to type here-- is what the computer gets.
So position the cursor.
Hold Shift.
Type I-S space W-H-A-T--
notice that I got a blank when I typed
an S. That's because the rule is that typing
copies the character that's on the keyboard right now.
And right now, the S is blank.
So back to typing.
T-H-- typing wraps to the next line when you hit a margin.
So C-O-- there's the bold C. Before I go on,
I'd like to show you something.
The rule is that word wrap happens when the cursor hits
a cell that isn't a character-- that is,
a cell that isn't on the keyboard right now.
That means that every time you type a letter,
the system scans the entire keyboard
to see if the current cell is a character.
So if we copy, say, this cell onto the keyboard,
we change the behavior of word wrap.
So back to typing.
E-R space G-E-T-S-- went right through the border,
because the border is now a character.
Here's another experiment.
First, I'll copy the processor's nose onto the keyboard.
And, of course, these are characters you can type.
See shift 9 and shift 0.
OK, now I'm going to type processor
gets instead of computer gets.
Well, actually, there isn't any S here.
So I'll copy this S to here.
And while I'm at it, I might as well fill in this S. OK,
so P-R-O-C-E-S-S-O-R space G-E-T-S.
So you see what happened?
I'll do it again, just the last part.
Type G-E-- now, when the T encounters this S, it's-- well,
the S isn't on the keyboard.
So it says, well, that's not a character.
So it wraps to the next line.
It erases these characters, and then it
searches back for the beginning of the next line.
And the way that works is looks back character
by character for the first non-character.
Well, these are all characters.
Those are characters.
So the first non-character is here.
And it goes down one line and searches right
until it finds a character.
And the first one it finds is here, the blank.
It types what was erased from the previous line.
And then we add an S here.
Oh, and since we don't actually have an S,
I'll finish this off by copying this.
There.
You may have wondered about this flickering triangle.
There are two separate programs that take
turns acting on the screen--
the user program and the processor program.
First, the user program reads the keyboard and the mouse
and writes the red cursor in the key highlights.
All user input is colored red.
When the user program is done, it
redraws the interlock in front of the processor.
The processor then sees the interlock in front of its name,
wakes up, locates the red cursor and the key highlights,
and takes the appropriate action.
For instance, if you had pressed an A,
the processor would see the red highlight around the A and type
in A. The interlock goes back and forth so fast,
you really don't see it in this tape.
So the purpose of the interlock is
to coordinate two programs that talk to each other solely
through the screen.
Now that you've seen how Viewpoint works,
I'd like to show you how I drew this picture the first time.
So I started with a blank screen and had to use Viewpoint
to build itself.
I call this process the visual boot.
The only objects on the screen were the interlock,
the selection, and the cursor.
The hot areas inside the puff box and the keys
are still there, but you can't see them.
So let's draw a cell and select it,
revealing the location of the puff box.
I'll mark the corners so that we know where it is.
And remember that the puff box has a border,
so I will erase this corner and select it and now
draw in the border.
When I didn't have copying, this was really painful.
Now it's just moderately painful.
Let's see.
Oops.
OK, next, I want to draw the A key.
So hold down the A to find where it is.
And I'm going to draw the border of the key,
so I select that corner of the puff box and copy it to here.
Now that I've got part of the A border, I drawn in the rest.
After you've used Viewpoint a while,
you learn to look at images as collections
of tiles that can be copied to make other pictures.
OK.
Select the location where the A would go,
and draw ourselves a lower case A.
Now that we've gotten A, we can type it.
You could even type it inside the key itself.
In fact, if we select that one and change it a bit,
we can see that we now have two different forms of the letter
A. By continuing to build up keys this way,
I drew the entire keyboard.
In this tape, we have seen viewpoint, a strictly visible
text and graphics editor.
Now that we know that strict visibility is possible,
we may ask, what other systems can be made visible?
How does visibility constrain program organization?
And how does it affect user interface design?
Ultimately, though, the point of Viewpoint
is not text, graphics, editing, or even visibility.
Viewpoint challenges a deep belief in computer science
that the pixels on the screen are mere shadows of real data
structures.
Only by treating the screen itself as a first-class citizen
will we be able to build computers that
are truly for visual thinkers.