Chatting with Bill Moggridge – Part Two – What Interaction Designers can learn from games

Microphone Man

Here’s the second part of my chat with Bill Moggridge.

You might remember that I was lucky enough to have the chance to talk with him about his new book, Designing Interactions and that he was happy for me to record the chat and share it with you. Here’s Part One in case you missed it! (update: you can get part three here too!)

As you can see from my microphone stand pictured above, I am a very professional correspondent and go to any length to ensure good sound quality.

(Clearly this is a blatant lie… I’m working on it!)

Anyway – in this second part of the chat we spend some time talking about designing games and what interactions can learn from games design. Interesting stuff.

(Duration: 5.49)

Chatting with Bill Moggridge – Part One


In December last year I was lucky enough to catch up with Bill Moggridge to chat about his new book, Designing Interactions.

My mission was to write a piece for Usability News (mission accomplished).

I recorded our chat and Bill was happy for me to share it with you all, so – apologies for the not so great sound quality – I hope you enjoy it!

In part one Bill talks about the process he went through to design/write the book (yes, there was a prototype involved!) as well as some thoughts on what factors are common where good interaction design is created.

(Duration: 10.02)

update: also check out Part Two (5.49) and Part Three (10.28)

XHTML2 and XForms (an unusual kind of post for a blog like this)

Steven Pemberton

I’m going to go out on a limb now and talk about technical stuff that I don’t really know heaps about, but I think is really interesting for Information Architects and Interaction Designers. I hope that people of a more technical bent will chip in and correct any errors I make and fill in any gaps I’ve missed!

This post was inspired by what I think was the most intriguing presentation at the recent EuroIA conference in Berlin. This presentation was given by Steven Pemberton.

Now, Steven started his talk by breaking one of Kathy Sierra’s rules of presentations (don’t spend time telling people who you are and what you’ve done), but thank goodness he did, because I had no idea who he was or the amazing history that he has in shaping the web as we know it today.

Steven was sharing with a room full of Information Architects the joys of Xforms and XHTML2. A challenging task, given the range of backgrounds and expertise that Information Architects naturally have. Now… I know there were a few IAs with glazed over eyes, but for me… Steven’s talk held exciting prospects.

Let’s start with my take on Xforms.

Xform is short for XML Powered Web Form. The W3C says:

“XForms” is W3C’s name for a specification of Web forms that can be used with a wide variety of platforms including desktop computers, hand helds, information appliances, and even paper.

When talking about Xforms, advocates use great terms such as: open, interoperable, accessible, interoperable. The other thing they talk about is that you don’t need JavaScript and that it takes a fraction of the time to develop as compared with alternative technical approaches. We love the sound of this so far.

An XForms fan on the W3C website says that XForms are:

truly interactive, bi-directional Web of Applications, boosting structured interchange of information world-wide. This infrastructure standard significantly lowers development costs and total cost of ownership across all vertical, service and application-oriented web products – from e-commerce to e-goverment, e-finance to personal web communication.

So, in laymans terms (by my interpretation) what does this mean?

It means that we can design smart and more usable forms without having to use JavaScript (which we often can’t) and without increasing development time.

So, for example, address forms are only shown if the user indicates that they want or need to complete address details. If a form calls for partner/spouse information, these are only shown once a user indicates that they have a spouse or partner. So users only see the fields that they indicate they need to see. All users don’t have to see all forms.

Simpler forms. Less errors. Faster completion. All good.

How does this work technically? Well… unfortunately you’re at the wrong blog to work that out, but a quick look at Wikipedia (of course) shows you the downside that Steven didn’t really dwell on so much in his talk….

At the time of this writing, no widely used web browser supports XForms natively.

I don’t know much about Firefox 2.0 or IE 7.0, but from a quick review, it seems they’re into XForms. More’s the pity.

So why talk about Xforms?

Well… because they seem to me to be a great opportunity waiting to happen. And because if we don’t start talking about them and why we want/need them, then why will the browser manufacturers ever bother to support them?

Same, unfortunately, goes for XHTML2.

Steven’s talk got me all excited about the possibilities of XHTML2. It has a couple of key objectives including:

  • Less Presentation, More Structure – we all know that getting presentation OUT of HTML is a good idea
  • More Usability – for people who code, that is. Making HTML easier to write. That means making GOOD HTML easier to write. That’s a good idea.
  • More Accessibility – now, lots of people think that accessibility is boring or ‘out of scope for their target audience’ (that’s a whole other blog post). When Steven talks about accessibility he talks about ‘designing for our future selves’, when we all will have a shaky mouse hand and dodgy eyesight. Accessibility is boring whilst you’re young and agile, but you may live to regret thinking it too hard in the long term.
  • Better Internationalisation. Well… actually Steven says ‘internationalization’. I rest my case. (As an Australian this is a sore point, and there are sooooo many much worse off than I).
  • More device independence. Anyone who’s developed for multiple platforms would love this to be true… however, see above re: browser support, and then consider the nightmare that is mobile phones… even I think this may be optimistic. A great objective nonetheless.
  • Better Semantics. Now, this is the bit that I think is REALLY sexy :)

What does Better Semantics mean? Well, from what I understand it means that when I write ‘tomorrow’, it can actually mean 28 October 2006 without me spelling it out, and in a way that can be added to a calendar, or linked to other people’s ‘tomorrow’s’ that mean the same date, without me having to Google it and then link to ever single one. When I refer to a person, either by name or by a term like ‘the President of the United States’ I don’t need to explicitly explain who I’m talking about and then provide a link… but that potentially, all that additional information, or other information that I’ve already gathered, is available through that simple statement.

Now… even as I write that, I wonder how it would work. At this stage, I’m not inclined to trawl through the details, but the potential seems obvious.

As does the challenge for Information Architects. If we thought tags were problematic… then what kind of a challenge is this! How do we embrace the possibilities of a semantic version of HTML without unnecessarily constricting it OR compromising it through freedom? And, when and by whom are these semantic decisions made? By an IA, a designer or a coder?

Now, it’s completely possibly that I’ve entirely misintepreted both XForms and XHTML2. Afterall, you don’t come to this blog for the down and dirty on all things technical. But, based on what I heard from Steven, there are some interesting possibilities for the future that could be embraced sooner rather than later. And, no, this is nothing new. Afterall, Jeffrey Veen was lamenting XHTML2 and it’s lack of backward compatibility in 2003!

But I don’t live under a rock. And these things interest and potentially affect me. And I’ve not really heard much of them before.

I wonder if you’ve heard of/ been thinking of/ have an opinion on Xforms or XHTML2?

(And I very nervously hit Publish on a such-technically minded blog post…  If I’m completely off base… I blame Steven. Or Berlin!)

Image Credit: Michiel Hildebrand @ Flickr