Prototyping with XHTML

Written by: Anders Ramsay

Illustrations by Leah Buley

If you design user experiences for standards-based websites and applications (i.e. those built with XHTML, CSS, and JavaScript), there are several great reasons for adding XHTML prototyping to your UX tool kit. Perhaps you’ve found that traditional wireframes just aren’t sufficient and are looking for more powerful ways to explore and communicate design solutions. Perhaps your current practice is based on the traditional waterfall model (i.e. first creating wireframes, which are handed off to creative, who hand off comps to tech, and so forth), and you want to explore more contemporary methodologies, such as agile and iterative development. Regardless, a great way to embark on that journey is to start prototyping with XHTML.

So what does it mean to prototype with XHTML? Essentially, it’s the process of using the XHTML itself, and related technologies, to evolve and define your design solution. And what does an XHTML prototype look like? While, as we’ll see, that depends on where you are in your prototyping process, an XHTML prototype generally looks like any other web page built with XHTML, with some links or features perhaps being non-functional. In other words, anything you can build with XHTML, from consumer websites to enterprise applications, you can also prototype with XHTML. As we’ll see, there are numerous advantages to this approach compared to designing with wireframes or other prototyping tools.

An Iterative Process

While prototyping with XHTML isn’t tied to a specific design process, iterative development seems to effectively leverage its strengths. There are many reasons for this, but perhaps the most significant is that in both cases the prototype, and later the application itself, doubles as a specification. We’ll explore what that means in a bit, but first let’s walk through a suggested process for prototyping with XHTML.Let us start with an overview of the larger design process:

In this (iterative) methodology, rather than design the entire application before starting to build it, one designs and builds a unit of the application and then uses what has been built to inform and serve as a starting point for other application units. As with other design methods, the design work begins with sketching, which plays a particularly important role relative to prototyping.

Sketching: A Freeform Question

The term ‘sketching’ refers here to any freeform exploration unconstrained by a specific technology. This includes production of wireframes, which in this model are reframed, as it were, from specification artifact to refined sketch. When thought of, and presented to stakeholders, as sketches, its more natural to discard your wireframes once the design has evolved beyond them. This is usually after a prototype equivalent has been produced. With the design team I work with, we’ve found that when prototyping with XHTML, wireframes often became superfluous, and it’s more effective to go directly from sketch to prototype.

Prototyping: A Concrete Response

Prototyping has a counterpoint relationship to sketching. To paraphrase Bill Buxton, while sketches ask a question—“Is this a good design idea?”— prototypes provide a response. By making the idea manifest, prototypes force upon it the concrete realities and user experience idiosyncrasies of the actual production technology and offer a crisp verdict on the quality of what you dreamed up in drawings.

The Prototype/Build Relationship

When prototyping with XHTML, especially in an iterative model, the build and prototype become very intertwined. If you’re prototyping a new application or product, the XHTML prototype is essentially a rough draft of the actual application. However, when updating the design of an existing application, the production version can serve as the starting point for the prototype of the new solution.

Three Integrated Layers: Structure, Behavior, Foundation

The model for XHTML prototyping is based on the best practices model for actual site production: start by setting the foundation with XHTML, add a presentation layer with CSS, follow it by a behavioral layer using JavaScript then iterate.

Let’s start by looking at the structural layer.

Structure: Set the Page Foundation

The first step in production of the XHTML prototype is to create a structural foundation. Similar to how we create a wireframe, we start by representing the main content areas on the page, except we do so with text-based XHTML markup.

| If our sketch or wireframe looks like this | …our XHTML might look like this: |
|^. |^.

My Account

Account options

Account details

Account Help


(We’re only displaying the relevant snippet of the XHTML here.)
|

Next, we add detailed content elements that have been defined, using the XHTML structure appropriate for the corresponding content.

| For example, if our detailed sketch looks like this | …we’d represent the list of account help topics as an unordered list (i.e. use the ul tag): |
|^. |^.


|

Continuing to add detailed content to the page, we have essentially produced a structured content inventory of the page. This serves as a foundation for the rest of the prototype production. While wireframes force us to represent a page’s information architecture within a specific layout, this is pure structure and hierarchy, and, in my opinion, represents the true information architecture of a web page.

By defining the information architecture directly in the XHTML, we can also easily define accessibility-specific attributes, such as being cognizant of how users traversing the page with a screen reader will experience the page, and order content blocks accordingly. Additionally, we can more easily define elements often overlooked when working with wireframes, such as effective use ofLabel tags in forms.

If one were to view the structural layer in a browser, it would essentially look like an unstyled web page, and would not be interesting to look at. Just as building foundations are not known for their aesthetic qualities, but instead for the impact their quality has on the building they support, so too will the quality of the page structure significantly impact the overall quality of the web page. In fact, that absence of style is a key advantage of working with XHTML.

Evolving the Presentation Layer

With a page structure in place, we are ready to focus on how content will be presented. Looking back at our sketches, we’ve already explored some layout concepts, which we can begin to apply to our content structure. The way that look and feel is developed and applied will vary widely from team to team. While you may choose to do your initial exploration of look and feel with design comps, especially if you are also developing an overall brand, it’s worthwhile to redefine comps similarly to how we previously redefined wireframes. Just like wireframes are great as sketches, design comps are great for initial exploration of look and feel. But the practice of fully developing the presentation layer away from the actual technology, and then cutting it up and applying it wholesale to a web page is like wallpapering a façade onto a building. It’s impossible to be aware of all the dynamic aspects of a web page when working in static illustration software. However, when prototyping with XHTML, you can leverage the power of rendering your design in the same way that it will be seen by users, and incrementally evolve page presentation based on this immediate and rich feedback.

Issues that don’t easily reveal themselves when working in illustration software will often be obvious. This includes issues related to your design and the browser viewport, from the basic question of if the design should center itself in the browser window, to more advanced issues, such as how to design for different window sizes and browser resolutions. For example, for small windows sizes, is it okay if some content disappears out of view, or should the design adapt to the window size? When look and feel is designed solely with illustration software, questions like this are often unexplored to the detriment of user experience.

Adding Behavior: Unreinventing the Wheel

When prototyping with XHTML, you are designing within the larger ecosystem of the web, which effectively becomes your always-up-to-date UI library. Instead of laboring over the design of a detailed piece of functionality, start by letting Google inform you if anyone else has designed and built something similar, and then use that as the starting point for your solution. This can include anything from date-pickers to web widgets to whatever cutting edge UI idea was just created. Additionally, prototyping with XHTML makes it easy to incorporate and simulate Web 2.0 functionality, such as embedded widgets and syndication. If you don’t know JavaScript, or whatever technology is being used, you can collaborate with your developer on integrating the solution. Of course, you’re not going to find a solution for all your design needs online. In those cases, go back to sketching and collaborating with your team.

Iteration: Discovery, Evolution

The true power of prototyping really emerges during iteration This is when users can interact with your prototype. On a recent project, we sketched out a solution in which users could drag videos from a library onto a playlist. Looking at the static illustrations, it seemed a simple and elegant idea. But when users were able to interact with the solution, dragging and dropping video thumbnails, they found that it was a pretty tedious activity, especially for large numbers of videos. In other words, the prototype allowed us to discover a design problem that went unnoticed when looking at a wireframe.

And therein lies a core problem with using static artifacts to communicate interactive solutions; they effectively force the user to prototype the solution in their imagination, where all solutions seem to function in glorious perfection. With XHTML, we minimize the cognitive leap that users need to make, allowing them to instead experience and respond to something nearly identical to the actual solution.

Once users provide feedback and the team begins work on the next iteration, another measure of the quality of the prototyping methodology comes into play: how rapidly are you able to iterate? The longer an iteration takes, the less valuable your prototype. When prototyping with XHTML, iterations can be incredibly fast, first because the prototype can be easily presented to users, since it’s usually just a question of posting your files and sending out a URL. Second, because XHTML is text-based, iterations such as text changes or basic functional updates can often be completed in just a few minutes. More advanced design updates usually don’t take more than a few hours of actual production time.

How XHTML Can Double as a Specification

One of the most powerful aspects of XHTML is that it is self-describing. The same XHTML markup that tells a browser what to display can also double as a specification for a developer. For example…

^.

^.

This markup Would be read as
^.

“This is the start of the header content block.”
   
^. XYZ Application “display the product name, which should link to the homepage”
   
^.

Signed in as Jane Smith (Editor)

;

^. “display user information, including the user’s role (or set of application permissions”

In buzzword-speak, the practice we are applying here is writing semantically meaningful markup, which means we are selecting tags and naming our IDs and Classes such that they communicate the meaning and function of the content they enclose.

Annotations Visible Only to Those Who Care About Them

Another advantage of using XHTML as a specification is that IDs and Class names can double as annotation references. In other words, the annotations for the content block with the ID “account-options” would appear under the heading “Account Options” in your specification.

Rather than obscure and clutter a page design by placing annotation callouts on top of it, a common practice when using wireframes, that may confuse and distract non-technical viewers, references are only in the markup view for developers who are interested in seeing them. And since the XHTML file itself is so richly informative, the actual annotations written tend to only be short bullet points.

More Standards, Less Noise

One of the biggest problems with wireframes is the lack of a standardized notation. In other words, my wireframes certainly don’t look anything like your wireframes. This means that visual designers and developers who use wireframes are continually relearning how to interpret our work, leading to noise between author and reader. To compensate for the lack of a standard, we have to create highly detailed wireframes, with often lengthy annotations that explain what our wireframes mean and how elements in them work. These, in turn, are collected in large specification documents that usually are so labor-intensive they become impossible to maintain. When they are no longer kept up-to-date, the team stops trusting and relying on them as the design specification, which leads to all kinds of bad things happening.

In contrast to wireframes, XHTML is a standardized notation, anyone who knows XHTML can read your document. More importantly, it is a language spoken fluently by a key target audience of your design documents, the developers. And those who don’t know or care about XHTML can view the part they do care about, the page design, by opening the document in a browser.

Using a standardized notation also means you are not confined to specialized wireframing or prototyping software, but can use anything from a simple text editor to the range of tools available for editing XHTML files. Also the compact syntax of XHTML, particularly compared to verbose wireframe annotations, combined with the fact that you are just typing in a text file, leaving it to a browser to deal with the visuals, allows you to work rapidly and efficiently.

A Small Amount of Knowledge Goes a Long Way

If you’re new to XHTML, you’ll discover that a small amount of knowledge goes a long way. Spend just a few hours following any of the innumerable online tutorials and you’ll be writing XHTML markup in no time. (Two great places to start are htmldog.com or w3schools.com) Better yet, rather than invest time learning the UX tool du jour, you deepen your understanding of the technology that realizes your design.

Dividing and Conquering

The redefining of a wireframe from a blueprint to a sketch has a domino effect on who does what and when in evolving the page or application design. After a rough page design has been sketched out, rather than have one team member toil away in isolation, wireframing detailed representations of each page design, this model takes a divide-and-conquer approach. On the team I work with, I might produce an initial cut of the XHTML and some of the CSS, while other team members build on that, updating the XHTML, adding more advanced CSS, as well as JavaScript. If the team as a whole conceives of a solution, why not also have the team as a whole design it? In other words, rather than creating one person’s vision of a team’s solution, why not have the entire team contribute their particular expertise? When working with XHTML, we can use the tight integration of CSS and JavaScript to allow team members to contribute their dimension of the design via a set of integrated artifacts.

Where To Go From Here

This has, of course, been a mere whetting of the appetite for anyone interested in prototyping with XHTML. If you are interested in exploring the methodology further, particularly if you currently follow a traditional waterfall-oriented process, I recommend a many-small-steps approach. In other words, prototype the methodology itself, working with your team on a small project, and then building on that. If your experience is anything like mine, you’ll find it an incredibly powerful addition to your UX toolbox — a more effective way to straddle that proverbial divide between user experience and technology.

Getting a Form’s Structure Right: Designing Usable Online Email Applications

Written by: Afshan Kirmani

I started writing this article with an emphasis on the financial domain. I then realized that I would like to broaden the focus because my findings are also applicable to a general domain like email account registrations, for example. In this article, I would like to take a simple example of how users register for an email account online. For a first timer, is the transition from a real world of letter writing to the online medium easy? And for a frequent user, is he or she motivated enough to create an email account with another service provider?

Yes, this is for all of you out there—my fellow usability practitioners, information architects, designers, managers, project leads, editors, and people who are looking to develop their UX practice.

In the modern family, where often both parents are working full-time and the children are involved in many after-school activities, people may only have a few minutes to spare on an important task during the day. And it’s the Internet that supposedly helps people achieve this. But do we, as designers and usability practitioners, always help them do it? I say, “No.”

Just the other day, a friend of mine begins to complain of the spam mails that she receives everyday. “I have two separate email ID’s to keep myself away from such mails—one for official purposes and the other for my junk emails. But even my official ID seems to be flooded with these emails. So I found myself moving to another email service provider. Again, I found myself grappling with the registration process.”

There are three people who determine success of a web-based form: the usability practitioner, the designer, and the user (Image 1). Taking a simple everyday example like an email service, I aim to discuss the various aspects that lead to a great forms structure.

Image 1: Success of a web-based form requires involvement of a usability practitioner, designer, and user.

There are a million websites out there. There are a million email service providers out there. How do you ensure that you gain the right audience to join your service? What are those factors that will help users move ahead and become your loyal customer? Part of the answer has to do with the first step: REGISTRATION!

In the first part of this series, I will focus on the basic issues that a usability practitioner must address to create a usable web-based form:

  1. Affordance
  2. Orientation
  3. Chunking

1. Affordance: The Lure

We all know how grueling and tedious a registration process can be. Therefore, we need to ensure that our sites adequately “lure” users into the process. To do this successfully is not just a matter of providing the right cues, but how and where we provide them.

Coming from the real world

Every online form was created keeping the real world in mind. We all once began filling in forms in real life before we began moving to the online medium of getting things done quicker.

Email service providers must allow for a smooth transition from a real world scenario to the internet, for those who are petrified of it. Users should know the advantages of the service provided as compared to the real world scenario of letter writing. Why would users move to your service when they can just write a letter? What are the advantages of sending an email? Is it quick? It is easy? These issues should be addressed upfront to ensure that they are lured forward.

None of the websites that I reviewed follow this practice effectively.

Entry points

An entry point to an application must be clear and appropriate to the specific needs of the user. For example, let’s say a user visits a website to send out an email to a distant relative. He or she has never used a web-based email service before. Not knowing that he/she needs to register, they would look for a direct cue to send out an email. Where do you think this user would look for a cue? This is where you need to perform a quick goal-task analysis. Let’s consider a scenario:

A first timer enters the website to send out an email. This user is hauled because he/she is unsure of their next step.

Let’s have a look at Gmail, our most used email provider. Most websites that I reviewed allow you to register. But users are not lured into it. As a first time user of a website, they need to know the benefits of registering clearly, up front. Gmail does a good job of this (Image 2).

Users often hate to register. Therefore, as usability practitioners, we need to tell them of the benefits of registration when they enter a website for the first time.

Image 2: A good example of enticing users to register online by clearly listing the benefits up front.

Service/Product comparison

Remember, your users are watching your competitors as well. So if you aren’t that big in the market, how exactly would you think big? Compare your features with that of your competitors to formulate your strengths over the others in the market. Let’s see how Bluebottle effectively does this (Image 3).

Image 3: Bluebottle’s website allows users to take a peek at service comparisons. Users also have the freedom to view a detailed comparison.

Online benefits

It is important to inform the user up front of what they will gain after registering. It’s a competitive world out there and users must and should know what the website is selling them. This affirms the brand’s identity and responsibility to gain customers online. A basic cue reassuring users about the benefits helps build trust which encourages them to use your services. As shown in image 2, Gmail clearly provides the online benefits.

Another clever way to entice them is to provide a view of what the service looks like once they have registered or applied. In this case, it would be ideal to show users on the homepage a view of what their personal landing page (the inbox) would look like once they have registered.

None of the websites that I reviewed follow this practice rightly.

Security

It is essential that users know that the information they are entering will be secure. A basic “Lock” or “Key” icon would do the trick. Also, providing them with security information and its benefits improves customer loyalty and trust. With the case of Yahoo, the website uniquely utilizes this feature to grab users towards their secure service (Image 4).

Image 4: Providing a security message increases loyalty which moves users towards registering.

Taking a tour

Before users move ahead to encounter a form, it is necessary to tell them why they need to do it and most importantly how they need to do it. Again, taking the same examples forward, if you look at the example below, you will see how AIM Mail allows users to take a tour (Image 5). This also gives an edge to its competitors as they are showing them of what’s inside even before registering.

Image 5: The website allows users to take a tour before registering.

User’s path forward

This doesn’t just end with the benefits. Users have to be told where to go after they have been guided. All websites do provide a way to move ahead. But I specifically want to use an example that can show improvement in terms of placement of this cue, which is most important while users are making a decision.

We love Gmail. But we sometimes wish it were always right.

Provide users with a clear path forward AFTER you are done enticing them with the meat.

Image 6: The website must provide a clear path forward after enticing users with the benefits.

Consistent design

As users transition from the homepage to the form, it is important that the design of the pages remain consistent. Any small change in the design or layout could affect their performance and decrease the overall experience.

Most websites get this right. But we can still look for improvement. Let’s have a look at the example below (Image 7). Here, as users move from the landing page to the form, we see significant changes in the layout and the visual design.

Image 7: The design of the page is inconsistent with the previous page.

An overview of what’s to come

As users enter the application, they need to know what to expect, however short it maybe. Therefore, throwing users directly into a form is not the best way to help them achieve their goals. Instead, the website must first provide users with an overview of what’s to come, including the application requirements and the next steps. This can be just a few lines telling them of the benefits, the things that are expected and an instant access to their emails soon after they are done.

Let’s have a look at Yahoo as an example (Image 8). It doesn’t do a perfect job. But it’s nearly there. All the information that the user is expected to provide during the registration process is described up front.

Image 8: The website informs users of what is expected of them while registering.

Lending a helping hand

We all know that people fumble along the way. Heck, sometimes I come across forms that I don’t understand. Therefore, it is essential to provide users with online help whenever needed.

For applications that drive business, a toll free number is essential as this brings in the revenue. But with the case of an email service provider, online help would suffice.

The visibility and location of the help link is equally important. By providing this, you can ensure that users not only find it quickly but also feel safe just by seeing it. This is also useful for first time users who are just transitioning from the real world of letter writing to the web world of emails.

None of the websites that I reviewed follow this practice successfully.

Language aid

There are websites that allow users to view their services in the language they choose. This should also be the case with web forms. Choosing the language of their choice gives them freedom and control. It also helps them move forward and register as they can be assured that the website caters to their needs as well.

Image 9: The website provides a way for users to set their language preferences.

Save and continue

Let’s say that the basic goal is to register online, so why not just save users’ information automatically as they proceed? A basic “Save and Continue” button would not only tell users that their information is automatically saved but it would also allow them to access the information if they need to resume the application later.

Now if your form is just a page long, you would obviously need a button that reads “submit” or “done”.

Most websites only follow the later.

2. Orientation

Form title

Ensuring that the page header follows a clear task flow from the preceding cue helps applicants orient themselves to the page. Most websites do this successfully. Let’s take a look at the example below (Image 10). Gmail follows a clear flow from one page to another, telling the users where they are at each specific point in time.

 

Image 10: The website provides a clear orientation feedback to the users as they move from one page to another.

Progress indicator

How ever short or long your application form maybe, users need to know their path ahead. A well-positioned progress indicator outlining the entire application process helps users see what lies ahead of them. There’s no use of providing the progress indicator on the left or the right of the form. Users need it up front as they do not tend to look to the left or the right of the form when they are entering information into an application. The best way to grab the user’s attention is to display the progress indicator on the top of every page of the application.

Let’s have a look at an example below (Image 11). This website has got the concept right. Yet, it can further deliver what’s best for users at this point. If you are providing users with a form, make sure that you tell them what each step entails. For example, Step 1: Enter your personal details. The example below does provide a progress indicator by telling users of the number of steps ahead. Yet, it fails to mention the step details.

Image 11: An example of a progress indicator. Though, the website needs to take a further step to provide the step details.

Progress feedback

More than 60% of web-based forms that I’ve encountered add in extra steps along the way, ones not included in the progress indicator. As applicants do not see all the steps up front, they are baffled when additional steps start appearing. When you tell users that the form entails 3 steps, don’t cheat them. Keep it to 3 however tempted you might be. With the example above (Image 11), users are probed into a number of pages, viewing the same orientation feedback for pages to come. Make sure that each step is provided on the same page. Moving them through pages and providing them with the same orientation feedback is only going to cause confusion.

3. Chunking

People perceive information more easily when related parts are grouped. This increases users’ efficiency and reduces reading effort. Chunking information into related parts helps users better understand information to navigate more effectively.

Headers

Ensure that you break the form into logical content groups and provide relevant headers for each information chunk. I have seen more than 90% of web forms that just provide the main header and then continue with about 20 questions on the same page. This can overwhelm a user. A quick way to organize information into groups would be to do a card sort with potential users of the application or even your co-workers. An example of effective chunking is found at Yahoo and My Way (Image 12 and 13).

A clever trick is to number the chunks to allow users to perceive how much is left and also to perceive that they are moving forward. It provides clear direction of a way forward.

Image 12: The form is well-chunked, with clear headers describing the grouped content.

Image 13: The form is well-chunked, with clear headers describing the grouped content.

Labels

Labels on individual pages within the application process must be related to the main header as well as its elements. For example, forms should display a clear and simple header along with related sub-headers. In the example above (Image 12 and 13), the sub-headers (labels) are clearly grouped with their header. You have personal information and password information separated with clear headers that define the structure. This provides clarity and direction.

Summary

As usability practitioners, we need to first and foremost understand the user’s intentions and expectations, in order to provide an online experience that accommodates them. The image below (Image 14) shows the mapping between the user’s intentions and expectations and the ways in which the usability practitioner can help accommodate them in order to ensure the ultimate success of online application forms.

 

Image 14: The usability practitioner ensures that the form’s structure accommodates the user’s mental model, experience, and expectations.

The journey of creating a successful online application form requires three people working in parallel: the usability practitioner, the designer, and the user. The usability practitioner needs to keep in mind the big picture. The designer needs to have a clear understanding of all the details that will go into the form’s structure. The user helps shape the overall approach to the application form and ensures its ultimate success.

You might agree, partially agree, or even disagree with my thoughts. You might even have something to add to this. Let’s hear your point of view. We are innovating, remember?

Coming up…

The next part of this article will focus on the designer’s role in the process of creating the form’s structure, layout, segmentation, widgets, color schemes, formatting, alignment, and consistency.


References

  • “GUI Design for Dummies” by Laura Arlov, 1997
  • “GUI Bloopers: Don’ts and Do’s for Software Developers and Web Designers” by Jeff Johnson, 2000

 

Calling in the Big Guns

Written by: Will Evans

B&A readers get 10% off when purchasing from Rosenfeldmedia.com (use code WFDBA)
Discount for Boxes and Arrows readers: Get a 10% discount by purchasing the book directly from Rosenfeld Media. Just use the code WFDBA.

The scene is all too familiar. You’re presenting wireframes of the registration process for a new web application when the discussion veers down a dark alley. The sky has turned the color of black ink, and you can smell sulfur in the air as one team member after another debates the alignment of form labels.

Before you can toss up a quick Hail Mary, marketing says that the opt-in for marketing solicitations has to be defaulted to yes, and you can feel your soul sucked out of your body through your nose as a simple one hour meeting turns into a 3 hour discussion over the pro’s and cons of inline validation while your stomach grumbles because you just missed lunch.

I have heard this war story many times from many interaction designers and information architects, with little variation except in the details. What we need is air cover in this battle to design better forms. Now, it’s here.

“Forms Suck!”

And so Luke Wroblewski begins his new book on web form design with a canon shot, providing just the air cover and ammunition interaction designers need; and every review, including this one, begins with a first impression.

Mine was: Boffo.

(bof·fo (bf) slang, adj.: Extremely successful; great.)

Wroblewski opens “Web Form Design” with a strategic exploration of why users interact with forms. News flash: It’s not because they enjoy it. Interaction designers need to confront the truth that a user’s goal is to get to some successful outcome on the other side of a form – as quickly and painlessly as possible. We want our iPhone, tax return, or account with Facebook. We don’t want to fill out forms.

bq. Forms suck. If you don’t believe me, try to find people who like filling them in. You may turn up an accountant who gets a rush when wrapping up a client’s tax return or perhaps a desk clerk who loves to tidy up office payroll. But for most of us, forms are just an annoyance. What we want to do is to vote, apply for a job, buy a book online, join a group, or get a rebate back from a recent purchase. Forms just stand in our way.

Wroblewski has researched everything from the basics of good form design, to labels and most-direct route, delivering his explanations, patterns and recommendations with a casual urgency that avoids preaching. This book is a useful guide for both the novice interaction designer and the battle tested UX guru, offering salient, field tested examples of the good, bad, and often times ugly forms that have proliferated the web like so many mushrooms after a good rain.

Wroblewski has also invited many seasoned professionals to contribute sidebars, including Caroline Jarrett’s no-nonsense perspective on designing great forms by advising us to “start thinking about people and relationships,” instead of just diving into labeling our forms and choosing where to put the Submit button. I especially appreciated her strategic guidelines for picking what questions should go into a form in the first place, which she aptly titles “Keep, Cut, Postpone, or Explain.”

Wroblewski is aware of how challenging most readers will find good form design. It comes as a relief, for instance, when he writes that we should think less about forms as a means of filling a database, and more as a means of creating a meaningful conversation between the user and the company.

He generally succeeds at adopting the warm tone of a confidant who can win you over with self-deprecating, you-too-can-make-dynamic-forms-every-day enthusiasm. The more subtle points of user-centered design or goal-driven design are not discussed explicitly; only the trained ear will detect them.

What’s In the Book?

“Web Form Design” is part of a wave of User Experience books from Rosenfeld Media – books focused on bringing practical, actionable and well-researched methods to actual practitioners in the field. This literature is going to have a powerful effect on our community of practice, maybe as powerful as the effect the Polar Bear book had on our grandparents’ era. This volume is broken out into three sections:

Section one: “Form Structure” begins with an overview of why form design matters and describes the principles behind good form design, followed by Form Organization, Path to Completion, and Labels (hint: your form design should start from goals). Working quickly through strategy to tactics, Wroblewski gives numerous examples – within the context of usability studies – so that you are not left wondering whether these patterns are recommended based just on his opinion.

Section two: “Form Elements,” is a useful, clearly written exploration of each of the components of form design: labels, fields, actions and messages (help, errors, success). Wroblewski attacks each one of these by defining particular problem spaces, and then shows good and bad solutions to the problems while highlighting how these solutions faired in controlled usability tests, including eye-tracking. He then finishes each chapter off with a succinct list of ‘Best Practices’ that I suggest are good enough to staple to the inside of your eyelids.

Section three” “Form Interaction,” includes chapters on everything from Inline Validation to Selection-dependent Inputs (a barn burner). Here we move from the world of designing labels, alignment, and content to designing the actual complex interactions between the system — that wants to be fed like the plant in Little Shop of Horrors –- and the world-weary user that just wants to get to the other side of the rainbow. As Wroblewski explains in his opening of chapter 9 “Inline Validation:”

Despite our best efforts to format questions clearly and provide meaningful affordances for our inputs, some of our questions will always have more than one possible answer…

Inline validation can provide several types of feedback: confirmation that an appropriate answer was given, suggestions for valid answers, and real-time updates designed to help people stay within necessary limits. These bits of feedback usually happen when people begin, continue, or stop entering answers within input fields.

To establish communication between the user and the form, provide clear, easy-to-read feedback so that the user doesn’t get the “select a username or die” travesty that we see in registration forms all over the web. You know the ones: you type in your name, choose a username, enter your email address, and your password (twice), hit the submit button…and…bad things happen. The username is already taken. Worse, the form is cleared and you have to enter all that information all over again. Wroblewski provides advice for validation (without set-in-stone rules), and a bulleted list of best practices.

The final, and perhaps most interesting chapter in the book, covers the topic of Gradual Engagement. This is particularly timely given the kudzu-like proliferation of Web 2.0 applications and services as well as social networking sites and micro-blogging sites. Instead of starting your engagement with a new company that all your friends are raving about with yet another registration form – as Wroblewski writes:

bq. “We can do better. In fact, I believe we can get people engaged with digital services in a way that tells them how they work and why they should care enough to use them.1 I also believe we can do this without explicitly making them fill out a sign-up form as a first step.”

He continues by highlighting the benefits of moving a user through the application or service – actually engaging with it, and seeing it’s benefits, while registration is either postponed, or handled behind the scenes. He explores web applications like JumpCut, where the user steps through the process of creating, uploading and editing their video — and only when they actually want to publish and share it, does the user encounter a form — at which point they have already learned the service, it’s benefits, and it’s value. This is certainly a more engaging experience than being confronted with a form and a captcha before ever realizing the value of the web application. He ends this compelling chapter by providing some advise and best practices :

bq. When you’re exploring if gradual engagement might be right for your Web service, it’s important to consider how a series of interactions can explain how potential customers can use your service and why they should care. Gradual engagement isn’t well served by simply distributing each of your sign-up form input fields onto separate Web pages.

Wroblewski showed three excellent examples of web applications that seem to very successfully utilize this new strategy for engaging new users while avoiding or at least postponing the ubiquitous registration process. This is certainly welcome news. The key is to rethink how new users become engaged with your company. Does the conversation start with a form? Gradually introducing new customers to your service and it’s benefits – letting them actually use it and learn it first seems like a better way to start the conversation.

I wish this chapter had more to it, as it covers an exciting exploration of web application design innovation. Wroblewski wrote a very compelling article in UXmatters back in 2006 titled, “The Complexity of Simplicity,” which was a predecessor to this chapter of the book. After an extensive search online, this was about the only source I could find other than some blog posts referencing that article. One article on ReadWriteWeb, “Good UI Design: Make It Easy, Show Me You Care” did include two more examples – FuseCal, a calendar syncing online application, and Twiddla, an online whiteboarding service.

Another spot that could have used improvement were in the last chapter. Perhaps this was either my reading of it or the way it was presented. What’s Next, certainly made me feel that he would be exploring his vision of the future of form design, and forms in general — which he certainly does in the section on the disappearing form, and proceeds into a very brief discussion of game-like elicitation methods (GEMS). These are welcome additions, I wish that he had gone a bit deeper into this chapter, especially about GEMS. It’s a fascinating discussion point, and we will see more examples in the coming year.

I also wanted more resources and references to studies that a form designer, information architect or interaction designer could use to bolster their design decisions. Many good designers out there know how to design good forms. The hard part is the politics and the negotiation process with stakeholders — and numbers always help.

I am reminded of a conversation I had over lunch about a month ago here in D.C. The UX professional was giving a short presentation on form design to an in-house crowd and was trying to subtly indicate the value that often times less is more in form design. He wanted to show to stakeholders that the concept that adding one, two, or four more form fields in a registration process has a cost, even if the design and development cost is minimal. I suggested that a simple info graphic that showed how, as the number of form fields increased, user signups decreased. His immediate reaction was that some stakeholders would immediately want to see metrics to back up the assertion.

I am unaware of any numbers about fall-off rates, but from my professional experience tells me less is better than confronting a first-time potential user with a long form to complete. Perhaps it would be sufficient to include a “Further Reading” section divided up into sections like Academic Research, Field Studies, and Conference Papers. The book may not the best place to put something like this — I wonder if the online companion to this book has such a thing. Either way, it would be a valuable addition.

Summary

What is likely to win the most converts, though, is the joy Wroblewski takes in designing. This impression becomes clear as you page through the book. He isn’t just an ardent evangelizer, following the rituals of going to conferences selling snake oil. He’s been there in the trenches, just like you; he’s done this a hundred, maybe a thousand times. He’s tested these ideas and provides a framework for you to use from day one. Half the battle in good form design is defending your decisions to stakeholders. This is your air cover, so call it in!

You can get Web Form Design from Rosenfeld Media or Amazon.com. Just keep in mind that, for the same price, Rosenfeld Media tosses in a nicely formatted digital version which you can use to quote from when you have to sell a good form design to a team that wants to bicker over form labels.

Don’t forget the discount for Boxes and Arrows readers: Get a 10% discount by purchasing the book directly from Rosenfeld Media. Just use the code WFDBA.

Web Form Design: Filling in the Blanks
By Luke Wroblewski; foreword by JaredSpool.
RosenfeldMedia: May,2008.
ISBN:1933820241
Buy from: Rosenfeld | Amazon