John E. Simpson wrote:
> "What would be some good visual metaphors for editing attributes?"
> Answering this would require figuring out how to characterize the
> relationship between elements and attributes. I'm not looking for a formal
> definition of the relationship necessarily; by the time someone starts
> hankering for a WYSIWYG interface, she's no longer got formal definitions
> at the top of the priority list (if she ever did). No, the question really
> is, when someone's holding a rough sort of element tree in his head and
> about to embark on "editing" it, what are attributes' roles in the tree?
> Leaf coloration? Is this getting too cute?
At this juncture, one could justifiably ask whether the notion of an
"attribute" as modeled in XML/SGML syntax is suitably close to the
average user's notion of an "attribute," or whether the XML/SGML
notion is just fundamentally broken. No question that it's very
difficult to design a user interface which supports editing hierarchical
"depth" and the semantic richness of text, as multidimensionally
conceived. No question that it puts a burden upon a user to grok
a certain artificial notion of serialization when the information in
the user's problem space is not intrinsically serialized, and especially,
in that [complex] attributes of complex objects *have* no inherant
serial order. If you add to that burden a certain lack of semantic
transparency (aka lack of correspondence between the user's
conceptual model of the real world objects and the model offered
by the editing interface, because complex attributes have to be
modeled *as elements* [no real choice here]). . . well, the problem
becomes even more difficult. If you expose the markup syntax to the
user at this point, it presents a conflict because it will not,
for any complex application, match the real world situation with
respect to objects and their (real) attributes.
In the judgment of many, the "attribute" problem becomes somewhat nasty
at just this point. Not that any design of a structure editor is
easy in any case.
In my work environment, the best thinkers have concluded that the
solution is task-driven tools that provide sensible interfaces to
objects on a per-class basis. That is: engineer as many common
UI constructs as possible, but expect that the editing tools for
individual objects will look pretty different, but will be intuitive
because they respect the user's view of the object at the conceptual
level. How these objects are used in the construction of a
(generic) "document" is a different matter. "Authors should create
information; programs should generate documents."
In this world, where the focus is upon the semantics of the
information, a markup representation in SGML/XML is just one
possible view of the information. Objects can be told how
to display themselves (recursively) in terms of markup models.
All told: it's about semantics, not syntax.
Just my 2 cents.
Robin Cover Email: [log in to unmask]
6634 Sarah Drive
Dallas, TX 75236 USA >>> The SGML/XML Web Page <<<
Tel: +1 (972) 296-1783 (h) http://www.sil.org/sgml/sgml.html
Tel: +1 (972) 708-7346 (w)
FAX: +1 (972) 708-7380