Microsoft and Apple have a lot to answer for. Yes, Xerox PARC created Bravo, seen as the first WYSIWYG (what you see is what you get) interface, but Microsoft and Apple made WYSIWYG the expected interface putting content into a computer. What we called “word processors” were actually desktop publishers, giving users the ability to see on the screen something very similar to what would come out on the printer.
That user expectation crept into the world of web designers with HotDog, WYSIWYG content management systems (CMS) and phrases like “above the fold”.
At the time none of us were thinking about screens as their own medium. WYSIWYG refers to paper. “Above the fold” refers to paper. Websites have nothing to do with paper and WYSIWYG should have no place in creating websites.
To start with, when a piece of paper’s size changes, its content and value changes with it.
Responsiveness
If we’re asked to come up with a new website design in 2016, there is no question that we have to make it responsive. WYSIWYG and responsiveness cannot coexist. We can’t demand that everybody set their screens to the size we’ve designed for. We tried that in 1999 and it was stupid even then.
WYSIWYG exists as an opportunity for people to design how the screen will appear. The problem, obviously, is that the screen will almost never appear that way.
Karen McGrane explained this well in her 2013 A List Apart piece, “WYSIWTF”.
By allowing clients to continue to use WYSIWYG, we are doing them a disservice: allowing them to engage in an ongoing self-deception that content is going to look a certain way when it’s published. It’s part of the same self-deception that publication is final and no further maintenance is required.
Building a better experience for everyone
When we start discouraging clients from pursuing a WYSIWYG solution, we will encounter resistance.
Many people think that WYSIWYG is the only way. Its existence popularised word processing and personalised the act of typing. People expect the ability to control how their content appears in the world.
We have to show them the value in the alternative. That’s a difficult path because it involves more work up front.
If we do our job properly at the start of a project, we can work out all the different kinds of content our clients are likely to have on their websites. (At Floate we did this with ANZ’s Shareholder Centre redesign) by auditing all of their content and identifying different types like “personnel”, “events”, “securities”, “protected pages”, “disclaimers”, etcetera.)
Then we work out the rules for these types of content:
- When do they display and how do they appear?
- What options do they come with?
- How do images work with prose?
- What are the maximum sizes that images can appear at the maximum width of the website?
- What can be automated to reduce the size (both in dimensions and bytes) of images before they are served to the user?
- How do we make it easy for people to apply semantics to text without specifying a visual treatment?
What’s a semantic-whosit-now?
This last question raises one of WYSIWYG’s biggest issues: It has clouded over the difference between visual-treatment applied to some text and the meaning that visual treatment was intended to provide.
Italics are a perfect example of this. Let’s quickly look at the needs of a music news publication. They might have a style guide that says something like:
Album titles are to be italicised (eg Carrie & Lowell refers to the Sufjan Stevens album) and song titles should be in double quotation marks (eg “Carrie & Lowell” to refer to the song by Sufjan Stevens). This will avoid ambiguity in reading and also remove the need for constant reiteration of which you are referring to.
That’s great for printing on paper that’s going to have that consistent style forever. We can’t guarantee that web-styles will perpetuate but the hope is to have the content remain available forever. We also can’t guarantee other technologies (non-visual technologies) are going to convey the meaning provided by the font-treatment or the quotation marks.
The visual treatment in print was implying metadata but on computers we have the opportunity to embed the metadata. Album titles can be assigned a property of being an album title, rather than just emphasised text the reader has to interpret.
It’s our job to teach our clients the differences here and help them adjust their workflows and concepts of the content they’re creating. It’s our job to facilitate our clients putting meaningful content into the world.
But clients don’t want to learn html
Nobody should be expected to learn Markdown or HTML or Textile just to add content to a website. They should be able to type and apply semantic classification of different bits of text in a graphical user interface (GUI) that they can recognise and use easily.
Entering content into the site should have a pretty short and shallow learning curve. That means that if people are used to highlighting text and clicking on a button on a toolbar to assign it some kind of role, then that functionality should be available to them.
This also means that we should remove buttons like 
for italics and 
for bold and replace them with buttons for [emphasis] and [strong] and other buttons that might give a similar visual treatments but include different meaning in the metadata like [cite].
If all you do is change the code for the [I] button so that it produces <em> tags, you’re telling the client “We all know that italics is the same as emphasis, so let’s just use this shorthand.” By doing that, you are perpetuating this idea that the visual treatment is meaning when it’s actually an abstraction of the meaning. Remember, our job is to give clients the right tool to help them understand what they are doing. We can’t continue misleading them because it’s easier in the short run.
You can create a visual editor that still applies visible changes to the text as it’s entered into the CMS. It can use colours and visual treatments to differentiate assignments of meaning to text that requires it. This will make the client’s job easier.
Importantly, though, when we talk about this content editor with the client, we cannot call that WYSIWYG and should not lead clients to think that it is WYSIWYG.
So, what the hell is WYSIWYG?
WYSIWYG literally tells people that what they see in their interface is what will be produced on the other side. It implies that someone can change fonts and font sizes and that they can decide on text-wrapping and colours. These are aspects of the design that should all be defined in the CSS, performing a number of efficiencies including:
- protecting the brand by having a central control over visual style
- reducing the time it takes someone to enter content.
If we give content-enterers the control to define how the final product is displayed, those visual embellishments end up saved in the database (because they are inline in the code, by nature). Subsequently, any update to the design of the website will not be able to override those inline embellishments. That might result in text being unreadable or images appearing out of alignment. Then it becomes somebody’s job to clean up content that doesn’t work with the new styles.
In that scenario, we’ve avoided doing some extra work now that might end up costing the client many thousands of dollars in years to come or forcing them to compromise their visual identity.
The Big Challenge
We have to convince people who are used to a certain amount of control that a bit of a learning curve up front will save the company a lot of effort down the track. Even more difficult than that is the discussion we have to have with project owners that a bit of extra hard work at the start will mean a truer responsive website, future-proofing the investment while also helping to minimise future costs of adding and maintaining content.
This post was originally published in the Floate Design Partners blog