I’m a big prototype guy. I like to make prototypes as early as possible in the process. I think of a site like a story, it unfolds the deeper you get into it. The only way you can reveal how they story will unfold, it to have something that people can click on and experience first hand.
Over the last year, I’ve made a big transition in how I design and build sites. It has saved me a lot of time (therefore money) and produced a better deliverable to clients and to test with users.
Of course there are a lot of deliverables that lead up to the prototype. But for know I’ll skip right to how to create the prototype.
By using web Standards I’m able to iteratively add to the prototype to save time and money. But by using Ajax I’m able to easily add a level of interaction to my prototypes.
Why Ajax?
Before I started using Ajax, I would have to build out every page and link to it. It didn’t take too much time by its self, the problem was as the prototype evolved, I would have to go back and retrofit code. The prototype could quickly grow out of control and eat up a lot of my time.
Using Ajax solves two problems.
1. By breaking up my page into a variety of elements, like a header, a navigation menu, a sidebar, etc I’m able to create reusable snippets of code. If I have to go back and retrofit, I don’t have to do it in more than one place.
More so, I can breakup the page with more granularity than I can with includes.
2. Most importantly by using Ajax, I’m prepping the site for web Application Integration. The general structure of an Ajax prototype is remarkably similar to the structure to how a Engineer would incorporate the design into a web Application framework. They don’t have to dig through endless lines of presentation code, rather each function is nicely separated into it’s own HTML file.
When to build a Prototype
Projects can evolve in different ways. The prototype is a helpful deliverable for both interaction and design phases. Sometimes I’ll start the prototype with a designed mock-up and sometimes I’ll start with building a prototype and do the mock-up later. This largely depends on the project.
With some clients, the design process can be the longest, on these I tend to do a prototype before design. I use the prototype to help work out strategic issues, do an early round of testing and help the client make decisions regarding the design.
On other projects, usually where I have free reign with the design, I will start with a mock-up and build the prototype once the design is close to approval.
Step 1. Create HTML Wireframe
Regardless of which comes first, the first step in creating my prototype is to build a good code structure to which I can add to.
By using web Standards I can create a basic wireframe to work out the interaction. Starting with a simply structure I will add interaction elements, like buttons and copy blocks sans-styling.
I will often take the diagramed wireframe and create a literal translation first, then gradually add to it.
Step 2. Use Ajax to add Interaction
Next I start breaking out each functional element into it’s own Ajax include.
Where to create a “page divide” largely depends on the project. My rule of thumb is each user goal or action is contained with a page. That way each page contains a complete and functional user flow.
Step 3. Apply Design with CSS
Finally I start adding the presentation layer using CSS. On more than one occasion, I would hand off my code, before I finalized the Design. On tight projects, getting the code done and handed off to Engineers before design is complete allows for design and development to work synchronously towards the common goal.
Since I iteratively structured my site and I have a good sense of where my styles will apply and I can control presentation and rarely have to alter code after hand off. This can be less than ideal, but it gets the job done.
Updated 9/26: Below is some more information that hopefully clarifies a few questions mentioned in the comments.
Why Not Use Server-Side Includes?
Server-Side Includes (SSIs) work great for simplifying your code structure, manage changes and create reusable components. Before Ajax, I often used PHP SSIs for the task, though I would often get dirty looks from the Engineers I was handing it to.
My SSIs would primarily be key structural elements like the header, navigation and footer. For each interaction, I would need to create a unique page for every action. By using Ajax I am able to add several layers of interaction by replacing content within a DIV with only the content element.
Ajax includes allows me to focus on each element of the page, viewing it as standalone object, then inserting it into a prototype to test with users, or work out issues. I end up managing the elements rather than the pages.
A Prototype Prototype
I also thought that it would be helpful to give an example of what I’m talking about. A lot of the prototypes I’ve made over the last few months aren’t available for public consumption. So this morning over my cup of coffee I put this together.
This shows an early prototype where interaction can be tested. Once figured out, you can gradually add styles to reach a final code deliverable.
http://blueflavor.com/examples/ajaxprototype/
Since you can’t tell a lot by viewing source, I’ve linked to the individual Ajax includes, as well as put it together in a nice neat package (remember to look at Ajax content locally, you must put view it on a server).
Forgive me if this is 100% valid or has some quirks, I literally put this together in about 20 minutes, but should work fine in any Standards-friendly browser.
Conclusion
It may not be the best approach for all projects, but I’ve found it to be a great way to iteratively build upon early interaction deliverables like wireframes. Working from malleable prototype to finished polished design without a lot of rework of steps.
I appreciate the feedback, keep it coming!
What’s an “Ajax include?” Do you mean simply a regular old server side include, where a chunk of HTML is imported from another file? Or something more like proper Ajax functionality?
The thing about prototyping with Ajax, is that it really only lets you prototype Ajax-based interactions, right? I mean, you’re not prototyping a Windows fat client here.
I do agree with the main idea, which I’m not sure is all that clearly stated: that “responsive” prototypes for Ajax functions (as opposed to static colored wireframes built in HTML) can be pretty easily built without any server-side programming or even very much advanced Javascript. All you’re really doing is swapping out one bit of the DOM for some HTML that lives in its own file somewhere. Using something like the Prototype.js library, it’s quite easy to add an onclick here, or handle a submit there, and make it “feel” a bit more like a functional web application.
Like Andrew I’m a bit confused about the AJAX include. I feel like I’m missing part of the story.
Why not just use standard SSIs instead of ajax and continue to use them throughout the like of the project. It seems that with ajax you would need to recode parts of your application (such as links) once you move out of the prototype stage? Anyway, I agree with you that client’s need something to click :)
This is a (potentially) good intro to a much longer explanation of this technique. I’d like to see you flesh this out more so that it provides more information. How about stepping us through a simple example?
I’ve updated the post above to hopefully clarify some of the great questions that have been asked here. Keep them coming!
Thanks very much for the Ajax prototype example. It definitely pulls the article together.
I can see where you’re going with this example, but it begs the question why? This is simple site navigation; using Ajax here doesn’t do much but break the Back button. Would you actually specify that the site function this way?
I understand the desire to break a screen into components that can be worked on in isolation, then combined, but I still question whether Ajax is the appropriate tool here. In fact, Ajax strikes me as a terrible way to get the effect of “including a module”. I mean, you don’t have to worry about different server response codes when you do something like #include “foo”.
Using Ajax in prototypes still seems like a powerful tool, since documenting Ajax behavior in wireframes is kind of tricky. It’s hard to convey the behavior without actually building the darn thing.
That prototype got me pretty excited (I’ve never thought of going that far with JS before on a simple page layout!), but it’s made me wonder: what about search engine optimization? It seems that having an AJAX layout could throw all that straight out the window. Granted, SEO isn’t always the end-all be-all, but still, keeping your HTML hidden behind layers of JS seems like a good way to ensure that search engines will have a tougher time indexing it.
Maybe I am missing the point but using Ajax instead of SSI is like using Flash for a simple HTML/CSS navigation. And I agree with Micah. The search engines won’t have any content to look at and this technique breaks down without JavaScript.
The whole Ajax concept breaks down without JavaScript. That doesn’t mean we should stifle innovation that uses it.
It seems that a number of the commenters aren’t understanding the idea of prototyping at all.
Folks, these prototype ‘sites’ are never meant to be used in any other way than to show the client a basic idea of what’s going on. During this phase there is no need to have any concerns with breaking back-button functionality, search-engine optimisation and such like! It is merely a prototype; a work-in-progress. And something tangible for the client to give feedback on.
Peter is exactly right.
An Ajax prototype isn’t production ready code, you use it to gather client feedback and most importantly to put something that is a little higher resolution in front of people to test.
SSI’s can also do the trick, though if you are building a web application built with Java, the last thing you want to hand off to engineers is a bunch of PHP code.
Since Ajax is for web applications, it allows you to break up the structure of your site exactly how a web application will be built. By breaking up your code by functional DIV, all of your would-be dynamic elements are already broken out into the logical interaction elements.
I’ve found this greatly reduces the time it takes to hand off code to engineers.
You may be aware of this already, but the links to your protoype are down. I would be interested in seeing them, thanks!
Mahalie,
Thanks for pointing that out. We moved our host a while back and this got missed. I’ve updated the link.
Wouldn’t it be a Good Thing if you used an unobtrusive javascript layer as well as a working ssi include to do the prototype? It isn’t that hard to add the click elements and the return falses to their functions without inline markup. Then you can show your client what the whole spectrum of interaction is.
It also allows you to work out the back button issue ( use hashes, check to see if the ajax engine is able to run and parse the hash string. works like a charm. You can add the hashes and remove the link href with the js.
Also, this isn’t ajax. This is ahah (to abuse buzz words.)
If you were really concerned with building off of the prototype you would also make use of a real ajax/effects library. MooFX, JQuery, Prototype, Dojo etc can all be combined to one degree or another and can be used in increasing degrees allowing you to build on your prototype instead of causing you to rebuild your prototype.
Just my $0.02.