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.

Rambling: Radegast, Building Tools, and the 1-Prim Database!

Well, before long the Guide may be somewhat deprecated.  Somewhat, I say!  I think there will be a need for spinoffs from it for some time to come.

Over in her blog, Dianna talks about her experiences with Radegast, a new SL Viewer in development that is working on being fully accessible for her.  There’s a few things yet to do, but already it replaces most of what my Guide can do, and it includes some things I cannot do, like give access to IMs, using the in-world economy, etc.  It’s also an all-in-one solution for client-side accessibility: viewer and speech in one package.  She’s pretty psyched about it!

And I am pretty darned happy with it, too.  I have always stated that most of this stuff should be considered no more than an ugly workaround, and I have advocated for a client-side solution from Day 1.

That doesn’t mean ScriptAble will be irrelevant!  Some people may prefer to use the other options.   For example, someone with Low Vision may well prefer a graphical Viewer with Speech as a complement.  Some things are going to be harder to implement with the viewer than with LSL.  And, the most important point of all: when we make these scripts and hand them out to people, we learn things.

I found the landowner tool to be more frustrating than fun, so I put it on the shelf for a little bit. I am going to get it into the shop, I just need to avoid the temptation to jump up and down on it with cast-iron boots.  Instead, I am tackling the beginnings of a challenge that has fascinated me since I picked up the LSL Hammer: Building In SL for the Blind. I really don’t know where this is going to lead us, but I know we aren’t going to learn anything, or make anything useful, unless we try.  I am starting with llGetPrimitiveParams and putting together a (relatively) simple script to let my Alpha-Tester (that’s Dianna) tell me how to better present the information.  I know the learning curve on this is going to be steep! We’re starting with one prim for now, and we’re going to just give information for the moment, not permit changes.  Once we have the feedback system working like we want, we can add in functions to shape and change this prim into…well, I don’t know what is going to come out of it!

Working with llGetPrimitiveParams inspired me to a bit of Mad Science. This really has nothing to do with Assistive Technology, it just shows what a complete Nerd Genius I am.

One of the complaints of the LSL Scripter is that it is nearly impossible to store information using an LSL script, unless you pipe if off-world to a URL that can receive it and return it at need.  (That gets ugly in its own way, from what I have seen.)

Then it hit me: if you are willing to get a little creative with how you encode your information, you have a Data Storage Device in your basic 1-prim box! It’s all numbers, after all…

Take PRIM_TYPE and PRIM_MATERIAL, and you have a 2-digit Octal numeral.  There are a maximum of nine different Faces on the basic Box, with the ability to store 2 booleans on each (PRIM_FULLBRIGHT and PRIM_TEXGEN). Discounting Temp_on_Rez, there are places to store 22 different boolean integers on one box.  Vectors and Rotation, Floats, Integers of varying ranges: a really enterprising Nerd LSL Scripter could encode a lot of information on one prim without having to worry about the ephemeral nature of script variables.

I don’t think I am going to implement this myself, but it would make for an interesting challenge: how much useful/usable information can you store in one Prim?

How to make Talvin scream

Want to ruin my day?

Say Dataserver

AHH!  I said “Dataserver“!

AHHHHH! I said “Dataserver” AGAIN!

Talvin glares balefully at the Lindens and stomps off to his Scripter’s Cave again.

2.0! Wiki. And the future

Been a while since I posted here!  But I have been busy!

Guide 2.0 went out. I haven’t gotten a single bug report back.  I hope that means people are using it and are happy.

The Wiki LIVES! http://ScriptAble.wikispaces.com/ Rather than posting code here, you can find it there. The formatting should be a little easier to read.

Interested in becoming an editor or contributor to the Wiki?  Got some Assistive Technology you are willing to license under the Creative Commons?  Talk to me, I’m all ears.  Yes, even if you think you have made something like what I made, but better. I’m open to the idea.  Room enough in there for both.  There are some Contributor Guidelines, but they are written in plain, blunt English. 

I managed what I consider a BIG win this last week: I got Blue Linden to put the link to the Wiki on the TeenSL Forums.  To the best of my knowledge, this is the first attempt to bring Accessibility to the Teen Grid.  I think we can build on this.

So, where do I go from here?

1. If one more person asks me, “So how are you advertising your stuff?” I am going to…concede that they are correct.  I need to get out there and wave the flag more.  I’m working on how exactly to do that.  I have to reach more of the market that is already in-world, and I need to reach more people who are thinking about trying SL.  I also need to reach more organizations that are looking for resources like mine.  Hey, it’s free: can’t beat that.
2. I need to find more Scripters.  I have branched out a little bit, but I am still focused on Blindness/Low Vision with most of my stuff.  Other people with other interests can make ScriptAble something truly diverse and alive.
3. On the practical side, I am going to devote some time this week to getting the landowner’s tool in the shop. It’s not difficult, I just need to apply myself a bit.
4. Once that is done, I think it is time to start working on “Toys”.  Until now, I have mostly focused on things that help you use Second Life on the most fundamental level: sensing, moving, dealing with inventory, managing a parcel of land.    Now I want to move into stuff that is just fun: games, RP tools, etc.  I would like to see if I can make at least some of it compatible with existing systems, but I will have to see what is out there and what the owners of those copyrights think.
5. This is my blue-sky project: Building Tools.  Code-wise, it can be done.  In practical terms, I just do not know!  I can make the tools and see how they are used, that’s all.  At the least it will be a fun toy!

BTW: some people have suggested I should charge for this stuff.  I went out and canvassed my friends who write Code for a living (not LSL), explained what I do, and asked what I should expect to get paid a year for doing it. Opinions varied: $37,000/year USD was the low end, we won’t talk about the high end.

So, to make it actually worth my while, I would need 1,000 users of my products paying me $37/year.  I don’t see 1,000 users right now!  OK, let’s shoot for a more realistic number: let’s get 100 Blind People into SL and charge them $370 a year to do what anybody else can do for free. Yeah, that’s the ticket!

Eh. Fuggedaboutit.  It’s staying free.  Awfully sorry if this disappoints anyone.

16 Objects

llSensor returns 16 objects.  No more, and less only if fewer than 16 are in range.

There are blessed few places in SL that you can go where you will find fewer than 16 objects!

So, here’s an idea:

Make a Skybox object.  That’s 1!  Put it up out of range of other people’s builds.

Now, make the most interesting and accessible place you can–for both Sighted and Blind users!–with just 15 other objects. Prim count is not so much an issue here, but what can you make with 15 things? Remember: an object is just prims linked together. The Guide doesn’t see prims, it sees one object, and reports back on it.

Right now, it couldn’t be a store, because Vendor Objects don’t work with the available tech.  Some other builds might be similarly without use at this time.

What can you make?

2.0 Beta

So, I have this object that is going to be the 2.0 Beta for the Guide. I am going to sleep on it tonight, do a couple things to it in the morning (like putting copyright and license notices in the files, etc.), and then I am going to hand it to my Beta Testers.

After they have had a chance to comment, and any tweaks/fixes have been made, I’ll get it out there to everyone.

So, what’s new?

• follow is fixed.  Um, kids, when declaring a global variable, be careful not to redeclare it in a function.  Just redefine the variable. Don’t put string in front of it if you did that already, just say variable = blah;   Yeah. Trust me on this one.  *headdesk*
• profile This is a fairly simple one that will give you the URL for somebody’s profile on the web.  Like going into the search tool in-world and looking them up in “All”.
• New name.  ScriptAble. Dianna and I are working on the Wiki.  Going to open it up to other scripters who want to use it to share their work.
• Support for–to some extent, reliance on–the Restrained Life Viewer.  The old commands and scripts still work!  I have carefully separated out the commands into scripts that end with -alt, so they can be excluded in a “Standard Version”.  Though, maintaining two versions may be more trouble than I need.  We’ll see.
• Thanks to the RLV, we have: face, sit, stand, tp, and for clothing and attachments, we have: add, remove, replace, inv, clothing.

The much-promised look and ping are going to wait.  Why?  They require things that are outside the Guide itself.  I have to get some tools made up for those who want to make their builds accessible, and I have to convince a few builders at least to use them.  That’s not going to happen in the next couple of weeks!

The new Wiki will also be a good place to show off the new Transcriber Tool (revised from earlier concept under the KISS Principle) as well as another project I stopped to do for some folks.

Oh, I don’t know if I said this: somebody out there is modding my stuff to work in OpenSim.  (I know diddly and squat about how LSL behaves in OpenSim!)  To this I say yea, and yay!  That’s the sort of thing I had in mind when I started this: take it and run with it.

I’ll see if we can get that added to the Wiki as well.  It’s up to them.

New Name

I was going to do this later, but later is getting awfully close to “now”.

We have a new name.  ScriptAble. That should be spoken like “Script Able”, not “Scriptable”, though I am not too stressed over it however you decide to say it.
Why?

1. BOSS is a horrid acronym.
2. It contains the name “SL”, and that gets into legal gray areas with their trademarks.  I’m being proactive in changing it.
3. It’s not just about Blindness anymore.  Every time I turn around, we’re adding another subset of the Disability Community to those being served.
4. Nobody else can post here, so some of the functions of this blog are going to be moved to a Wiki, so others can post what they are doing–or what they need!

The basic concept remains the same.  There is a Wiki that I am getting set up to hold the documentation and the code.  This will just be my “Here’s what’s going on in Talvin’s projects” blog.

More on this later!

LandOwner Tools

I know of at least two Blind/VI people who own land. I have been putting this off by rationalizing that “Nobody needs it yet” and pushing it down the list. Foolish, foolish!

Here’s a few useful things I could do with Land Tools easily, I think. Note that I haven’t fully tested this, so there may be a troll hiding under one or more of these bridges.

• Media and Music: Get and set the Music and Media URLs.
• Prim Count: Give you the max prims, the current number of prims, and the list of prim owners with count.
• Give you the power to eject someone from your land, the power to ban them, and the power to send them home.

What’s not so easy?  llModifyLand, as found at http://wiki.secondlife.com/wiki/LlModifyLand

It seems doable.  It would be very interesting to see someone make the attempt! Like object creation and editing, the tools are there, but I will need to just code it to someone’s spec and watch them learn how to use it by trial and error, I suspect.
So, End-Users! What is your priority? What commands would you like to have to call these various functions?  This won’t go in the Guide, it will go in something else.  Call it…what?  You tell me. You’re the Customer, and the Customer is, if not always right, always the person who knows their own needs and desires best.

Clothing: Lessons Learned

By far, the most difficult project on the slog to 2.0 is clothing.  RLV gives some interesting and complex options.

A few lessons I have learned along the way:

• Avoid homophones when coding for people who use Text-to-Speech.  This would also apply to Speech-t0-Text.  So, “wear” conflicts with “where”.  wear is now replace.  (I will include add as well, another post.)
• It works on a “partial match” basis.  Be careful when naming your folders.
• It’s a good idea to add “outfit” to the name of anything that is a complete set of clothes. If you name something “Concert T-Shirt”, is that a T-Shirt alone, or a T-shirt added on to your usual jeans and such?  If it’s just the T-shirt, it better be a LONG t-shirt, or replace is going to get you banned from a PG sim.

Sit. Stand.

We now have /3 sit <name> and /3 stand.

And there was much rejoicing.

Going to let the beta testers take a few whacks at it.  I am thinking this is all going to go out in a big 2.0 release.