So, this blog goes silent

Linden Lab is cracking down (with questionable legal basis, IMHO) on anybody who uses a domain name that contains anything they have trademarked.  Mine contains “LSL”, which they lay claim to.

They haven’t contacted me yet, but Dianna is about to kick over a big trashcan full of crap right on top of them over their accessibility policy.  That’s why she has ended her “BlindSL” blog and moved to “BlindVW”.

Too, I am starting to re-develop the scripts for the Reaction Grid.  So far, I am only running into one issue (though, it’s a biggie!)

So, sic transit blindlsl.wordpress.com as an active thing
Any announcements on Guide Updates will come via Dianna’s new blog.  I *may* create a blog for my thoughts on coding in LSL, but it will be a personal one and not limited to accessibility scripts.

The ScriptAble Project Wiki is still there, and I am going to get cracking on updating it.  ScriptAble.Wikispaces.com  And I would love to see others get on board with that.

I won’t delete this blog any time soon.  It will remain as an historical document for so long as LL decides to leave me alone.

Blind People Can Now Edit Scripts In SL Using Radegast

What else is there to say?

“Thank You, Latif!”  That’s what!

Back to the Guide!

I thought I was done with the Guide.  Not so, not so!

Radegast, which has largely replaced the Guide, now has RLV support in the works.  YAY! This is the best of both worlds.

So now I am going to work on a Radegast-optimized version of the Guide.  I don’t know yet exactly what that will entail: I have to work with the Radegast users to see just what features they still want and use, and what is just so much extra junk.

Here’s the thing: I took the HUD version of the Guide to a region where I am an Estate Manager and did some looking at the script time. The HUD is taking up .03 milliseconds.  I’m not crashing the sim with that, but I feel that I can and should bring that down.

Here’s a few tentative ideas for how to optimize the Guide for Radegast. Input most welcomed!

1. The most requested feature to date is tp. The current TP works fine, except that all the destinations are stored inside the script.  When I first coded tp, that made sense: users could not edit notecards OR scripts, so someone would have to assist them either way.  So, I avoided the need for a dataserver event by just defining a short list as a variable.  Radegast now permits users to edit notecards, but not scripts.  So, tp needs to have notecard support.
2. The Clothing stuff can largely go away.  Radegast has clothing and attachments support.  Unless anyone has a serious objection?
3. Slurl strikes me as largely unneeded, now.
4. Do we still need who, what, and where? I know that Radegast supports most of these functions client-side.  If they went away, would we miss anything?  The biggest thing I can see would be the loss of Region Rating–or is that included? We could eliminate most of an entire channel, here.  facing should stay, but what of the rest?
5. go and follow are still used.  face, sit, and possibly stand are desired. Sit is usable with Radegast, but if you know the name, using the script is MUCH faster.  face is, to my knowledge, not replaced by Radegast.
6. inv can go away.  replace, add, remove, clothing, all go bye-bye.  time–does Radegast give SL Time?  (Yes, it’s Pacific, I know.)  Can you view profiles with Radegast? If so, then profile is done.
7. help It takes three scripts to do help, and it’s a lot of work whenever I have to update it.  Would anybody be too upset if I just replaced that with a notecard?  They are accessible, now, so I don’t feel the urgency to maintain a command-line help.

Anything I have missed?  Hopefully I can improve the user experience while filing down the Guide to something smaller and easier for me to maintain.

Interface for the Editor Tool

This one is going to be a little bit long, I am afraid.  Once again, I am posting working notes.

The real challenge of the Building/Editor Tool is not the code.  llGetPrimitiveParams() and llSetPrimitiveParams are going to handle better than 90% of it. That’s not “hard”, just “tedious, lengthy, and requires careful organization.”  I’m good at tedious and lengthy, and I can get careful organization after a few tries.

The part that requires Creative Coding rather than assembling existing parts is the User Interface.

As is so often the case with these things, I am working my way through a compromise.  After all, this is something that will work entirely through chat channel commands, but it is a workaround for the lack of accessibility of the Edit tool in the Standard Viewer.  It’s worth noting that many Sighted, Abled-Bodied people look at that tool and run away and hide.  It’s rather intimidating!  Even so, that defines the “language” that everyone else uses.  If I require the users of this tool to speak a different language, it is going to be inherently discriminatory, placing needless barriers to communication and instruction.

Therefore, the internal help documents and the commands are going to be based off the tabs in the standard editor.  If you type “/7 General”, you will get a list of commands relating to the Name, Description, Owner, Creator, Permissions, Left-Click behavior, etc.  If you type /7 Object, you will get Locked, Physical, Temporary, Phantom, Position, Rotation, Size, Material, etc. If you type Features, you get Flexible Path and Light.  If you type Texture, you get access to the “faces” commands. If you type Content, you get something cool and amazing that I am sure to figure out before the first Beta-Tester gets ahold of it.

This way, if a person without any experience with my tool says to look for “Force X” under “Flexible Path” in “Features”, the process to get to that point in my Editor will be parallel.  There will be some extra commands, such as a command to set which face you are currently working on (0 through whatever, or All), a help command, and eventually other things relating to linking stuff together, but as far as possible, someone with the standard editor and someone with the Adaptive Editor will be speaking the same language.

This is not going to be “menu based”, though. While you can work through the “menus” until you find what you want, any command will always be available.  So if you know from the start that you want to change the plus X side of the Box to  Full Bright, you can type /7 face plusx and then /7 fullbright on.

I should note that /7 is an arbitrary channel.  I intend to allow for different channels so you can be working on more than one prim at a time.  I am also going to allow for collaboration: this is a feature that some people without disabilities may find to be of interest as well!  You’ll be able to either keep it owner-only or else open it up for others to edit.  I haven’t worked out all the details on that yet, of course.

In the end, this is going to be a bigger project than the Guide.

Here’s my working notes which are mutating slowly into a list of commands for this.

GENERAL
Name (string)
Description (string)
Creator (key)
Owner (key)
Group (key)
Permissions
“You can modify this object.”
Share with Group (boolean)  [Deed to Group Button]
Allow anyone to move (boolean)
Allow anyone to copy (boolean)
Show in search  (boolean) [Research this!  Can objects show up in search, or is this a legacy thing?]
For Sale (boolean) Price: L$ (integer)
Original/Copy/Contents
Next Owner Can
Modify (boolean)
Copy (boolean)
Transfer (boolean)
Left-click behavior
Touch/Grab, Sit, Buy, Pay, Open, Play Parcel Media, Open Parcel Media

OBJECT
Locked (boolean)
Physical(boolean)
Temp_on_rez (boolean)
Phantom (boolean)
Position (vector)
Size (vector) meters
Rotation (rotation) need to change to degrees.
Material
Type
Path Cut (vector, xy)
Hollow (float)
Hollow Shape (integer constant)
Twist Begin/End (vector, XY)
Taper (vector, XY)
Top Shear (vector, XY)
Slice (vector, XY)
Dimple (vector, XY)
Hole Size
Profile Cut
Radius
Revolutions
Sculpt Texture
Mirror
Inside-out
Stitching Type

FEATURES
Flexible

1. Softness
2. Gravity
3. Drag
4. Wind
5. Tension
6. ForceX
7. ForceY
8. ForceZ

Light

1. Color
2. Intensity
3. Radius
4. Falloff

TEXTURE
Texture [Let's differentiate this somehow, in an intuitive way, from the tab-title "Texture".]
Color
Transparency
Glow
Full Bright (Boolean)
Mapping (Texgen)
Shininess

1. None
2. Low
3. Medium
4. High

Bumpiness

• NONE      0      none: no bump map
• BRIGHT     1     brightness: generate from highlights
• DARK     2     darkness: generate from lowlights
• WOOD     3     woodgrain
• BARK     4     bark
• BRICKS     5     bricks
• CHECKER     6     checker
• CONCRETE     7     concrete
• TILE     8     crustytile
• STONE     9     cutstone: blocks
• DISKS     10     discs: packed circles
• GRAVEL     11     gravel
• BLOBS     12     petridish: blobby amoeba like shapes
• SIDING     13     siding
• LARGETILE     14     stonetile
• STUCCO     15     stucco
• SUCTION     16     suction: rings
• WEAVE     17     weave

Repeats per face

• Horizontal    [Flip]
• Vertical         [Flip]

Rotation (degrees)
Repeats Per Meter
Offset

• Horizontal
• Vertical

Align Media Texture Button

CONTENTS

Saving Face!

Yes, that title is a horrible pun. 

I am going to ask that you bear with me.  As I write this, I am working through the structure of the script that I have to write.

I have been playing with the llGetPrimitiveParams() function, and I have created a script that will tell you pretty much everything *except* the Face flags.  Face, you see, is not a simple concept for LSL.  Check out the Face List and you will see just how interesting this can be!  I can’t start making scripts that will permit Blind/VI users (and possibly those with other disabilities that inhibit use of the client’s editing tools) to create and manipulate objects until I am able to describe those objects with some degree of accuracy.  Clarity is another matter: the learning curve on this stuff is going to be steep, and we are going to have to find good teachers for it!

So, before we can describe the object, we have to know how many faces there are, and which ones they are. This is going to involve a fairly high degree of Artificial Intelligence for an LSL script: it’s going to have to analyze the prim that it is inside of and infer some things about how it looks.  Remember that a prim can have just 1 face (an unmodified sphere or sculpted prim), and as many as 9 faces (a heavily modified box or tube).

1. What type of Prim am I?  We’ve got 8 possibilities here.
2. How many sides (faces) do I have?  llGetNumberOfSides()
3. The following are in varying order and may or may not appear depending on the answer to #1
4. Am I hollow?
5. Is there a profile cut?
6. If there is a profile cut, have one or more faces disappeared as a result? Which ones?
7. If there a path cut?
8. If there is a path cut, have one or more faces disappeared as a result? Which ones?
9. Do I have dimples? (And do they make me look cute?)
10. Is the circular path broken for some reason besides a path cut? (Several conditions can create this.)
11. Now we should have all the faces in their proper order in a list, by name.

Then we go through by face number, pull the name we assigned to that face, and add whatever information the builder is looking for: texture, shininess, bumpiness, alpha, color, texgen, glow, or fullbright.

When looking at the object as a whole, it would probably be best to just put the information in a parallel list. That way if we wind up with a list where the values are all the same, we can just say “This applies to all sides.” when speaking of a parameter.  If everything is the same color value, there is no point in spamming the user with the same value for each face.

Figuring out how to present the information efficiently is a later challenge, though.  First I have to figure out how to get the information accurately and without *too* much script load.  Fun!

The good thing is, once I know how to get it all effectively, making a script to modify the parameters should be relatively easy.

Sic Transit Guide

It’s been a couple months since I posted here.  Real Life came along and gave us some hard hits, and we have had other things going on in SL as well.

As for the topic of this post: the Guide isn’t dead–yet.  Nor will it completely die for some time to come!  However, the people over at the Radegast Client Project have been doing an amazing job of making their product accessible.

In fact, it is possible (Dianna tells me) to read Scripts.  She says she can’t yet edit or create them, but she can read a script from her inventory.  This is coming very close to one of my Big Goals! There is a slogan among People With Disabilities that I firmly believe in: “Nothing About Us Without Us.”  I have always hoped to see my role as a Scripter for Blind and Visually Impaired people become at least somewhat deprecated.  I don’t feel that every Blind or VI user in SL should or even could become a competent Scripter, but the Community as a whole should have a chance to produce some coders who can bring their direct experiences to the task.

It’s an adage in SL as in many other such situations that, if you don’t like what’s already out there, learn LSL and go do your own thing!  The problem is that, for now, that’s not really an option for Dianna or others like her.  Oh, she could write a script, email it to me, and have me paste it into SL and compile it for her.  Think about the cycle of debugging, compiling, tweaking, and compiling again!  Doing it through someone else is just not very practical, and bound to create tensions.  Besides, I would either have to log in as her (which is OK between a husband and wife, but not necessarily for others!), or she would have to surrender ownership of her code to someone else.  LL looks at the name in the “Creator” field, after all.  Being able to open the editor, write or paste in her own stuff, and hit “compile” is just the way to go.  Once that happens, the Blind Community doesn’t have to try to cajole and convince the Sighted Scripters that what they need is what they want: they CAN do it themselves!

Freedom of the Press belongs to the guy who owns one.  Freedom of the Code belongs to the guy with a compiler.

 

But I digress.   With the advances we are seeing, Dianna and others are using the Guide less and less, though they keep it for some things.  A few have chosen not to switch to Radegast, which is their right!  It’s also one of the reasons why I made ScriptAble products Open-Source: others can pick it up and move it in whatever direction works best for them.

With Radegast moving along well, I intend to work more on things that are not so easily solved by making an accessible client.  I am working on an accessible sailboat, though I have to be careful of the license on that one, as I am using someone else’s code and the license is not exactly like what I use.  I am also working on my crazy building project idea.  More on that in the next post.

If you use the Guide and you would like to see a new feature, or if you find a bug?  I’M STILL HERE.   I haven’t gotten a single feature request or bug report in months, which tells me that people are either well-satisfied, or else they are moving to Radegast and don’t need it. But if somebody needs it, I’m not leaving you adrift!  Talk to me.

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.