Friday, August 7, 2015

Why most WYSIWYG composers (and editors) suck

Whenever you need to write something that contains anything more complicated than plain text, you usually have a WYSIWYG-style editor at your disposal, be it authoring a simple cover letter in MS Word or using post composer on this blog.

WYSIWYG stands for "what you see is what you get" and means that you have simple text-styling tools (bold, italic, font size/color, etc.) at your disposal. It is usually a good thing to have - not because what you see in the composer is what you finally get (this is, generally speaking, false: your blog post will be affected by your template, the viewer's browser and many other factors; even in the telltale Word getting things exactly as you want them is not always easy), but because it is a time saver: it is often faster to press a toolbar button than to manually write HTML tags every time you need them.


But WYSIWYG has a huge caveat in that it encourages users to omit the most important step in text formatting: logic. Usually, any text can be broken down into logical blocks: here is the "main text", these sentences are "more important" or "less important", here is a "heading", this here is a "footnote", this is a "caption", and so on. And it is these logical blocks that we "decorate": make their text smaller / larger, bold/italic/underlined, set a different color / background, etc.

You've probably already guessed what I am getting at: styles. Now the (disappointing) truth is that any document the slightest bit more complicated than your garage sale ad will need styles. Unless you're writing something like a cyber-punk hippie gothic new age underground pamphlet, you'll want your logic blocks look the same throughout your document -- or many documents in case of a blog.

The caveat about WYSIWYG composers is that they direct your attention away from styles and towards text decoration. Most of you would still have an "implicit style table" in your memory, and would try to stick to it. This might work -- for a fraction of people who really deserve to have "paranoid attention to detail" in their résumés. The rest of us will inevitably have different  look to their logically identical fragments -- ranging from slightly different to markedly different and all the way to "you must have been daydreaming as you were writing this" different. 

And that's not the worst of it. Suppose you wrote half your big document (say a Ph.D. thesis in maths) and the formatting requirements were updated, urging you to change the font and coloring of all lemmas in your text (yes, all 118 of them). Or you wrote a bunch of blog posts and discovered that your quotations look ugly as they are, black on yellow centered, and should instead be green on off-white beige and left-aligned. If you had used your styles correctly, the change would be a few minutes. Otherwise, you're in for a night of miserable and thankless drudgery. 

This is why the first thing I did before I even started the blog was adding this to the template:

<!-- CUSTOM STYLES FOR CODE ITEMS-->
<style>
  .mycode {font-family:"Consolas", "Monaco", "Bitstream Vera Sans Mono", "Courier New", Courier, monospace; 
           background-color:#E8E8E8;}
  .myaux {font-size:80%; color:#666699;background-color:#FFFFF0}
  .myinline {color:#999999;}
</style>
saving myself a whole lot of work in the future. Yes, I need to set the custom classes in the HTML mode, but it is way better than having to set all attributes manually (and rely on my less-than-ideal memory) each time I use them - not to mention that I need to go to the HTML mode to enter the code snippets anyway.

No comments:

Post a Comment