This is the second of three installments of A Designer’s Guide to Prototyping Ajax. Be sure to also check out the Introduction and the final installment on JavaScript Basics for Prototyping.


Last week we introduced the concept of prototyping as a solution to the problem of representing Ajax at the early stages of designing an interface. We talked about some general strategies and attitudes we should take when starting a project (like not being a hero and establishing good relationships with our programmers) and reviewed some fundamental XHTML and CSS skills we should have in our arsenal before beginning the prototyping process.

HTML Form Builder

In this installment, we’re going to go over a few techniques and approaches we use to create the foundation of every prototype—wireframes. In addition to serving as documentation for those working with the markup, wireframes are a great way to create screenshots and debug rendering problems that are happening during DOM manipulation. Whenever we find something looking funny during the development process, we always refer back to our wireframes to see if it’s a markup / presentation problem. If it renders right in the browser statically, then we know to look for the problem in the JavaScript or server side programming.

Creating an XHTML/CSS wireframe is easy enough, basically you just build the web site with your editor of choice (we like TextMate and Skedit on OSX and Notepad++ on XP). Good XHTML/CSS wireframes take into consideration all the markup changes that will happen on a web site and if done well, are extremely versatile. The problem is how do you efficiently indicate all the dynamic action that’s going to be taking place on the page? The answer is not easily. The following three methods are some of the approaches we discovered to help us prepare wireframes for prototyping.


Zeldman referred to this as the “Chuck Jones” approach. Basically, you’ll create an XHTML wireframe page for every possible state your application or feature will be in. For example, if we were to design a login form, we’d design a page for when you first come to it and a version for when there’s errors. It’s the easiest approach to understand and comes at the price of being the most tedious. The files created in this approach are great for making storyboards and integrating into page-flow diagrams, but a bit of a hassle during the rapid prototyping step because you have to manage multiple files at once.


If handling multiple files doesn’t appeal to you, you might want to try stacking. The principle is simple, just duplicate the markup variations and stack them on top of each other like so:

    <form id="login" action="">
        <!-- Without Errors-->
            Username : <input id="user" type="text" /> <br />
            Password : <input id="pass" type="password" /> <br />
            <input type="submit" value="Submit" /> 
        </div>        <!-- With Errors-->
            <span class="error">Password doesn't match.</span>
            Username : <input id="user" type="text" /> <br />
            Password : <input id="pass" type="password" /> <br />
            <input type="submit" value="Submit" />
        </div>        <!-- Forgot Password-->
            <p>Provide your email and we'll send you a new password.</p>
            Email Address : <input id="email" type="text" /> <br />
            <input type="submit" value="Send New Password" />

This approach is great because it’s easy to understand and convenient to have all the markup variations on one page. When we turn this into a prototype, we’ll just hide and show the appropriate stack at the right times with CSS and JavaScript. When you hand this version off to your developer, the markup for these stacks, however, will probably move into an XSL template, the JavaScript, or a page called upon by Ajax. The problem with this kind of wireframe is that it probably can’t be left like this. If you do not turn this into a a prototype where JavaScript helps control the display, they’re not really useful on elements that are absolutely positioned or contain a specific height.

Turn On Possibilities (TOP)

Stacking is great for segments of markup that are just going to be replaced by one another dynamically, but are a bit of a waste for when elements are just going to change their state with a class name change or a style change. In our login example above, I probably would combine the with and without error stacks because they’re similar in markup (note that the “with errors” only contains an extra span.)

TOP Screenshot

Here’s a better example of a TOP wireframe. In this wireframe, I’ve indicated various interface situations like when a field is focused (yellow hover, instructions on the side) and when there’s an error. As you can see, TOPs are great for creating controlled screenshots.

The thing to remember is that it is best to use all three approaches in combination to develop your wireframes for prototyping. On Wufoo, we used keyframing for lightboxes, stacking for showing the various fields types in our demo, and TOP for tooltips, help menus and properties.

Using Useful Class Names

Before we get into any JavaScript, I want to talk about how we’re going to keep things simple. When I’m using the Stacking or TOP approaches, it is necessary for me to selectively hide and show certain elements so I can debug a design for the prototyping step. Instead of going in and changing the CSS property of an element every time I need to get at something underneath or below, I create a few useful CSS classes to streamline my workflow:

.hide {display:none} 
.show {display:block}.invisible {visibility:hidden}
.inline {display:inline}

Then, whenever I need something out of my way, I just add a class of hide or invisible to the element. These aren’t truly universal and should definitely be customized to your project’s needs. There are cases when you might want an element to hide itself in a different manner. For example, in IE when you set a Flash object to display:none, the Flash movie will reset to the first frame when you change the display to block again. Annoying. The way to get around this is to just set the height of the Flash movie to 0, which would redefine our hide class like so:


Because of CSS specificity this rule will override the more generic .hide class above whether it appears above or below the rule. No !important property necessary. Other useful class names that we use in our wireframes are:

.on     .push       .focused    .error
.off    .clicked    .activated  .highlight  

CSS Boolean

If you’ve ever created CSS navigation that highlights the link representing the current page based off a body id, then you’ll find the following concept pretty familiar. CSS Boolean is an example of how to conditionally present specific sections of HTML with CSS. In the following example, I’ll use it to show whether an Option is in the On or Off state. Here’s the CSS:

.ifTrue, .ifFalse{
.true .ifTrue{
.false .ifFalse{
#option .ifTrue{
#option .ifFalse{

And here’s the markup:

<a id="option" class="false">
    <img class="ifTrue" src="/images/icons/star.gif" alt="Bright Star" />
    <img class="ifFalse" src="/images/icons/stardim.gif" alt="Dimmed Star" />
    <span class="ifTrue">(On)</span>
    <span class="ifFalse">(Off)</span>

When we change the class of the link to “true,” the image of the Bright Star becomes visible and the “(On)” is displayed in green text while the image of the Dimmed Star and the red “(Off)” goes away. There are many variations of this concept. You could, if you wanted to be more efficient, specify that the false state is shown on default and change when a class of true is applied. I don’t always use this method with the same syntax (most of the time I’m using show/hide or on/off rather than true/false), but it illustrates how you can take the useful class names mentioned above to condense and present various Ajax states with CSS and XHTML.

Why would you want to use CSS Boolean? Because it will help you easily conceptualize before writing a single line of JavaScript what exactly needs to be done to make your page come alive. If you know that manually changing a class of an element to “show” or “activate” makes the feature appear properly on a page, then you also know that your equivalent JavaScript function for your prototype need only do that same simple task.

And that concludes the second part of A Designer’s Guide to Prototyping Ajax. Be sure to come back next Monday for the last part of our series, where we’ll finally dive into some JavaScript functions and techniques to help transform our wireframe foundations into dynamic application previews.

HTML Form Builder
Kevin Hale

Ajax Wireframing Approaches by Kevin Hale

This entry was posted 5 years ago and was filed under Features.
Comments are currently closed.


  1. Drew Yeaton · 5 years ago

    Interesting approach to this long standing problem. I’ve seen this before, but your commentary is top notch. Good job.

  2. Blaise Bernier · 5 years ago

    Thanks a lot! All of you guys! ParticleTree is, along with ALA, my favorite feed. Seriously this is here that I learn the most!

  3. Relapse · 5 years ago

    CSS Boolean. Simple idea, great use. Going to be sending that one on to the team at work.

  4. John Fairley · 5 years ago

    Interesting, I’d like to see a more fleshed out example however. Since the WuFoo example even has a visual design already applied this is basically turning a mock into a working prototype.

    So, this should be called Ajax Prototyping Approaches. Something that is both in colour and working is by definition not a wireframe.

  5. Kevin · 5 years ago

    I understand where you’re coming from John, but we actually haven’t gotten into the JavaScript yet, so nothing explained here will just work on it’s own. The states right now have to be manually triggered by adding a class here and there. Next week, we’ll go over the JS that will actually turn these wireframes into prototypes.

  6. John Fairley · 5 years ago

    Right, all I’m saying is.. that screenshot is of a high-fidelity colour-applied html page and you’re calling it a wireframe. By definition it’s not a wireframe, wireframes would be what come before that. So when the HTML was raw and unstyled, that could be called an HTML Wireframe.

    I know it seems like I’m splitting hairs here, but what I’m syaing is: it’s okay to skip wireframes and go right into prototyping, just don’t call prototyping wireframes.

  7. Luke Kenneth Casson Leighton · 5 years ago

    stacking: completely wrong approach.

    use something like formencode ( which understands input, textarea and select / option tags, including radio and check buttons, and substitutes into the form - at the right place - the values and the errors.

    rest of the article: great help.

  8. Pedram · 5 years ago

    formencode is python and is just form generation and validation… which nothing to do with stacking

  9. Dustin Diaz · 5 years ago

    Now these are the articles I like to see. Seems like everyone is just jumping into an ajax app without thouroughly wire-framing it…and with good reason; because nobody knows how. Good work with these basic steps. One thing I will be a stickler on is the use of class names like ‘hide’ and ‘show’ - I indeed think they’re fine for the prototyping stage since that’s the way designers typically think. However they are most definitely behavioral classes (just like presentational) and not necessarily semantic. Nevermind the matter, if everything makes sense to everyone and it’s easier to manage in the end for everyone in the group, then what the hell. Leave ‘em.

  10. Tyler McMullen · 5 years ago

    So what if they use the word “wireframe” for it? We all understand what he’s saying. Its not like its creating some huge misunderstanding. And the reason that “wireframing” is used is obviously because they can’t use the word “prototype” for both things.

    This first thing is a prototype.

    This second is a more-better-prototype.


  11. Brock · 5 years ago

    “Be sure to come back next Monday for the last part of our series, where we’ll finally dive into some JavaScript functions and techniques to help transform our wireframe foundations into dynamic application previews.”

    Next Monday? I’m getting antsy… the first two articles were so great I can’t wait for the 3rd!!! Bring on article #3!!! =)

  12. James Jackson · 4 years ago

    Everyone needs a hug.

  13. kgkgkg · 4 years ago


  14. Website Design · 4 years ago

    I’m just starting to try getting into all this AJAX stuff and implement it in all my websites. It’s got to be the future! Nice article, many thanks

  15. Kumar Chetan · 4 years ago

    I have a point here, why I go into designing html stuff wen I can achieve the same wireframe design using Photoshop or GIMP? In any case I need a graphic designer with me, he/she can designe the stuff and programmer can create CSS and HTML on the fly. I still need to study the advantages of your concept. Still a good article. Time to read the last installment. Oh yes, U deserve a hug.

  16. nathan hale · 4 years ago

    Ajax = Ajoke You guys have your heads so far up in the clouds that no one will ever accomplish anything real with Ajax. I don’t know what you are talking about and neither will the majority of real people who just want to get some CONTENT onto the web. I don’t know who you are, but, from my standpoint, a helpdesk person at a high school with 400+ PC’s, Ajax is of no use and is incomprehensible, compared to, or any other MS technology that can link into real apps and real solutions. Good luck and good bye…

  17. nume · 4 years ago

    Everyone needs a hug.

  18. name · 4 years ago

    Everyone needs a hug.

  19. WWW · 4 years ago

    useful info.

  20. xGPkex9s7Y · 4 years ago

    Hi! Very nice site! Thanks you very much! n3BzsxFMvesnPO

  21. Ahmad · 4 years ago

    Everyone needs a hug.

  22. zvzfsnlzip · 3 years ago


  23. Joe Mama · 3 years ago

    Everyone needs a hug.