When Do I Get The Payout?: Coding To User Experience.

You walk into a casino and put some money in the Slot Machine.  You pull the handle.  Odds are, you aren’t going to get anything the first time.  Probably not the second, or the third.  But Casinos know that there is a window of opportunity for them: if you don’t see something line up in front of you, if you don’t hear the ring of coins or chips dropping into the till within a certain span of time, you are going to walk away.  They set the odds, therefore, such that within that window of opportunity you probably will get a payout of some amount.

Probably not the Jackpot.

More than likely, not even as much as you have put in.

Still, you have to get some measure of satisfaction and gratification from it, or eventually even the Gambling Addicts are going to walk away–or at least try a different game.  The level of payout required is determined, not via any intellectual mathematics, but through a sort of emotional calculus that varies person-to-person.

The same theory applies to developing technology for the End-User: if the User starts using your tech and doesn’t get some sense of satisfaction from it fairly quickly, they will decide it is not worth their valuable time.  They will view it as “broken”, and they will describe it as such to others.  Given that word-of-mouth is still the most potent form of advertising, this can make or break you.

Microsoft learned this the hard way with Windows Vista.  They thought that people not only would not, but could not go back to XP.  They did, in droves.  Apple recognized this when they released Snow Leopard: while Snow Leopard contains some important stuff for the future of Macs, it’s all under the hood.  The average user isn’t going to see much of a “payout”, so they priced it really low: $29.  To bring things in line with the topic of this blog, Linden Lab recognizes this basic fact about how people choose and adopt technology: they put a lot of effort (even if some of us don’t see it happening! Lack of payout, there) into resolving questions like these about Resident’s early experiences within Second Life.

Now add the challenges of Assistive Technology.  Most Software Development (sadly) assumes the hypothetical “Normal Person” as the audience.  This person doesn’t really exist, of course.  We are too diverse.  Perhaps we need to reconsider that whole concept, but that is a post for another time, and probably another blog.

My audience is almost never going to fit the “Normal Person” characteristics.  The End-User may not use their eyes.  They may not use–or even have!–hands.  They may have a high level of intelligence yet have difficulty communicating with me effectively due to dysfunction in one part of their brain.  They may have a disability “just like” someone else’s, and yet live their lives and deal with the world in a totally different way.  It is my job to create technology that will give them a “payout” in their first hour using it.  Sometimes, I even succeed.

I am NOT complaining!  I have been exposed to life in a call center for an ISP.  I have dealt with “Normal Person”, and I don’t ever want to go back.  I love these challenges!

How do I do it?  Sometimes, I have to just sit down with the person and talk about what their needs and expectations are.  This part of the process can sometimes take longer than the actual “programming”–nor is that a bad thing!  As I see it, spending an hour talking to a client and then 10 minutes writing what they need is a better use of my time than 10 minutes talking to them and an hour fixing things I didn’t get right on the first go.

Some things, I build in based on experience.  For instance, I have had scripters question why I have the Guide working on three channels: /2, /3, and /4.  It’s a matter of User Experience.  First, the people who use it are typically taught Orientation, Mobility, and Other Skills.  So, I divided it up like that.  /2 is Orientation.  who, what, where. There are refinements of each, but the basic stuff is found in those three commands.  Once you have mastered those? PAYOUT!  You have mastered a set of essential skills needed to navigate SL.  Then you can move on to /3, which involves Mobility (commands to move your avatar from point to point.)  After that, you can worry about stuff like clothes and profiles and other miscellany.

I give them two Payouts that can be reached with some effort, but significant reward.  Then I worry about the little stuff.

My first Transcriber Tool was a failure.  The scripts compiled, and they do wonderful things!  Nobody used them! The people doing transcription from VoiceChat to Text weren’t interested, and the consumers of their product didn’t seem to want it.  I made it too complicated.  I required too many actions from the Transcriptionist and from the Receiver of Transcription.  So, I tossed it out and went back to the KISS rule.

First, the person who wants/needs the service need do nothing but show up, just like Hearing folks and those who have no technical issues with Voice Chat do.   Second, the Transcriptionist (who has other things to do!) has to go through, at most, four steps to get their product to the clients:

1. Attach the Tool to their HUD
2. Set the name of the Tool to either “Voice” or the name of the speaker with a built-in command
3. Drop a notecard with the prepared remarks in the Tool.
4. Click the Tool in step with the speaker to send each line to local chat

OR

1. Attach the Tool to their HUD
2. Set the name of the Tool to either “Voice” or the name of the speaker with a built-in command
3. (If they are using an RLV-enhanced Viewer) set their viewer to divert anything they type in local chat to /1
4. Type the meaning-to-meaning (not word-for-word) text of the speech, adding /1 at the beginning if not using RLV.

This version got good reviews, and it is being used regularly.  The first time, I failed User Experience.  The second time, I managed to get it right.

The moral of this story?  IT Students should be sure to get a good Liberal Arts education.  OK, seriously: the code you write may look elegant, efficient, and useful–to another Scripter.  How does it look to the End-User? If they don’t start getting some coins in their till pretty quickly, they are going to stop pulling the handle, and you wasted a lot of time on a work of modern art.

Get to know your audience.