dry htmling

improving your workflow

I used to believe that the input for html was a combination of wireframes and designs. The result was that the html phase in the development process could only start once the designs were finalized. This way of working proved to be rather inefficient though, as there weren't too many options to work parallel to other phases, dragging out the development time considerably. Further proof of this issue could be found in last year's design in your browser hype, where people were trying to merge the design and css phase.

The problem with designing in your browser is that you're basically doing not two but three things at once. You're not only developing a graphic design while writing css, you're also writing mark-up to hook your css to. Separating the priorities of these three tasks is virtually impossible, so ideally you would throw everything away when the design is finished and start the html and css work all over again. If you've ever worked on a real-world project, you already know that's not going to happen. On top of that, you're not really improving your workflow when you work like that.

And so we needed a different approach, one that would allow us to win time on the overall development cycle, but would also allow us to focus on writing quality html.

ditching the design

The solution to our problem was actually quite simple: just ditch the design and use the wireframes as your sole input document for writing html. After all, wireframes are a means of showing "what" goes "where", which happens to be a perfect match for "semantics" and "structure", the two core principles of html. Sure there are times when we have to provide extra hooks for styling, but these are the exceptions, not the norm (especially with css3 and progressive enhancement in mind).

By starting html development as soon as the wireframes were finalized, it became possible to deliver the html version of the templates at about the same time the design was finished. There was only one final check needed to see if and where extra structural elements were needed. Once those were added the html work was finished. Developers could start the implementation while we could begin work on the css and javascript tracks.

so why is it dry?

If you're not used to writing html based on wireframes alone, it can be a little daunting to start for the first time. There's little visual pay-off and there's no real sense of accomplishment. You're basically looking at black and white drawings and translating those to a mesh of tags. The most exciting thing is coming up with good class names. Not exactly rock & roll (or breakcore, if you're not living in the 60s anymore).

That said, there's a lot to be gained from adopting this way of working. For one you lose all the visual clutter that a design offers. Putting it like that may sound a little disrespectful, but even though designs have a clear functional vision, they are also meant to make things more attractive. A focus block on one page can look very different from a focus block on the next page, but at their (html) core they are the still very much the same thing, so the html should match.

Taking a design away makes it easier to see underlying structures and semantics, usually because these elements are still visualized the same in the wireframes. In the end all you have to do is make sure that a component (variant) is either defined by an extra class or by its context. The rest of the work is up to the css guy, who takes the design and matches it to the html code.

one word of warning

Make sure you are prepared to easily change a few things around when the designs are finalized. There's nothing more frustrating than having finished your html and having to add an extra structural element on each and every instance of a component throughout a set of 30+ templates. We developed an inhouse tool that allows us to write a component only once and use that across our entire set of templates, but if you're still hand-coding this might be a bit more problematic.

conclusion

Dry-htmling brings you focus. It helps you in finding the true nature of html, which is not about writing hooks for css and javascript, but about translating components and structure to a logical set of tags and classes. On the other hand, it takes some time to get used to working days on end with very little to show for it. html is not something you can easily showcase, it is not something that looks good in a browser. The key is to make sure others understand the importance of good html while at the same time trying to make it clear that it is all a back-end developer needs to get his work started.

So the next time you get a set of wireframes, rather than wait for a design you may want to start writing html right away. If you think it's boring maybe writing html really isn't your kind of thing, in the other case you might start learning a thing or two about html.