poetix

this time for sure

Against WYSIWYG

One of the happier days of my life so far was when I left a job where I had to use MSWord every day - often with embedded MSExcel spreadsheets - and started one where I never had to use it at all.

I still make documents of various kinds, but I make them with markdown/pandoc or, if fancy maths symbols are required, Lyx.

WYSIWYG doesn’t work, and is one of the grossest errors in the history of computing.

Why doesn’t WYSIWYG work? Because there’s a mismatch between the grammar of interaction and the grammar of definition. Everything maddening about working with MSWord (or any other word processor that doesn’t let you get behind the what-you-see and edit its markup) comes from this mismatch.

By “grammar of interaction” I mean the ways you do things with a mouse and keyboard: pointing and clicking, highlighting regions of text, dragging and dropping. You see the changes happening as you make them; there’s a tight feedback loop between acting and having something to react to. This is thought to make human beings happier and more productive, and up to a point it does.

By “grammar of definition” I mean the way the content and layout of a document is specified in some symbolic language. The symbolic language determines in the last instance what the document is going to look like; everything you do when interacting with the graphical representation of the document is modifying its symbolic representation in some way.

The experience everyone has when using MSWord is that there is something in the symbolic representation of the document - the computer has got something into its head about what you want to see - that isn’t immediately visible or tractable through the user interface. You can’t see the thing that’s mucking up your layout, you can’t select it or delete it or do anything to it, and it looks like the only way to make it go away is to delete everything in the surrounding area and hope for the best. This is known to make human beings crabby and superstitious, and to play a significant role in inculcating the feelings of learned helplessness with which “non-techies” approach even their most amiable and well-loved computing devices.

With a bit of experience, you get to know the most common of these glitches, and the quickest ways to resolve them. But it still feels like a bit of a black art. You’re not dealing with the document at its most fundamental level of representation; you’re stage-whispering instructions through a thick, velvety curtain. The same curtain that felt so plush and inviting when you first brushed up against it…

I don’t want to fiddle directly with the program’s internal data structures; that would be silly. But I would like to work with a representation of those data structures that is complete, concise, and readable/editable by both human beings and machines. And that’s what a markup language is: simply the cleanest, clearest, most tractable and predictable way of controlling what the computer’s going to put on the screen or send to the printer.