Direct Manipulation Interfaces, Document-Centric Applications and 7 More Reasons to Use AJAX

Dietrich Kappe, Tuesday, May 2, 2006 @ 9:00 am

Alex Bosworth over at Source Labs has a blog entry up entitled 10 Places You Must Use Ajax. I count six places you should use them and six that you shouldn't. His arithmetic aside, he makes some good points about where  AJAX can be  employed, mostly from a general usability standpoint. For instance,

• Deep hierarchical tree navigation.

  First of all, applications with deep hierarchical tree navigation
  are generally a nightmare. Simple flat topologies and search/tagging
  works very well in most circumstances. But if an application really
  calls for it, use Javascript to manage the topology ui, and Ajax to
  lessen the burden on the server by lazy loading deep hierarchy data.
  For example: it's way too time consuming to read discussion threads by
  clicking through and loading completely new pages to see a one line
  response.

In point of fact, these types of uses are already commonplace. I'd add one big category that he missed, namely the Direct Manipulation Interface. From the wikipedia definition:

Direct manipulation is a human-computer interaction style that was defined by Ben Shneiderman
and which involves continuous representation of objects of interest,
and rapid, reversible, incremental actions and feedback. The intention
is to allow a user to directly manipulate objects presented to them,
using actions that correspond at least loosely to the physical world.
Having real-world metaphors for objects and actions can make it easier
for a user to learn and use an interface (some might say that the
interface is more natural or intuitive), and rapid, incremental
feedback allows a user to make fewer errors and complete tasks in less
time, because they can see the results of an action before completing
the action. An example of direct-manipulation is resizing a graphical
shape, such as a rectangle, by dragging its corners or edges with a
mouse.

Google Maps is a good example of this style as realized in AJAX, as are the drag-and-drop aspects of many of the new AJAX enable mail and calendaring applications. The places to look for good uses of this style are existing desktop applications. In fact, beyond direct manipulation, there are a number of other techniques worth using as we move from the simple data report applications that Alex envisions and the more document centric apps of the web future. It is the user's experience with these desktop applications that will make their introduction in the web effective -- in short, the user already knows how things should work.

• Use visual metaphors whenever appropriate

Alex argues that "a slider to pick the price to the cent is just overkill." I agree, but that's not an argument not to use a color picker or a slider to manipulate contrast settings in an image within a CMS.

• Spacial data manipulation

We've already mentioned Google Maps as one example of this. Management and monitoring of nodes and edges, such as UML class diagrams, Physical computer networks, BPM diagrams, are also a staple of desktop apps that are now within reach of the webapp with AJAX.

• Modal dialogs for presentation of finite tasks

Ironically, it is the use of modal dialogs within the AJAX app that makes the webapp less modal as a whole. It removes the need for separate data entry and support screens -- two distinct "modes" of the program. As it stands now you have an unpleasant choice, as popping up non-modal browser windows to perform modal tasks is problematic.

• Modeless dialogs for presentation of ongoing tasks

Displaying controls and results in modeless dialogs allows users to work their way rather than in a tightly constrained flow dictated by the application designer. Searching and search results, detail information, task lists,  tool bars,  contextual help -- all optional or peripheral information that can benefit from modeless dialogs.

• Visual Feedback for long-running tasks

That's right, long running tasks. It was awkward tracking ongoing processing before AJAX. Now that we can handle them, we should use thing like progress bars to give users an idea of what exactly is going on or dynamic tooltips to allow users to investigate status on demand.

• Application level undo instead of the Back button

When manipulating documents instead of doing CRUD, the back button can be pressed into service as an undo, but it takes some work. Better to use application level undo than the ham handed back button. Do you search the interface of your word processor or the documents on the hard disk? Do you email a bookmark to a particular UI state or the document you've produced?

• Contextual controls

Don't display all the controls -- buttons, sliders, tree controls -- at once. Display only high level controls and display new controls as you display new context. This is especially important when we are working on documents rather than reports. For example, AJAX based word processors should not display controls for editing headers and footers at the same time as displaying the controls for editing the main body.

This is just a sampling of what it a rich body of knowledge from the world of desktop WIMP GUI's can yield to the astute AJAX developer.

Alex seems to disagree with the use of some of the above applications because they are either too bandwidth intensive or because they lead to poor application design. Actually, it seems he's just plain opposed to the use of AJAX for anything beyond data updates. I agree that if write the new AJAX apps the way we've designed the layered form-and-reports page oriented applications of the past, adding any sort of sophisticated UI styles will lead to some major spaghetti code. You need to think outside the box for this sort of application, otherwise you as a developer will spend more time writing the same old forms and reports apps with a little bit of AJAX sugar, while other programmers are cranking out Rich Interaction Applications in a fraction of the time.

That's why I recommend looking at the various component based GUI's for AJAX, either the client side ones like Tibco GI or OpenLaszlo (for DHTML) or the server side ones like Echo2.

Related posts:

1. MXGraph – Direct Manipulation Graph Component
2. AJAX and the Zeigarnik Effect
3. Epiware – Ajax Enabled Document Management
4. 10 Business Reasons to Use AJAX
5. RIA and AJAX: Another Perspective

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment