Designing Fictions, Part 2: Thoughtful HTML & Content Structure

(This is the second part to my process of designing my Fictions homepage. Here’s the first part, in case you haven’t and want to read that first.)

It seems there are two distinct approaches to laying out content in web design: content first, versus design first. I’m not about to start arguing which is the better approach, but I do know I’m using the former approach with this project.

The Typical Process

The typical development team approaches content development by first coming up with either the wireframe or mockup, or frequently both. Based on what they understand about what the page does, they imagine the steps the user goes through before coming up with blocks of content laid out in an interface that is hopefully easy to use. After which the designers and/or developers take over to code things up.

My Preferred Approach: HTML First

I’ve, since many years back, established my personal process – one that places emphasis on the HTML. First, because I’m in the privileged position of knowing my content (it’s my fictions homepage after all), I’m able to, from the start, divide the content into 3 main sections: a Fictions section that briefly describes my fictional works, a Works section that lay out my existing works, and finally a Connect section that invites users to connect with me. Without worrying about where the individual content blocks are laid out at this stage, I dive straight into the code and come up with the below:

 <article id="home">
<section id="intro" class="tcenter rel">
<a href="/"><img src="images/uebyn-logo.jpg"></a>
<p>is the pseudonym I adopt as an artist, no less because it emphasizes my individuality, which I hope is expressed in my works.</p>
<p>I consider myself a <em>narrative artist</em> working primarily with words, stories, colors and type.</p>
</section>
<section id="projects">
<h1 class="sans">Projects</h1>
<dl>
<dt>Ongoing</dt>
<dd>
<span>Scraps</span>
<span class="year">2014 -</span>
</dd>
</dl>
<dl>
<dt>K.I.V</dt>
<dd>
<span>Parallel</span>
<span class="year">2011...</span>
</dd>
</dl>
<dl>
<dt>Completed</dt>
<dd>
<span><a target="_blank" href="http://minimal-english.uebyn.com">Minimal English</a></span>
<span class="year">2008</span>
</dd>
</dl>
</section>
</article>

The reason I’m starting with HTML is because I know that HTML is the foundation of the Web. No, it’s not CSS, which styles the webpages, nor is it Javascript, which improves the interactivity of the Web. Give anyone a most simple web browser—say a Lynx or a smart watch—and he should, without gorgeous styling and cool animation, be able to browse the base text content without any issues. By coding up the HTML content from the start, I’m essentially ensuring that I’m laying down the right foundation for CSS and Javascript, much like a professional painter smoothens and cleans the wall before applying paint to it.

More Appropriate HTML

I find that by focusing first on HTML content, you are more likely to choose the right HTML code for the occasion, whereas diving headfirst into the visual design encourages one to skip over code. As a simple example, every page should have a <h1> header that explains what the page is about. If you start coding with the design or mockup in mind—say for instance with the final design of the page here,

Final Design of Fictions Homepage
Final Design of Fictions Homepage

it’s easy for you to forget that fact and not code the header in. When you focus solely on determining the right code for the content though, you’re less likely to be distracted by the visuals and more likely to remember to hook the page to a top level <h1> header, like all pages are supposed to. By focusing solely on the content, I feel more capable of coming up with semantically correct HTML that describes the content accurately and in a way both search engines and visually challenged users are able to digest easily.

That Being Said.

In most of my working environments so far, starting off with mockups has been the norm. In fact, in many cases, that’s all I get; no actual written content or information architecture is provided by anyone else, and I’m expected to come up with the code based solely on the text (if any beyond Lorem Ipsum) in the mockups. While not ideal, this is one of the ways bigger teams manage the development process, and I’ve learnt to make the best of it. In fact, this gives me an opportunity to polish my copywriting skills and test out how well I can write HTML with just the mockups at hand. (Which I’ll find out when testing the accessibility later. More of that in another post.)

Structure and Semantics Matters.

At one of my previous companies, I was given access to the information architecture of the website I was to code HTML for. These were prepared by the project managers who knew the content and were required by the process to come up with an Excel sheet laying out all the mandatory content.

In spite of that, the content provided was organized from a top level and could not possibly provide all the necessary details needed in a properly coded HTML page. At the end of the day, it is still the HTML coders who make the final decisions as to what the HTML content should be for each individual page. By breaking the HTML into distinct sections, each with a header that describes the section, and using the right tags to describe each and every element on the page, the HTML coder is providing a digestible road map to the content that is to be consumed by the user, even if the user does not have the capability to interpret the content visually.

HTML Matters.

The reason I’m spending so much time talking about this is that I see a disturbing trend of professionals in the industry putting all their focus on the Javascript side of things without consideration for the most fundamental technology of the Web. By taking the easy way out and using <div>s everywhere and using <span>s to emulate buttons and links, they/we (I’m guilty of it sometimes, too) are increasingly ripping the Web of its universal accessibility and making web content bad.

Moving On.

So now that I have my typography and proper HTML in place, I’m ready to build my design. In the next post, I’ll describe how I decide on my layout, by designing in the browser.