I've mentioned Robert Hoekman, Jr.'s excellent book "Designing the Obvious" a number of times in previous posts. Hoekman devotes an entire chapter ("Turn Beginners Into Intermediates, Immediately") to the subject of getting users up to speed with applications as quickly and unobtrusively as possible. He argues that most of the users who stick around long enogh to use your application don't ever get beyond being "intermediate"-level users, and that:
So how do we do this? How do we know someone is a real beginner, an intermediate user, or an expert user (for those rare people who really want to take the time to learn all the nooks and crannies of the application)? How do we then track they they are gaining experience with the application so we no longer treat them as beginners but as intermediate users (or advanced users, as appropriate)?
I'm working on a simple API to help provide the appropriate level of contextual guidance to users of an application. The focus here is really on the backend tracking and determination of a user's experience level with an application. The contextual guidance API would be called before a page-view is rendered and the view itself would determine what to display based on the "experience level" of the user that has been passed along to it. With this system, we can hopefully begin to provide users instructive text (aka help) in a way that's useful and appropriate to their experience with the application, and that adapts over time to get out of their way or change to show them new tools at their disposal.
The core function would look something like this:
The arguments would be:
- userID (numeric): The PKEY userID of the user.
- applicationName (string): The string name of the application, so that multiple applications could be tracked within the same table, if appropriate. This could also be an applicationID value, if you have an applications table to work with which defined each application and gave it an ID.
- Optional: applicationSection (string): The string value of the section of the application in which the user is working. This is useful in larger applications, where a user may spend most of their time in sections A and B but not in C. The user would need more help in section C of the application, and less in A and B. You need a way to be able to discern this, and this is the proposed way.
The function would return a string containing one of three values:
You could return a numeric value that somehow translated in to a range (eg; 1-10 = super noob, 10-20 = inexperienced, 20-30 = lower intermediate, and so on), but that level of granularity is probably more trouble than its worth — especially in the view where you'd have to write a whole lot of conditional logic to handle the appropriate display for each of those value ranges.
So those are the basics of the method. In the next post on this topic, I'll talk about internal logic and the fact that we can't reduce experience to simple numbers. We have to take in to account the fallibility of memory in our business logic.
If you have any questions or comments, I'd love to hear them!