Welcome to Particletree!

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.

Introduction

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.

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.

Keyframing

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.

Stacking

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-->
        <div>
            Username : <input id="user" type="text" /> <br />
            Password : <input id="pass" type="password" /> <br />
            <input type="submit" value="Submit" /> 
        </div>        <!-- With Errors-->
        <div>
            <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-->
        <div>
            <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" />
        </div>
    </form>

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.)

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:

#flashObject.hide{
    display:block;
    height:0;
}

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{
    display:none;
}
.true .ifTrue{
    display:inline;
}
.false .ifFalse{
    display:inline;
}#option{
    font-size:.8em;
    color:#444;
}
#option .ifTrue{
    color:green;
}
#option .ifFalse{
    color:red;
}

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" />
    Option
    <span class="ifTrue">(On)</span>
    <span class="ifFalse">(Off)</span>
</a>

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.