Visual Cues and Affordances
One of the things usability experts try to do is construct an interface in such a way that people don't need to be trained on it. The interface should use patterns that suggest the features and functionality within, that is, something that can be dragged should have an obvious grab point that suggests "drag me," and possibly a drop-shadow to indicate that it is floating above the page. Try to think of ways to help the user by visually augmenting on-screen controls with cues. Entire books have been written on UI design and usability (some great ones include Don't Make Me Think by Steve Krug and Designing Visual Interfaces: Communication Oriented Techniques by Kevin Mullet and Darrell Sano), but here are some quick guidelines:
• Make controls visible and intuitive. Use high-contrast, evocative iconography to indicate functionality, that is use a trash can for delete.
• Use images to augment links and actions. There is a positive relationship between using image links and user success for goal-driven navigation.
• Use familiarity to your advantage. Build on users' prior knowledge of popular desktop software such as Microsoft Office, Photoshop, Media Player, Windows Explorer, and so on by using similar iconography and interface paradigms.
• Provide proactive assistance. Use HTML features such as tooltips (alt tags) and rollovers (onmouseover, onmouseout) to provide proactive information about the control and inform the user about its function.
• Utilize subtractive design. Draw attention to the visual cues that matter by reducing the clutter on the screen. Do this by eliminating any visual element that doesn't directly contribute to user communication.
• Use visual cues. Simply style an object so that users can easily determine its function. Good visual cues resemble real-world objects. For example, things that need to be dragged can be styled with a texture that indicates good grip (something bumpy or ridged). Something that can be clicked should have a 3D pushable button resemblance.
• Be consistent. Repeat the use of visual patterns throughout the application wherever possible.
Free databases of user interface patterns are available online, including the good Yahoo Design Pattern Library.
Avoid Gold Plating
Gold plating is adding more to the system than specified in the requirements. Gold plating can also occur in the design phase of a project by adding unnecessary requirements. Building in features above and beyond what the requirements of a software project state can be a lot of fun but can add costs and maintenance work down the road. Every additional feature is a feature that needs to be tested, that can break other parts of the software, and that someone else might need to reverse engineer and understand some day. Goldplating sometimes results from conversations that start: "Wouldn't it be cool if..." Keeping tight control on scope creep; and managing the project carefully helps avoid gold plating.
The counter-argument to this is that tightly controlling scope and being strict about requirements can stifle innovation and take the fun out of developing rich applications. It might be that some of our best features come from moments of inspiration midway through the project. A balance between a focus on requirements and leeway for unplanned innovation could be considered - keeping in mind how it impacts the overall risk of the project.
Plan for Maintenance
Testing needs to happen in any software development project, but with AJAX, developers must perform testing and maintenance at regular intervals to ensure longitudinal success as browsers evolve. Periodically review the target browser list for currency and update to include new versions of popular browsers (including beta versions). Establish repeatable tests and run through them when the browser list changes.
Software risk management
Some global principals of software risk management can handle risk in software. Briefly, here are a few of the things we recommend to generally keep it in check:
- Adopting a holistic view -- Taking the wide-angle approach and looking at not only the immediate technical and budgetary constraints, but also external issues such as opportunity cost (the value of an alternative to the choice you make) and how this project impacts marketing goals. The point is to maintain a common understanding of what is important in a software project.
- Having a common product vision -- Developing a culture of shared ownership between team members and understanding what the project is and what the desired outcomes are.
- Using teamwork -- Bringing together the different strengths of each team member to form a whole that is more than the sum of its parts.
- Maintaining a long-term view -- Keeping the potential future impact of decisions in mind and budgeting for long-term risk management and project management.
- Having open lines of communication -- Encouraging both formal and informal means of team communication.
Adopt a Revenue Model the Works
We discussed earlier how AJAX can create a problem with traditional CPM cost-per-impression revenue model. It can cause a site's traffic (in terms of the number of raw impressions) to be underestimated, and consequently, undervalued.
What we want to achieve with ad-driven monetization is a way to tie the true value of a Web site with the cost of advertising there. The question is what makes ad space valuable? Lots of things do, such as unique traffic, people spending a lot of time on a site, people buying things on a site, having a niche audience that appeals to particular advertisers, and so on. To be fair, a revenue model needs to be simple and measurable, and vendors of advertising need to set their own rates based on the demand for their particular property.
Cost-per-Mille (Cost per Impression) Model Guidelines
The thing to pay attention to in CPM revenue models is to update the advertisement when enough content on the page has changed to warrant a new impression.
Cost-per-Click Model Guidelines
Click-through rates are impacted by the appropriateness of the ad for the Web site. In content-driven, consumer-targeted Web sites, the ad server must show contextual ads based on content. When page content is loaded with AJAX, it might not be read by Adsense or other ad servers. An update to the advertising context might be appropriate.
Cost-per-Visitor Guidelines
If a visitor is defined as a unique person per day, a cost-per-visitor model works irrespective of how many page loads occur or how bad or good the advertising is. A unique visitor can be measured reasonably well by looking at the IP address and browser User Agent and by setting a cookie.
Include Training as Part of the Application
Now that we know what affects user trainability, we can look at what impacts the success of user training. If we want to provide training for software applications to improve user acceptance, how do we do it?
• Organize training around user goals, not product features. For example, it would be better to structure a lesson around the goal of creating an invoice, rather than how to use the invoice tool. This way, users can understand why they should be motivated to pay attention. It also gets to the heart of what they want to learn.
• Find out what users want to use the tool for; provide training for that. Information overload is deadly for the success of training. Trying to cover too much ground can overwhelm your users and get them to turn off, bringing information absorption to a halt.
• Use training to identify flaws in product design. If training is delivered in-person, it can be an opportunity to identify parts of the application that are too hard to use. Although no substitute for early usability testing, this might be the last opportunity to catch problems.
• Support and encourage a user community. Support communication tools that allow users to teach one another. Forums and mailing lists can be useful in this regard.
When we think of training, we might be thinking mistakenly about in-person sessions or even live webinars. These can be worthwhile, and by no means rule them out, but consider low-cost alternatives, too:
• Use context-specific training material. Make material accessible from within the application and at useful interaction points. For example, provide information on how to create a new invoice available from the invoice management screen and so on.
• Show don't tell. Use a screen capture tool such as Adobe Captivate, Camtasia, or iShowU (for the Mac) to provide inexpensive screencast training material that you can deliver through a web page. Many users prefer to learn this way, and there's nothing like having an actual demonstration of a product feature because by definition, it shows a complete goal-story from beginning to end. Some free in-application web tour tools are also available, such as Nitobi Spotlight (http://www.nitobi.com) AmberJack (http://amberjack. org/), although these might not be as effective as a prerecorded demonstration with audio.
Summary
Because of the unstable nature of the JavaScript/CSS/DHTML/XHR paradigm (the fact that the earth keeps shifting beneath our feet with each browser release), we need to employ a Continuous Risk Management process during and after an application is rolled out. This doesn't need to be overly officious and complicated, but it should at least involve unit and regression testing and a holistic look at current browser technology and the underlying mechanisms of AJAX. To put it simply: Does our solution continue to function with current browsers and OSs and will it continue to over the near-term with upcoming releases?
Along with a continuous approach to analyzing risk in a software project must be a willingness to revisit design decisions and also perform rework and maintenance. Both browsers and users can be a moving target, and changes to the JavaScript, CSS, and XHR engines can subtly affect AJAX applications. These are most likely to be the culprit of any long-term maintenance problems. Microsoft, Mozilla, Opera and Apple are all watching the AJAX landscape carefully to help us avoid these as best they can, but a continuous approach to risk management is needed to stay on top of this and ensure a long and healthy lifespan for our Web applications.
Resources
Search Engine Optimization
WebProNews
SearchEngineWatch
Google SEO Recommendations
Google Guidelines for Site Design
Google Sitemaps
Statistics
The Counter Global Web Usage Statistics
Roadmaps
Firefox 3 Roadmap
ACID2 Rendering Test
CSS 3.0 Roadmap
Screen Capture Tools
Adobe Captivate
Camtasia
iShowU
This article is excerpted from the book Enterprise AJAX: Strategies for Building High Performance Web Applications by David Johnson, Alexei White and Andre Charland, published by Prentice Hall Professional. Copyright 2008 Dave Johnson, Alexei White, Andre Charland.