Tuesday, March 08, 2005

XForms Myths rebutted

I’m not an XForms expert, I do not have specific interests in XForms, but I have to admit that I like certain aspects of XForms. When you’re into the XML-family of standards, it’s just a very elegant way to create form-based applications. Ian Hickson, the driving force behind WhatWG’s Web Forms 2.0, is clearly annoyed by the marketing speak of XForms proponents. I’ve added some serious and some not-so-serious comments on the arguments of Hixie, so please compare this with his article.

XForms is declarative
XForms is more declarative than HTML + JavaScript, but I think the main benefit is that 80% of the commonly used functionality is available as a tag, thus reducing the learning curve (although XForms is not so easy to learn because it introduces several more advanced concepts).

Scripting is bad for accessibility
Two competing standards (Web Forms 2.0 and XForms) is bad for accessibility, because screen readers will need to learn about both standards, instead of just one.

Script is harder to maintain than XPath expressions
I’m not an expert in this, but it seems that there are more degrees of freedom for JavaScript programs than for XPath expressions. More freedom means more power to do messy things.

HTML mixes presentation and content - XForms doesn't
Somewhat true, but I do like the client-side data instance of XForms. Some content should just be inserted server-side by a content management system, and there is no need to keep it separate on the client.

XForms is better than HTML because it is media-independent
Indeed, crap. What does the independence of the media have to do with XForms or HTML?

HTML mainly specifies how the control should look, while XForms specifies what the control should do
Yes, I think that’s a myth. From what I remember, XForms leaves it up to the XForms player to render the user interface. Just like the web browser renders the form controls.

HTML has limitations, so it had to be replaced with XForms
Yes, that’s something I can’t agree with. It’s better to extend HTML.

HTML requires authors to use hacks; XForms doesn't because is cleanly designed
Somewhat true: HTML was not designed to have client-side applications, but XForms was, so it’s easier to make a good implementation.

JavaScript switched on?

Jeremy Keith argues that an Ajax application should also work if JavaScript is switched off in the browser. I think this approach will not unlock the true value of Ajax applications. In the more advanced Ajax applications business logic will partly move to the client: this is similar to how client-server applications compare to mainframe applications. For simple form validation, search queries and the like it does make sense to have a non-JavaScript version. For applications where not every mouse-click is communicated to the server and client-side logic is executed, it might be very difficult to build a non-JavaScript equivalent. I believe the browser is capable of more than just displaying static pages with a little bit of interaction: the browser is a complete software development platform. There are even people who have created a complete execution stack, with its own command prompt.

Monday, March 07, 2005

New interaction patterns

In my previous post I mentioned I was looking for usability best practices for Single Page Interfaces. This was on response to an article by Jesse James Garrett that explained the technical concepts quite well, but not the usability aspects. His colleague Peter Merholz wrote a nice article about Google Maps in which he identified the core issue, I think: "how do you provide people with cues, so they know what to do, but enable new, more powerful means?"

This is probably one of the main questions that needs to be answered before you create a successful Singe Page Interface application. There are lots of new possibilities, but how does the user know about it? I’m just trying to think of a list of unexpected behaviors, but please add to it:

  • Drag-and-drop
  • Right-click and double-click
  • Keyboard shortcuts
  • Modal windows
  • Using decks instead of pages, enabling a more parallel workflow
  • Changes in one part of the screen trigger changes in another part of the screen

So which ideas are useful to explain people about these new features? Again, just some ideas:

  • A correct mouse pointer can give a hint that you can drag (which Google Maps is not doing, why not?)
  • A non-modal window can provide help (e.g. click F1 during a PowerPoint presentation to see all useful keyboard shortcuts: this is a modal window unfortunately)
  • Animations and effects: a good example is the cloud animation when you drag items out of the shopping cart in the Panic shop, or the Yellow Fade technique to highlight which area of the screen has changed.
  • Although a parallel workflow might offer many benefits, a step-wise input wizard might help first-time users
  • And, last but not least, it might be good to stick to well-known keyboard shortcuts, such as + and – for zoom in and zoom out (as Google Maps is doing)

As Jesse James Garrett mentioned: "[we can] begin to imagine a wider, richer range of possibilities".

Sunday, March 06, 2005

Single Page Interfaces

After Jesse James Garret’s article about Ajax there have been several interesting posts.

Cameron Adams argues that it’s acceptable for some sites to exclude visitors that have JavaScript switched off, especially for web applications (as opposed to content-rich sites). I agree: there are some standards-enthusiasts who promote unobtrusive JavaScript, but they usually come from a content-publishing background.

Tantek Celik proposes a new name for Ajax, to get rid of associations with soap or football clubs. He proposes Cadex, short for CSS Asynchronous DOM Ecmascript XML/XHTML. What I don’t like about both Ajax (Asynchronous JavaScript + XML) and Cadex is that they focus on technology instead of usability. What I see as the main different between Ajax and old web interface is that it’s actually a single-page interface, instead of a multi-page interface. Maybe the name it’s somewhat simplistic, but I would suggest using Single-Page Interface instead of Ajax.

To continue on the usability angle: Jason Fried explains that Ajax in itself does not improve the user experience: it enables it. The example of the Yellow Fade technique is one of the first examples I’ve seen with clear usability benefits. I’m myself working on a website with a Single-Page Interface, and it’s easy to come up with all kinds of spectacular effects, but difficult to find those effects that really enhance usability. A peak preview of what our technology is capable of can be seen in a shop and a portal demo, and the result of my project can be seen in a couple of months at Backbase.com. In the mean time I’ll be scouring the web for more usability best practices for single page interfaces. And if you know any great usability examples, please let me know.