Comments on Practical Applications: Visio or HTML for Wireframes

R. A. White — Tue, 28 Aug 2007 00:45:23 GMT

More great reasons to use Freehand: multiple page support (not in illustrator for *some* reason) and great SWF/Flash support. Perfect for mocking up storyboard animations also, and if the destination medium is Flash, you can also pre-define symbols and save time.

I have been using InDesign of late to construct wireframes and design docs; the PDF support is much better than Freehand. Freehand is probably the best all-around vector wireframing tool IMHO. Some clients really like a printable PDF that they can print and spread out on their desk.

That said, I am very excited by this article. A few years back when I tried HTML wireframing, my lack of skills with HTML held me back; it was frustrating. Now that I’m CSS/XHTML fluent, it totally makes sense, especially for application and internet design.

Todd W.: totally hear you about clients not getting the whole wireframe idea. I put so much extra effort into setting expectations and making sure the client understands *what* the wirframes are. Usually, the analogy of the architect’s blueprint gives concrete thinkers something to connect with conceptually. “You know-wall here, plumbing here, look-a door! etc.”

One problem I haven’t figured out how to surmount is clients that get it (or pretend to), but then have to get approval internally from people who they think can’t understand. What then? (sorry if that’s getting OT =).

StudioDino — Tue, 28 Aug 2007 00:24:51 GMT

Good points overall – this forum is a great way of having a healthy discussion on Web development, and at the same time, open our minds to new insights: the final result to become better specialist in our fields.

For me, my “creating wireframe tool” of choice is Macromedia Freehand. This allows me the freedom to export files to any format, TIF, GIF, JPG or EPS. The files can be imported to MS Word, PowerPoint, PhotoShop or Quark X-press, in any OS format – from there, we developed Creative brief, Storyboards, or Technical specs for our programmers or clients. I noticed someone mentioning Adobe Illustrator for creating wireframes and site maps for the same flexibility of use.

Presenting wireframes via HTML on a computer screen would cause some confusion to the user/customer/client, unless the user is instructed on what is the purpose of this session, nevertheless using HTML wireframe for a pre-usability exercise is not a bad idea. We start pre-usability testing from the prototype (JPG images) stage, refining as we move forward.

Thanks for the good article and everyone’s feedback.

Jim Ospenson — Tue, 28 Aug 2007 00:53:09 GMT

Nice article.

I’ve done several projects where the bulk of design was executed in Visio (i.e. pages that would be used by the greatest number of users), but key administrative pages were prototyped in Dreamweaver. Since Admin users are frequently on a known platform, my crude HTML prototypes *were* often used as production code for these pages—saving time for the front-end developers. This is a judgement call, depending on the client and the tasks and rsources at hand.

Another point – When working with visual designers, it’s helpful to collaborate closely and early with the visual designer in order to work out high-level navigation structures as you begin wireframing, whether using visio (vector-based hi-fi prototypes) or HTML. When I say high-level navigation structures, I mean the basic components of primary and secondary nav structures: tabs, horizontal or vertical layout, persistent forms such as search boxes, branding elements.

In my experience, the nav structures are often presented to the client or end-users throughout wireframing, so it’s best to *always* present to the client/users a solid high-level recommendation to present that both IA and visual design can support. This goes far in *not* presenting a visual designer with a fait-accompli, and not constraining their design before they’ve had a chance to understand the project.

To do this I’d build some time in the workplan to consult with visual design as I was moving from site maps/ flow diagrams/ task analysis and beginning to get down to wireframing. Depending on resource constraints it can be anywhere from 2 hours or a week of collaboration with visual design. Then the Visual Designer would roll off until later, when we had sufficient interfaces designed to begin concentrated Visual Design (usually 40-50%, including a Home Page if possible).

Todd Warfel — Tue, 28 Aug 2007 00:53:09 GMT

Excellent article. I’d agree with most of the points, but do want to add a few items (corrections).

As the author points out, there are other options for doing wireframes and IA work. As shawn pointed out, there’s OmniGraffle for the Mac. OmniGraffle is scriptable and great for doing wireframes, IA, and visual mappings. Additionally, there’s Adobe Illustrator – my personal favorite. And like Visio, Illustrator is able to export to various industry standard formats.

I have used Visio in the past and find it to be like trying to draw using chalk on a paper bag on top of gravel. Illustrator gives you much better control, precision, and allows for the creation of beautiful sitemaps and visual diagrams – http://messagefirst.com/downloads/CLO_Site_Mapv1.2.pdf (276k). And of course, it isn’t for the Mac :(.

One correction to the article is that you can actually quickly move objects on screen in HTML – if you create the wireframes using CSS for layout, which is how it should be done anyway. Tables are for data presentation, not layout. Using CSS for layout allows the designer/developer to make one quick edit in the CSS file and viola – the object can change size, shape, placement, and appearance in no time. While you can’t necessarily drag and drop like you can in Visio, you can accomplish the same goal of quickly moving objects.

A have to agree that one of the biggest pitfalls of HTML wireframes, or any type of refined wireframe for that matter, is that clients can tend to interpret them as final designs. I’ve had it happen once or twice. And when it did, it was a nightmare. I had to explain 6, or 7 times that these were not final designs, but a wireframe.

All in all, paper “lo-fi” and HTML “hi-fi” wireframes and prototypes each have their place. Feel out your client to determine which one will be more appropriate.

Todd Warfel — Tue, 28 Aug 2007 00:53:09 GMT

Excellent article. I’d agree with most of the points, but do want to add a few items (corrections).

All in all, paper “lo-fi” and HTML “hi-fi” wireframes and prototypes each have their place. Feel out your client to determine which one will be more appropriate.

shawn thompson — Tue, 28 Aug 2007 00:45:22 GMT

Hi Jeff, Good article. Thanks. I concurr with most of your points. Once thing though, Visio isn’t available on the Mac, but OmniGraffle is getting pretty damn good for drawing wireframe diagrams. Definitely worth mentioning in the future for those die-hard Mac Information Architects out there looking for a decent wireframing tool.

Dan Saffer — Tue, 28 Aug 2007 00:53:09 GMT

Nothing says you can’t do both, either. First, do Visio/paper wireframes, then do a more fleshed-out prototype in HTML to see how the navigation and page flows really work. Easier (IMHO) to do any user testing on HTML prototypes than with paper anyway.

Gene — Tue, 28 Aug 2007 00:45:22 GMT

Often I find that different projects require different approaches. Sometimes I use paper prototypes and other times hi-fidelity HTML wireframes. If you are presenting multi-layered information to the user and are having a difficult time envisioning how it works, often I find that using an HTML prototype helps me see how things could be put together or more importantly see where things beging to fall apart.

Steve Hunt — Tue, 28 Aug 2007 00:45:22 GMT

hehe Dan,

All of your points are valid and ones which I wholly identify with.

Your first point about the client is an absolute reality, and something which I come across over and over again. But to simply move from paper onto ‘finished design’, without planning and mocking up web work in ‘vanilla’ html first has always proved really detrimental to my final work.

AND I have worked with clients who refuse to believe that anything planned/drafted/presented on paper (no matter how meticuously) can be in ‘any’ way indicitive of final design. Despite the fact that the basic interaction HTML models always look/feel ‘less finished’ than the initial screens from which their build is taken.

Perhaps what we really need is not an article on what tools to use, but on how best to teach the client the ‘ways’ of us; that we know best, and to trust us (even if our IA stuff consists of post-it notes connected with string) ;-p

Jeff Gothelf — Tue, 28 Aug 2007 00:45:22 GMT

Thanks for the kind comments. I wanted to address Leo’s points specifically (and send him an example).

1. Depending on how your organization’s methodology is setup, you may or may not have a detailed functional spec document. Some use use cases, others use separate docs. In my experience, it is a big pain (as Dan notes) to hop between applications or even printed documents to get all the information you need to develop. Therefore, I strive to place as much functional detail on the wireframe. This requires me to understand the technology that will go into building the application and I often consult a tech lead on the feasiblity of an idea that I have.

2. That being said, not everyone has a great development team backing them up and so we are forced to understand the technologies we design. Also, understanding these technologies allows us to realize, reach and push the boundaries of our interfaces.

3. Finally, I agree that IA is a unique discipline but it DOES need to follow a model. Even in a good economy we all switch jobs occasionally and need a certain methodology to follow so that our deliverables meet the needs of our current development team. Don’t misunderstand, I am not suggesting you quit using PowerPoint. If it works for you, great, but if it doesn’t deliver the kind of information your developers need to complete their builds on time and on budget, then perhaps I have given you a new method to use within the context of my article.

Thanks for reading!
[Jeff Gothelf]

PeterV — Tue, 28 Aug 2007 00:45:22 GMT

Here is an example of a prototype (it isn’t really a wireframe) done in Visio. http://petervandijck.net/portfolio5.htm or http://petervandijck.net/images/layout500.gif It was exported as a clickable HTML prototype. I know others have done nicer looking ones, and *real* wireframes (with less design elements).

I prefer doing my wireframes in Visio, because of all the reasons mentioned, but mainly because you can give things a distinct *look* that clearly converys this is *not* the website design.

Leo Sarmento — Tue, 28 Aug 2007 00:45:22 GMT

Hmmm… I´ve been using for quite some time only Power Point Wireframes. I realy would like to see the looks and feel of a Visio Wireframe. Could someone send me an example? (leosarma@brturbo.com)
I agree with most of the article. But I would like to add some.
I think a Wireframe is a structure… a skeleton of a necessity. The technology that will be used when the end meets, realy, that´s not of its concern. I prefer not knowing anything of HTML, XML or FLASH, and concentrate on designing the user experience, flat and square, and having a great development team backing me up. They worry about all the other issues. I think our job as IA is extremely important and should be unique, not following any model at all. Those technologies blocks us on their usual limitations. I´ll come up with whatever is necessary… let them figure out how to realize our “visions”. And the web will evolve.

Dan Saffer — Tue, 28 Aug 2007 00:53:09 GMT

I used to be a huge advocate for HTML wireframes, but in the last two years have reversed my opinion, for a few reasons:

1) Clients thought the HTML work was basically done after the wireframes, not knowing that I had done them as rough and ugly (code-wise) as I could.

2) Like you pointed out, Jeff, printing them is a pain. One trick: Make one master page that contains a link to all the other pages (which is, itself, a pain to maintain). Then, when you want to pint out a whole set of them (usually to show the client), under Print/Options in IE, check the Print All Linked Documents box. They will still come out pretty broken up, but it’ll save a lot of time.

3) Vanity. They look lousy in a portfolio. Seriously. I never got complimented on my HTML wireframes and my Visio ones looks infinately more professional. I lost a job over it, I’m sure.

4) Developers hate them because they have to leave their programming tool to flip through an HTML site to find what they are looking for, rather than just have a sheet of paper next to them.

5) Same deal with Designers. No one wants to hop out of Illustrator to see what a tab is named.

A cool article though, one I’ve been waiting to see for a long time.

Dan

Steve Hunt — Tue, 28 Aug 2007 00:45:22 GMT

hehe.. err that url by my name in the above response isn’t mine, and is NOTHING TO DO WITH ME. I don’t have time for a personal site so just typed in anything. I didn’t actually know that that existed, so it wasn’t an endorsement or anything. This one is though. The BBCi homepage was my last big project.

(sorry about that)

Steve Hunt — Tue, 28 Aug 2007 00:45:21 GMT

This is a useful and informative article Jeff, thankyou.

I would like to highlight one point you make towards the end and actually feel that, rather than being a Visual Layout vs HTML ‘prototype’ comment, the discussion of ‘context’ of usage of these tools is of far greater importance. (It’s been a long day today so apologies if my sentence structure is a little ‘squiffy’ ;-p)

On nearly all of my projects for the past 8 years, I have used lo-fi (scribbled post-it note style wireframes) and higher-fidelity ‘html prototypes’, plus the many myriad of hybrid solutions in between. On some projects I have used all these methods, on others just the one. It really does depend on the context of the project and the nature of the work.

You are right about the usability differences between the two however, and this is indeed a difference that should not be under-estimated.

Whilst ‘paper’ wireframes aid in initial problem indentification, and basic solution discovery, the results of nearly all of my user testing have differed quite considerably after transposing from flat ‘2d’ paper and into a more interactive/immersive screen environment. I have always found it useful to be itterative within both environments as this, despite being initially time-consuming, really stops some of the later pitfalls of development.

An excellent beginners guide though Jeff, and something I wish there were more of ‘back in the day’ ;-p