Perverting Revert

[Bob Perez <bobp>]

"Of course, as anyone at Xanadu can tell, my traditional mental 
model is just not sophisticated enough. But part of the desire 
is to avoid repairing millions of mental models this first time 
out."

Exactly. The very discussion underway provides the best example 
of the danger we're courting. If *we* are having trouble parsing 
the Revert path, etc. Simplification does not necessarily imply 
reduction -- extra verbs that serve a purpose are far better 
than overloading existing verbs beyond recognition. 

[An aside: I'm not sure how much of this capability has to make 
its way into InfoFactory 1.0. What Xanadu/InfoFactory will provide 
in its simplest form is so self-evidently valuable, so monumentally 
unique, there's really no need to jump up and down, beating our 
chests in a feature frenzy.]

I'm very disturbed by the notions of "Revert Forward", "Revert 
Backward", or "UnRevert",though I understand the value of these 
capabilities and the complexity inherent in trying to represent 
them. I guess what bothers me are 2 things:

1) We're trying too hard to shoe-horn into an existing framework 
capabilities that were never contemplated. For an example of 
how ugly this can get, take a look at QUED's multiple Cut & Paste 
operations. I fear we're about to set new standards for editing 
complexity with the unfortunate "X..vert" progression.

2) According to Inside Macintosh (I-57), "'Revert to Saved' returns 
the active document to the state it was in the last time it was 
saved". This is not IM dicta -- this notion has assumed the force 
of law within the Macintosh community. In the Macintosh universe, 
"Revert" means to restore the document to the condition it was 
in the last time it was saved, or at the time it was opened if 
it had not yet been saved during the active session. Any deviation 
from this important norm will guarantee savage and brutal treatment 
by most of the reviewers and opinion makers of interest to us. 
More importantly, our users will resent it because it's not what 
they expect.

"Undo reverses the effect of the previous operation." (IM, p59). 
Period.

To most users, the combined effect of these understandings is 
necessarily dichotomous. That is, they either have their document 
the way it was at the last Save (or Open), or they have it as 
it exists after all modifications since that point. "Revert" 
takes them back to the last Save (Open), and a subsequent "Undo" 
returns them to the pre-"Revert" state. There is no room within 
the current framework for gradations between these two states.

If we wish to provide our users with the ability to visit and 
revisit fine gradations, then we need to present a new interface 
model rather than try and stretch the existing model beyond its 
limits.

I'm not sure what the answer is. Perhaps an additional set of 
items in the Edit menu (below a dotted line) that reflects the 
ability to Trace Forward/Backward. Anyway, I'm much more receptive 
to this kind of thing.

-- bobp

PS. Another point occurs to me: by adding a separate set of
editing commands, we call out the fact that our application offers
advanced editing capabilities, above and beyond those provided 
by the simple Revert/Undo model. Burying these abilities within
the existing edit model obscures them.