Welcome to Particletree!

This is the first of three installments of A Designer’s Guide to Prototyping Ajax. Be sure to also check out Ajax Wireframing Techniques and JavaScript Basics for Prototyping.

Introduction

Jeffery Zeldman wrote earlier this year in his essay about Web 3.0 that “Wireframing AJAX is a bitch.” And while I can’t deny the statement, I do think there are steps we can take to alleviate the pain. The problem is static XHTML/CSS wireframes are woefully inefficient at the task of communicating and documenting the features available to the new crop of Ajax web sites. Because we’ve been working on a rather intense Ajax project for the last few months, we’ve been developing and refining a number of techniques and guidelines to help our team design for Ajax by moving beyond the traditional forms of functional specs and wireframes to something a bit more appropriate for the dynamic medium—rapid prototyping.

There’s nothing new about them. 37signals’s Getting Real movement is all about sitting down and getting in front of the interface. A prototype is just one of the ways a team can dive right in. For us, prototypes are basically wireframes come to life. A combination of CSS, XHTML and JavaScript, they help me, as an interface designer, communicate effectively the look and feel of a proposed page to a programmer, like Ryan, so he can integrate the interface into a project quickly and efficiently.

“The combination of valid HTML/XHTML markup and external CSS can be used to rapidly create prototypes, speed up the development process, and easily incorporate more user-centered techniques into the design process.”

Jeff Lash

The problem, of course, is figuring out the logistics and mechanics of the process—drawing a line from point wireframe to point prototype. How exactly does one “rapidly create” a prototype from a wireframe? How much JavaScript should one inject at such an early stage in the process? What works? What’s necessary?

Well, our rapid prototypes have no data layer present (no databases, no sql, and no Ajax calls) and all of our interactions are kept strictly boolean (on/off states, no animations or tweening, functions only take place on mouseovers and clicks). The limitations we put on a prototype make them easy to change, easy to debug and easy to make portable. We use prototypes for communication, development, troubleshooting, screenshots, demos and documentation—basically, at every stage of an Ajax project, a prototype can help us do it better.

In fact, the demo that you see on Wufoo was spun off from an advanced prototype. Prototypes have completely changed the speed and efficiency of how we work around here and over the next few weeks, we’re happy to share exactly how we do it.

Now, I want to remind people that I acknowledge that everyone’s workflow is unique. Ajax applications appeared long before this article was written so there’s no doubt in my mind that you can get the same things done with completely different methods and approaches. Over the next three weeks, I will be going over just an example of the guidelines our team uses when tackling an Ajax project. This series was written to help designers that are just beginning to brave the JavaScript frontier. We’ll start off with some skills you’ll want in your arsenal before beginning, move on to some approaches we’ve researched for wireframing Ajax and then finishing off with a few tips we’ve discovered to help make the prototyping step smooth as silk.

There are No Heroes in Prototyping

Because it’s usually the designer’s responsibility to build the structures that are handed off to programmers, we’ve taken into account that you’re probably no code master. We actually don’t need any fancy pants in there anyway. Because of this, our motto for JavaScript usage in a prototype is “Don’t try to be a hero.” Of course, feel completely free to familiarize your self with concepts like innerhtml, node creation, animation and even Ajax, but you’re not going to want to put any of that in a rapid prototype.

Here’s why: This early in the game, we want as much separation as possible between our structure, presentation and behavior layers. If you start using any of those advanced concepts mentioned above, you’re going to find a good amount of markup and CSS stuck inside your JavaScript. You’re going to want to let your programmer decide the best way to approach those decisions, because they’ll know best how they want to pull information from their data source and assemble it on the page. Plus, you want to keep them happy for reasons I’ll explain later.

The reason you want to design for only boolean states and save animations for the very last thing you do is because JavaScript animation is 1) almost always frivolous, 2) basically still in its infancy and 3) just too cool. You’ll waste too much time playing and tweaking it to your own amusement. Trust me, we know. Once your database and dynamic data is all hooked up, working and stable, then you can allow yourself the luxury of adding the eye candy in a way that helps you determine which animations slow down your application and which animations enhance the user experience. Now, no one ever really listens to me on this (hence our demo with the integrated animations), but it is for the best. You’re going to want to keep code complexity very basic, because you need things to be as flexible as possible later on. That said, the JavaScript concepts and functions we’ll go over in this series are the absolute minimum needed to turn a wireframe into a basic prototype.

Relationship Skills

Secretly, everyone loves participating in the design process. I think it might be because the barrier to entry on giving an opinion about design is being born with eyes. And while it gives me the most terrible headaches, if you involve your developers in the process, they will love you for it. Kidding aside, the best thing you can ever do for your team is to establish open communications with the developers and engineers working on a project. I’m always learning new tricks about the DOM and the capabilities of a server side language from Ryan and Chris and they are always surprised to find out when a bug or quirk can be fixed with simple tweaks to XHTML and CSS.

Also, happy programmers don’t touch markup. Like most designers, I’m a complete control freak when it comes to the XHTML and CSS I generate. When I create a wireframe or prototype, I make sure I provide all of the necessary DOM hooks (IDs and Classes) to let a programmer do his job. By incorporating their needs into the design, you don’t have to worry about them trying to hack a solution or (God forbid) attempt to make changes themselves. You don’t have to leave all the problem solving to them. Too many times I’ve seen a function appear that attempts to target an element with a complex set of node traversing rules. Making a developer guess and figure out how to access elements is a complete waste of time.

Before beginning, you’ll want to know and understand the environments the developers are using to integrate your work. You’ll want to know what frameworks, toolkits and animation libraries are at their disposal and what templating options are available for presentation. There are many out there and whether its a Movabletype template, XSLT, Smarty Templates or the up and coming JSONT, you’ll want to take into account each one’s subtleties. If your team completely compartmentalizes design and development, take the time to follow-up with the developers and ask about what worked and what they needed to make your creation come alive.

XHTML Skills

Good prototypes are built on good wireframes and good wireframes come from those who have made markup their proverbial bitch. You’re going to want to put your XHTML understanding on lock and the best place to start is with the source. I’ve said this time and time again, but reading w3c specifications, while mind-numbingly boring at times, is the best way to master this craft. I learn something new every time I go back to read them and honestly, it’s all good stuff. The following are the sections I’ve found most useful for those designing interfaces for Ajax applications.

Difference between an id and a class

Simple enough concept, but we’ll go over it for good measure. An id is applied to a unique object (no two elements can have the same id on a page) and classes can be applied to multiple objects. Many browsers do not enforce this rule but it’s a basic rule of HTML/XHTML and should ALWAYS be observed. IDs are extremely important for your programmer because they allow them to hone in on that element like a laser. How you work these throughout your markup will often guide how a developer can make it come to life.

Multiple Class Names on One Element

Yes, you can do this and not enough people who know how, do. Leveraged appropriately, multiple class names are ridiculously useful for turning wireframes into prototypes. I couldn’t live without them. For example, let’s look at the following structures:

<div id="message1" class="notice">The monkey is in my house.</div>  
<div id="message2" class="error notice">The monkey is angry.</div>  
<div id="message3" class="hide error notice">I forgot to feed it.</div>

We see class names here are semantically rich enough to indicate not only how we might set the CSS rules for these classes, but how we should tell the functional story and properties of these elements to a programmer. This is all done by adding and removing appropriate class names. I’ll go over this in more detail in the second part of this series.

Form Elements

Forms are the original gatekeepers for user input and the traditional methods for transmitting and communicating information back to the server. In most cases, they’re the degradable solution for every Ajax transaction. Most of the structural mistakes I’ve seen usually take place in forms because they’re tedious and boring. You’ll want to know how to take advantage of every element (form, fieldset, legend, input, textarea, select, button) and attribute (method, action, readonly, disabled). Forms can be fun. It just takes time.

Anchors/Links

Anchors or <a> elements are the other traditional points of contact for user interaction on a web site. They are the only elements that have usable pseudo classes (:hover, :active, :visited, :focus) to hook into via CSS on all browsers. This is useful for those that find certain JavaScript pseudo-class solutions incompatible with a project. Links possess a surprising number of valid attributes that can be used to store a number of alternative sources of information that can later be utilized with DOM manipulation. In addition to href and title, we have name, rel, rev, accesskey and type to store variables that can be passed on to a JavaScript function. Nicer Titles, for example, use the title attribute to store additional info about a link and Lightboxes use the rel attribute to process which links should behave in a specific manner.

CSS Skills

Being a designer’s guide, I recognize that this is probably your forte. I’ll try to keep this brief—linking to better sources where appropriate. But yes, you’ll definitely need those CSS skills. In addition to your normal layout shenanigans, here’s what you’ll want to catch up on:

The Display Property

First, you’ll want to know exactly how the display property differs from the visibility property. If you think the display property is only good for making elements appear and disappear, you’re barely scratching the surface. The display property controls how a browser renders the fundamental structure (the box) of every element on a page. It is is an all-powerful property. In addition to making things disappear, the display property can fix a majority of IE rendering problems and even make divs and spans behave exactly like a list element or even a table cell. Specifically, you’ll want to know with confidence the difference between block, inline, inline-block and list-item. PPK always tells this story best.

Controlling Box Generation

While you’re looking up the display property, review the visual formatting model and specifically the section on how to control box generation. The visual formatting model dictates that each element in the document tree generates zero or more boxes according to the box model. You’ll want to know which elements by default are inline and which elements by default are block. You’ll also want to take a look into Internet Explorer’s peculiar responses to “hasLayout.”. Make sure you’re familiar with what elements have “layout” by default and the style properties needed to invoke “layout.”

CSS Specificity

I’ve seen too many stylesheets covered with unnecessary !important rules that prevented many a developer from changing an element on the fly. These were usually the result of an incomplete understanding of CSS specificity. Specificity is used in a browser’s secondary sort to help determine cascading order. Translated: If you have two (or more) conflicting CSS rules pointing to the same element, there are some basic rules that a browser follows to determine which one is the most specific and therefore applied to the markup.

A selector’s specificity is calculated as follows:

• Count the # of ID attributes in the selector (= a)
• Count the # of other attributes and pseudo-classes in the selector (= b)
• Count the # of element names in the selector (= c)
• Ignore pseudo-elements.

For Example:

*              {}  /* a=0 b=0 c=0 -> specificity =   0 */
li             {}  /* a=0 b=0 c=1 -> specificity =   1 */
ul li          {}  /* a=0 b=0 c=2 -> specificity =   2 */
ul li a        {}  /* a=0 b=0 c=3 -> specificity =   3 */
a:hover        {}  /* a=0 b=1 c=1 -> specificity =  11 */
ul li a.red    {}  /* a=0 b=1 c=3 -> specificity =  13 */ 
li a.red:hover {}  /* a=0 b=2 c=2 -> specificity =  22 */
#candy         {}  /* a=1 b=0 c=0 -> specificity = 100 */

For more information, check out what Eric and Molly have to say about specificity.

Image Replacement

You will use this probably infinity times. Good thing there’s like a million ways to do it. Know this cold. For Ajax applications, I recommend avoiding a JavaScript method for this. Personally, I love text-indent:-9000px.

More Information

Alright, that does it for our introduction and cursory XHTML and CSS review. Next Monday, come back for DGPA Part 2 : Ajax Wireframing, where we’ll go over several techniques we’ve developed to prepare our markup and CSS for the protoyping process. Until then, please read up on what other developers have to say about the benefits of wireframing and prototyping and let us know some of your thoughts on the topic as well.

• Just Build It: HTML Prototyping and Agile Development · Clearly, jumping into HTML sooner isn’t always the answer, but it is a perfectly reasonable option that clearly deserves consideration. Determining whether it’s right for you and your project depends on many different factors.

• Getting Creative With Specs: Usable Software Specifications · An effective, usable spec serves two main purposes: First, it elicits feedback early, which helps to avoid problems and misunderstandings later on. Second, an effective spec ensures the software stays in line with the designer’s intentions.

• HTML Wireframes and Prototypes: All Gain and No Pain · A great introduction to wireframes and a list of benefits they provide to the workflow process.

• How do we do HTML wireframes? · An outline of a conversation between a few intelligent and experienced developers on their wireframing tools and methods.

• Prototype Techniques in the Web Design Workflow · Molly briefly goes over a number links to various techniques that can be used to build wireframes and prototypes.

• Prototyping With Style · Answers the following two questions: What tools should I use for prototyping? What technologies do I need to know?

• Prototyping with Standards and Ajax · Blue Flavor actually incorporates Ajax right into their prototypes. They take various “Ajax includes” and insert them dynamically as needed. Definitely, check out the demo.