Review: Beyond WYSIWYG

A Review of “Typsetting and Publishing Tools: Beyond WYSIWYG”

Noah Jodice

In their talk, “Typesetting and Publishing Tools: Beyond WYSIWYG,” Julie Blanc and Clémence Imbert clarify the paradigm of “What You See Is What You Get” and ask how we could apply that paradigm to contemporary issues in design. The problem, as they state it, is that no-code, visuals-first web design has alienated form and content. WYSIWYG, as they describe, is an illusion which hides the computer behind a screen. “It is about making the human interaction more important than how the thing actually functions.” But, can the WYSIWYG paradigm rescue web design?

They use Figma as an example of the problem at hand. The software “abstract[s] technical complexity into basic visual metaphor.” It’s reusable components can build responsive web designs. Figma has an auto-layout function, which does what it says: it automatically adjusts layout based on context and screen proportions, with no code necessary. It builds the CSS code for you. CSS is a graphic markup language, which makes apparent the cause and effect relationship of design. The designer uses elements and code descriptions to instruct a website on how it should look under a given set of circumstances. But, the preesenters note, Figma’s auto-layout function “raises the question of an additional abstraction built on the top of CSS and producing new terminologies that can distance designers from developers.”

Complicating the WYSIWYG paradigm, Blanc and Imbert hope, might re-introduce a conversation between designer and tool. Looking back at the development of desktop publishing in the late 1980’s, they call WYSIWYG a “marketing promise that is never achieved practically.” Usefully, they break WYSIWYG down into two aspects.

1. “WYSIWYG is a paradigm based on visuality — what you see is what you get — and not so much on automation, the concept on which most technological developments have built.” Designers appreciated that WYSIWYG tools let them play on the screen, try and re-try ideas in endless secession. These tools introduced an intuitive, artful, conceptual approach, free from the constraints of production which disappeared in the black box of a PostScript file.
2. WYSIWYG is based on concepts from the print era, particularly the concept of the page. Before the advent of the web, the computer was a production tool for print objects. Print was the “superior objective.” PageMaker, an early product from the Aldus Corporation, names its goal explicitly: this software helps you make pages. Blanc and Imbert note that Paul Brainerd, CEO of Altus, had experience in typesetting. PageMaker is a “virtual transposition of the tools and gestures of layout designers.” The software thinks, they note, in terms of the page.

Both of these aspects help us clearly understand how the WYSIWYG paradigm operates. Early marketing makes it clear that WYSIWYG tools were purpose-built for automation. See, for example, the headline of a 1988 advertisement for Adobe Illustrator: “Introducing Automatic Art.” As a technology, WYSIWYG’s emphasis on visuality is in fact a form of automation. The hand becomes subservient to the eye. “What you see” determines “how you make.” What is the impact? Design can become technology-as-knowledge rather than technology-as-process.

“Introducing Automatic Art,” from MacWorld, June 1988.

As explained by the anthropologist Tim Ingold, technology-as-process defines “technology” as the activities of making and using tools. (See Ingold’s The Perception of the Environment, Chapter 15) “The key element here is that of skill,” Ingold writes. A skilled activity — the cutting and pasting of hard copy, the measuring out of page margins by ruler, the sketching of type by hand — is a technological process. So, too, are digital activities like typing and the use of a language like CSS. Language use is dependent on a keen understanding of the vocabulary and grammar (or a willingness to learn them through immersion). Technology-as-knowledge, on the other hand, distinguishes the practice of a skill from the intelligence applied to that skill. Skill is an “application of dexterity,” while intelligence or “know-how” is a conceptualization of that action. In other words, when PageMaker transposes “the tools and gestures of layout designers,” technology-as-process is abstracted. Just as Figma’s auto-layout feature is an abstraction of CSS coding, a layout software is an abstraction of physical layout practices.

If a software automates a process, does it also automate the “know-how,” the conceptualization of that process as knowledge? In Blanc and Imbert’s consideration of no-code websites, the answer seems to be “yes.” As previously noted, such tools distance designers and developers. Elements within a design are selected for how they look rather than how they function. Over time, knowledge of the process becomes objectified into a button within a software.

Is the same thing true of a software like PageMaker? It depends. Designers who were trained on non-WYSIWYG tools and then learned digital software had both conceptual and skills-based knowledge. They might understand that a transposition of a gesture or tool may not work as its analog counterpart does, but they know enough about that analog counterpart to make informed decisions. Later generations of designers, trained first on the digital abstractions, have a different relationship. Unless they are deeply invested in the historical memory of the field, the knowledge of why a particularly abstraction works the way it does is lost. Through this process, emerging designers are deskilled, reliant on a visuals-first approach rather than a content-first approach.

Blanc and Imbert experiment in using non-WYSIWYG practices within web design. One experiment shows how CSS coding can be used for page layout. A word document is converted to HTML and rich CSS. The designer can then select and change elements using her knowledge of CSS, re-asserting the language’s graphic properties. The adaptive concepts of web design get applied backwards onto the print object. “With the use of web technology we are no longer bound in the content of fixed-page design, but, instead, can design content that is flexible and adapts to different media and sized paper.” Further, this experiment opens up the black box of digital layout design.

Their practice revives one of the original intentions of graphic markup languages, discarded from desktop publishing’s early years in favor of more user-friendly software. In its October 12, 1987 edition, The Seybold Report on Desktop Publishing describes how 20 years of development have produced “a complex standardized coding scheme, SGML, which includes conditional statements and operations as well as straight-forward generic tags.” The article notes that this runs counter to WYSIWYG displays, which are the favorite among desktop publishing developers because they allow users to “deal with form and content at the same time.” The advantage of SGML, however, is that it “can be recomposed to any reasonable format (including display CRT screens and/or different page sizes and formats).”

“Is separation of form and content relevant for desktop publishing?,” the article asks. Votes in favor come from Soft Quad, Hewlett-Packard, and SOBE-MAP, each developers of SGML editing programs. Soft Quad developed the Author/Editor program, which separated form and content through a “context view” and “structure view.”¹

Votes against the separation of form and content come from Ted Johnson of Aldus. He “does not see SGML as relevant for the type of work his customers do. This is most often layout-driven work for which page formatting is very important and separation of form and content is of less value.” As mentioned earlier, Aldus developed PageMaker, the “transposer of tools and gestures.” In 1994, Aldus was acquired by Adobe, who continued to develop PageMaker until 1998. Adobe InDesign, the current standard for page layout in desktop publishing, emerged from PageMaker’s ashes.

In other words, the purveyors of the WYSIWYG paradigm actively downplayed the potential of opposing processes, such as SGML. They did so under the guise of user-friendliness and democratization. Blanc and Imbert confront the same issue in contemporary web design. No-code tools don’t just prioritize form over content — they abstract the relationship between the two. The result in both cases is templatization, homogenization, and deskilling.

What is most exciting about Blanc and Imbert’s experiments is that they reach backwards in time, revive a discarded process, and apply it within a new context. By separating form and content, they also re-center the relationship between the two. They also emphasize that this, too, can be user-friendly. Languages like HTML, Markdown, and CSS are, after all, graphic languages. They use indents, color, and other visual attributes to guide the user through their grammatical constructions. They are only less “user-friendly” because they do not attempt to automate away a designer’s decision-making.

Blanc and Imbert end the presentation by noting that, as WYSIWYG tools reorganized the boundaries of design professions, these tools urge us to ask “who redefines our work?” Should we leave it to private tech startups and bigger corporations, or should we redefine our tools and way to work by ourselves?” This is the right question at the right time. WYSIWYG can be democratizing, in the sense of allowing designers greater access and experimentation. But it is a representative democracy, where constraints are set before you even open the program. Skills become automated. Tools are transposed. Software defaults — typeface selection, margins, point size, even the size of the page — morph from suggestions to constraints. If designers are not deeply involved in the construction of their own tools, the constraints placed upon them will be alienating. Designers then rely on the expertise of the software rather than their own “know-how.”

As automation rears its ugly head again through the most recent cycle of “artificial intelligence,” we should be wary of WYSIWYG-like paradigms. Before rushing to embrace a new software, we should ask who built it and why. Knowing these answers, we can exert more agency in how we define our profession and our way of working.