Comments on HTML Wireframes and Prototypes: All Gain and No Pain

Che Tamahori — Fri, 26 Jan 2007 14:50:55 GMT

Wow. Lots of comments by people that don’t know how to use Dreamweaver.

Dreamweaver is a deleriously powerful tool for managing common elements or templates across multiple pages: indeed, superior to tools like Visio, Illustrator or Freehand.

The key is to use the Template and Library Item features within Dreamweaver. With these, huge chunks of a site’s navigation can be updated site wide _much more quickly_ than in Visio or (god forbid) Illustrator.

A key advantage to using HTML tables is that when an element is added to a layout (eg: you’ve added more links to the header, so it’s now 50% taller!) the rest of the page elements flow to accommodate it.

Sketching tools simply don’t do this. Changing a background layer in Visio isn’t going to bump your foreground elements down a skritch. Using HTML DIVs puts you in the same boat; that’s why Tables are preferable.

I’ve been using DW to do HTML prototyping for a couple of years now. Our company has an in-house DW extension that supplies a pallete of useful object libraries: paragraphs of Lorem Ipsum, breadcrumb trails, next and back buttons, etc. Elements have built-in CSS to give them appropriate font sizes, outlines, and clearspace. All in glorious technicolor shades of grey.

We can develop complex site prototypes more rapidly in HTML than in drawing or diagramming tools. We’ve checked. Through appropriate use of templates (and now nested templates in DW MX) we can rest assured that site-wide updates to navigation can be implemented instantly.

P.S. If you’re still worried about clients not “getting” the fact that the HTML prototypes are not designs… print them out!

Henrik Olsen — Fri, 26 Jan 2007 14:50:55 GMT

The two main reasons why I don’t use HTML prototypes is that:

1. You have to struggle with tables, in order to layout elements on pages
2. If you want to make site wide corrections, or corrections which apply to a section of a web site, you have to alter each and every page manually

As you can read in my article, Visio – The interaction designer’s nail gun http://www.guuui.com/issues/02_03_02.asp ,Visio is pretty good at these two things:

1. You can drag-and-drop interface objects onto pages and place the anywhere you like
2. You can use layered backgrounds, which allow you to make changes to multiple pages – sections or site wide – by altering a background that the pages share.

As it has been mentioned, Visio has some flaws. It isn’t possible for users to enter data into text entry fields or interact with dynamic controls, such as drop-down boxes and list boxes. But those shortcomings are hardly ever a problem, and can be solved with a bit of creativity.

If you prefer to use a HTML tool for prototyping, I would recommend Adobe GoLive. It has a thing called a layout grid, which you can place elements onto, so you avoid having to struggle with tables. It has been a while since I used it, but I doubt it has the same flexibility as Visio when having to make rapid changes to multiple pages.

Bryan Buchs — Fri, 26 Jan 2007 14:50:55 GMT

I’ve always steered clear of doing HTML prototypes where clients are concerned. No matter how explicitly you try and explain that THIS IS NOT THE DESIGN, if they can see it in a browser, the client typically starts to focus on design issues, not interaction. I’ve just found that when it’s on paper (I user Visio), those problems happen less often.

Keith Wilson — Fri, 26 Jan 2007 14:50:55 GMT

Julie,

I appreciated the article and agree that wire prototyping with HTML is very effective. I worked on a recent project where we used Fireworks screen images to prototype the system. It became very difficult to make changes after a few dozen screenshots had been developed.

There is an alternative to Dreamweaver and their ilk (sorry!) that I think people should consider. That is an HTML preprocessor. I wrote one a few years ago named htmlPX and it is freeware (www.wiserve.com/htmlpx). There are many others available.

You develop templates as plain text files and then build individual pages based on those templates. You can generate an entire site in seconds. Changes to the template creates a new look and you have a complete, interactive site.

It is then up to the designer to avoid falling into the trap of trying to make it look like a production quality site while they are trying to get feedback from the client.

Any thoughts?

L. Goffin — Fri, 26 Jan 2007 14:50:55 GMT

For infos, u can find more infos about Denim at < Berkeley Group for User Interface research
http://guir.berkeley.edu/links/

L. Goffin — Fri, 26 Jan 2007 14:50:55 GMT

For infos, u can find more infos about Denim at < Berkeley Group for User Interface research
http://guir.berkeley.edu/links/

Gunnar Langemark — Fri, 26 Jan 2007 14:50:55 GMT

Very fine points about prototyping and wireframes.
I would like to point out though, that both Powerpoint and perhaps especially Visio have close to excellent tools for interactive prototypes. They are not flat at all – unless you don’t know your tools.
One key issue with prototyping in Dreamweaver or other HTML based tool is the risk that the prototype might be taken for the product – or at least that some code will “spill” over to the end product. Prototypes done in totally different tools never do that.

ed — Fri, 26 Jan 2007 14:50:55 GMT

It’s interesting that Denim hasn’t been mentioned. It is a tool that allows fast but intelligent prototyping of sites, from entire architecture down to page design, through sketches. It can then generates HTML output, so no need to create any HTML yourself.

Also the sketch like appearance of the generated html wireframes avoids the client spending too much time worrying about visual aspects.

Needless to say from the above testimonial, i find it very useful

L. Goffin — Fri, 26 Jan 2007 14:50:55 GMT

As i told previously, one of the main problem of the HTML prototyping is maitaining and changing the prototypes. I read your primer about dreamweaver and then i remembered some technique to ease this maintenance of HTML prototype system.

A solution could be to use floating layers (DIV) and the Dreamweaver Libraries Object.

In the step of prototyping, the main issue is to validate some process and the website grid. Through HTML, you provide the ability to click and it’s great. For this step, we can imagine to make a browser dependant prototype HTML code.

So we could use floating layers positionned with an embedded CSS so we can change easily the grid within a whole site. It’s easier to manage than table. I love table but when i need to go fast, i use DIV. So through the DIV, we have a fast way to make the grid. Only one problem : it’s absolute positioning.. It can be fine for the main part of the interface of a site.

About the content of the DIV such as navigation, header, function bar, footer items that require to change all pages when we change something. We can use the Dreamweaver librairies object. It allow you to select a piece of code and stock it into kind of snippet (for Homesite user)

In all pages where u place this object, dreamweaver make a intelligent cut and paste of the code. If you change the object, Macromedia propose you to update the all the pages using the object. It does not require any server side technologie, i bet you dont want to make server side include for an HTML prototype. Librairies have an extra value according to search and replace and include because it updates the path to image or links according to the physical website structure.

For those using other wysywig HTML authoring tool, i think Golive does have a similar technique.

I think those 2 techniques can ease to maintain an HTML prototype. you’ll have probably a prototype working only on MSIE, but the goal is not to validate a corss browser HTML code yet.

george oates — Fri, 26 Jan 2007 14:50:55 GMT

IMHO I think the *best* thing about HTML prototyping is that it’s the easiest way for the client (and the dev team!) to understand the flow of the application… “What happens after i press save?”... ... “Oh that.” This saves a lot of time and money. Totally agree with Julie’s standpoint.

Julie Stanford — Fri, 26 Jan 2007 14:50:55 GMT

Hello,

I will respond in this comment to the issues raised in previous comments. However, I have to preface my responses with the bias that I spend most of my time working on large web applications as opposed to primarily content driven websites. I have not done enough research to comment substantially on process differences between working on web apps versus web content sites.

That being said, here are my responses.

Issue 1: Spending too much time on the visual look of the wireframe when it is in HTML

We actually deliberately go out of our way to make the wireframe not be very visually appealing and completely gray scale. One issue that we have found with the HTML wireframes is that it sometimes invites comments about the visual design such as “I don’t like that shade of grey” which we have been able to avoid by really just focusing on the interaction and not thinking about visual issues other than making sure that things generally align (which working with tables does for you anyway)

Issue 2: Reusing code
I feel fairly strongly that the designer should not be the implementor of a web application so that conflicts of interest don’t arise. As a result, we work closely with developers once the design is done to supervise the implementation and verify with developers while we are designing that things are feasible, but really don’t think much about reuse of code. Since we are not the ones doing the implementing we don’t personally feel tempted to have clean code or reusable code or any code related worries. We just want things to work in a smoke and mirrors sort of way to demonstrate/approximate the functionality that we are after. I can see that if you are the one who will be doing the implementation, the temptation to reuse code/clean up code may be great, but this is a situation that deliberately does not affect my work.

Issue 3: HTML being too heavy when making changes
I am not sure that we have run into this problem. L. Goffin could your provide an example of this? One thing I particularly like about HTML is that when have some big navigation change that goes accorss mutliple wireframes, we can use find and replace to change it once we have made it the way we want on one page.

Issue 4: Wasting time by spending too much time on making stuff realistic or messing with the HTML

I think it is important to be realistic of what you can and can’t accomplish with some quick HTML. Some things are best left explained and some elements of an HTML wireframe will still be flat and just a screen shot fitted into the HTML. THis is exemplified in the accompanying Primer article by the multi select box scroll bar which is just a gif and does not really work. I actually have the opposite problem of wasting too much time in Illustrator because I spend too much time aligning things and making them look perfect instead of being rough. For me, HTML has been a solution that allows me do things more roughly and more quickly. But, I think the key is to be clear with yourself and your client that you are not interested in the code behind the wireframe and that you are most interested in the functionality communication and not in the visual design. Since our HTML wireframes are so light weight and quick, we can change them quickly as client functionality needs change. We also tell the client to only view them in IE since we are not going to waste time optimizing code.

Issue 5: Avoiding being technology driven:
“Interaction design uses many methods to limit this effect. Most methods seek to remain “abstract” or “technology-neutral” during the early stages of design. Using HTML for early models and prototypes may seem innocuous enough, but it is not a technology-neutral technique.”

I am not sure that I agree entirely with the goal of remaining technology neutral. When I am designing a web application, I think it is important to be aware of both constraints and common practices on the web platform that you are designing for. A great example is a client that recently came to us with a web application that they had designed that they needed help with. Since they were not that familiar with the web, they had designed a web application where users double clicked on icons, could use function keys to access functionality, and right clicked to get accesses to a menu of options since there were NO buttons on the screen to control forms functionality. I am not kidding. Now while some of these things may be OK on a Windows application, double clicking for example is not OK on the web as everyone knows. Although design should not be tech driven, it should be tech aware and constraint aware. I think presenting designs with no idea if they could ever be implemented on the web to a client who is very focused on delivering a working web app can contribue to giving designers a bad name.

At any rate, that is my two cents. I am curious to hear of specific examples when people have tried to do an HTML wireframe and felt that it took too much time to see if the process there differs from ours.

Kyle Pero — Fri, 26 Jan 2007 14:50:55 GMT

I have to agree with L. Goffin that an HTML template (whether you use Dreamweaver or not) takes longer to develop and is more time consuming to modify or revise.

I do agree that an HTML template would work better when you are developing a web application rather than a concept for an entire website.

I’m responsible for client-side programming as well as wireframe construction and usability at my work. Even though I hand-code HTML templates I still prefer VISIO for developing wireframes. I would never really suggest writing a line of code until you have everything the client wants solidified.

I must admit that I do have a bias against Dreamweaver any any tool that generates code for you. In my experience the code is never as clean as when it’s hand-coded and there are cross-browser issues with the code that’s generated.

Josh Seiden — Fri, 26 Jan 2007 14:50:55 GMT

Julie,

Your article implies that the reason designers avoid HTML is laziness, lack of training, and lack of personal comfort. There is however an important strategic reason to avoid HTML wireframes and prototypes.

Good interaction design processes strive to create artifacts that conform as closely as possible to the user’s mental model. This is difficult, of course, because the easy path to software product creation always adheres to the implementation model: that is, solutions reflect their construction methods and media.

Interaction design uses many methods to limit this effect. Most methods seek to remain “abstract” or “technology-neutral” during the early stages of design. Using HTML for early models and prototypes may seem innocuous enough, but it is not a technology-neutral technique.

For this reason designers often seek to avoid HTML until later in the design cycle.

L. Goffin — Fri, 26 Jan 2007 14:50:54 GMT

Thanks a lot for your nice article explaining a possible way of prototyping using HTML.

HTML prototyping offers a lot of advantages such as a very realistic user experience. I personnaly use illustratorto make sketch and diagram using a mix of wireframe for the screen prototyping and some mix of UML and merisse for the functionnal flow and so on.

Before making prototypes, i was senior HTML integrator and client side developper using Javascript and so on… I should have make prototypes in HTML but i had the following problem : when u have made a first version of a site prototype, HTML is very heavy when you have to make an important change in the prototype.

An other problem is to want to be too much realistic in the user experience. If you prototype navigation, prototyping this navigation require sometime to develop all the machanism of this navigation and then, i ve a problem with this time wasting.

In my experience with Illustrator, my main advantage is to have a very fast authoring tool for modifications and free drawings. We can also make clickable demo using Illsutrator as authoring tool and exprot the sketch in SVG. I will make a demo of this because i think it could be really interesting to show to the community.

Thanks a lot again for your paper.
PS : excuse my poor english

Laura S. Quinn — Fri, 26 Jan 2007 14:50:54 GMT

Enjoyed the article, Julie! A couple of comments. I have to admit that I’m hooked on Visio prototypes and can’t go back—so take these with a grain of salt.

Two minor downsides that I’ve found with HTML prototypes—probably can be overcome simply with very clear communication. First, I’ve found that people are much more tempted to make prototypes really pretty, with color, etc—spending unnecessary time on presentation simply because it’s HTML, and they’re used to doing more polished looking things in HTML. In the same way, on each of the couple of projects in which there was an HTML prototype, I’ve found myself having to fight to not reuse the HTML code from the prototype…I guess it just feels wrong to people somehow to recreate HTML that exists in some HTML version, regardless of how purposely slapped together that code was….

Also, you mention that one of the main limitation of one of the main limitations of the “flat” prototyping tools like Visio is that they’re not interactive or sharable over the internet. You can in fact create HTMLish prototypes in Visio—you can add a hyperlink to make one object (say a button) link to another page (through InsertàHyperlink), and then Save As HTML. It creates weird (and large) image map based pages, which are a bit quirky and buggy, but they are clickable enough to user test with, and sharable over the web. If you want to go nuts, you can even put code behind any of the objects through VB (I’ve not tried it, but I assume it could be conditional, etc.). The one thing you can’t do is have working controls (i.e. you can’t write in text fields, drop downs don’t drop-down).