Re: WHAT MOVES ON SCREEN?

[mpriestley -at- VNET -dot- IBM -dot- COM]

Warning: long append

Rod Hester writes:
>> Intuition (and working with hypertext) leads me to believe the data
>> moves, not the window.  However, it probably depends on the program and
>> the programmer's mental state at the time ;-).

and Matt Hicks replies:
>My take on this is that neither the data nor the window "moves". A
>graphical representation of the data is redisplayed at a number of
...
>I think this topic is amusing and interesting as a kind of mind expansion
>exercise, but ultimately it's just mental masturbation.

Bzzzt!  Wrong, Hans!

Sorry, but I'll have to agree with Ron on this one.  I think the problem
is that you are addressing the problem on different levels (I just agree
with Ron's level :-).  On a "phenomenal" level, sure, nothing moves,
everything is just redrawing pixels (well the electron gun moves).  On
a conceptual level though, software can clearly support one mental model
or another.  Two examples:

1) Standard word processor vertical scroll bar:
The length of the scroll bar represents the length of the document.
The "thumb" represents your current window's position relative to the
document (if the doc is large and you are viewing the top of it, the "thumb"
is small and at the top of the scroll bar).  The arrow buttons move the
thumb up and down: moving the _window_ relative to the _data_.
Selecting "up" displays info towards the _top_ of the doc; "down" displays
info towards the bottom.

If the data were moving instead of the window, then selecting "up" should
move the data up, thus displaying info towards the bottom of the doc.
Hold down the "down" button, and you would eventually reach the top of
the doc.


2) The OS/2 spin button (could be true of other controls, I know OS/2):
A button that scrolls through a list of values.  Selecting "up" displays
higher values, selecting "down" displays lower values.  Fine, except that
most people order numbers from top to bottom:



etc.  and thus could reasonably expect for "up" to display lower values.
As a matter of fact, the spin button has been a very problematic control,
with about half the users expecting to get a higher-"value" number (which
they get), and half expecting a higher-"position" number (and being
confused when they don't get).

In a nutshell: for wordprocessors, the window moves but the data stands still.
For spin buttons, the data moves but the window stands still.

In conclusion, I don't think this is mental masturbation, but a matter of
seeing clearly what metaphors the software is supporting.  Matt isn't
really wrong, in his assessment, but I think that looking at it from
a more conceptual level (albeit a less phenomenologically exact one) does
actually give some results that justify the effort.  I think it was poor
thinking, on this level, that resulted in the spin button.  It broke a
powerful (even if unconscious) conceptual model that 50% of the users held.
Luckily, OS/2 rarely uses spin buttons these days, and they're mostly a
hold over from previous releases.

I will agree with the "mind expansion" assessment, though - thanks for
continuing the discussion.

My apologies for being so long-winded,

Michael Priestley
mpriestley -at- vnet -dot- ibm -dot- com
Disclaimer: I'm speaking on my behalf, not IBM's.