Think WYSIOP, not WYSIWYG
Several years ago, someone used the term WYSIOP (What You See Is One Possibility) when talking about the RoboHelp HTML editor, because what developers saw in the editor didn't usually match the results. I had what I thought was an absolutely brilliant leap of logic ;-) a couple of months ago when I realized that today's WYSIWYG (What You See Is What You Get) editors are really WYSIOP, because the results are determined by whatever layout template is assigned at the time the results are viewed. It may have been a brilliant leap, but as I discovered when researching this article, I wasn't the first!
You may also want to read Do You Suffer from Compulsive Obsessive Pagination Syndrome? While that article deals primarily with AuthorIT, the overall concept is the same: concentrate on content and not the look of the end result.
A Brief History of WYSIWYG
For years, we've been told that certain tools are WYSIWYG: that what we see on the screen during development is what our users will see when viewing the results. However, we learned fairly quickly that WYSIWYG wasn't always WYSIWYG...it was more an approximation than anything else.
Back in the old days...and I mean the really old days...the world was WYSIWYG because all we had was print. Carve a letter into a stone tablet. Layout blocks of type. (OK, that was really more like reverse WYSIWYG.) Use a manual typewriter. The carver/author/typesetter knew exactly what the results were going to look like because he could see them during development.
When we made the move to electric typewriters, we still had WYSIWYG, although we had more control. The typist could replace the existing type ball with another to change the font. This increased our font possibilities, but was still WYSIWYG.
Then we made the move to computers, but we still lived in a WYSIWYG world. What we saw on the screen was what was printed. As the computing world evolved, we were able to use printer fonts (by inserting a cartridge into the printer) and then, eventually, we got software fonts that we could install on our systems. (This, of course, led to the "ransom note" layouts of the early 80s, where it seemed like every possible font was used in a document. This also led to font usability tests. But that's another article.)
And then we got word processors. The second one that I used, called SATURN, ran on a DEC PDP-11 and used tags ([b] for bold, for example). It was a major improvement from the Linolex system that I had been using, which required three eight-inch disks: one for the program, one for the source document, and one for the updated document. (As the document was read from the second disk, it was written to the third. If I missed making a correction, I had to finish writing the document to the third disk, swap disks two and three, and start over.) With SATURN, I could scroll up and down through the entire document if I wanted to.
But SATURN (and others like it) weren't WYSIWYG. I could see the content and the tags on my monitor, but I didn't know what the printed manual looked like until I actually printed. And because my docs were 500+ pages, I would send them to the printer at night before leaving the office...many times returning in the morning to discover that I'd forgotten to set an end bold tag. (Beginning and ending tags used the same syntax, so forgetting the end tag reversed the pattern for the rest of the document. Unless, of course, I'd managed to forget another tag somewhere...which then made the printout look like that section was OK, but it wasn't.)
When HTML came along, everyone learned how to tag. Most folks used Notepad (or something similar), and then opened the saved page in a browser to see the results. Many developers initially designed their layouts by applying font attributes to the various tags (unfortunately, many still do). These attributes made editors seem like they were WYSIWYG.
As more developers accepted Cascading Style Sheets (CSS), they used the CSS file to apply the layout. WYSIWYG editors let developers see what their results would look like without opening a browser.
But as the browser wars came into play, many WYSIWYG editors let developers see what the results would look like, usually in Internet Explorer (IE). And as CSS evolved, those same editors couldn't do as good a job, because they couldn't interpret the CSS positioning definitions or account for browser differences. Other editors couldn't directly use a browser, so they provided an emulator (typically for IE), which required extra tags for the WYSIWYG display to work correctly. (Many Help authors are familiar with RoboHelp HTML and the kadov tags.)
Introducing WYSIOP
Even though many editors still say that they are WYSIWYG, they're not. They're WYSIOP, and the results are dependent on the layout definition for the specified output.
Chris Lilley of the W3C coined the term in 1998, and first used it in an email to the CSS working group list. In an email to the W3C's public HTML mailing list on 17 February 2000, Jelks Cabaniss publicly credited Chris with creating the term.
Chris says, "The idea was that visual editing was done with the firm understanding that structure was being generated underneath; and that the styling being used for the editing was just one possible way to present the information. A different styling might be used at different times during editing, and a different one entirely for reading the content."
Originally, Chris' idea related to XML: a transform for a browser-based output will use a different layout template than a transform for print, PDAs, mobile phones, and so on. But today, as Help developers get more accustomed to the separation of content and presentation, the terminology used by the various Help authoring tools (HAT) takes on new meaning:
- EC Software's Alexander Halsey says that his HAT, Help & Manual, is "almost WYSIWYG," because while the HTML will probably look the same, the XML output is dependent on files that can't be emulated or displayed.
- MadCap Software's Flare is marketed as a WYSIWYG editor, but what you see in development will be dependent on the attached style sheet. (In this case, it means that you don't see the tags like you would in a code editor.)
- AuthorIT never claimed to be WYSIWYG, but it too is WYSIOP, because you can define the development environment to match the look of an output (or not...it's up to you).
- Doc-To-Help also never claimed to be WYSIWYG, because you do most of the editing in Microsoft Word (which is close to WYSIWYG for print, but not necessarily for online). The latest version, Doc-To-Help Enterprise 2005, lets you include HTML files created in any editor, which may or may not be WYSIWYG (or WYSIOP).
- WebWorks ePublisher Pro for Word or Frame never claimed to be WYSIWYG either, again because you work in a print development medium. However, like Doc-To-Help, the latest version lets you include HTML files.
Think WYSIOP
Whether you use a HAT, HTML editor, XML editor, or word processor, the chances are good that you'll be working in a WYSIOP environment. It may take a bit of getting used to, because it's a bit scary the first time you work on a project without the WYSIWYG safety net. Ultimately, however, it frees you to concentrate on the content.
