WYSIWYG is often preached as a great step in the history of e.g. document processing; presumably, because it brings advantages for very casual users and pure beginners. However, in the office, in professional use, it is a disaster: The inefficiencies and problems of WYSIWYG bring gigantic losses. The damage I saw MS Word cause alone during my time at E4 ... Unfortunately, the naivete of most users has made it the standard, and anyone who tries to bring in superior technologies is considered a reactionary.
Among the typical problems we have:
Program crashes and instability that are more frequent than with e.g. a LaTeX system, and actually can cause data corruption or loss.
Proprietary formats that complicate the move to another software.
Excessive and wasteful use of processor cycles, working memory, and hard disk space—not to mention bandwidth, e.g. when sending emails.
The inability to actually do what one wants to do (as opposed to what the program presumes that one intended), respectively the inability to know whether a specific instruction has been interpreted as intended.
Discrepancies between what is seen and what is gotten. (I.e., the promise of WYSIWYG is seldom actually fulfilled.)
Below, I will focus on one issue—(lack of) separation between content and layout.
MS Word is one of the best demonstrations of WYSIWYG falling flat on its face (although this, unfortunately, is not obvious to most casual observers)—partly because it has no decent separation between content and layout. That Word has a poor user interface, is bug-ridden, does not like cooperating with third-party products, etc., does not help. LaTeX, in contrast, has a strong support for this division and is one of the best examples of non-WYSIWYG–editing excelling. Notably, LaTeX documents can be edited with the users editor of choice, which makes usability issues a secondary concern—if worst comes to worst, the macro-functionality of LaTeX, it self, and of the editor can overcome as good as any usability issue.
Consider how these two tools handle a number of tasks:
| Task/System | MS Word | LaTeX |
| Edit a document | User must use MS Word or a small set of other tools. | Any arbitrary text editor can be used. |
| Change formatting of all contents that are e.g. quotes or code examples | Go through document and change all entries manually, laboriously, and with a high risk of error. (Word has a supporting mechanism, “styles”, that can be used to at least emulate markup in this regard; however, in my experience, even “professional” users tend to lack the knowledge and self-discipline to actually use it.) | Change the corresponding definition in one place. |
| Get a document version that contains only code examples | A lo-o-ot of manual work. Separate documents must now be kept in sync. | One “master” is kept. Different scripts or sets of macros are used to generate the individual documents from the master. |
| Make a diff | Either use user-unfriendly and often malfunctioning special tools, or rely on the bloating “track changes”. | Trivial. Any arbitrary diff tool (for text) can be used. |
| Merge different versions or documents | As above, but much worse. In reality, a pure manual merge will often be needed. | As above, although limited manual review and corrections may be needed. |
| Use version control or collaboration | Very hard. Manual work, specialized tools, proprietary mechanisms, and other trouble follows. | Easy. All standard version-control tools and (cf. above) merge/diff tools work. |
| Edit a list | Largely, one has to rely on luck, and that the program correctly guesses the intentions of the author. Consider, e.g., whether 1. 2. 3. 4. is one list, or two lists that incidentally have consequent numbers. | Done by mark-up. Exact structure is visible and easily changeable. |
| Correct a mistake | With a bit of luck the built-in undo works—and works correctly. If not, one is screwed. | Undo is always available. Further, version control can be used to correct older changes and to gain more flexibility. |
| Make a mistake with large ramifications or that went unnoticed | Even an innocent and trivial change can wreck havoc. | Unlikely to happen. If it does happen, undo and diffs easily identify the problem—and allow it to be resolved... |
| Repair an error | Hope and pray for built-in functionality and correct guesses from the program. | Easy, as described above. |
| Change margins | Fool around with the margin bar. Hope that one changes exactly what one wanted to change. | Change markup definition in one place with complete control. |
| Break up document into several files. | Usually no practicable solution available | No problem. |
| Add a new feature (by the software producer) to the format | Old programs do not work anymore. Users are forced to upgrade—including those that merely want to read what someone else has written. | All editors and viewers still work perfectly. (The generating program may need updating; however, from a usability POV that is of little importance—and only applies to the actual author of the text.) |
Some of the weaknesses of MS Word above are not inherent to WYSIWYG; yet, every WYSIWYG program seems to have them.
LaTeX (and similar technologies) have a higher threshold for the beginning user; for mid- and long-term use, the situation is very different: Not only are the limitations of WYSIWYG tools much larger, the knowledge needed to do “advanced” tasks is much more arcane and obscure. [TODO] notes that even secretaries with no major IT experience soon become more productive after a switch to LaTeX.
MS Word is WYSIWYG; LaTeX is “You Get What You Want”.
Disturbingly, many people grab MS Word even for the simplest texts, e.g. in that they send an entirely unformatted e-mail text as a MS Word document instead of plain-text—blowing the size (in bytes) of the text to several hundred times its natural size, and forcing the receiver to open extra applications (where he could else have just read the text in his e-mail client).
MS Word invites the user to play around with margins, fonts, etc.—usually in an inefficient and error prone way. LaTeX provides defaults thought through by experts; changes are seldom needed, and when they are, they can be done centrally and in a controlled manner. With LaTeX the author can focus on his job—writing the actual text. The newer XML formats used by some office programs are marginally better than the old binary formats; however, they still have individual layouts for individual elements, instead of having individual layouts for individual element types.
Obviously, there are cases where WYSIWYG does bring benefits, even for proficient users.
WYSIWYG can have a limited justification in that it allows to judge the effects of some changes in real-time, e.g. when a graphical object is re-sized or moved. Here considerable time can be saved in finding the configuration that makes most sense from an aesthetical POV. (Unfortunately, only very simple manipulations can actually be done in real-time even in WYSIWYG tools.) If so, it may work to make a prototype or rough design in a WYSIWYG tool; followed by the final implementation in e.g. mark-up. (Critically, the end result of the WYSIWYG manipulations will only suffice as a design, not the implementation—no matter how tempting it is to use the raw design.)
Of course, if this prototyping can be made without use of computers (which may be even more advantageous) then the WYSIWYG-advantage disappears. Notably, a very typical statement in design guides of various kinds is “First draw your design on paper.” (with variations).
This would also help explain why so many “non-techies” stubbornly insist on WYSIWYG in the face of reason: They see themselves limited in the “aesthetical interaction”, but fail to see the immense advantages they can gain elsewhere.
WYSIWYG is today typically used to contrast e.g. MS-Word and LaTeX, or HTML editors that work with code and those who use WYSIWYG editing. However, reading an online biography on Stallmane, I found “WYSIWYG” referring to the difference between text editors with and without a display of the text. (The earliest editors actually did not have this ability: Even I have on occasion had to work with edw on servers with rudimentary installations.) In this particular context, WYSIWYG is a great step forward; however, in the typical sense used today, this does not hold.
In my defense, I am used think of this differentiation as visual vs. non-visual editing, rather than WYSIWYG vs. non-WYSIWYG: The Unix ur-editor ed(itor)w was succeeded by vi(sual editor)w, and vi is the ancestor of my own favourite—Vimw.
I also note that very many modern text editors, notably Notepad, are so poor that ed is far superior in at least some regards: Consider, e.g., making non-trivial replacements in a long file.
Interestingly, as demonstrated in a discussion of my favicon it is possible to even introduce some WYSIWYG functionality in a plain-text editor to edit simple images. This further demonstrates that the problem with WYSIWYG need not be with the concept itself, but with over-simplistic implementations made without understanding.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.