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.”
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.
If you found this post useful you may also want to check these out:
