XML editor design indents XML without tabs/spaces - disadvantages?

Question

I've developed an XML text editor that indents XML using a 'floating' left-margin rather than the more common tab or space characters. Indentation is updated continuously and only relies on the XML context of new-line characters. The intended use for the tool is for XSLT editing and for XML vocabularies which tend to be hand-crafted and where whitespace management is critical (such as XMLSpec).

To make this tool work with XML from other sources, any XML file opened, or pasted from the clipboard, is first scanned for indent characters; these are then stripped before rendering the formatted XML.

After overcoming some significant early problems such as formatting of attributes, commented-out XML and a tendency for the XML to leap alarmingly across the screen, there do appear to be many benefits to this, in terms of readability, UI efficiency/ergonomics, processing, version-control etc.

However, if there are such benefits, I worry why all XML editors don't already do this.

So, in terms of usability of the tool and readability/usefulness of the XML produced, when characters used for indenting XML are removed; what are the potential issues and how should I mitigate them?

I've tested other XML editors with XML produced by this tool. They all succeed in reformatting the XML reasonably (except for attributes - which have more variable indentation conventions) by inserting padding characters.

The editor provides also an alternate view where the left-margin is collapsed, but no characters are affected. In the examples linked below, the highlighted element in each view shows the only place (highlighted area with no characters) where space characters were added by the author for indentation. This was required to indent a single line within a multi-line attribute value, so the XML-context was not sufficient.

XML Editor Screenshots: Comparing Indented and Non-Indented Views

[Edit] Some more points:

Text moving around the screen whilst the user typed presents some challenges (as already mentioned). However, using auto-completion of tags/attributes and delayed formatting helps. Also, there's already some movements of tags in more conventional editors, so this behavior won't be completely unexpected.

Attention has been paid to handling keyboard-shortcuts that have special affects on whitespace (like ctrl-backspace or tab) so that there are not too many surprises.

The editor works best with word-wrap on, but many users follow text editor conventions for maintaining a maximum line-length by inserting line-feeds. An optional feature removes such line-feeds but its recognised that this could cause as many problems as it solves.

The rationale behind auto-indenting XML tags found within comments is that blocks of XML may be commented/uncommented at will. CData blocks, though they may contain XML tags are treated as normal text; this is because the CData tags can't be removed without making the XML invalid. CData contents is colored differently from parsed text to avoid any confusion about indentation.

Indentation of XML within comments: Though automated this is independent of the 'real' XML indentation to avoid anything within comments affecting the formatting of the rest of the XML.

Pasting to other XML tools - Because there's no 'foreign' indentation for the editor to handle, this probably works better than when copying between 2 conventional tools.

Pasting to text-only tools (such as a wiki) - This presents a problem unless that tool recognises RTF.

An option for saving-with-whitespace could be provided, however, a redistributable/online 'reformatting tool' might provide more flexibility?

Just for info: This editor was initially released as part of a much larger XML processing system, however, to get more general feedback I've also now put out a simpler, lighter free version, XMLQuire. Given the number of day 1 downloads for this, I hope to be in a position to assess disadvantages direct from live user feedback fairly soon...

[update] Downloads of products using this system run at about 200 per week, so total downloads must exceed 10,000 by now. No users have yet complained of the whitespace handling, but just a handful have come back with complimentary feedback. It seems that for many this feature goes largely unnoticed.

Answer 1

You're bending normal editor conventions, so users will have to get used to not typing spaces/tabs and also to text jumping right when they complete a new opening tag and left on completing a closing tag. None of this seems in itself to be that big an obstacle. In effect you are running 'prettify' with each keypress, and so giving more responsive feedback. You can view it as being analogous to color syntax highlighting as you type. People had to adjust to that, but it's a net win.

The usability questions that come to my mind are in the gray area between UX questions and questions about the app's functionality.

• What about <!CDATA[]]>? Will the automatic indenting be turned off for that? Or optionally turned off? It could get a bit confusing mixing automating indenting and manual. That's not a problem with an app where all formatting is manual.
• The app works without indentation internally. Can I export/save with indentation if I want to? I might be wanting to use it with an editor that cannot automatically add indentation, or to cut and paste to a wiki.

Edit

Thanks for the update.

It is now sounding like the kind of thing where one can only make more useful and detailed comment by actually trying it out. A while back I wrote an 'instant assembler' that did all the syntax and type checking, macro expansion, code generation as you typed. Getting the responsiveness required was not easy, but in the end the main usability issues were not there. The usability issues were in the select text behavior not implementing all details of normal editor selection (dragging to extend causing window scrolling) - and that happened because I don't do that myself, and because I wasn't able to just extend a standard editor control.

So test, with one to three users and get their feedback. Problems are likely to be not in the area you are worrying about.

I would say you would be very safe to run with your idea. It looks as if you have the option that people who really want to use explicit spaces can do so, and your target market looks computer literate enough that they will find that option - if they happen to want to stick to the old way of doing it.

It sounds a nice idea. Good luck with it.

Answer 2

If you're actually removing indentation characters from the source, as opposed to just rendering as if they were not there, then you may be breaking interoperability with other editors. Someone who created a manually-formatted XML file in, say, emacs (or Notepad or whatever), and then used your editor with it, should not lose his ability to return to his original editor.