Web Directions

The challenge of WYSIWYG development for the web

• By:John
• Tweet: @johnallsopp
• September 27, 2011
• Leave a response

This is the first in what I hope will be a number of articles I’m writing to clarify my thinking in the lead up to my Dao of Web Design Revisited presentation at this years Web Directions South.

In the middle 1990s, by an accident of fate and coincidence far too tedious to go into here, I found myself teaching some of the earliest web related courses at TAFENSW. A lot of my focus was in getting students to think conceptually about document structure, linking, interactive tables of contents and so on. Very little was about HTML. Indeed, so convinced was I that WYSIWYG editing was just around the corner, I felt it a waste of their time learning markup (this was pre CSS, but that’s another story). We used Claris HomePage, a surprisingly useful application, to develop web sites as part of these courses.

Pretty much everyone at the time felt that actually working at the markup level for the web would go the way of assembly programming.

There were reasonable precedents to this belief. Desktop publishing in the middle 1980s (really only around 10 years before this time) had revolutionized traditionally markup based print page layout (and more or less given the world the term WYSIWYG).

And, around that same time (the middle and latter half of the 1980s), I was studying Computer Science at University, where for our final year major project, we were the first cohort to no longer use COBOL (I kid you not). Rather we used a 4GL named Omnis (4GLs or Fourth Generation Languages were supposed to abstract away all the messy stuff when developing complex applications). The consensus was (and this was a classic CS program with lots of C, and algorithms and stuff) that the traditional approach to programming was going the way of assembly language.

4GLs live on in systems like 4D, but you would have shocked us all back then if you said that we’d still be using 3GLs without even garbage collection today.

So, why did WYSIWYG revolutionize print design, but not application development?

Similarly, despite the success of, above all DreamWeaver, and to a lesser extent other WYSIWYG web development tools, we’re still very much working at the codeface (I don’t think I know any professional web developers who use a WYSIWYG tool these days, though many, myself included, once did).

But why is that? Will it always be the case? Or will one day someone crack the code (literally and metaphorically) and deliver a WYSIWYG tool that liberates us from the “grind” of coding.

But first, let’s consider why WYSIWYG was so successful in the world of print. I’d suggest a big part of that success was that is possible to map every aspect of a printed page onto the screen (or better, into the internal model of the software). You can even map colors onto a grayscale screen, which many desktop publishing systems were in the mid 1980s, color screens were seriously expensive. So, there was little if any need for metaphor or abstraction. This part of the page right here, will be pantone color whatever. And this little bit over here, will be white. And so on.

The problem space of printed page layout was sufficiently constrained that everything the designer might want to do, they could do with DTP software. I’d argue that a constrained “possibility space” is a key requirement for WYSIWYG systems to really work.

So, what about the web? Douglas Engelbart, one of the giants of modern computing, coined the term “WYSIAYG” (what you see is all you get), which I think captures the challenge faced in developing web development tools, and software tools more generally. With desktop publishing, all you get is all you need. As we saw, the space of possible outcomes can be mapped into a set of tools.

But with the web (even leaving aside JavaScript and the DOM), the possibility space is I’d argue, too open ended to map well onto any WYSIWYG software. So the designer of development tools needs to decide what the all is. Unlike print design, where the problem was constrained by the medium, with the web, software designers constrain the problem space.

So, if you were developing a “WYSIWYG” web development tool, how would you enable your users to make the first paragraph after a heading of level 2, in the introductory section of a document bold? You could allow users to add a class (though you may or may not use that term) to that particular page object (or do you call them elements?). Or, you could provide an interface that is familiar from word processors, where the user selects text, and a bold tool, and behind the scenes the software adds a strong element (to code the user will never see). Or you might add inline style of bold to that paragraph.

And this is about as simple a scenario as it gets. No interaction. Just styled text based on document structure.

Now, what if a document is divided into chapters. And what if the designer wants the first line in the first paragraph in each chapter to be capitalized? Or every other row in a table to have a given background color?

The best possible approach to these particular challenges at the markup and CSS level is likely to use structural selectors (e.g. nth-​​child). But how to intuit from the users’ actions their intent, and map that intent onto the capabilities of CSS?

And we still haven’t even introduced any interactivity to the challenge yet.

This isn’t simply a theoretical issue for me. I’ve been developing the CSS Editor Style Master for well over a decade. One of the design principles for it has been to never hide the underlying CSS concepts behind metaphors and abstractions. Rather, the goal is to make understanding, and using, these powerful features of CSS easier, more productive, and more enjoyable. This same design principle informs my work on various CSS3 tools, for example my gradient and animation tools. While other tools (and this is not a criticism, simply an observation), create metaphors (for example, provide a Photoshop-​​like interface for creating gradients), I emphasise a direct correspondence between the objects you manipulate, and the underlying CSS concepts.

But, to return to the question, is WYSIWYG possible for the web? I actually think that it is, but not in general. But in situations where a specific problem is sufficiently constrained, I think we can provide WYSIWYG tools. Which means the approach Adobe is taking with MUSE, will run up against the same challenges that all general purpose WYSIWYG web development tools have. That’s not to say it might not be very useful, but will be so within the constraints of its capabilities, of the problem space its designers have chosen to map.

Where I do think WYSIWYG can be, and already often is very successful is in constrained problem spaces. Blog posting is a particular example. An area I’m focussing on right now is presentations, which I believe is sufficiently constrained to make a WYWIWYG approach meaningful (but even here, I think being able to bust out an editor for markup, CSS or JS is important).
Ironically, you could create a WYSIWYG print design tool with web technologies, for precisely the same reason you can do it with other languages and development platforms.

In essence, the set of problems the web presents developers and designers is open ended in a way that no other system is. Viewport sizes can range from 128 x 128 pixels (or less) to 3840 x 2160, and no doubt beyond. Pixel density, color depth, available fonts, all of these will vary dramatically. Then there’s varying levels of support for CSS, HTML, DOM, SVG. There’s varying network speeds, drastic performance differences. Different input methods (mouse, keyboard, touch, Kinect, …) And none of these are going away. They are getting “worse” (which ironically means better — because more diversity among these characteristics means more people are using the web in more ways, which is good). The fact it causes challenges for designers and developers is essentially irrelevant. That’s our problem.

The search for an over-​​arching WYSIWYG solution to the challenge of developing for the web reflects our ongoing misconception of what the web is. It’s a medium unlike those which it is in some ways conceptually built on — be that paper, TV or desktop platforms like Windows. It’s understandable that we want it to be more like these. We know them well, we’re comfortable with their concepts and techniques. We’ve invested hugely in technology and expertise to design and develop for them. The web continues to make us uncomfortable. As it should. It is something new, and exciting, and challenging, and unfinished. What we see is never going to be all web get. That’s the challenge, and beauty, of the web.

7 responses to “The challenge of WYSIWYG development for the web”:

1. • By:James Pearce
   • September 27th, 2011
   

   This is a great question.

   Even WYSIWYG editors in web platforms (e.g. CMS) feel like a hack and always seem subject to broken round-​​trips and the like.

   That we can’t elegantly provide tooling for (2 dimensional) documents does not bode well for (4+ dimensional) state machines — otherwise known as apps.

   But personally I’d extrapolate your position to be a general call for help for tools for contemporary web development. Pretty much any tooling around HTML5, CSS3, JavaScript right now starts to fill a vacuum. (It might be partly a function of the early-​​adopting crowd adopting this stuff, but I rarely see anything more advanced than TextMate in use)

   But your conclusion implies that we should just accept this, and that its inability to be tooled is some underlying property of the amorphous web. I see your point, but it’s unsatisfactory. We shouldn’t give up trying if we want to make it a level, democratic, read-​​write medium for all ( — at a document-​​centric level at least)

2. • By:Saeed Neamati
   • September 27th, 2011
   

   A damn problem I found in web WYSIWYG editors is the lack of HTML5 support. I personally wanted to create my own website using HTML5 and also I wanted to be able to use HTML5 tags in my articles. But no editor at that time supported that. Thus, my only way was to write HTML markup by hand. Yeah, by hand. That sound a little frustrating at first, but then I used to it.

   And generally speaking, I think the overall result of writing markup by hand is better than using a WYSIWYG editor. This means that for my WordPress sites, I simply create the markup, and using a query, directly insert them into the MySQL.

3. • By:Adrian Schmidt
   • September 27th, 2011
   

   I agree with James that making the web, at least on a document-​​centric level, democratic and read-​​write for all is important, and should not be given up on.

   WordPress has made an invaluable contribution in this respect.

   But I also believe that it is more or less hopeless to wish for general purpose WYSIWYG-​​editors for the web. I realise that I run the risk of looking like a grand fool one day in the future, but I base this belief on the complexity of the medium, similarly to what John says.

   The underlying problem is that building web sites and apps is infinitely more complex than designing a print page.

   A printed page is static. That means you can basically draw on it like you would a canvas. A box does not need to know how to react if the paper changes orientation, because that is not very likely to happen once the page is printed.

   The same box sitting on a web page, however, needs a plethora of extra information to know how to react to stuff that can happen both inside and outside it.

   So were in DTP you are finished once the page is “drawn” on the canvas, in web you have the majority of the work ahead of you. And even though WYSIWYG-​​editors might make the first part of the job a lot easier, they usually just make the latter, and much bigger, part a lot more painful than TextMate does.

   The question is, I think, is there a simpler way to give the computer these instructions than by writing them in plain text? Until we hook our brains directly to computers, which I am sure we will pretty soon, I am going to guess no.

4. • By:Joe Hewitt
   • September 28th, 2011
   

   I really liked the way the original Dreamweaver tried to be impartial between code and WYSIWYG. Over time it seemed to push the text editor further and further into the background, and now it’s just a WYSIWYG tool. When I’m developing purely in a text editor, I miss having a live view that I can edit in WYSIWYG fashion while still keeping an eye on the code.

5. • By:bowerbird
   • September 29th, 2011
   

   who wants wysiwyg anyway?

   you’re barking up the wrong tree.
   i’m serious.

   i am not a designer, and i don’t want to be one,
   and i don’t want to have to hire one, either…

   i wanna throw some barely-​​formatted content in the
   machine, and have the computer make it beautiful,
   flexible to any change in its underlying canvas…

   bonus-​​points if my users can easily manipulate it
   so it conforms to _​their_​ idiosyncratic needs…
   (because they _​are_​ the important party — right?)

   think about it.

   –bowerbird

6. • By:Richard Fink
   • October 6th, 2011
   

   I’m glad you’re writing about the dearth of original thinking when it comes to authoring tools.

   Here, in a nutshell is what I don’t understand:
   We’ve reached the point where the CSS 2.1 spec, at least, is fixed in place. There is a comprehensive suite of test pages.
   The rules conform to algorithms. Why do I not have or see authoring tools which allow me to intuitively apply those algorithms to all of the objects on the page. Or am I missing something?

   I understand where bowerbird is coming from — wysiwyg — as most of us normally think of it, works within a range of “desktop” sized canvases. Or paper sizes. I don’t necessarily need to know exactly how it’s going to look on every conceivable viewport. But what I do need, is to be able to set a color on something and have the program tell me that another rule on an object higher up in the heirarchy, is going to override it. So what would I like to do to prevent that from happening?
   The learning curve needs to be lowered. People should be able to turn out decent product for the web without years of experience. To borrow the terms of yesterday’s publishing industry, today we are being asked to be writer, compositor, and press operator all rolled into one. What we need is the application to be compositor and press operator.
   When I create a brochure in an application like InDesign or Microsoft Publisher, I don’t need to understand the underlying code the program is using to get me the result I want.

   I also share, BTW, bowerbird’s desire — and insistence, I think — that simple, basically contructed content should look not only good, but styled. I haven’t the foggiest how to achieve that, but as someone smarter than me once said: if you reach for stars, at least you know you won’t end up with a handful of mud.

   This making any sense?

   Regards,

   Rich

7. • By:Russell Searle
   • October 20th, 2011
   

   My view is that the maturation of most forms of technology involves, amongst other things, the development of progressively more intelligent and intuitive tools that sublimate (embed or conceal) specialist knowledge into simple user interfaces. This was the case with cars, phones, houses, electricity, trains, weapons, water, agriculture and so on. As a technology matures, it tends to become a commodity, a utility, in order to become ubiquitous.

   The same process applies to IT up to a point, but the process is not finished: IT is not mature. Some things are getting close to that, e.g. PCs, storage, bandwidth. But some things are not. Software technology is still very immature. All sorts of developers and ventures are still rewarded for reinventing the wheel, seemingly regardless of whether the new wheel is a clear improvement over the old one, or just another distraction in an already crowded field.

   The maturation of a technology is necessary for a technology to reach its potential in terms of its benefits to the world. But the maturation of technologies is largely the story of standardisation (around often imperfect but commonly accepted standards), and the steady development of simple tools that essentially deskill the application of the technology.

   You may not like that word “deskill”, since it’s an implied threat to our profession, or at least our rates. Well consider the precedents, say cars and phones. Do we still think of auto mechanics and phone technicians as being the bearers of secret knowledge? Are there still pissing contests about who is the most elegant auto mechanic? Do some rock star mechanics command premium rates because they deliver lots of keynotes at car conferences?

   IT is still taking baby steps (OK, a baby with pretty long legs). Deskilling is inevitable, if the world at large is to achieve maximum returns on our technology. The technology must be simple and foolproof. Anybody should be able to use it quickly and intuitively. At the moment, those statements wouldn’t apply even to such a basic activity as writing a WordPress blog; although maybe iPhones and iPads are getting close. As a profession, IT is still a long way away from this state of grace, and most of us seem to be doing our best to make it harder, not simpler.

   Deskilling happens when tools embody specialist knowledge and replace specialists. I’ve always seen this as a healthy and natural process. So I’ve always been a fan of WYSIWYG tools. I want tools that let me work directly on the medium, however complex it is (and there are a number of WYSIWYG tools in common use that are very helpful even if they don’t provide complete coverage, e.g. Firebug, Artisteer, Stylizer, KompoZer, Amaya). I don’t want to have to make do with textual tools that force me to deal with an abstraction, a shadow of the medium. Yes, I can and I do work with them, but it’s not what I want and it’s not what our users want. To paraphrase Einstein, I don’t want to have to learn things that a tool can do for me.

   So the technology, the libraries, the interfaces keep getting more complex and difficult (that’s us doing that, BTW), and they keep outstripping the capability of the tools? That’s just not good enough. We need more intuitive tools for our own use, and we need to be able to put those tools in the hands of the users, so that users can harness their creativity, their collective genius in our medium without having to filter it through us.

   My fond hope is that the tools will eventually catch up with software technology (even if the technology has to be tamed to achieve that), and the developers of those tools will probably become the Henry Fords of our industry. As far as I’m concerned, it can’t happen soon enough. That’s how IT will eventually reach its potential. That’s how our world (not just the IT profession) will win.

Your opinion: