How do we do HTML wireframes?

There's been a lot of chatter on the IA lists over the past couple weeks about HTML wireframes. How do you do them? What tools do you use? How do you deal with problem X?

Here's a round-up of the conversation. (Thanks to Austin Govella for bringing it up.)

Why HTML wireframes

The big three reasons for HTML wireframes were:

• Generate testable prototypes
• Reduce wasted time and effort of reworking Visio wireframes or comps into an HTML product. For his work, Thomas Vander Wal reported that "the semantic framing of the pages in (X)HTML makes it all the way to production in 95% of the projects."
• Work in the medium you're designing for

Methods & Process

• The most common method was "use Dreamweaver." Julie Stanford has written a couple of Boxes and Arrows articles on the topic (linked below)
• A number of people mentioned using Axure RP, which generates a clickable HTML prototype. Serena's ProcessComposer generates an HTML prototype as well, though I think this was only seen in a demo.
• A couple of people rolled their own HTML prototypes with a database, scripts, XML and other tools.

Thomas Vander Wal went into some detail about the process his team uses:

Similar to the CSS Zen Garden the framework only structures the content objects and the presentation layer is either largely or completely done in CSS. The initial wireframes are done with a CSS that only sets intial fonts and turns on content block borders so the page takes on a wireframe look. Visual designers/information designers do their work on top of the XHTML wireframes by changing the CSS and adding visual elements where needed.

When there are changes to the XHTML structure farther down the line in the workflow these changes are easily added back into the wireframe stage to ensure documentation is consistant with the end products.

Being able to iterate in a clickable wireframe and start getting the right questions asked early as well as having the IA's wireframe work product used in the workflow (not having to rework the Visio or Illustrator comps) is incredibly efficient and gets needed questions up front when it is least expensive to make changes.

The IA, visual designer, and engineer/developers all can work as a team and are working off the same real component of the workflow.

Anders Ramsay added this (he uses the terms standards-based wireframes instead of HTML wireframes):

Standards-based wireframes, however, allow the IA to describe content without describing layout or styling (among many other advantages) by leveraging the XHTML/CSS separation of content and presentation. This, in turn, allows for potentially being able to reuse 100% of the IAs work... Think of the standards-based wireframe as the unstyled version of a web page, in which content presentation is hierarchically and structurally correct (content is ordered correctly, page headers use the h1 tag, etc.), but with the important addition of having self-describing meta data (e.g. ID="global-nav" as opposed to ID="blue-module") For this reason, I have found hand-coding the wireframes to be most effective. It also allows me to incorporate a lot of best practices (such as us of the <LABEL> tag for form labels), as well as defining content classes as I go (e.g. an 'error-message' class, which I would apply to error message copy.) Of course, I am not defining these classes or the wireframe as a whole in isolation. The wireframe is produced after a design concept has been defined by the team and in close cooperation with other team members, especially the visual designer and most likely also the site builder (in fact, part of the beauty of this model is that it enforces close cooperation), which leads to another [Dreamweaveer] advantage - single-sourcing and file sharing with file check-in/check-out."

Dave Heller brought up this potential drawback of HTML wireframes--multiple files for sign-off:

"To review HTML wireframes is to review multiple files. Sign-off (where that exists) is more difficult to control, especially in environments that are audited. But that is extreme for most of us. But even w/o that, I find it a lot easier to communicate around a single document/file than around a website when I’m talking about documentation, which is what a set wireframes are (at least in my process)."

Annotations

Annotations can pose a problem with HTML wireframes. Here are some suggestions people had for handling them:

• "print the XHTML to PDF and annotate the PDF in Photoshop or Illustrator (I believe it can be done in OmniGraffle also with a layer)" (Thomas Vander Wal)
• "We do all of our wireframes in Dreamweaver--fully clickable--and our annotations are in tables beneath the wireframe on the same page" (Lisa Colvin)
• "What I'd do is embed the notes in a <div> or <span> inside the <div> for your element/object in the wireframe. Then use your favorite stylesheet switching method (or the built-in CSS switching in Firefox) to hide or display the annotations inline rather than at the bottom of the page." (Michael Angeles)
• "A somewhat more robust attempt at incorporating annotations has been made by the W3C with their Amaya tool (http://www.w3.org/Amaya/), which uses RDF and Xpointer to support annotations" (Anders Ramsay)

Tools

Listed in order of popularity. Roughly.

• Dreamweaver
• Axure RP (we've used this as a prototyping tool; not quite there for wireframing though, e.g. no zoom tool)
• Serena ProcessComposer
• GoLive
• ColdFusion MX, ASP, PHP, etc.
• Drupal wireframe module (I don't think anyone had actually used this)
• A few text editors, e.g. Notepad, were mentioned as well.

Articles

• HTML Wireframes and Prototypes: All Gain and No Pain (Boxes and Arrows)
• Dreamweaver Primer (Boxes and Arros)
• Practical Applications: Visio or HTML for Wireframes (Boxes and Arrows)
• First Things First: IA and CSS (Nate Koechley's Blog)

Outstanding Questions

• "How do you keep track of versions and changes?" (Crystal Kubitsky)
• "Why are we still talking wireframes though? There is so much innovation waiting to happen in tools for IA's, and wireframes are such a tiny part of that." (Peter Van Dijck)