WYSIWYG Editing: A glimpse of the Future?
Tuesday, May 13th, 2008Wysiwyg, one of the buzzwords in the 90’s, has experienced a decline in popularity over the past years. Although prevalent in word processing applications among others it still is considered a must in rapid application development, for instance web application development.
Web application developers seek complete control over the output of their applications, not relying on typical wysiwyg implementation of HTML constructs. Also, in a typical web application production environment, it is hard to have a wysiwyg representation of the final product where the sources come from many files and are subject to business logic, view engines and what not.
The biggest hurdle to be taken though, in my opinion, is that every wysiwyg editing experience is confined to the implementation language. We speak of tables and divs and spans whereas would we want the same visual product implemented in another formatting language we would have to change our ways of thinking and moreover: think language-specific.
Let’s say you want to make an HTML layout with elements like tables, spans, divs etc. What if you had a set of building blocks of which one is say: a box. You can attribute to that box certain semantics so that it breaks a line, or is tabular. This box could also easily be implemented in another formatting language, like OOXML. This way we can think of wysiwyg building blocks which we can decouple from language-specific implementation.
What’s the catch? Certain functionalities between languages are incomparable or through imagination too hard to abstract for it to be seen as one and the same. Also, too abstract a way of thinking makes you lose touch with the implementation level where, as mentioned above, a great deal of control is desired.
Enter the customizable building blocks.
What if you could have complete control of how building blocks and their semantics are implemented on the language-specific level? This way developers would have complete control of the final implementation of their designs. Also, different flavors can be thought of for specific end-user requirements. This makes porting designs not only between formatting languages easy but also between different implementations of those languages a breeze.
The main problem though is that there should be consensus between all the parties involved who manage the many formatting languages that are out there. These languages need to be abstracted to a point where they sufficiently overlap. A degree of standardization is therefore necessary.