Responsive Design Workflow: Designing in Text
- It's all content
- Marking up plain text
- Converting plain text to HTML
- “Plain text is the underlying content stream to which formatting can be applied. [...] Plain text is public, standardized, and universally readable.”
- —THE UNICODE STANDARD, VERSION 6.1
The world’s first web page was practically mobile ready. And that was in a time when there were no tablets or smartphones. There’s one simple reason for this: the web page consisted of plain text. Actually, it consisted of structured text with hyperlinks. This was how the web started, and the premise of structured content is still the basic foundation of the web (Figure 4.1).
Figure 4.1. The world’s first website was essentially mobile ready.
It’s all content
We need not concern ourselves with the heated discussions about apps versus documents. For our purposes, if it’s on the web, it’s probably both. Most websites composed of documents are run by an application such as a content management system that requires a user interface. This tends to be the case even if the site’s purpose is informational.
By the same token, I’ve never seen a web app without content. No app simply contains buttons with nothing on them, text fields without labels, and absolutely no text on the page.
One of the biggest problems in web accessibility is that many people start with the advanced user interface, take that as a given, and try to “add accessibility.” Many websites are designed from the UI in rather than from the content out.
Take a geographical mapping application such as Open Street Maps or Google Maps as an example. It’s easy for developers to plot out company locations on a map. When embedding these types of apps within a web page, there may be a focus on making that interface accessible—ensuring that the user can navigate with nothing more than a keyboard, for example. This is great, but there’s a problem: technically complex or advanced user interfaces can’t be viewed or used on every device. There’s only one type of content that can be viewed on virtually any web-enabled device, and that is plain text, or rather, plain text that’s been structured with HTML. Like it or not, HTML is the way we structure plain text for the web, because HTML is the single most portable and universally readable format at the time of this writing. Anything that can show websites can read and display HTML.
This means that there’s an alternative approach to accessibility for complex interfaces, and for making any content universally available: start with the text-based foundation of the website or application you’re designing, and then add the complex interface as a layer on top of this text base.
This might sound weird at first, but when you think about it, a mapping application does contain actual data and textual content. It’s simply obscured from the user. We have to deal with a layer of abstraction to get to that information. Responsive design starts at the base: the structured content level. This allows sites and apps to respond to the user’s environment, rather than expecting the user to respond to the interface (perhaps by grabbing a different device so she can actually use what we’ve built).
The way to do this is to start with the data, that is, the plain old textual content that’s always available somewhere. Don’t bury this under an avalanche of UI, but expose it from the very beginning. Allow that content to be the base on which you build.
So what about those company location maps? Well, the base data is probably a list of company location addresses, and perhaps other data such as phone numbers and URLs. My opinion? Don’t hide this data in a map. If you need or want a map, that’s fine, but leave the textual data open for the user as well, instead of taking perfectly accessible data and hiding it from some users.
If you think this sounds a lot like progressive enhancement, you’re absolutely right. That’s what it is. And of course there are exceptions; there always are. But generally, many web apps are web forms at their core. Many websites are simply structured text at their core. By starting the design at the core, we can build websites that are more accessible and more usable by more and larger groups of people.
Starting design with plain text
Designer Bryan Rieger shares my love of plain text. During some correspondence with me about the subject, he shared these thoughts:
- “One technique I’ve used for years is to ‘design in text’... not necessarily describing everything in textual form [...] essentially what is the message that needs to be communicated if I was only able to provide the user with unstyled HTML?”
- —BRYAN RIEGER
Rieger’s statement embodies most of what this book is all about: creating from the most basic, important content and working from that point forward. The technique of designing in text—that is, unstyled HTML—has some absolute benefits:
- As in content inventory and content reference wireframes, the focus is on content. In the case of designing in text, it’s all about the structure of the textual content. Irrelevant content becomes easy to spot, as it’s not hidden by the design.
Designing in text utilizes one of the most important building blocks of the web: HTML.
- The linear form of structured text prepares us for the starting point for responsive design: the smallest screens with the least capabilities. (Remember the web’s first page!)
- Clients familiar with word processors are probably familiar with the idea of linear, structured content (although some require an explanation of the difference between visual and structural formatting). It’s relatively easy to convert word processor documents into structured plain text.
When you create a page with unstyled HTML, you have created a web page that’s mobile ready. From a design standpoint, it’s also mobile first. With the default width of 100%, you might say it’s on a single-column, flexible grid. This is a perfect starting point for responsive design.
Where content reference wireframes get us thinking about content at a block level, designing in text shifts the focus to the smaller bits of content. Let’s take a look at how these ideas apply to the book website.