UXD - User eXperience Design

Ajax and Design

Some random thoughts on Ajax and design.

Don’t design your page around Ajax. Armed with the same user-centric methodology you’re (hopefully) using today, you’ll first design the page and then see where Ajax can be added to enhance the interaction behavior. Start with the wireframes, which detail the page structure and content layout. Detail the wireframes by adding in the page and/or element behavior as you’ve always done. From there, evaluate the design and determine where Ajax can be used on the page to enhance the user experience.

One thing to keep in mind is that Ajax is best leveraged as an enhancement that gracefully degrades whenever possible. First defining the behavior of a page and then adding in the enhancement is one way to ensure it'll work in user agents that don’t accept client-side scripting, such as some mobile devices.

So why use it? Well, one nice thing about Ajax is that it gives the illusion of speed. It allows the browser to display information onscreen while continuing to query and receive data in the background. The user doesn’t have to wait for a page refresh before seeing new information. Because the browser didn’t have to wait for the entire results set before rendering data, the users perceives the site as being quick.

This illusion of speed, however, can backfire by confusing the user since they might not realize anything actually happened. Here’s where some basic usability needs to be tied into Ajax. Let the user know when something changes on the screen. Display a success message, highlight the new information, change from form elements to text, etc. What you do, of course, depends on the widget involved, page design, etc. My point is that you need to visibly indicate to the user that their action was received and acted upon.

Rethinking the Help System in an Ajax World

In desktop applications and the new genre of Ajax applications it's possible to provide contextual information to the user. This is typically done one of two ways. Either real estate is devoted up front to the display of this information, or a pop-up (or slide-in) of some kind emerges.

The ability to contextualize information physically suggests the necessity to rethink the creation of the help system. Not only must we consider what the information must be, but also when and where it will likely be accessed. The help system truly must be a system, not just an encyclopedia of the features of the tool (that is still a good thing to have, nonetheless).

The down side of a highly contextual help system is cost. Someone has to design it, not just write it (you have to do that too). There may be a good middle ground, though. Consider providing specific help access points contextually in your application for the things users are most likely to get stuck on. Provide opportunities for assistance, advice or suggestions in context where the benefits are significant to the task at hand. Let the user easily get the information, and get rid of it when their needs have been met. This approach can deliver value to your users, while keeping the creation and maintenance costs reasonable.

Technorati : ajax, design, help system, usability

Dietrich Kappe at CHI2, March 31

It was a dark and stormy night on March 31, 2006, when Dietrich Kappe held the crowd spellbound with an exposition of Component GUI’s & Ajax. at the monthly meeting of CHI2.

The title  was “Back to the Future”. Dietrich mapped a history of paradigms - in the early nineties, the Browser was like a mars lander - you sent it out, it wandered around on the users desktop & sent back some cryptic messages which senior technologists claimed they had intended and understood. The context was that of pure unmitigated text, and even now, if you browse with a textual browser like lynx, most pages still work just fine, really.

Sites were based in a philosophy often referred to as CRUD: Create, Read, Update, Display. And like all new technologies - recall Gutenberg designing movable type to imitate blackletter script - they tended to imitate existing technologies. In this case the models ranged from Phd theses to early CD-Rom notions of multimedia.

In the last couple of years these models have evolved from document centric content management systems to an interactive single page interface. This is a dramatic shift in developers terms from reading an essentially static table to building a complex model and interacting with it. No longer a low res fanzine, the paradigm is that of an online application.

[This certainly maps to my own experience. The interesting problems in interactive design used to be large content sites; application design was seen as a very separate practice. Increasingly, applications are being designed to be delivered through browsers, which encourages convergence and invention in both areas.]

Dietrich went on to note a short history of User Interface:
_ Command line: mediated usage
_ GUI/WIMP: applications & early adopters
_ Web: sort of dumb reports
_ Rich clients: influenced by GUI/Wimp. The philosophical habits of the development community are pervasive; as people reuse GUI components, people also reuse GUI paradigms, which become a jumping off point for Rich Interaction Conventions. Jakob Neilson would claim this as truth.

Dietrich closed his remarks emphasizing the shift from a browser environment to display technology. The scenario he outlined reminded me of Oracles early notions of distributed computing, with the business rules on the server & the browser referencing them. From a development standpoint, it means a centralized maintenance location and a component UI of reusable widgets. Back to the future it is then, as this does have the ring of object oriented programming.

Full disclosure: As you may have guessed by the context of this review, I work with Dietrich at Pathfinder Associates. And often agree with him.

Leveraging the User’s Experience: Insights on Designing for AJAX

When the first GUIs were created they leveraged perhaps the most ubiquitous items people experienced in an office environment: a desktop with folders and documents.

As we move into the world of AJAX and rich interactions, the principle of leveraging experience can be extended not just to objects but how we interact with those objects. Google maps provide a familiar example. Using rich interactions, we are able to interact with the map almost as if it were a physical object (without having to figure out how to fold it – a benefit to be sure). Another form of interaction being seen more and more is the concept of a sliding drawer. Objects we may need are closely available, but are not consuming precious screen real estate until needed.

As rich interaction and AJAX technologies mature, they present endless possibilities for the designer to create something that is innovative through its familiarity.

An example of Ajax providing a good user experience

A little while back I commented on the need for designers to use new technologies not for their own sake, but as a means to an end (on the web, that end being a good user experience).  Here's a perfect example of what I meant. 
Duo consulting has done some really nice work for the Chicago Parks District.  The web site takes advantage of 'web 2.0' features to maximize the user experience, and as a result, a highly successful site that among other things, greatly increased online registration for park district classes, and decreased cart abandonment by 80%.
Here's the Ajax enabled online registration app. that they built...
And here's the original post on the Duo Consulting blog.

Ajax and user experience

The increasing ubiquity of Ajax is becoming somewhat of a vicious cycle, as more demand creates more hype which creates even more demand.  As such, it presents interesting challenges for designers.  How do designers weight the pressure to 'Ajaxify', with the needs of the user. 

While Ajax does represent the beginnings of a new way of using the web, Ajax doesn't make sense all the time.  Yet it has become such a hot topic that design and development firms are experiencing more and more demand for anything 'Ajax'.  Frequently, those clamoring for the technology don't really know what it is, nor what it can be usefull for, but they know what they've heard...that it's the hot new thing, and there web site or web app is just not worth the browser its rendered on unless its got Ajax. 

The results can be frustrating to see.  For instance, have you ever come across an instance of a drag and drop module where a simple mouse click is so much easier and more effective?  Yeah it's cool...because, um...well, I'm dragging and dropping something...on a web site...and it's Ajax! 

Designers need to curb clients enthusiasm, so to speak, and make them understand that having the best web site doesn't mean using the latest and flashiest technologies.  It means applying a strong methodology, good user research, and an understanding of heuristic principles to build something that provides users with a useful and satisfying experience.

Usability Roundup - The Back Button

An oldie but a goodie -- the back button. The bain of designers, developers and usability experts everywhere. Some love it, some hate it. Here is a roundup of some of the best resources on this topic.

• Web Navigation - a treasure trove of web usability research by Professor Andy Cockburn of the University of Canterbury, Christchurch, NZ. If you are after some hard data rather than speculation, this is a very good place to start.
• Navigation Blindness - Why users ignore navigation and what to do about it.
• Flash Back Button Fix - Robert Penner came up with this back button/bookmark fix for flash a while back.
• Attack of the Back Button - Some words of warning from John Rhodes. While some of the techniques on this page may be a little worn, the sentiments are not.
• dojo.io.bind() Intro - A discussion of the usability issues around Ajax/XHR breaking the back button and a possible solution to the problem within the Dojo toolkit.
• Fixing the back button that AJAX broke - An excellent analysis of the problems of the back button, and the related problem of bookmarks, and a lengthy rumination on some possible solutions.
• Flash Usability - The flash folks have been wrestling with the back button for a bit longer than the Ajax folks. This is a long article with just a little bit on the back button, but some of their suggestions are quite useful.
• Breadcrumb Navigation - With breadcrumbs, users used the back button less frequently, but overall task efficiency was no better.
• Exploring User Mental Models of Breadcrumbs in Web Navigation - Another study on bread crumbs as a solution to back button issues.
• SmartBack: Supporting Users in Back Navigation - excellent overview of research in navigation and some tested ideas on how to inprove back navigation. Could be very interesting for those implementing their own "undo" functions in Ajax.
• Fixing the Back Button and Enabling Bookmarking for AJAX Apps - Mike Stenhouse's crack at fixing this problem.

Visualizing Rich Interactions in Paper Prototypes

Wireframes and paper prototypes work well in documenting the standard page metaphor of the Web, as the functionality of each screen can be captured in a single wireframe. Rich interactions, though, pose the challenge of expressing a series of states that may occur on a single screen.

As technologies like AJAX gain greater popularity, designers face the challenge of exploring and developing new and innovative visual vocabularies and flexible tools for capturing the microflows of rich interactivity.

At Pathfinder, we are drawing inspiration from the discipline of storyboarding, which is, of course, closely related to wireframing. Storyboards express ideas in a sequence of "key frames," showing only the minimum number of frames to convey the idea. The richness of storyboards comes not from just the individual pictures, but from the change from picture to picture. It's possible, then, to embed a miniature storyboard into a wireframe, thus illustrating the quality of the rich interaction.

A second technique is to create a visual taskflow representation to the system. In this format, all screens are miniaturized to capture both the linear and non-linear flows within individual screens and from screen to screen.

Our fellow practitioners are tackling this challenge as well. Bill Scott considers several strategies for creating interactive wireframes, including the PowerPoint clickthroughs, the development of quick and easy RIA toolkits, and standardized notations to indicate interaction effects in traditional, static wireframes. His personal technique involves the creation of storyboards in Visio, which he then animates. The strategy is detailed in his blog entry, "Interactive Wireframes: Documenting RIAs."