Earlier this summer I attended Wikimania, the annual conference of the Wikipedia community, and went to a session demonstrating a new interface for editing Wikipedia pages.
Editing Wikipedia needs to be more intuitive, the speaker pointed out in his presentation. Currently, when editing pages on Wikipedia (which anyone can do), you need to use what’s called wikicode, a complicated markup that can seem baffling to new users. For example, text is made italic by enclosing it in double apostrophes, hyperlinks are enclosed in double brackets, and headings are enclosed in multiple equals sign symbols.
So of course it should be more intuitive.
But next the presenter told us, “The interface should be more like a word processor.”
Wait. No, it shouldn’t.
Actually, not even word processors should be like word processors. Much less all the websites with content editing interfaces.
I mean, can’t we get past the point where the entire web has to be modeled on what things were like before we had the web?
The first word processors weren’t computer software, they were stand-alone, glorified electric typewriters. Their main feature was that they had a little bit of memory to store documents, so that you could make changes and reprint your document without having to retype everything. That was an incredible productivity advancement.
When personal computers started to become popular, creating text documents was naturally a primary use of the machines. Early text editing software evolved into word processing and desktop publishing.
The first word processor I used was geoWrite, which was part of the GEOS operating system, bundled with Commodore computers in the late 1980s. It was very exciting to be able to choose different typefaces, change the size and color of text, and do all sorts of other amazing things to make my document look interesting. But the web had not yet been invented, so pretty much every word I typed was meant to end up on paper.
Concentrating on visual presentation made sense when word processing meant producing documents to be printed. Word processors then, and now, use a what-you-see-is-what-you-get (WYSIWYG) interface, which, as implied by the name, means that what you see on your screen is (in theory) exactly what your printed document will look like.
But these days, content produced in word processing software is much more likely to be consumed on a screen, not on paper.
We need to stop using “word processors” to produce print-ready text that’s actually meant for the screen. We assume our documents will look the same on everybody’s computer, but they won’t. We can control our own printers, but we can’t control everybody else’s computer or display. Even when using the same software on a different computer, sizes and colors may be very different. Viewing a document in different software may mean even more radical changes to the intended formatting.
So instead of print-ready text, we should have tools that encourage us to produce screen-ready text by default. By screen-ready, I mean text that may not look the same across software or devices, but that will be displayed so that it’s interpreted in the same way by the person reading it, regardless of software or device.
If you work on websites, you already know about semantic markup. Headings are marked up with <h1> to <h6> tags; <p> for paragraphs; <ol>, <ul>, and <li> for ordered and unordered lists. This is called “semantic” markup because the markup conveys meaning about the text, rather than defining the presentation of the text.
Some word processors do give you the ability to assign semantic information to sections of text. For example, Microsoft Word’s styles functionality gives you the option to use heading levels and other defined styles, so you can carry consistent formatting throughout your document and more easily transfer styled content to other editing tools or formats.
But almost nobody uses the styles feature in Word. If you have a heading, you’re probably just going to make the font larger and bold. Because it’s easier. This looks nice, but adds no structure to the document. So when you transfer your content to another editing tool, it doesn’t know you meant that text to be a heading. You may lose your visual formatting, or your formatting may even turn into something weird that you hadn’t intended.
So instead, imagine that your content editing tool, whatever it is, produces semantic content by default as part of your editing process, and that your content can be easily migrated to any other editing tool while retaining the document structure.
Ideally, as you write and edit, you wouldn’t see font formatting options at all. You would see style choices, such as heading levels, paragraph text, or list items. You would have the ability to globally change the visual formatting of text, such as typeface, size, or color, but underneath the visual changes, your semantic content would remain intact.
Since much of the content produced in offline word processors ends up on the web, this will allow anyone, regardless of knowledge/skills, to produce content that could be easily converted to appropriate, semantic HTML. Your content could also be easily viewed or edited in different content editing tools. And having semantic content on web pages and in electronic documents makes it much easier for users who are blind or visually impaired to navigate through the document using screenreader software.
Having word processors produce semantic content doesn’t need to be complicated for the user. In fact, it would make things easier by removing extraneous options from the default interface, and giving users only the appropriate buttons needed to produce semantic content. All those other formatting options would still be there somewhere, for those who need them; it would just be a little harder to find them.
Some tools make an effort toward semantic markup, such as the software I use for this site, WordPress. The post editing interface doesn’t give you the option to adjust font sizes, instead, it has a dropdown box that allows you to change sections of text from paragraph formatting to each of the 6 heading levels. However, this option is part of the “extended toolbar,” which isn’t visible by default when you’re editing a post. I have no doubt many WordPress users simply bold their heading text, because the bold button is right there.
This is not to say that people shouldn’t have the option to make their text huge and purple and Comic Sans if they really want to. But being able to take advantage of that option shouldn’t be the default scenario for producing content.
Leave a Reply