Heaven help us if we need yet another technical document to describe what it is we need to design, develop, or structure. I am all for documenting things, but at some point, enough is enough. This is often where the documentation process becomes more effort than it’s worth.
Now, as an Information Architect, I can assure you that going without blueprints is no way to build a website. But what are blueprints, really? Think about all the sitemaps, wireframes, personas, process flows and such that you created on a project. While all of these deliverables are valuable to the creation of the site, they are not all recyclable.
Yes, I’m talking about creating IA documents, or any documents for that matter, that can be reused. Think about the documents you create as an IA and what specific goal they have: to communicate the location of different types of information, to communicate how the navigation will work, to communicate the location of pages within the site, etc.
Recyclable Formats
Now think about the traditional format of these documents. Sometimes they are created in programs like Visio, OmniGraffle or ConceptDraw and are often saved out as PDF or just handed off in the native format. In a few cases, IAs may use tools like Illustrator, or even just Microsoft Word or Apple Pages. These formats are non-recyclable beyond textual cut and paste, or maybe some reusable infographics.
What if the documents you create as an IA could be re-used by yourself or others working on the project? What if those documents could be built on and expanded to eventually become the final product itself? If you have done any prototyping work, you can probably already see my point here. Prototypes are often just HTML versions of wireframes with maybe some more detailed content. Just static web pages with links to other static web pages.
If you are following modern web standards practices, these pages are probably built with XHTML for structure and CSS for markup. XHTML is an excellent structure that can serve as the basis for a wireframe that can later be transitioned into a prototype and eventually designed via CSS and so on. No material is wasted. Doing it the old-fashioned way you’d have to re-invest time in creating an XHTML page based on the wireframes done in PDF or a native file format for the tool it was created in.
Benefits
Why would we want to do XHTML wireframes? Wouldn’t it take more time to do them in XHTML than it would in Visio or something? Well, yes and no. Yes, you would have to code the XHTML, but that would need to be done at some point anyway. It may seem like it’s slower to create wireframes in XHTML, but once you have done your first website using this method a lot of the same markup can be repurposed, especially when it comes to navigation and various methods of displaying information on a page like multi-column lists and so forth.
In the end, it’s actually more efficient to be building wireframes in XHTML and even navigation schemas because you can see exactly how it works and you only spend the energy necessary to create it once, not twice (once in Visio and once in XHTML).
Don’t take that point I made about seeing how it actually works too lightly. The number one cause of scope change, hour overages, and elongated project phases has to do with the client fully understanding how something will work on a functional level.
When you show clients a PDF of your IA, I don’t care how good of a presenter you are, they are only going to be able to absorb so much of that information. Odds are, they will come back after the initial development phase and request changes based on what the functionality currently is and what they thought it was going to be like based on the IA documents. So why not just show them how it will actually be first and save yourself and the client a little time, headaches, and budget?
Not for everyone
A note of caution here. At Blue Flavor we have used this XHTML IA process to create wireframes, navigation schemas, and even site maps for various projects… but not all of them. XHTML wireframes are not ideal for all projects. Make logical decisions when choosing one method over the other on a per-project basis.
Sometimes it may make more sense to do the IA in good old OmniGraffle than it would to do the markup. Each project is different so consider all the variables and don’t set it as a new company wide mandate. Use it cautiously where it produces the most value with the least amount of effort.
Resources
If you are seriously considering doing XHTML IA, here is a list of a few resources you should check out. Feel free to list additional resources I may have overlooked in the comments are of this blog post.
Just Build It: HTML Prototyping and Agile Development
by Garrett Dimon
Practical Applications: Visio or HTML for Wireframes
by Jeff Gothelf
HTML Wireframes and Prototypes: All Gain and No Pain
by Julie Stanford
How do we do HTML wireframes?
by Gene Smith
First Things First: IA and CSS
by Nate Koechley
Make an HTML Wireframe
by Dustin Diaz
Using Prototypes
By Gerd Waloszek and Joelle Carignan
For me, the distinction goes something like this:
If you already know enough about what you want, building it in XHTML is a Good Idea. If the client is unsure or there’s a lot of waffling going on, it might be better to play with a faster medium for a while until things get more solid. Once you have a good working draft and have defined core conventions, the XHTML road will save time for sure.
To use an egg metaphor (we struggle in our house to get soft and hard-boiled eggs to come out “just right”), you want the white part (surrounding structure) to be solid, but there’s some variability in peoples’ preference on the yolk, or what happens inside. You need a good conceptual framework for a site, then you can handle the variability of preference for some of the details and new features that inevitably come along.
Rapid prototyping and building high fidelity wireframes is also an advantage when undertaking usability testing. XHTML/CSS wireframes are valuable when pilot testing. Any amendments can be quickly implemented to firm up the product before taking it to the usability lab.
I also find sharing a link to an XHTML prototype a lot easier to share than attaching heavy PDFs.
I obviously whole-heartedly agree, but you’ve done an excellent job communicating the point. Beautiful.
Gabriel - I’d honestly argue the opposite based on my experience. There’s times where we we spent an inordinate amount of time doing and redoing wireframes not because we were off base, but because the client just didn’t grasp the wireframe idea. We went in circles over and over again because they couldn’t touch or feel what we were trying to do. Admittedly, we still had some rough spots once we went to XHTML, but they were significantly fewer. Every situtation is different, but from my experience, I’ll always lean towards XHTML first and fall back on wireframes if I think they might help. Otherwise, a sketch is plenty for me nowadays.
On my last project, I used flat wireframes to initially document my thinking and give people something with annotations explaining elements, then created XHTML to click through and demonstrate how it would flow. One benefit was that I picked up things I had missed in the flat file. The other, of course, was that the stakeholders got a better picture of how it would hang together.
I’m fast at both now, so have no hesitation doing the XHTML any more…
One other benefit of doing the wireframe in XHTML rather than a static file like a PDF or JPG image, etc. is that you know the client will be seeing the page at the screen size you intended. JPEG’s have a nasty habit of being resized if viewed in Internet Explorer, and there’s no garauntee that the client is looking at the PDF at 100% view or not. Even if you are designing a purely liquid design, there are always going to be some elements that need a fized size (images, etc..).
Getting approval on photoshop mockups or pdf wireframes, only to have the client complain about the page size once HTML production starts is a drag. Just my 2 cents from past experience…
I also advocate the use of html-based wireframes for prototyping. If the code is written well from the beginning, it will simply get rolled into the development stage and in the long run, you will save time.
However, if your IA’s are not experienced enough with development to write semantic xhtml, they may either be reluctanct to adopt this process, or they might jump into their favorite WYSIWYG editor and produce code that will need to get rewritten anyway. In this case, you lose much of the benefit of this method.
Also, if your company is large and/or heavily silo’d and your IA group is not affected by the concerns of the development group, they might shrug off the idea that if they do not learn to write the code properly, the time spent on their xhtml wireframes is essentially wasted. This is a situation that I ran into recently.
I suppose everything can boil down to internal politics, but when trying to introduce a new process, one road block might be your teams adaptability and willingness to learn/change. The era of the webmaster/jack-of-all-trades is gone, and it seems that nowadays, people are tending to specialize and don’t come with the varied skill sets that they used to.
…sorry one more thing. Sometimes their is a bit of specialization snobbery, where an IA might scoff when you ask them to write code. I guess their feeling is that have worked their way up from the bottom, and have worked hard to be where they are now, they shouldn’t have to get their hands dirty in code anymore.
(I don’t feel this way obviously)
Great post, Nick. One thing I’d add to this is: sometimes, creating a design model that you know is not recyclable (in the way you mean) is an important way to move forward in the design / build process.
I think there are two forces at play that are important to recognize: 1) contraints on the design process, and 2) the clean separation of distinct layers of definition.
With regards to constraints on the design process, we benefit from some, but not too many; and from clarifying ones, but not complicating ones.
So, working with drawing programs like OmniGraffle constrains your process differently than working with HTML / CSS. And, sometimes, working with a drawing really helps you clarify things because you can experiment in ways that are independent of HTML (for example, it’s easier to model non-rectangular areas).
HTML let’s you experiment and clarify things in other ways.
With regard to the clean separation of distinct layers of definition, working in HTML / CSS should require you, from the start, to be thinking about what defines good HTML / CSS code (HTML semantics and CSS layout rules). And, that can either get in the way or help you with moving forward and defining good information relationships (information semantics), etc., e.g., depending on how much you know up-front about how those relationships are or are not going to tied to HTML code structures and CSS’s abilities.
I think though, generally speaking, when we are designing HTML / CSS websites, we think about HTML / CSS pretty early in the process, and so it’s natural to get into the HTML / CSS early-on.
Personally, I find myself doing wireframes in OmniGraffle with certain details handled in XHTML. I like to work back and forth between these tools when I can.
Nick, great discussion on a topic that seems to be more and more important with us.
Jay also points out the distinctions well, noting when graphic wireframes might better serve and when HTML wireframes are ideal. What I think would help make most people take the leap and go the route of HTML wireframes is a tool or IDE — much like a CMS — that will let you lay wireframes out, cleanly build out the markup, let you style it, and document the elements. I’m not talking about Dreamweaver. I have Axure and think it comes close and is suitable for wireframing and building prototypes for demo/test purposes, but it still doesn’t produce clean markup that you can do any development from.
Wireframing for me is intentionally low fi and disposable. It can be a big part of the communication process in design as well as part of the development process. They help people visualize communicated (spoken/written) specifications and often point out where people are not on the same page. For me they’ve often been temporary documents to poke at and grafitti with notes. HTML wireframes/prototypes can really give you the feeling/interaction of dynamic elements, but to some clients can feel very final and may cause the client to feel different about commenting on changes to a final-feeling document as opposed to a low-fi paper document (or PDF).
I do HTML wireframes with certain groups and in certain situations, e.g. to demonstrate interactivity. But in addition to the reasons I point out above, I find it quicker to do them in Visio or OG. After a meeting, I can often bang out a Visio document using all of my pre-assembled libraries (stencils) much more quickly than I can in HTML. The purpose of the doc for us is to continue discussing/validating/invalidating decisions made as a group, then note take and discard it to build the real thing.
Until there is a tool that will actually allow me to build the visual document as quickly as I can with Visio, I actually think the time is better spent doing quickly them this way. Of course, I can see the value in going from HTML wireframe to production markup. I’m waiting for the product that let’s me do it the way I want, with the clean markup I want. I’ll work with anyone who wants to discuss building it. Until then I continue to live with Visio.
Congrats! Some real great information here on your page. Quite an effort! I wonder how someone can contribute so much to the industry. Please keep the hard work up. Please let me know if need any info or help on <a href=”http://www.virses.com” rel=”nofollow”>architectural renderings and illustrations</a> Regards!
I agree with Singh on the information above. We too provide <a href=”http://www.lunarstudio.com” rel=”nofollow”>architectural renderings and illustrations</a>. So please feel free to write us!
And here is another one with <a href=”http://www.3ddreams.com”>Architectural Renderings</a>
Every situtation is different, but from my experience, I’ll always lean towards XHTML first and fall back on wireframes if I think they might help. Otherwise, a sketch is plenty for me nowadays…
thanks all
Inspired, I build a tool to convert Excel files into Visio sitemaps. Using Excel I can concentrate on the logic of the information architecture and navigation instead of fussing with how it looks.
http://jasonpearce.com/blog/2008/02/08/lazy-sitemap-generator/
I hope you and others find my Lazy Sitemap Generator useful.