If you have worked with a web content management system, such as WordPress, you have likely seen a rich text editor, or a WYSIWYG html editor (“What You See Is What You Get”). These rich text editors offer a convenient way to add additional text formatting, but they are also responsible for a lot of badly formatted content and code. Changing the font size of a text is particularly discerning because what seems alright to the user may not look correct on another screen size or device. In this case, “What You See Is” not necessarily “What You Get”.

As an all-time advocate for structured information, we at Hubnest, strive to build web pages that synthesize content from meta data, or “pure information”. Ideally, the content editor should provide just the mere text. For example, a paragraph for a product description; an intro to an event. These texts are then displayed in pre-defined, carefully styled containers.

Therefore, rich text editing is the opposite of structured content. The content administrator may inject arbitrary HTML code either through direct code editing or by using a WYSIWYG editor.

Lack of code control and compliance with a WYSIWYG html editor introduce potential risks to designers and developers. Meanwhile, for a non-technical user, a WYSIWYG editor is quite limiting. Once the basic formatting options are exhausted, the user quickly resort to direct HTML editing, which defeats the premise of a WYSIWYG editor and potentially affects the integrity of the site.

We tackled the issue of semantic free-text editing by first looking at the “language” that’s used between the user and the editor. Phrases in this language are expressed as buttons in the editor’s toolbar, namely “bold”, “italic”, “underline”, “color”, “background color”, “insert image”, “block quote”, “indent”, “bullet”, “font family”, “font size”, etc. It turns out that as developers, not only do we not want the end-users to write arbitrary HTML code, we also don’t want them to think in these terms when editing the content.

In order to fix this problem for several clients, we replaced the existing style formatting buttons (which are visual concepts that are not tied to a specific presentation) with buttons for “headlines”, “2 columns” and “side columns”.

To make editing the column layout easier, we created guide lines so that it’s clear to the user which section is being edited. These guide lines are not visible on the live site.

It’s our job to ensure that the website functions as designed, while giving the users an ability to create meaningful content. A list of Q&As is a good example where the user can create Q&A section using a rich text editor in a strictly paired format.

The containers are color coded so that it’s easy to edit but on-the-web (front end) styling can be completely different although it uses the same styling markups.

Structured, Data Driven Content

The next example is taken from Massachusetts Bay transportation Authority. In an ideal setup, the page should be driven by a structured database, with information about all the projects such as their location, budget and description.

With a project data source, we could use a shortcode/plugin approach by simply referencing the data object. Note that even in this case, the title of the listing can be modified by the WYSIWYG editor:

Unstructured Text

What if the listing is just an unstructured text that appears to be structured? In this case we built two tools: one for creating a project group container; and one for inserting project items. The project hierarchy is expressed by indentation and colour-coded background.

At this point, we have steered the user to a more manageable mindset. Two concepts should have been established by now:

• Web content has structure, even if it’s not data driven.
• Text editors should be used as if inserting text into a PowerPoint template

Contextual Templates

Semantic templates can significantly simplify content management. Templates can be created for all sorts of layouts and content structures. For example, product ratings, review quotes, featured sales, sales blurbs; and the list goes on. The editor’s tool bar will soon run out of space for these buttons. What do we do then?

One of the key reasons we haven’t seen a reasonable WYSIWYG editor is because they create a a general-purpose editing tool. The only way an editor can be generic is to be out of context, while structured presentation of content requires context. For this reason when we incorporate CMS systems for our clients, each WYSIWYG html editor is already in the context of its related design. For example, the editor for an event entry may have templates for maps, locations, catering menus; and the editor for a staff member’s bio may contain an achievement listing template.

In conclusion

Be careful when using generic WYSIWYG HTML editors. Instead create content editors for specific information within the structured context as it will maintain integrity of the visual designs and functionality.