[
Lists Home |
Date Index |
Thread Index
]
I'm also an xml-editor developer.
Our customers definitely don't want to see tags or concern themselves
with validation. They need to be convinced of the merits of structured
authoring. They want their authoring environments to be as Word-like as
possible (that's what we're competing against) and we go to great
efforts to make that possible, while keeping style and formating away
from the markup.
It takes a while to get users used to structured authoring - they are
used to be able to do whatever they want, wherever they want. Once we
can get them over the 'hump' and can sell the merits of capturing
information rather than style, they generally see the light.
We are constantly grappling with the over-markup issue. Adopting a
philosphy that if you're not sure whether something should be marked up
or not - mark it up, makes a lot of sense to me. The only way we can
convince skeptics of the merits of storing their precious data in XML is
to demonstrate to them sexy things that can be achieved that are either
not possible or extremely difficult with non-structured information. We
also need to keep in mind that the lazy author will err on the side of
not marking up information - it's usually better to provide containers
as cues for what content is worth capturing.
I've played with an Office 11 beta and basically it's similar to an
early version of XMetal. Lots of tags, a tree view and an attribute
picker. I'm very glad that Microsoft has gone with XML output/editing as
it shows our users that structured authoring is the right direction to
be heading in - even Word supports it!
Simon St.Laurent wrote:
> ricko@allette.com.au (Rick Jelliffe) writes:
>
>>>"Fortunately, it turned out that when developers are
>>>happy, they write lots of software, and that ends up making users
>>>happy as well."
>>
>>That there is a lot of potential software I would not dispute.
>
>
> You've certainly done your best to realize that potential through your
> work at Topologi. If everyone on xml-dev was writing editors....
>
> In particular, I think this (later) comment gets a lot right:
>
>>I think the killer is the idea that you should do text entry
>>(authoring) and markup all at the same time (rather than, say, text
>>entry with just enough markup to help your writing flow rather than
>>distract you). That just overloads people.
>
>
> This is an important insight, and it marks a boundary between different
> ways of looking at markup. A lot of developers see XML editing as
> filling structured containers with appropriate content, and the
> containers should more or less guide you as to the content. This can
> mean that a huge amount of detail needs to be dealt with at one pass,
> and it often has meant that developers create interfaces which are
> actually more difficult to use than paper forms. Leaving markup for
> later lets people focus on the information as they see it rather than
> forcing them from the outset into someone else's preferred boxes.
>
> I worry that too much of "XML development" has focused on approaches
> that are convenient for computers and programmers and not nearly enough
> has focused on how people want to work. Tree-based interfaces and
> expectations that authors _want_ to work with metadata both seem oddly
> disconnected.
>
> About the most I've been able to get non-XML people to do consistently -
> and not always consistently at that - is to apply Word styles to
> content. Even there, they almost always get paragraph-level styling
> right and leave out lots of character-level styling. I guess we'll get
> to see how easy Word's upcoming XML features prove for ordinary users.
>
>
>>And certainly not to slag off at XForms.
>
>
> I'm not sure why the HTML world's effort to provide decent interfaces
> that never really evolved on the XML side is worth slagging. Strange.
> XDocs/InfoPath was worth looking at during XML 2003, and I guess we'll
> see where all these ideas lead in the next year or two.
>
|
