Re: XML Tree View: Guidelines and ideas

Probably different designs are more appropriate to different usages. 
For example, having written a book in XML (not on, *in* XML - DocBook), 
I would have deeply appreciated a sort of "master-detail view" with one 
or more layers to it, i.e.

View:   [x]book       [ ]chapter       [ ]section
----------------------------------------------------
Chap. 1   | <title>Chapter 3.</title>
Chap. 2   | <para>If you've read this far, you've gotten
(Chap. 3) | through the boring introductory chapters!</para>
Chap. 4   |
Chap. 5   | <para>In this chapter you will learn how to write a
Chap. 6   | module that lets NetBeans do your dishes.  First,
Chap. 7   | take the lampshade off your head - you won't be
Chap. 8   | needing it for this chapter...

(I still have some fantasies of doing such a UI for Jesse's DocBook 
module sometime in the distant future).

On the other hand, I imagine such a UI, though it could be generic, 
doesn't lend itself at all to other usages, particularly XML documents 
which don't contain many or any CDATA sections.  The meta-point here is 
that when appropriate, decomposing a tree into a set of lists can be 
helpful - trees just don't make for great UI for a lot of things - high 
faithfulness to the structure of the data tends to come at the expense 
of usability (which is usually about either filtering out noise [data 
not relevant to the task at hand] or reducing the number of gestures 
required to navigate).  It depends on what you're trying to do.


Good filtering is pretty important to separate actually interesting info 
from uninteresting info.

To play devil's advocate for a minute, what exactly do you get from a 
tree view that you don't get from opening the XML file in a text editor? 
(okay, composing in entity includes and such is obvious).  It's an 
important question.  Inside the answer is the kernel of what problem an 
XML tree view is supposed to solve - a fully detailed XML tree view is 
essentially a pretty-printer.


Probably the main problem in doing an XML tree editor is scalability, 
though.  One of the reasons the old XML tree editor away was, for 
example, opening the NetBeans book's DocBook XML took 25 minutes on a 
fast machine...

That said, there's nothing wrong with an XML editor that's useful for 
small documents, but refuses to open a huge one - as long as it fails 
quickly and gracefully and communicates what's going on.  Despite claims 
to the contrary, 0, 1 and n are not necessarily the only numbers in the 
universe...

-Tim

Hutchison, Ben wrote:

> An XML Tree-view is requested in issue: 
> http://xml.netbeans.org/issues/show_bug.cgi?id=14206
> 
> I think this is a big piece of functionality and it should be approached 
> carefully. XML is become so widespread for Java that good XML 
> view/editing will make a big improvement for IDE users, but I think its 
> also easy to design an XML tree view of very limited usefulness.
> 
> 1. For me the biggest single reason for wanting a tree view is to get a 
> condensed, data-oriented way to work with XML. I dont want to see or 
> type end-tags, and I want as little on the screen except the data 
> content of the document.
> 
> 2. Easy editing is as important as viewing. Common actions, like 
> move-current-focus, add-element, edit element, add-attribute, 
> edit-attribute, move element, need to be simple and intutive for both 
> mouse and (especially) keyboard users.
> 
> 3. When using a tree view, care must be taken not to make the tree 
> consume too much screen space. Some XML tree designs use fixed, 
> widely-spaced node-arrangements, indent and line height settings. These 
> can leave large amounts of screen as useless whitespace, and  tend to 
> flow off to the right and bottom of the screen for a large document. 
> Example of this problem see screenshots at: 
> http://www.xmlmind.com/xmleditor/detailed_features.html
> 
> Some ideas:
> * Display Attributes stacked after an element on same line, rather than 
> under or 1 per line.
> * Use a small indent (ie 2 chars) by default for nesting
> * Allow user defined spacing/fonts, just like setting a text editor font 
> size.
> 
> 4. The best XML editor I have yet seen is XMLSpy. May I encourage the 
> developers working on XML support to download an evaluation copy and 
> look at the different ways it presents XML, and innovations like the 
> Table View, for editing a repetitive rectangular schema. They have done 
> alot of smart thinking that we can learn from. Eg 
> :http://www.altova.com/features_views.html#enhanced_grid
> 
> 5. By default, a tree view should be fully expanded, which mirrors the 
> way a default text/code view is the whole document.
> 
> 6. For easy attribute navigation, creation & editing:
> * Show attributes that are allowed by not defined greyed-out at the end 
> of the row.
> * The user can hop focus between atts using Ctl-Left/Right, including 
> the greyed out one.
> * If they start typing when a greyed out one has focus, the attribute is 
> automatically defined with the entered text as its value.
> 
> * For existing attributes, ensure the value is auto-selected when the 
> node gets focus, so its can be replaced simply by typing.
> 
> Regards
> Ben
> 
> www.sensis.com.au
> 
> A leading Australian advertising, information 
> and directories business. 
> 
> www.yellowpages.com.au
> www.whitepages.com.au
> www.citysearch.com.au
> www.whereis.com.au
> www.telstra.com.au
> 
> This email and any attachments are intended only for the use of the recipient and may be confidential and/or legally privileged.
> Sensis Pty Ltd disclaims liability for any errors, omissions, viruses, loss and/or damage arising from using, opening or transmitting this email.
> If you are not the intended recipient you must not use, interfere with, disclose, copy or retain this email and you should notify the sender immediately by return email or by contacting Sensis Pty Ltd by telephone on [+61 3 9201 4888]
>