One of our customers asked us recently about best practices on how to configure Xopus to improve the user experience for their users. There are quite a few ways to enhance the editing experience in Xopus, so here's a guide on how to use them and make working with Xopus a delight.

In this first post we are taking a birds-eye view on what you could do to improve the editing experience. In future blogposts we will be looking at some of these in more detail.

Styling and visual design

The look and feel of any application has a big impact on the user experience. If something looks good, it generally is more pleasurable to work with. For an editor like Xopus, the document itself takes up the biggest part of the screen. So the visual design of your documents is very important for the overall look and feel.
The minimal thing to do here is to align the display in the editor with the most common final output. If that output is html you could match the target styles completely, or even reuse the stylesheets. If your users see a pdf or print version of the content as the leading output there might be things you cannot do in the editor, for example pagination. But matching fonts, sizing and colors will already give a familiar feeling to the editor. Also consider increasing the left and right margins and setting a maximum width for the document display. Too wide lines of text are harder to read, and because of that also harder to edit.

Show structure

If you want your users to create documents in the correct structure, they need to be able to understand the structure. This by no means has to be showing the underlying XML structure, there are more friendly ways of doing this as well. Which way to use depends on both the targeted users and the type of content.


The most common way to show structure is to change the formatting. Everyone will understand that text that is displayed in a larger bold font is a title, since this is something we learn by reading books and seeing this being used all around us. This works well for all things that are common and easily recognized, like titles, lists and so on. Other elements, for example sections like Prerequisites and Context in DITA tasks, are not as easy to recognize from their styling alone. In those cases the styling is not conveying enough information about the structure and you will need to use other ways as well.


When an element is empty, placeholders can give more information about the type of content that is expected in this element. This will show for example the element name in grey text, and allows the user to click on that text and start entering content. But as soon as the user starts typing, the placeholder will disappear, and the information about the structure is not visible anymore. This makes it a good tool in addition to other clues for the user, but should not be used as the only way to show structure.
Read more about using placeholders in Xopus.


Where styling works well for common structures known from for example Word, labels are crucial to give more information about what content is expected for less common elements. Examples here are metadata elements, but also sections with special meaning like Prerequisites and Context in DITA tasks. By showing labels for these elements, you can offer a form-like interface, which works well for these type of elements, where formatting alone is not enough to make them clearly identifiable. By using a form metaphor, you make working with these less familiar elements easier by using a familiar interaction pattern.
This is a step away from WYSIWYG, but this is not a bad thing. Better keep the good parts (easy recognition by using familiar styling), and throw away the bad (not enough clarity on document structure). In many situations there are also multiple output targets, resulting in people coining terms like WYSIOO (What You See Is One Option), and realizing that trying to be 100% correct is not the right goal.

Tags-on view

This is a more generic way of showing structure, while keeping the styles of the normal document view in place. While this is a great way of looking at the document for certain users, it is not the most friendly display for people who are not used to this. This should be used in addition to the other methods of showing structure written above, and should not be a replacement for them.
The Xopus tags-on view can also be configured to show tags for only some elements, so you can also choose for a hybrid solution where well-known elements do not have their tag shown, but lesser known and harder to recognize elements do.
Read more about using the tags-on view in Xopus.

XML view

This is the most direct view on the document structure, but because of the uniform styling of the data not the easiest to work with and recognize the different elements. If the display stylesheets are written correctly, your users should not have to use this.

Do not start with an empty document

Many of the XML Schema's we see being used with Xopus allow a document that can be completely empty. Xopus will only add elements automatically when the schema requires those elements. So if your schema doesn't require any content, give your users a head start by setting templates. This applies to the entire document structure, where the solution is to load files with already some structure in them when loading them into Xopus. But this also applies on a smaller level, where you can configure templates to tell Xopus what child elements to insert when a user inserts an element.
Read more about using templates in Xopus.

Tweak the default UI

The Xopus UI offers generic ways of interacting with the structure, based on the XML Schema loaded into the editor. In practice it seems to happen often that the XML Schema offers more possibilities than what you want to expose to your end users. So hide the elements that you do not expect your users to add to the document (if they happen to be there it'll still work), and if the list of possible elements is too big, divide it up into multiple groups.
Read more about hiding elements/read more about dividing elements into groups.

Add accelerators for often used actions

Last but not least, take a look at what editing operations your end users need to do most. Do they often need to add new sections to a document? Consider adding a button right there between the existing sections to add a new one. The generic schema-based UI is effective for accomplishing most tasks, but with a little more knowledge on what matters most to your users you can greatly speed up their tasks by adding additional tools.
Read more about using the Xopus API from the XSLT.

These are some important things to consider to get the most out of Xopus. Stay tuned for future blog posts where we will discuss some of the items discussed here in more detail.
Do you have more tips for your fellow Xopus developers? Let us know in the comments below! And if you need any assistance in implementing any of those tips, feel free to ask for advice on the forum.