It’s not uncommon now-a-days to hear this weird jargon thrown around called ‘AJAX’, but what does it stand for?

I’ve yet to read a better history and break down than what Jeremy Keith wrote in his book entitled “Bulletproof AJAX“. So without further ado, I’m going to quote Keith a bunch:

“Jesse James Garrett is an information architect, author and founding partner of the San Francisco-based company Adaptive Path. In February 2005, he published an essay on the Adaptive Path Web site titled ‘Ajax: A New Approach to Web Applications.’ In this essay, Garrett coined the term Ajax to describe techniques used by a new kind of Web application…. It was originally intended to be an acronym standing for ‘Asynchronous JavaScript and XML.’ ”

Keith goes on to explain that the acronym implies that asynchronous and XML are requirements within AJAX, which just isn’t true. (JavaScript is definitely required in most cases, but the AJAX behavior could be done through Flash or Java as well, just to name a couple.) “Jesse James Garrett later updated his essay, making it clear that Ajax is not an acronym.” The technology has been around before Garrett as well but coining the term made it possible for most of us to talk about a set of technologies, that when used together, create a new user experience. So think of AJAX more as a user experience than a certain set of technologies.

Garrett created the term AJAX so he could more easily have a conversation with clients and his developers alike. So why is the AJAX behavior different than your traditional development? 

Example
- Tradition: You login at a web site and notice your  browser has to think for a bit while it either refreshes your current page or goes to a new one. This makes you have to reload the same content or be forced to load new content.
- AJAX alternative: You login at a web site, it gives you a little notice saying that you’re now logged in. That’s it. No loading required on your end.

What AJAX does is allow the user to send and receive information back from the site without ever having to load content. It’s not that the technology is that much smarter, or psychic, but that all the loading happens behind the scenes, putting the burden on what matters the least, in the code. What matters most is the user and their experience on your site.

So why ask for it?

AJAX allows for a faster, smoother user experience. It’s becoming so mainstream lately that it’s making more traditional web development seem bulky and slow to use in comparison. Ever used Google Maps? Yep, all AJAX. Even the competition switched over to use their techniques – Mapquest and Yahoo, to name a couple.

It’s also pretty neat on our end too. This affords us with some pretty neat effects we can do easily for our clients’ sites, like animation.

Now that you’re just a little more knowledgeable on the subject, I hope your next web site will include a lot of AJAX implementation to give your users a smoother experience. Feel free to contact us for more information regarding AJAX implementation on your site.

“Building a web site requires teamwork. Although I’m your facilitator in building your web site, the web site is an extension of your company, it still needs your work to be successful. I may be your biggest fan, but you definitely know your company better than I do.”

This may come as a surprise to some in the audience, but I’ve said that on occasion to clients in the past. When it comes to web sites, it really does require teamwork from all sides to make it successful.

I hear common questions from clients about what is required to make a successful site. Time and time again though, I have to stress that there are certain processes to web development that are done by certain people and these separations are usually, unfortunately, not common knowledge. So allow me to spoil some important secrets and provide a good foundation for those of you who are interested in creating a new company web site or looking to redesign your company’s web site.

“What does research tell us is the #1 ‘make or break’ thing we need for our web site?”
Good content. Studies time and time again show that content is more important than navigation, visual design, functionality and interactivity. ¹ To put it into perspective, content is what drives people to your site in the first place whether on purpose or by accident. Content is what people will tell other people about your company’s web site. When I advise someone to buy a book off of Amazon.com, I just told someone about the content. When I share a link with someone to read an article at BBC World News, I just advertised about the content. When I search a search engine to find an answer to my question, I’m in desperate need to find content about my question.

Beacon can provide the most exceptional, functional, useful, marketable, and pleasant web site for you, but if people don’t have a reason to use it, they simply won’t be using it. Beacon can advise you to add certain pages in your site like a “Site Map”, “Privacy Policy”, or “About Us” page, but you know your company a lot better than we do. If your company is all about selling different types of brick, only you will know if it’s important to have content on that web site explaining the different types of brick you offer and what your customers expect to see. Would they like to see photos of the different bricks? We don’t know, and we’ll suggest these things to you, but you have a much better perspective on it than we do. Just remember that your customer/audience is your #1 knowledge bank and the answers to their questions are usually necessary content material for your web site.

“What are some things we can do to improve our content?”
General tips on improving your content:

1. You may be better off hiring at least one writer to write your content. There are actually businesses devoted to writing content for the Internet you could look into.
2. Build credibility within your content by providing articles with references, show author’s/company’s credentials, make sure it’s up-to-date, and provide links to outside resources. ²
3. Provide the content based on whether it will be read on screen or printed. Generally, if you want people to read it on the monitor, and therefore quickly, keep it concise. ³
4. Avoid jargon, use familiar words, use abbreviations sparingly, use an active versus a passive voice, and make first sentences descriptive within paragraphs. ⁴
5. If all else fails, you may need to reinterpret the feedback you are getting from your customers. “Customers can’t tell you how to fix a problem; they can only tell you that the problem exists.” You may have to rethink what they’re trying to tell you. ⁵

“We loved reviewing the analysis documents with you; we never thought about this aspect before. Was there anything we could have done to foreshadow this?”
There are many ways to help the success of your site and ease the analysis process. Here are some things you should consider before starting work on the site:

1. Annette Fowler, here at Beacon, wrote an article in the past that covers some basic questions, check it out.
2. Think about your company’s web site as a medium to become an advertisement, a brochure, a customer service representative, a call center, a store, a face and a reference to your company. It can be all the things that make up your company. If you think about the web site as a separate entity from your company, then it will never be successful, it won’t work for your company. Make sure to plan your web site into your company’s business, marketing and long-term strategies before looking to create it. ⁵
3. “It’s a good idea to communicate these things to, and develop consensus from, management and those working as representatives during the development process later.” ⁶

The most important thing to remember is teamwork - when everyone involved does their best, the site will always be successful! What questions did you have regarding things you could do to improve the success of your site?

1 Asher, 1980; Badre, 2002; Baldwin, Peleg-Bruckner and McClintock, 1985; Celsi and Olson, 1988; Levine, 1996; Nielsen and Tahir, 2002; Nielsen, 1997b; Nielsen, 2000; Rajani and Rosenberg, 1999; Sano, 1996; Sinha, et al., 2001; Spyridakis, 2000; Stevens, 1980;
2 Fogg, 2002; Fogg, et al., 2001; Lightner, 2003; Nielsen, 2003.
3 Shaikh and Chaparro, 2004.
4 Cockburn and Jones, 1996; Evans, 1998; Horton, 1990; Mayhew, 1992; Morkes and Nielsen, 1997; Morkes and Nielsen, 1998; Nall, Koyani and Lafond, 2001; Schramm, 1973; Spyridakis, 2000; Tullis, 2001; Zimmerman and Prickett, 2000; Zimmerman, et al., 2002; Furnas, et al., 1987; Kucera and Francis, 1967; Leech, Rayson and Wilson, 2001; Spyridakis, 2000; Whissell, 1998; Ahlstrom and Longo, 2001; Evans, 1998; Morrell, et al., 2002; Nall, Koyani and Lafond, 2001; Nielsen and Tahir, 2002; Tullis, 2001; Flower, Hayes and Swarts, 1983; Horton, 1990; Palermo and Bourne, 1978; Palmquist and Zimmerman, 1999; Redish, Felker and Rose, 1981; Smith and Mosier, 1986; Spinillo and Dyson, 2000/2001; Spyridakis, 2000; Wright, 1977; Zimmerman and Clark, 1987; Bailey, Koyani and Nall, 2000; Lynch and Horton, 2002; Morkes and Nielsen, 1997; Morkes and Nielsen, 1998; Spyridakis, 2000.
5 Lee Gomes, “Good Site, Bad Site: Evolving Web Design“. 2007, The Wall Street Journal.
6 Badre, 2002; Coney and Steehouder, 2000; Detweiler and Omanson, 1996.
All references, with exception to Gomes, have been  obtained within the research of Shneiderman, “Research-Based Web Design & Usability Guidelines”. 2007, U.S. Government Official Edition. ISBN: 0-16-076270-7

Every usability expert, designer or developer could give you different opinions about what makes forms more usable, less confusing and less daunting. I sought out to research all the experiments and form a general list of things that developers, designers, and gurus should and should not do. The rest, as usual, always depends on the context of the project.

After combining this research with fellow co-workers and everyone’s combined knowledge, I generated a short list of common things you can do to improve your forms, but I want to discuss what types of forms I’m talking about first.

One type of form is the generic one: I’m talking about the generic “contact” form on the web, the one with fields that aren’t even new to my grandmother anymore. Fields are empty areas for you to fill in data, usually personal data. Fields like “Name”, “E-Mail Address” and “Comments” are very well known. Also, forms like “Request for Quote”, “Search” or “Sweepstakes” have much in common with the “Contact” form: they are generic, no task required, “enter in that information yet again”, forms.

The other type of form is one that requires more thought on the user. Forms like these include insurance quotes, submitting payment, government forms, loan requests, etc. These are the types of forms you receive in the mail in a booklet and have an instruction book accompanying it. These forms are quite different from the “generic” forms I mentioned above. The more data and thought necessary required from the user, the more division and instruction is needed in the form itself. In general, I think each form in this division should be designed in each instance, so I don’t think general tips apply all the time, but most of the ones I will list can apply.

So we will only be discussing the generic form, which is a good base for any working professional in this area I think. This form shares a commonality with many others, your contact form will be at least 50% identical the next guy’s contact form, and this means that already your user base is experienced with your form. Which brings me to the first tip:

#1 Don’t break convention just because it looks neat or you think it’s better
Break convention only if it works better. Your forms should be putting your user first. They are active participants ready to endure your form gauntlet – do not change their minds! Making your forms work should be the number one priority. What’s the only way to know if it’s working better? Field testing.

#2 Do field testing
I can’t agree with the usability experts more: field testing always shows you what went wrong or right with your forms. I understand that many companies lack the resources to hold usability tests, but they are a necessity. My favorite thing to do is actually allow the client to field test by bringing them in and watching them use your form. Make your coworker do it. Make your mom do it. Don’t tell them you’re testing the usability, make something up. If you are able to watch them use it, you did not guide them through it and you learned something from the experience, congratulations, you just did usability testing. Now take notes and correct what went wrong. This won’t be as accurate as some measurement tools the experts have, but it’s just as helpful and it was free. Have to say, nothing is more embarrassing then to watch that client months later use it and complain because it makes them frustrated or simply does not work. Field test before it’s too late.

#3 “Use the right field for the right task”¹⁸
Crescimanno and Nielsen argue that every field type should be appropriated correctly with the label. For example, if your label said “First Name” you should not use a radiobox for your field because then the user cannot correctly fill in their first name. A more complex example would be if your label said “Expiration Date” and you gave the user 3 drop down menus, 1 for month, 1 for day and 1 for year. The month and day fields have an absolute beginning and end, 01-12 for month and 10-31 for day. The year field, on the other hand, is a bit arbitrary since we are concerned with when said subject expires. Do you list the years until 2012? 2050? Should the user have to endure a very, very long drop down menu or should the user face having their year not even listed? If you put into too many years or not list enough, respectively, this could happen. Why not just make all 3 fields free entry? Or why not require just month and year in the same format and make it easier not only for the user, but also your developer? Usually there is a good solution to every type of data you need. And like Crescimanno suggests, stay away from multiple-selection boxes that are confusing (and may not even work in all browsers).

#4 Don’t let your clients pick your form structure for you
Unless your client is a certified master in creating usable forms, don’t allow them to pick what type of data they “think” they need. Have a good sit down with them and ask considerate questions about why they think they need this form, what do they expect from the user, what data are they looking for, how do they intend on using the data, and so on. I guarantee that your company (full of qualified, wonderful people) can create not only a more usable form, but also a form that integrates better with the database, integrates better with the graphical design of the website it is in, does not deter the user away, that takes the least amount of time to fill in, etc. Clients are blind-sighted by the bigger picture, take control of this crucial analysis process.

#5 Use informative error messages¹
Don’t tell me the form encountered a critical error after I hit “submit”. Don’t tell me my e-mail address is invalid when I only have not registered with it yet. Don’t tell me my password is not strong enough, tell me why. Please.

#6 Use better placed labels¹²³
Do not make them bold, do not place them far away, make them consistent with other labels, right-align if you won’t place the label above the field and don’t use illegible fonts.

#7 Quit putting in a reset button⁴
Reset buttons are accidentally hit instead of the “submit” button when the user submits a form, so what purpose does it serve?

References:
1 A List Apart: Sensible Forms: A Form Usability Checklist
2 UX Matters: Evaluating the Usability of Search Forms Using Eyetracking: A Practical Approach
3 UX Matters: Label Placement in Forms
4 Creating Good Websites: Usability
5 Sitepoint: 7 Steps to Usable Forms
6 Jarrett, Caroline. “Designing Usable Forms”, 2000, Effortmark.
7 Jarrett, Caroline and Christopher Minott. “Making a better web form”, 2003?, Effortmark.
8 Miller, Sarah and Caroline Jarrett. “Should I use a drop-down? Four steps for choosing form elements on the Web”, 2001, Effortmark.
9 Krug, Steve. “Don’t Make Me Think: A Common Sense Approach to Web Usability”, 2000, New Riders Press.
10 Nielsen, Jakob. “Designing Web Usability”, 1999, Peachpit Press.