For the complete series, check out Adaptive User Experiences in IBM XPages Applications

I am always fascinated by the advances in user interface and user experience made by game developers.

I was a Nintendo Generation kid, with Super Mario Brothers, Metroid, Contra, Zelda, and Super Mario Kart stealing away the late night hours during sleepovers with my cousins. The games were relatively simple: you really only had two buttons to hit (A+B) with a D-pad. Some games however, most of them the quest-style games, were almost impossible without frequent reference to the game booklet (which was often lost) or Nintendo Power. Aside from story-driven gotchas, some games were impossible for novice gamers due to their non-documented demands or near-impossible gameplay.

Can't tell you how many times I died a watery death playing Top Gun. What kind of sicko starts you out in the air only to tell you once you've completed Level 1 that you gotta land or restart the entire level again?!

Speed Up. Slow Down. Up. Down. Up. Speed Up. Down.

*watery death non-landing landing*

[Me:] Screw this, where's Mario Kart... I'm Chode!

(My cousins, who will never read this, would laugh...)

Today's gamers do not have to fall victim of such painful, soul-tearing 8-bit demoralizing rejection... and not, as you may think, because of the countless walkthroughs and gameplay tutorials available online.

From Game Design: Theory and Practice (2nd Edition) (Wordware Game Developer's Library) [emphasis added]:

... even with the most realistic game, players will need time to learn how to play your game, and this learning experience is often a crucial time in a player's overall experience. The first few minutes players spend with your game will often make the difference between whether they want to continue playing it or not. Whenever players tell friends about your game, they will often remember those first few minutes and say, "Well, it was a little weird to get used to" or, preferably, "It was great. I jumped right into the game and found all this interesting stuff."

In the past, many computer games relied on manual to teach players how to play them. With some titles players literally had almost no chance of success in the game without first reading a large chunk of the manual. Today many games try to get away from this reliance on players' reading ability, realizing that often the last thing players want to do when they have just purchased a new game is to sit down and read an extensive instruction manual. Players definitely have a strong desire to just pick up the controller and start playing the game.

Pick up any decent console game today, and you'll find that Level 1 is specifically designed to walk you through the gameplay while introducing you to the story. In Halo: Reach, the entire first level -- which is very action packed -- walks you through step-by-step how to navigate, use your weapons, ride vehicles, communicate with your team... and before you know it, you're actually playing the game using a hell of a lot more buttons than A+B!

The idea is to capture both the hard core gamer crowd as well as the all-important casual gamer.

... so what does this have to do with application development? Everything!

How many applications have you deployed that required some form of training? Sure, your application might be amazingly feature-rich, but if you have to pull people out of their jobs and into a classroom setting to learn how to fill out a form for toner cartridges or a new laptop after you accidentally dropped yours in the tub while you were taking a bath [yeah, this happened years ago at a company I worked for to a VIP...], then you might need to rethink not only your user interface, but also your overall user experience.

IT make for the worst QA people, because we think like IT. We actually expect that "some of these contents are not secure" error thrown by Internet Explorer, and we do not consider it an interruption in the user experience. We also know -- because it's our job -- that a "new BlackBerry" request would fall under the Mobile tab instead of the Computer tab... and we'd think to look for the mobile aircards under the Mobile tab as well.

What I'm getting at is that we're the hard core gamer. Our users, or at least the vast majority of our users, are nothing more than casual gamers.

We can take a cue from game developers and the idea of casual-to-hard core-evolving gameplay to create an adaptive learning user experience and user interface that matches the individual user's skills and understanding of the application.

This adaptive learning UI/UX will walk the user thru the use of the application and award them experience points upon reaching pre-defined milestones.

As the user gains XP, you simply disable the adaptive learning user experience and load the hard core (or power user) experience.

This is, quite frankly, not a new concept. Most consumer-facing technologies will give you a wizard-driven UI/UX to take you through your initial transactions, but once you've gained a history of usage you're pretty much given the power user UI/UX.

What I think is the new slant on this concept is simply this: XP drainage. Simply put, you need to lose XP over time.

So let's say you get 5 XP for every submitted request in your application. The adaptive learning user experience threshold is 20. Your XP drainage is 10 per month.

What this means is that frequent users of your application will have enough XP to never see the adaptive learning user experience guide again once they've passed their initial threshold... but if a user comes back to your application to complete a request 6 months after their last submission, they should see the adaptive learning user experience guide.

Let's take a look at a simple diagram that should help illustrate this idea:

This concept relies on the XP Store. This NotesDatabase will house User Profiles and Application-specific Milestones/achievements. A backend process, the XP Burn, will purge XP (as configured) for the specific application. And finally, the XP Store will be accessible via a pre-defined API.

Each application that uses the XP Store via the API can access the user profile information as well as the application-specific milestones and settings to determine both experience points awarding and, of course, which user experience to render.

In the next part of this series, I will discuss the architecture of the XP Store. We'll review the App-specific milestones (and other app-specific settings), we'll look at the user profile facility, and we'll establish the XP Burn process as well as the XP API.