I’ve seen more ways to create application prototypes than I can count, from PowerPoint (I’m look at you Chuck) to FileMaker Pro (and you, Bob) and everything in-between. Often, I see folks skip prototypes entirely and just using good ol’ OmniGraffle / Illustrator / Photoshop / hand-drawn wireframes with sticky notes. Never have any of the mechanisms I’ve seen or used felt quite right.

A recent post on Boxes and Arrows, Prototyping with XHTML, got me thinking about this again. In the article Anders Ramsay and Leah Buley write towards a design audience to advocate what the title implies: using XHTML to create prototypes. (The comment thread goes on to provide links to severalprototypes and the discussion turns to Protonotes, which we covered sometime ago, and PolyPage for jQuery, which we have not yet covered.)

Is hand-coded semantic mark-up with applied styles really the state-of-the-art for prototyping? Shouldn’t a primarily visual medium be used in the prototype stage? Or is semantic mark-up the way to go because it frees you to change the design of the same content quickly? How do you prototype your user interfaces? Or do you skip prototypes entirely?

Using HTML to create a prototype is way too time consuming; especially if you have a picky client. I’ve found that paper-prototyping is the quickest and easiest way to make changes and provide an easy way to discuss application functionality. Plus it makes the client feel much more involved with the design process.

Besides; when was the last time you got to sit down with scissors, construction paper, markers, and glue and create something?

>>Besides; when was the last time you got to sit down with scissors, construction paper, markers, and glue and create something?
.
I’m glad you said glue. If there’s any Elmer’s Paste around I simply can’t keep myself from eating it.

For web apps, I have to agree with 37signals: HTML (+JS + CSS) prototyping is the way to go. It’s very easy to change things; it’s difficult to end up promising more than you can deliver (since you implemented it in the final form already); plus, you may end up building something you can evolve into the final product (although there are definitely pitfalls to that mindset as well). Also, you can make things interactive much more easily.

Traditionally, i like a pencil+paper when prototyping small layouts or parts of it for my own eyes only and Photoshop files with grouped layers for more complex stuff that other people need to understand.
Some years ago i also used tabbed ASCII art occasionaly. ;)

There’s a myriad ways to do visual prototyping with tools that were not explicitely made for the job. With these, it all boils down to personal preference and finding the balance between the accuracy of the prototype and the time it takes to produce it.
However nowadays that web content becomes ever-more dynamic I also start to feel the shortcomings of my usual approaches. So I’ll definitely have a look at the links. :)
Anyways, thanks for bringing the topic up. It tends to be neglected.

Off topic: Is there an Spam Question in the system besides “What three letter acronym is what we use to style web pages?” ? Somehow that’s the only one i encounter. I could totally script that. ;)

I decide on tools depending of the task; one factor is for instance the required fidelity. Also, I tend to see “prototype” and “wireframe” as different things, although the border can be quite blurred sometimes (interactive HTML wireframe == prototype?)

Lately, for applications, I’ve been doing lo-fi wireframe (non-interactive), and then going directly to live prototype with the intention to use that code in the final product – creating the GUI “for real” and refactoring that is fast with the right tools, creating the “business layer” is another story…

I think the best prototyping method for a particular project depends on what tools the final product will use, since one usually wants to (re)use the prototype (code) when making the final product.

I (too) have been using Balsamiq Mockups for wireframes lately. I find it creates a suitable fidelity. Too hi-fi, and the discussions will suddenly be about the choice of fonts and colors, which should be another meeting, really…

I’m a fan of Fireworks. Lately Adobe is pushing it precisely as a prototyping tool, and it shows. Not only can I create a fast prototype, I can actually make it look nice and use the design for the final product.

As a freelancer, I find the problem with mocking up a workable prototype is that most clients — at least this is my experience in london the last 4 years — assume the job is now done. Regardless of how much you communicate to them that this is only a prototype and is not actually going to be used as the final product.

This then has a tendency to shorten the deadline of your project. A lot of managers are eager to please the business side of a company and the business don’t understand why what they’ve just seen needs to be improved and built in a way that makes the application modularized and therefore easily scalable.

In a city like london, where a lot of middle to upper management, of many big corporations, like to throw their weight around, it can be hard to then do your job properly.

So I feel the correct type of prototyping is situational. If you are working in an environment where people understand technology enough to know a prototype is a prototype, you will be fortunate enough to build more functional prototypes than if you are working with people who don’t; in which case paper prototyping or screen designs in fireworks/ photoshop are a better solution.

I generally fall back to three different approaches. If I just need non-interactive mockups, I’ll often just launch word and use its control toolbox to drag-and-drop together a form (often combined with tables for layout). Because word uses a page model, it actually translates quite easily to html designs afterwards. If word doesn’t cut it, I’ll launch a layered image editor, and copy/paste together parts of screenshots until it looks the way I need it to. If it needs better styling, or interactive behavior, I’ll do it in html, trying to write the code in such a way that it serves as a baseline for later implementation. Sometimes (for complex forms), I’ll cheat and put a mockup image in the background, implementing only a subset of the page in html code.

I have to agree with henryho, Balsamiq is a fantastic tool, it allows fast mockups for those of us who have the artistic talent of the average three year old. The problem with all fast digital mockups (hand sketching not included) is that you have to keep saying to the client “Bare in mind this is only a mockup”, when they ask why the border on one side is 2px larger than the other. With pen and paper this isn’t a problem, balsamiq gets around that by giving everything a hand drawn look, saving you from having to state the bleeding obvious.

Not free though, $79 for the air version. There’s a free trial version but you can’t save. For the skin flints, print screen still works though ;-)

The situation usually drives the tools I use. For simple wire framing PowerPoint with some custom addons will do the trick (It’s easily shared accross almost all computers). But if interaction, user testing,collaboration, annotations, reviews, and such is needed, I use a customized wiki to do create an interactive prototype. DoRIA.

XSL with XML. You’ll just simply use correct XHTML in your XSL templates, but unlike just plan .html files on your disc, XSL allows you to put recurring snippets of code (main menu, footer, header, etc.) in a separate template. With a little more knowledge you can even add some minor logic to it.

I’ve also written a piece of software that would iterate through XSL/XML files in a folder (where I build interactive prototypes) and create .html files out of them. Depending on the XSL:OUTPUT-tag it will automatically format the HTML to the specifications of my chosen doctype and output type (HTML, XML, etc.).

It runs in most modern browsers, it’s much faster than simple HTML (no recurring code) and it’s extremely flexible.

But I must add, where I work prototypes are a huge part of development. We do prototypes first, anything else later. It’s used as a demo for customers and should demonstrate the application’s functionality as much as possible.

Best benefit of all.. say you need a table listing of companies in your application, you would normally write some “Lorem ipsum” down and copy/paste one or two table-rows through until your page fills out a bit.

What I do.. I simply have a “_customers.xml” file with representative data in it, usually a database export, and simply loop through that. I don’t even write out the content, I get it delivered to my by programmers. It’s much easier to test out my design with real data instead of data that makes it look good.

I’ve tried a ton of other solutions, but none of them offer the power and flexibility of this method. Well, in my opinion anyway.

Axure RP. Its a GUI to layout wireframes / prototypes and it has a slick push to HTML ability that means your mockup can be walked through by your client. I’ve not convinced management to use it in all cases, but I know its very helpful to me to be able to create a mock-up, push the HTML out to a web-accessible location and have my boss approve the designs. I can’t imagine it being different with your clients.

I wrote my own! I’m a Fuseboxer so my apps always follow the FLiP methodology, which is wireframe first for scope/flow, then prototype, then architecting. So I wrote my application to be browser based and start with a wireframe with no layout, just a description of the function and any exits from that point. This ensures that the client is 100% focused explicitly on what we want him to be thinking about, which is whether or not our description of his application makes sense. At this point because there is no design whatsoever I can easily adjust exits if the flow is wrong, or add functions if the scope is wrong. Once the wireframe is approved I can design a layout and wrap the text wireframe inside it, along with the ability to prototype forms, and I can assign the exits either to forms or to links laid out in the template. I can even replace my wireframe text with mocked up html if I need to, so that pretty much the customer ends up seeing a fairly complete representation of the finished app. Once that’s approved I start working out my database tables/columns and map the form inputs to the columns, then I can start architecting my database queries. I do all this within my browser app, then once I have the whole thing architected I export the project to the hard-drive and I have 100% of my controllers final, about 90% of my model fully functional, and about 70% of my view. I fire up CF Studio or Eclipse and finish the rest by hand. It’s been a massive help to my productivity, not only because most of the coding is done automatically but because my clients’ feedback is automatically in stages where it’s actually useful. Much better than “describe your project to me before I’ve done any conceptualizing, then come back after I’ve written the whole thing”. I scrapped that method of development right after the first tear-down and complete re-write. And I’ve never looked back.