WYSIWYG considered harmful?

[dr_tectonic]

I was talking to my Mom today about various Microsoft products, and had an interesting thought:

Do WYSIWYG interfaces cause more problems than they solve?

The idea behind programs like MS-Word is that they make life easier for the user by hiding the structure of the document, protecting the user from dealing with it and intead allowing him to just interact directly with what gets presented. (This is most obviously applicable to text documents, web pages, and the like; with an image, the structure is the presentation unless you start getting into color separations for printing. But there are also things like GUI builders that are WYSIWYG.)

This is a great idea -- when it works. But my Mom's complaint is that it often doesn't work, that things will look different when they print than they do on the screen. So the first problem is, how reliably is WYSI actually WYG? Because when the correspondence between seeing and getting breaks down, it's more work to fix it with a WYSIWYG interface than a more abstract interface. To work well, WYSIWYG interfaces need to be map structure to presentation in a really robust and consistent way. This problem is even more obvious with webpages, where presentation has to be handed off to one of several browsers that can render the same content very differently.

The flip side of this problem is that when you do need to actually deal with structure directly, it's often really ugly. Since all that the WYSIWYG interface cares about is presentation, there's no particular incentive for it to keep the structure clean. So you'll get things like six nested layers of HTML formating tags applied to nothing. Irrelevant to display, but a pain to wade through looking for a problem, and sometimes things that seem to be invisible can actually affect display in weird and subtle ways.

But I think perhaps the most insidious problem is that it lets users create documents without thinking about the structure in any way. There are times when that's worth doing: some tasks are lightweight one-shots that neither need nor deserve serious attention. But it also encourages users to do things the quick-and-dirty way: using tabs and spaces to center text, or increasing font size instead of applying a "header" format. This is an approach that creates a lot of extra work if the document ever needs to be modified. It also lets users remain at an amateur skill level even though they use the program frequently. Why learn the more complicated way of doing it if the brute-force method is good enough, even though it takes ten times as long?

There's also a lot to be said for treating composition and formatting as separate tasks in the creation process. I've found that working with straight text first forces me to pay more attention to the organization, and formatting it later makes it more consistent in presentation. You can waste a lot of time dithering over what font size to use for subsection headings, only to get halfway through editing and realize that you don't wany any subsections at all. Heck, I even do this with the raw text: first, I figure out what to say, then I figure out how to word it appropriately for my intended audience, and it comes out a lot better than if I just try to produce the final product in a single pass.

So I'm thinking the best match for a WYSIWYG editor, which doesn't require much thought, is a document that doesn't require much thought either. The longer-lived and more complex a document you're trying to produce, the more likely that you'll be happier in the long run using a tool that encourages you to build something with a clean structure that's been thought out.

Whaddaya think?

Comments

[melted-snowball.livejournal.com]

I'm not sure. Text formatting extremely successfully using LaTeX is equivalent to learning yet another programming language, which is not much fun, especially when you only pull it out once every three or six months.

I have spent quite a bit of time making the formatting for my CV work well, and it is actually in Word. The primary reason is that the rendering methods to make .pdf, .ps, .txt and .html versions of it seem to actually do a better job than the equivalent outputs I can get with TeX.

But I'd go crazy trying to do science in a WYSIWYG editor.

[dr-tectonic.livejournal.com]

It's hard to compare LaTeX and Word, since they're targeted toward such different audiences. I think Word vs Lyx might be a better comparison, if Lyx were more mature and not freeware...

But the accessability factor for infrequent use is very important, you're right. I've never compared different output formats; that's an interesting (and surprising) data point.

[melted-snowball.livejournal.com]

There are .txt renderers for LaTeX, but I have not found one that I like. And I don't like the look-and-feel of latex2html; I like the appearance of HTML made by Word more.

[dpolicar]

The longer-lived and more complex a document you're trying to produce, the more likely that you'll be happier in the long run using a tool that encourages you to build something with a clean structure that's been thought out.

Well, that's certainly true, as written.

But the question remains whether, in practice, one is likely to cross that complexity-barrier often enough to make the more structured approach worthwhile, and how one can reasonably predict that.

When I was a full-time technical writer, I far preferred FrameMaker to Word. In fact, I insisted several times on refusing that transition, despite the associated expenses.

FM, if you haven't used it, is very much built on the premises of your post -- it's a book-building tool, rather than a page-building tool, and is very structure-heavy and rewards time spent up front deciding on things. For multi-chapter, cross-reference-heavy, equation-heavy, diagram-heavy sorts of things I've never found anything better.

Now that I'm a software architect, I don't write books, I write documents. Large, complex documents, but documents. I use Word for compatibility, and it's mostly OK. There are things about it that annoy me -- mostly its dumbass approach to crossreferences and embedded graphics -- but it's OK.

I doubt very many people write more complicated Word docs than I do.

The specific problem you cite -- presentation not matching up between screen and print -- there's no excuse for. That's not WYSIWYG vs something else, that's buggy WYSIWYG vs. non-buggy WYSIWYG.

Text-to-HTML, OTOH, is a great example of what you're talking about. HTML is a structured language, and if your source document isn't structured, you're going to get a lot of noise... the best you're going to manage is that your software makes plausible guesses and isn't wrong too often if you're doing normal things.

[dr-tectonic.livejournal.com]

That's not WYSIWYG vs something else, that's buggy WYSIWYG vs. non-buggy WYSIWYG.

True, but it's a problem that's much less significant for non-WYSIWYG UI. But if the spectrum of WYS and WYG is so broad that it makes the problem sufficiently hard that a company like Microsoft has trouble solving it, maybe it should be regarded less an implementation problem than a feasibility problem?

I was thinking a lot about text-to-HTML, true. Maybe I have the wrong conditions. Maybe it's less about document complexity than it is about the lifecycle of the document: what are the odds that someone will have to do something with the document other than just present it? The more hands and transformation it passes through, the more work will be avoided by good structure...

[dpolicar]

But if the spectrum of WYS and WYG is so broad that it makes the problem sufficiently hard that a company like Microsoft has trouble solving it, maybe it should be regarded less an implementation problem than a feasibility problem?

You can't be serious, can you?

I mean, I don't want to simply indulge in gratuitous Microsoft-bashing here, but... a company like Microsoft has enormous resources with which to add features and fix peripheral bugs, but is precisely the sort of company that has trouble making fundamental architectural improvements.

The simplest way to solve the display/print problem is by using the same routines to render for both. NextStep did something like this by using display postscript as its screen-display tool, but you don't even have to go that far. The problem of making the pixel display on your screen resemble that on your printer (leaving aside purely optical issues like moire and aliasing effects, about which I agree there's nothing to be done, but neither is there in a structured document) just isn't that hard, unless you're stuck trying to fix it without changing anything else and supporting a zillion different driver configurations, in which case good luck to you.

Text-to-HTML is a completely different issue -- again, because the target structure in this case _is_ a structure, and will be reprocessed by downstream systems that depend on its structure. Which is, as you say, a lifecycle issue in a sense: will you need to do structure-dependent downstream processing of this document?

Indexing and cataloging is another common place where this arises, although writing a document in such a way that the structure is in place to support _those_ operations is a GODFORSAKEN NIGHTMARE and in fact nobody in the real world does this, although many many many clever proposals for doing it exist.

[melted-snowball.livejournal.com]

The simplest way to solve the display/print problem is by using the same routines to render for both.

Would you want to?

In the course I'm teaching right now, the course notes are rendered in 3 different flavours: a set of notes that the students can buy, a set of notes as slides that include lots of extra notes for the instructors, and a set of slides that is shown on the screen when I teach the lectures, which include Scheme syntax highlighting.

It's totally awesome, and is exactly a consequence of the difference between the source (which is actually written in a marked up version of Scheme) and the four presentations, which each result from running (yes) a Scheme program. [No, I did none of this work, as you might guess.]

Similarly, when I typeset math, I get a lot of value from seeing all of the LaTeX commands I'm using; it's a hell of a lot easier to figure out how to fix a formula I've mistyped by seeing it in its unmarked-up version, compiling it, and then seeing the .dvi before I print it.

Really, all I'd prefer to have is some way of knowing what will appear on my printer--I don't need to always see it.

[dpolicar]

I would. I've done single-sourcing for multiple output formats and it's awesome, but nothing prevented me from doing that on the Next. The issue isn't "am i prevented from viewing something multiple different ways?" but "is it possible for me to view equivalent displays on different media?"

[melted-snowball.livejournal.com]

OK. I guess I can accept that you want to. I don't, though, and part of why not is my wacky eyes; it turns out that I can quite comfortably read black text on white paper, but black text on white screens gives me a headache almost instantly.

In general, the things I do to make computer screens more readable for me are quite different from those that I do to make computer-printed paper more readable for me.

[hapaxeslegomena.livejournal.com]

For HTML, I agree. I’ve yet to find a better tool than Notepad.

But for regular old documents, I don’t see how taking away Word’s tips and tricks are going to stop the less savvy from using spaces for tabs, hyphens for dashes, paragraph breaks for page breaks, etc.—and generally making life a living Hell for those of us who have to collaborate with them.

[dpolicar]

For HTML, I agree. I’ve yet to find a better tool than Notepad.

Try BBEdit if you ever get the chance. It's a nonWYSIWYG text editor but its HTML mode has a bunch of useful little gadgets built into it. It takes a while to get used to them, but I missed it when I stopped using it.

[hapaxeslegomena.livejournal.com]

I’d have to buy an entirely new computer to run it, but thanks for the tip. :)

[jofish22.livejournal.com]

You want TextPad. It rocks. The search-and-replace handsdown makes it worth it, but it does all the things you want it to do, and well.

Beemer, what about plain HTML? It's sufficiently structured without being a burden, and the images stay where you tell them to. I wrote my whole master's thesis that way, and only at the end threw it into InDesign for pretty.

[(Anonymous)]

I like TextPad and use it quite a bit, but the one thing that annoys me is that ctrl-F is not find. Or, rather, ctrl-F does a find on the last thing you searched on, even if it was in a completely different topic. I still use it, but it takes some muscle-memory overriding to hit F5 instead of ctrl-f.

[jofish22.livejournal.com]

Me too. But that's why I go in and change the keyboard settings to make Ctrl-F find like god intended.

[k8cre8.livejournal.com]

BBEdit is a good one, although, most of the time I use HomeSite, which, I'm not even sure if it's still available by itself.

[toosuto.livejournal.com]

It looks like Adobe is still selling Dreamweaver MX (I know, I know, but they (Macromedia) bought HomeSite so it counts for something right?)

[k8cre8.livejournal.com]

They did buy it, and it sorta counts, but, it's not as good in Dreamweaver as it was by itself. Dreamweaver's WYSIWYG is not bad, but, it's just not as good, especially if there is any actual programming code in the HTML. I also have issues with the Find/Replace in Dreamweaver, and a few other things. I'd say, for HTML WYSIWYGs, Dreamweaver's the best I've seen.

Really, I'd like a program that combines the things I like from BBEdit, Homesite, and Dreamweaver into a nice seemless single program. If I were a real programmer, I'd make it. But, I'm not.

[nehrlich.livejournal.com]

Yeah, one thing I hate is when software tries to do stuff for me (like formatting) and does it poorly, and then makes it hard for me to figure out how to fix it. There are definitely "WYSIWYG" editors (including Word occasionally, especially with lists) that fall into this category. If you're going to tell me "it just works", it better just work.

A lot of software suffers from the problem that the designers think it "just works" but it's impossible for anybody but the designers to make it work (that reminds me of a meeting I was at where a software developer claimed that something wasn't a bug because there was a workaround...a 15-step workaround. I had to leave that meeting because I was so annoyed).

[dpolicar]

Oh! Yeah! Lists! I'd blocked that out of my awareness. Word's list behavior is ABSOLUTELY FRIGGIN' INSANE and makes me scream in frustration at least a dozen times in any reasonably complicated project. And, in thinking about it now, I think this is precisely because it has no notion of the structure of the document in which the list belongs; it doesn't really understand nesting and containment but it tries to behave as if it did, so it makes guesses that just aren't true.

[nematsakis.livejournal.com]

In general, I agree. One of the common critiques of WYSIWYG is that what you see is typically all you get and, as you point out, sometimes you want something more. In the olden days, there were writers, editors, typesetters, and publishers, and they all had their own very distinct roles. A word processor mashes these all together, which is nice when you want to get something out quick, but otherwise the mixture of roles can muddle your document.

The funny thing is that the modern word processor was developed primarily for writing letters, but now the written letter is going the way of the dinosaur as email and other modes of communication (weblogs!) have taken its place. At the same time, the word processor has grown a bunch of other features and now there are whole industries, like the legal industry, which live in Microsoft Word.

I think this is really an accident of history. My dad uses Word in his law firm, and its revision tracking features are essential for what he does. But really, most of the stuff that's in Word isn't essential to the legal profession and they probably could be a lot more effective with a tool that was written to support the task of writing legal documents.

I don't know what I think normal people should use for short documents. At this point, I pretty much never use word processors, but the tools I use aren't really for novice users. For notes and organizing my writing, I use OmniOutliner. Then, I move the document into LaTeX for typesetting. LaTeX is good because it can produce I recently used InDesign for a project and liked it a lot because of its advanced typographic features, but its learning curve is huge and you start with a completely blank slate, which is less than even LaTeX gives you.

[thedragonweaver.livejournal.com]

There was a lovely rant I read once about people who spend more time making their books pretty in Word than in making it in a format that a typographer can deal with. More to the point, in a straight text editor, you can insert, say, (chapter) at the beginning of each chapter (with pointy brackets, of course), and then run it through a basic typographic program at the end and it numbers them for you, as well as properly placing the footnotes and headers. In Word, you have to do it manually, which I can affirm is a pain in the butt. (I once retyped a messy script for a friend and let me tell you, he had NO consistency. I had to renumber everything.)

I think it's a good idea for any long document to type it in a basic editor first. And then when you do put it in another program, don't use Word. It breaks things. Badly.

[madbodger.livejournal.com]

Strong agreement. The real clincher is browsers for the handicapped. Then, using
heading and emphasis tags properly (instead of a mishmash of italic, bold, font size
changes, and so forth) becomes critical to useful understanding of the document.
Also, web crawlers can much better make sense of a properly tagged document and
bring you interested readers. I'm a typography geek from 'way back, cut my teeth
on troff (still use it heavily), now use LaTex and FOP and ring changes with them
in some truly horrid ways.

[backrubbear.livejournal.com]

The problem is that you need enough of an interface to allow you to focus on the content with "enough" structure to do the job. What "enough" is will heavily depend on what you're intending to do.

It's no accident that almost every text processing program has the structure elements of HTML (or vice versa). The things in there are a good minimal set. Tables, lists, dd/dt and common things like bold, italics and colors.

A good editor lets you work with those things without spending a lot of time clicking around trying to use them. Most modern editors do a reasonable job.

Layout, on the other hand, is less about logical ordering of things than making them pretty. Making things pretty is *hard*.

The minute you start making people worry about layout in excess of document structure, the more things start to fall apart.

[flwyd.livejournal.com]

One of our product's main components is essentially a GUI builder. You do all your editing with a tree structure and property editor wizards, and then it refreshes your GUI in another panel. You see what it looks like but you can't lose track of how it's structured.

[earthling177.livejournal.com]

Well, I dunno... I think there are a couple things are being mashed up together here.

One is if you see the "commands" that "format" the presentation, the other is how you give commands to format the presentation and possibly a third thing being if the document has any structure in it.

For example, it's possible to have a document where all text is plain text with no structure at all, typed into a text editor and printed. The very same text output needs at least a few things to be seen thru a web browser, or TeX/LaTeX. That could be seen as "structure" that supports the text processing package, not the document. The actual document structure has more to do with what people see, like chapters, headings, headers, footers, footnotes, headlines etc.

Now, it's possible to see the commands that format the text if you say, output the Word file in .RTF (it looks similar to TeX), or if you open the split window in WordPerfect. You could type an entire Word document in RTF in some text editor and then just use Word to preview/print it, just like some people use TeX. There used to be a package that ran in VAXstations called VorTeX which would let you type in one window and see the output in real time (as the package was processing it, which was cool because one could see TeX changing the paragraphs formatting in real time to account for all the penalties for hyphenating, for example). The "what you see is what you get" has more to do with if you can see the document as it will appear than anything else -- VorTeX is WYSIWYG, and so is emacs, edt and vi, not that anyone would describe them like that or care nowadays.

People tend to describe packages as WYSIWYG when they can manipulate things "directly" by using the mouse to drag stuff around, or select things to format, and choose stuff from the menus. In WordPerfect for example, you can't "type" a command, you can only enter the formatting commands from the function keys and the menus, you don't say "/break/" or "/bold/" and when you see the commands interspersed with your text it's not necessarily what you type but a representation of what you type, unlike say, TeX or HTML. There used to be word-processing packages that forced people to enter documents in the style of WordPerfect and forced them to actually see the formatting commands interspersed with the text, which were not WYSIWYG at all, but were "user friendly" because you didn't have to remember commands or type long strings of commands.

Now, one of the reasons people like us, who started with non-WYSIWYG apps, tease other people with "what you see is all you get" is because very often WYSIWYG packages tend to be limited in what they can do (which shouldn't be a problem, HTML is terribly bad and limited when compared to, say, FrameMaker or TeX, but they are intended to cover vastly different markets) and also because it's easy to "see" what the command will do when you say "position this picture one inch from the top left corner of the paper", so the intention is clear, as opposed to when you only look at the "preview" and it looks like the picture is positioned the way you want, but there is little or no indication (depending on app) to if it's there because you asked it to or if it's accidental, say if I type another paragraph before the picture, will the picture be pushed down the page or will the text flow around the picture? Some apps are better than others at controlling things like that or telling you which one is which so you don't need to re-check the entire document every time a "small" change happens (say you change the font or the font size).

(Continued...)

[earthling177.livejournal.com]

(...Continued...)

Now, not all WYSIWYG apps are terrible when it comes to structured documents. Word, for example, if you stop and think about the structure and then start formatting and then you type, it can be very helpful. For example, you can define styles in the gallery for headings that make most of the document auto format: say each chapter starts with Heading 1 which you say is followed by Heading 2 which is followed by Body Text. You can then start a chapter by just entering the command to format Heading 1, type say "Chapter 10" and return, type say "Introduction" and a return and the next text you type will be body text. Makes it hard to screw up when you prepare the template and have people type in the text. But people usually do it completely backwards, they either want to format as they go, which sucks because they won't stay consistent (making it hard to change later) or they will type everything and then come back to format which is hard because now you do the work instead of the computer. The cool thing about most non-WYSIWYG systems is that they force you to stay structured and it's relatively easy, if you decide that you hate underlining to tell the text editor to replace all underline commands with bold, say. On the other hand, the best way to use either kind of system is not to say "bold" this, but to say "emphasize" this, so if you decide later that "emphasize" means bold and not underline you don't also mess up all the things that happen to be bold too if you are told "no, I liked underline better, put it back the way it was". ;-) (Can you tell I've helped way too many people deal with word/text processing their thesis? I may have seen everything when it comes to advisor/students clashes when it comes to formatting their thesis -- my advice, always, always, save all versions until you are done... it's way too easy for advisors to tell you to move a chapter to the other place and 3 versions later tell you to put it back where it was.)

My peeve with HTML is that the people who started HTML explicitly wanted to make people only have structure, never formatting, to their documents. One was not supposed to be able to choose the font, color, size or style of text, for example -- the entire idea was that you were supposed to mark up the text and let the end user tell their browser what each of those meant, so they could choose what displayed better in their equipment. Fast forward to when business discovered the web and wanted their precious appearance and "delightful" designs preserved on the other end, and we get the mess we have now, where it more often than not shows what the designer wanted, not what the user wanted.

For printing, I will wholeheartedly agree with dpolicar above, the reason it doesn't show what you saw on the screen more often than not has to do with the fact that people aren't using the same routines to draw the text on the screen and the printer (NeXT used Display PostScript, MacOS X uses PDF, for example). Even when the routines are different (for example the old MacOS used QuickDraw for screen/raster printers and PostScript for the higher end printers) it depends a whole lot on how well the programmers write drivers to translate from the display to the print drivers. And also, some laser printers have fake PostScript, which deviates every once in a while from the real thing. Microsoft, for example, seems not to have gotten the hang of doing that right to this day, and it's one more reason why people doing high-end typesetting or drawings/illustrations or page layout laugh out loud when someone asks them "why don't they just use a windows box?" -- because even if the windows box were cheaper than the Mac box (it's not always the case), if the client sees one thing in the proof and another in the final printed document, not only will they have a cow and you'll have to fix the problem, but you may never see the client again. A reliable proofing computer is way more valuable than the price difference.

(...Continued...)

[earthling177.livejournal.com]

(...Continued)

Speaking of Microsoft and Word, it's a very sad story really. Microsoft tends to be the folks that tripped over the transporter/replicator technology and don't know how it works, so when they try to add/change anything they screw up. The Word kernel came straight from a Xerox lab, it used to be fast, small and neat. Word was one of the first apps that understood that the thing displayed should be exactly (or as close as possible given the display you had) the same as the printed one. And also that things had structure. At the time, all the other word processors would force you to say things like "start the paragraph one inch from the left and wrap at seven inches on the right" -- which was great until someone came and said "oh, btw, we're not using letter paper, we're using this other size instead" and every single paragraph/ruler had to be changed. In Word you said things like "paragraphs run one inch from the paper margins" and the text/rulers would change automatically when you changed the paper size. There were style galleries. Things were good. Then that team left MS or at least they were not in the Word team anymore. Since then we have had this bug in every single version where if you use fast-save, sooner or later your document will get corrupted -- most people just install a new version of word and immediately uncheck the "use fast save" option and check "force a backup with each save" for good measure. One day maybe MS will re-write Word from scratch and hopefully do a good job with it making it small, fast and neat again. People tend to think that MS was big and brute forced Word on everyone. It's more like Word was a first class word processor once and propelled (along with Excel, which started on the Mac and was once the best spreadsheet software available) people to adopt other MS software. Oh, well.

Cheers,
-- Paulo.