///Ajax Wireframing Approaches

Ajax Wireframing Approaches

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

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:

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

2010-05-25T22:50:44+00:00 November 23rd, 2007|AJAX|0 Comments

About the Author:

Kevin Hale is responsible for championing good user experience and brilliant interface design. As much as Kevin likes keeping things clean and reliable, he loves innovation. More than that, he loves asking for innovation in the middle of the night from his favorite two people, The Brothers Campbell. As a child, Kevin was the kid in class who ate a box of crayons for a dollar.

Leave A Comment