Building an organization-specific XML editor in HTML

Question

I'm building a user friendly XML editor in HTML/JS.

Looking for some general advice on how to build the editor UI and which approach you'd recommend on mapping the data to the UI.

Details about the problem:

Basically I'll fetch a single object as XML from a sever. The XML objects in question will be a small set of organization-specific XML which can only be structured in a few different ways. (Overall there are only about 15 different types of nodes available.) So I'll know all kinds of nodes that can appear, so I know which kind of UI to create for each type of node.

Basically, all classes have the same root node (Item). The 1st child node of that class can be a single List, Table, Person or Building node. After that, there are usually about 4 levels of multiple child-nodes, of varying structures. For example:

• A Person containing a List of Addresses, where each Address node has two properties; an id and a type="personal address". Anywhere inside the text of each Address there can also be a reference, a kind of internal link to an id in the system.
• A Table consists of Header, Footer and a Body with and an optional number of rows and cells

The use case is the following:

The user will always start by loading an existing XML item into the editor. The user is allowed to edit existing values, remove them, and add new values. (Since all items have the same kind of root node, the user will have access to add pretty much any kind of node they want.) When they are done they hit 'Save' and the editor closes, and a view mode (already completed) shows the saved item.

---

I have 2 ideas for the editor UI:

• A sort of Markup-editor in the style of StackExchange (a single text field with simple markup tags)
• A HTML form where you render each node as one or more input fields, and use buttons to move/add/delete the fields. I'd render Tables as HTML tables, and Lists as an unordered list with every list item containing multiple input fields (one input field for each Address and one dropdown for the type, and stash the id in a data-id parameter).

Which of these UI approaches would you recommend? (Feel free to ask more questions about the XML.)

How would you recommend mapping the data to the UI? Would you keep all the data inside the HTML during editing and then parsing it back to XML when the user saves his work. Or store the data as a JavaScript object, work directly with the JS object and just update the UI based on the JS object? Perhaps using some MV* framework with 2-way-binding? (I suppose that method would only be considered if I built the UI as a Form.) Or would it always be easier to traverse the XML node-by-node and generate UI elements based on that?

Answer 1

In general, I'd expect a good graphical editor to be easier to use and a markup editor to be easier to implement and potentially more powerful, but this is really hard to answer in the general case:

• What is your team's skill set? A StackExchange-style markup editor would probably be easier to implement. An MV* framework has more of a learning curve. (I don't have enough experience with JavaScript MV* frameworks myself to give much of an opinion there.) Etc.
• How technically skilled are your users? To stereotype, I'd expect more technical users to be more willing to edit markup (and might even prefer to), while less technical users would be more comfortable with a graphical approach.
• How many resources do you have? For example, even though StackExchange has you type Markdown, they also have a very nifty live preview. However, your team may not have the resources that StackExchange does.
• Have you talked to your users? The answer to the question, "Which is the better UI?", is almost always, "Get some feedback from actual users." Developers' intuition about what makes a good UI is notoriously bad. Do a prototype (use paper prototypes if you don't want to build one on the computer), do some hallway usability testing, whatever it takes to get actual feedback from actual users.

Regarding how to implement the mapping of data to UI, any of the approaches that you've described should work. It depends on what your team's comfortable with, how you all prefer to work, and what frameworks or libraries you're using.