Web Directions Year round learning for product, design and engineering professionals

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.