[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <marcs>
- Subject: Perverting Revert
- From: Bob Perez <bobp>
- Date: Fri, 22 Sep 89 17:09:06 PDT
- Cc: <heh>, <michael>, <ravi>, <tribble>, <us>
"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
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
"Undo reverses the effect of the previous operation." (IM, p59).
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
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.
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.