Design the HTML
Originally published Friday, October 11, 2013
We keep using that word: “Content.” I don’t think it means what we think it means.
The question of whether “designers should code” can induce the same level of debate as “Emacs or vi”. At its most basic level, the argument is more or less whether “designers should understand how to execute their ideas themselves.”
As a developer, I couldn’t care less about whether a designer I work with does or doesn’t know how to code. (After all, I have to have something to do to get paid.) But I wholeheartedly agree that an understanding of how a medium works is critical to good design.
That’s why I think it’s important that designers understand markup. And markup isn’t code.
Imagine if you will: A small web project, with a designer (we’ll call him Mark) and a developer (we’ll call her Susan). The project proceeds in the time-honored tradition: (1) The customer provides the content. (2) Mark gets the customer’s agreement on a design. (3) Mark sends the design assets to Susan for implementation. To Susan’s surprise, Mark’s actually done a great job of layering and grouping. All is well until…
She gets to that one element. You know the one. It has beautifully rendered effects on the edges, achieved with multiple layer styles that can’t be duplicated in CSS. It has large headings, using a font with no web license, that have a glassy effect, translucent stroke, and reflections. It is truly a thing of beauty, and it’s nestled into the overall design in just a perfect way — it perfectly draws attention, it feels at home in the overall design theme, and it’s the customer’s favorite part of her new website.
And it’s a complete failure on Mark’s part as a designer.
What’s the problem?
To implement this, Susan’s going to have to export image assets and either include them as <img> elements, assign them as the background on an empty (and therefore meaningless) element, or put text on the element and move it off-screen with CSS trickery. The background container could end up causing Susan an additional nine empty elements just to contain all the layered effects. In short, the result is potential semantic and accessibility problems, not to mention an increased cost in kilobytes for all the images that need to be downloaded.
From an engineering perspective, this is bad because it requires a hack. Hacks are un-maintainable and costly in the long run.
From a management perspective, it’s bad due to the increased cost — Susan has to spend additional effort to work around the design, rather than work with the technology’s native capabilities.
From a design perspective, it’s bad because Mark has completely ignored both the audience and the content. Why? Because he thought the audience is human beings reading the website, and he thought the content is text and images. He’s wrong.
The audience is a web browser. The content is HTML.
… Say what?
Allow me to explain: when a designer is putting together a layout for print, say a magazine article, s/he are focusing on things like position, size, color, etc. In essence, s/he is going to develop a system for conveying meaning to reader: This idea is more important, that idea is less important, this idea follows that idea, this idea is important but only relates tangentially, and so on.
Print designers develop a visual language that conveys abstract concepts of hierarchy, inheritance, and relationship. It gives the reader context, and helps them to both consume and understand the content.
Imagine, though, that after a magazine article is published, the magazine is picked up by a third person and read out loud to the intended audience. He or she will then need to use vocal tools (or body language) to convey the same sense of meaning to the person(s) listening. If the designer has done his or her job well, the reader will pronounce headings with more emphasis, give a short pause between paragraphs, stress certain syllables, or change his or her voice slightly to indicate parenthetical asides. In short, the reader will consume the designer’s intended semantics, understand them, and convey them to the audience.
That’s exactly what happens on the web.
When a web page is written, there’s a third party sitting in between the person creating the content and the person consuming it. That third party is a well-known piece of software called a web browser. And that visual language? The one that conveys abstract semantic concepts to the reader? It already exists, and it’s called HTML.
You see, in the above example, I believe Mark stops halfway. He does a great job designing for the end user, but spends no time at all designing for the first user that will consume the content. Therefore it’s up to Susan to play the role of designer, and put together the HTML that will convey Mark’s intended semantics to the browser. Her ability to do this job is impeded by some of Mark’s visual decisions.
Seeing the markup
Understanding HTML really isn’t that difficult. In fact, if you can understand 8th grade concepts of writing an outline before starting an essay, you can get a pretty good concept of what HTML is designed to convey.
If Mark were so inclined, his first step in designing for his user’s content would be to try to see the structure. What are the major sections? What are the headings? What should be presented as a paragraph? What should be presented as a list? The good news is, he’s probably already doing that. Now all he needs to do is find the correct elements (<div>, <h1>, <h2>, <p>, <ul>, etc.) and plug them in.
This step is essential, because if one can describe a design as HTML, the page can already be delivered to (and understood by) 100% of the potential audience — as is, with no visuals necessary.
Mark’s second step, after the content is organized semantically, is to start designing visually. He develops a typographic hierarchy, and maybe a grid. He adds position and negative space, color for accent and calls to action. He considers whether the presentation will need to change for different devices (the answer to that is easy: It will) and makes adjustments accordingly.
This step is important because it reinforces the hierarchy, supports a brand (very important for his customer), and sets the visual tone for how the end user will consume the text and graphics. But it’s not as important as the first step. If all the CSS and visual style were removed from the website, the web browser (and thus end user) could still read and understand the content.
The tricky bit
After that comes the veneer. The little touches. The bits and pieces that make the design really stand out, and gives the website a unique voice in the cacophony of content that is the internet. This is the part where Mark has, in the past, justified his paycheck. And sadly, this is the part where he’s now going to struggle.
He’s going to have a difficult time understanding how to describe the things he’s adding with terms that make semantic sense: Why are there two boxes around that pull quote, one of which has a nifty photo-realistic border, and one that’s just plain white? Can he translate that to the browser without using a redundant element? The more he dives into his usual bag of tricks, the more stymied he’s going to be, the more boxed-in (literally) he’s going to feel.
But in the long run, he’ll come out with a much stronger understanding of the medium he’s working in.His designs will be better because they’ll be addressing the content in a much simpler and straightforward fashion. He’ll be ready to move to responsive design, and start to feel more confident about delivering content to any device.
And perhaps most importantly, Susan will enjoy working with him a lot more.
Originally published at Medium.