Welcome to Particletree!

This is the third and final installment of A Designer’s Guide to Prototyping Ajax. Be sure to also check out Ajax Wireframing Techniques and The Introduction if you haven’t already.

Introduction

Quick review: Last Monday A few weeks ago, we covered 3 different wireframing methods (keyframing, stacking and TOP) and how they can be used to create prototype-friendly XHTML/CSS wireframes. We touched on how descriptive interface class names like hide and show and techniques like CSS Boolean can help us conceptualize and understand the minimum markup changes that will be needed by our prototype to make them come alive. In the last part of this series, we’re going to finally get into some JavaScript fundamentals and the actual code that will help us make those specific markup changes dynamically.

I know there are a good number of designers out there afraid of anything that smells of programming (basically, if it’s not plug and play, it’s not being used). I completely understand. Dealing with CSS rending across browsers is bad enough already. Because prototypes are all about making an interface “look” like it works, the dabbling we’re going to go over here is actually a process that’s amenable to designers (especially those with programming skills that started off as just rudimentary hacking skills). CSS is the domain that most of the new crop of web designers are most comfortable with and so the functions we’re going to go over are ones that manipulate, for the most part, the styles of our elements. Remember, we won’t be concerning ourselves with any content generation concepts like Ajax, innerHTML or node creation. There are two reasons for this:

1. To keep it simple. We want our code to be as simple as possible when we hand off our work to developers (who’ll have a better idea of how they want to implement those features anyway since they should be database driven).

2. To keep it organized. If built correctly, all the potential states and interactions of our interface should be built right into our XHTML/CSS wireframes and accessed by either hiding or showing the elements or adding and removing semantically appropriate class names. Since our structure and presentation layers are basically done and nicely separated, it would be a shame to move our markup into the behavior layer this early into the process.

Making Things Happen

Alright, so let’s say we have a JavaScript function that does something awesome. Something like this:

function doSomethingAwesome(){
    alert('Hello World!);
}

How do we call our awesome function in our XHTML document? Well, the easiest way would be to add an event to an element right in the markup. For example, if we wanted to call the function when we click on an element we’d add an onclick attribute to the element like so:

<div onclick="doSomethingAwesome();">Click Me for Awesome!</div>

It’s pretty straightforward and there are all kinds of events to play with depending on the element you’re working on. Peter-Paul Koch has a great overview of the different events on his web site. Now, there are some tricky exceptions. For example, if you wanted to call the function when you click on a link, you’d probably think to apply it like this:

<a href="" onclick="doSomethingAwesome();">Click Me for Awesome!</a>

Perfectly rational. Unfortunately, your browser will run the function and then try to go to the url specified in the href, which in this example will just refresh the page and therefore nullify the function that was just called. Not very useful. There are two ways to get around this behavior for links. You can either disable the default behavior of the anchor element or call the JavaScript function in the href. The latter is made possible thanks to JavaScript-enabled browsers support of the javascript: protocol, which is just like the http: and ftp: protocols except it lets you execute statements rather than loading a new document.

<a href="javascript:doSomethingAwesome();">Click Me for Awesome!</a>

If you’re a Flash developer, this method is useful when you want your movies to call JavaScript functions without needing something as complex as a JavaScript/Actionscript Gateway or the External Interface feature. If you don’t like that approach, you can always disable the default behavior of the link. All we need to do is add a ‘return false’ after we call our function.

<a href="" onclick="doSomethingAwesome();return false;">Click Me for Awesome!</a>

For those that need to know more about this method, Ryan has written more detailed discussions about disabling links in this feature and this notebook. Feel free to skip them if you’re not hardcore. I try to skip them because it’s Ryan and he’ll usually just fix whatever I might mess up.

Anyway, that does it for the easiest way to apply an event to an element. Like all things easy, this method is, unfortunately, bad for you and your code in the long run. This method of adding behavior to your HTML is considered an obtrusive approach (called this because the JavaScript is inserted into the flow of the markup) and just as we didn’t want our structural layer to find itself in the behavior layer, we really don’t want our behavior layer mixed in with our structural layer.

Event Listeners

The unobtrusive (and slightly more complex) method for attaching events to our document uses something called event listeners. Event listener functions allow us to attach a function to an event that fires on elements of our choosing. This is all made possible thanks to JavaScript’s ability to crawl the DOM. There are far more intelligent and opinionated discussions all over the Internet about how and what event listeners to use and so I won’t try to cover all the complexities in this feature. Instead I’ll toss you a roundup:

• Document Object Model Events - W3C documentation on the subject. Best place to start is always from the source. The source knows all.

• Catching Up with AddEvent - Ryan wrote a brief history lesson about addEvent for Treehouse that does an excellent job explain why there’s multiple versions of the code flying around now. Lucky for you, we edit the magazine so I’ve made the article available for use in this tutorial.

• DOM Design Tricks II - Eisenberg does a great job going over the event-handling capabilities of the Document Object Model in this A List Apart article from back in the day.

• Forget addEvent, use Yahoo’s Event Utility - Diaz gives a thorough review of why Yahoo might have the best answer for dealing with event handling in JavaScript.

Changing the Style of a Specific Element

One of the most important notions in DOM programming is that elements can be identified uniquely so that they can be found and manipulated. Targeting an element by its unique id is the fastest method for making changes on a singular element. In your markup, make sure your element has an id attribute like so:

<div id="vegetable">Broccoli</div>

To make it disappear, we’d could use the following JavaScript:

document.getElementById("vegetable").style.display = "none";

If you wanted to make a reusable function out of it, you might write the following:

function hideElement(obj){
    document.getElementById(obj).style.display = "none";
}

And then call the function like so to hide our dirty green stalk:

hideElement("vegetable");

Changing All the Elements in a Class

While the initial specifications for JavaScript is great about helping us target a specific element by its ID and even targeting all elements of a particular tag (getElementsByTagName), it is for some reason beyond me why it does not allow us to target all elements of a particular class. Fortunately, the solution is on the Internet. There’s lots of variation out there for implementing this function, but our favorite and the one we use instead of the built in one provided by prototype was created by Robert Nyman called the Ultimate getElementsByClassName. He’s done a great job explaining why it was written the way it was and various ways of implementing it. With this function we can now take the following markup:

<div class="veggies">Broccoli</div>
<div class="veggies">Carrots</div>
<div class="veggies">Cabbage</div>

And use the following code to make them all disappear.

var allVegetables = getElementsByClassName(document, "div", "veggies");for(i = 0, i < allVeggies.length, i++){
    hideElement(allVeggies[i]);
}

Class Name Manipulation

During our prototyping process, we try to use JavaScript style changes only on the display and visibility properties of an element. There are times when we make changes to position, height and width, but those generally tend to be edge cases. When it comes to making multiple style changes on an element to indicate a change in state, we prefer to manipulate class names instead.

For example, let’s say we wanted to make a change to an element that’s a bit more complicated than hide/show like indicating that an element or group of elements is in an error state. When I indicate an error in my application, I like to change the color of the text and background and probably show things in bold. Based on what we know so far, I could make all of those style changes with JavaScript like so:

function showError(obj){
    document.getElementById(obj).style.color = "red";
    document.getElementById(obj).style.backgroundColor = "pink";
    document.getElementById(obj).style.fontWeight = "bold";
}

It works, but it’s not great. The problem is we’re now pushing presentation information into our behavior layer. Later down the road, a designer might will probably change their mind and want their errors to look completely different. Going into the JavaScript to make those changes every single time is annoying and counter-intuitive. It would be much easier to specify these rules in our CSS like this:

.error{
    color:red;
    background-color:pink;
    font-weight:bold;
}

And then have JavaScript just attach and remove the semantically viable class to an element to keep both layers clean and separated. If your development is using a toolkit like Prototype, then you have easy access to the following two functions to do just that:

• Prototype addClassName
• Prototype removeClassName

If you’re of the do-it-yourself variety, then you might want to use the following three functions to gain the same functionality.

String.prototype.trim = function() {
    return this.replace( /^\s+|\s+$/, "" );
}function addClassName (elem, className) {
    removeClassName (elem, className);
    elem.className = (elem.className + " " + className).trim();
}function removeClassName (elem, className) {
    elem.className = elem.className.replace(className, "").trim();
}

That first function is just a trimming function to remove leading and trailing spaces that might be created during the adding and removing process when dealing with multiple class names on an element. With these two functions in our arsenal, we can now use those useful class names we discussed in the 2nd part of this series to make our prototype come alive.

Conclusion

And that concludes the Designer’s Guide to Prototyping Ajax. Remember, these articles are meant to serve as a foundation and an initial set of guidelines to help you understand and develop practices that will work best for your work flow and team environment. We’ve found them to be great ways of relieving pressure off the developers, increasing designer responsibility and better code for the team to work off of in the long run. If you or your team has any other practices that you think would be beneficial for designers or prototyping in general, please do share because the way we see it, the love just follows you back for more.