Why WYSIWYG doesn’t work II

7. December, 2009

In my old post “The Space Between Two Characters“, I wrote about some flaws of WYSIWYG. Since then, I got some feedback.

The real issue behind the issues with WYSIWYG is that it doesn’t work while you edit the document. The concept is flawed, not the implementation. It is flawed because it omits some vital information that you need for editing. The information is omitted because it doesn’t make sense anymore as soon as you print the document on paper. And WYSIWYG means “if you don’t see it, you won’t get it.”

So it makes sense to omit feedback on where ranges start and end, what kind of break follows after a line, there the handles for a table are. But most WYSIWYG editors today have a “show invisible” option. Word can show you all those invisible characters so you can see “oh, this is a tab and not a space”.

For this to work, we need a tight integration between the editor model, the renderer and the view. The problem here is, as usual, performance. If you add all the hooks you need to be able to show nice visual feedback in the view, printing to a printer will be slower.

How much? Well, not much. Anymore. You’re quadcore will be 95% bored. It will need memory. How much? Well, to remember the bounding boxes for all letters rendered on the screen takes at most 4’608’000 bytes (“i”, 8px font, 30″ display with 3840×1200). That might seem like a lot but almost no PC sold next year will have less then 4GB of RAM, not even the Netbooks. My mobile phone comes with 32GB!

For printing, the values are usually much smaller. A normal page of text has around 1’500 to 2’500 characters per page and for printing, you just need to remember the current and maybe the next page (unless you need a page count but with todays CPUs, you can layout the pages twice).

So the final obstacles is code complexity. OO has helped a lot to cut down complexity in algorithms but there are problems which you can’t solve nicely with OO, for example “run this algorithm but replace line 5 with …” or “before … run …”.

AOP has come to solve this but it has failed to deliver so far. Maybe this is because point-cuts are too complicated to formulate, maybe because the debuggers can’t handle this case well, maybe because the setup is too complex or the resulting code is too fragile. Or because people are afraid of the leap of faith it takes to use it.

%d bloggers like this: