gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: revision control for documents (was plug-in foo


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: revision control for documents (was plug-in foo)
Date: Tue, 23 Dec 2003 11:56:54 -0800 (PST)

    > From: Thomas Zander <address@hidden>

    > The point being; if you are lying to the user [...] your
    > application should be upgraded to user expectations.


Want a pony with that?   What if your user interface has led users to
expect a square circle or a blue sound?   How are you going to upgrade
to _that_?

The point of they lying metaphor is that there are two logical models
of what an application does and is capable of:  there's the model
based in the data structures and algorithms of the code and then
there's a model induced in the user's brain by the suggestions of the
user interface.

One has to make those two models (the code model and the user's
conceptual model) isomorphic.   Beyond that, one has to make sure that
the user's required conceptual model is one that user's can actually
wrap their heads around.

In the case of OpenOffice documents and merging:

OpenOffice from a user's perspective tries to treat the XML format of
documents as a mere implementation detail --- it's not part of the
user's conceptual model.   At most it's a bullet point on the sales
brochure: "Uses the industry standard, XML, to store documents!"

Using a generic XML-diff/patch tool on those formats necessarily
confronts the user with what was formerly a behind-the-scene
implementation detail.  You can try to paper over that (lie) all you
like with "widgets" and "style sheets" for diffs but fundamentally,
you're confronting the user with a huge expansion of his required
conceptual model about what these documents are -- precisely because a
generic XML-diff/patch tool necessarily produces output which can
_only_ be explained in terms of a detailed understanding of the
underying XML representation.

My point in mentioning stone-age tools like troff is that they gave a
pretty clear conceptual model of "what documents are".  Within that
conceptual model, the idiosyncrasies of textual diff/patch are not
much of a surprise -- non-programmer users who grok the troff family
can cope with them.

Somewhere around the time of the original Macintosh, the idea that
rather than _hiding_ markup languages from users we might _explain_
them to users fell out of fashion.  Not for any good reason, mind you:
the mac was far less capable a tool and experience had begun to be
accumulated that non-programmer users could grok mark-up just fine.
Nevertheless, in the decades since, the effort has primarily been to
"protect" users from a good understanding of what the heck they're
doing and the enhanced capabilities that would result from that
understanding.

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]