My first object imported to OpenSim from Second Life

The Imprudence viewer exported the biplane model as XML, minus any textures I didn’t actually own (I’m not sure which those would be, since I textured this myself). Then I ran Sim-on-a-Stick, logged in with Imprudence and imported the XML. Over a period of about 30 seconds, I watched Imprudence assemble the plane in pieces — all 248 of them and all textured correctly. Proof of concept: Now I can start migrating my content away from Second Life.

Just to be perfectly clear, I’m not abandoning Second Life. I just think that it’s good to have a lifeboat available if the Titanic goes down.

UPDATE: After playing around with Imprudence in Second Life for a bit, I find that I can export almost nothing, because there’s always at least one part of the model or textures that have someone else as the “creator”, even if that name is my own alt account. What I need is a viewer that ignores the creator tag. Without that, all of my content is stuck in SL.

That things are improved by putting them on a stick holds true in other industries too, including software. Since former Linden, John “Pathfinder” Lester blogged about it back in October, I’ve been intrigued by the idea of putting an OpenSim server on a USB stick. It seems Second Lifer, Ener Hax, has been experimenting with the “sim-on-a-stick” idea for several months now and has gotten to the point where she is now sharing the fruits (on a stick) of her labour with the world at simonastick.com. (Who is Simon Astick? It’s a mystery.)

Today, having a bit of time on my hands, I decided to give Ener’s Sim-on-a-Stick a try, so I downloaded the zip file from simonastick.com. The setup was amazingly simple: you just copy the files to a USB stick (or to a folder on your hard drive, as I did) and run the various components. Within a few minutes of unzipping it, I had a single-region grid running locally, and had logged in and rezzed this cube:

It all starts with a cube: running OpenSim server, MoWes, and the Imprudence viewer.

The possibilities for applied use are intriguing. If I can find a way to export my content from Second Life and import it into OpenSim, then there’s a chance that I can take Abbotts Aerodrome and all of my creations with me should Second Life or its economy falter. Because it’s hosted locally, and therefore private, I could use OpenSim for simulations, demonstrations, and presentations for work-related projects.

Sim-on-a-Stick makes OpenSim approachable to an average user. It requires little in the way of technical skills to set up, and it’s completely self-contained so that it can be easily carried with you on your keychain. Everything really is better on a stick.

Obviously, the concept of the user as a god doesn’t exist in reality, and the idea that our programs should treat us as gods has essentially vanished. No application is truly subservient to your needs — in fact, that sentiment might have died with Clippy, the helpful paperclip. If anything, software developers create applications with the idea that the user is subservient to it. Create the basic functionality with no regard to ease-of-use, and if the user has difficulty, that’s their problem: if it works somehow, more or less, then the developer’s job is done.

While this is usually how software is made, this isn’t how good software is made. This is how useful software products fail, in fact. You can have the most functionally complete application ever created, but if you ask your user to fill in too many gaps, to do too much work to make your tools useful, then you might as well not have any product at all. If you want to create usable software, as opposed to useful software, then you have to keep your user in your mind with every line of code.

But who are your users? You know by talking to your customers that some are more technically competent than others. As much as you’d like to give the middle finger to anyone you don’t consider your intellectual equal, they are the reason you have a job. Your job is to write tools for actual users. So your job is to first understand who these users are.

No, they aren’t one homogenous mass of people with wallets. Each approaches your product with their own skill level and background. However, if you look carefully, you can break down the user base into three distinct groups, and focus your efforts accordingly.

First, and most obviously, there are the Beginners. Beginners have no extensive experience with computers or software in general, and they need a crapload of hand-holding. A subset of these are the ones who attack the software with no experience and no desire to read the manual — the needy users. Another subset will rely entirely on phoning tech support. Despite the fact that you speak to the needy users more than anyone else, these are a tiny minority. If you’ve designed your software correctly, the majority of Beginners will be able to intuitively understand how to use the tools you provided.

Second, we have the Skilled users. These are the ones who have spent enough days using your product that they’ve moved on from simple “how to” questions to advanced questions of how to affect the best use of your product. If you have a basic user manual, chances are, they are way beyond it already. Now they need advice on specific use-case scenarios and implementations. If you don’t cover these issues in your manual, these questions will inevitably fall to tech support and end up costing you money.

Finally, we have the Advanced users. These are the users you love, because they don’t actually need help. In fact, they’ve used your software so much, they can inform you as to what changes you need to make for future releases. It’s important to listen to these users, but at the same time, avoid being guided too much by their needs, because their needs by definition don’t match the needs of the vast majority of your user base.

So those are your users: Beginners, Skilled, and Advanced. If you design your product with the user in mind, which user are you designing for when the needs of each group is vastly different? Let’s focus on the learning timeline, because it’s clear that Beginners don’t stay Beginners forever; eventually, they’ll become Skilled. In fact, it’s likely that they’ll only remain fumbling, needy Beginners for a week or so before they master the basic skills and move on to more advanced issues. Advanced users are a tiny subset that could really master any interface in spite of even vast usability problems, while at the same time informing you of the problems as they work.

The group that you need to focus on is the Skilled group. Every day, these individuals sit down and use your product to solve problems. Your task is to make their life easier. And if you’ve designed your user interface right, you’ve eliminated the pain of repetitive tasks, and streamlined daily activities based on what they need. In terms of documentation, your manual provides tips on how to improve their work flow, rather than focusing on clicks and menus.

The ideal software is easy to approach for the Beginners, provides obvious benefits to the Skilled, and is open-ended enough to allow Advanced users to expand on what you started. If any of these users needs to read the manual to perform any basic function, then you’ll know that you screwed up the interface. A user’s experience both begins and ends with the interface. User experience is the alpha and omega of interface design, and for that reason, if you haven’t once said, “Oh, my User!” then you’re doing something wrong.

Arriving at their site, I clicked the link to “log in using Facebook”, which is essentially adds Kitely as a Facebook app with full permission to access all of your Facebook account. If you’re at all concerned about privacy or identity theft, this is a point of concern already. Any app to which you hand over the keys to your personal info can essentially mine your data or post on your behalf. However, since my Facebook account is largely free of info that I need to hide, I went ahead and agreed.

The next problematic step, after creating the world and naming it (in my case, it’s named “Terra”), is that to enter the world, you need two things:

• A Second Life client installed on your computer.
• A “Kitely plugin”, which is an installer that you download and run.

That you need a Second Life client isn’t a problem for anyone already in Second Life, but that’s a big step for a lot of casual Facebook users. Also, there isn’t an obvious link for users to download the SL client, but maybe I just missed that.

The Kitely plugin is an installer for a small program that launches the SL client to connect to a particular Kitely world. Now, if you’ve ever connected to a grid other than the default Second Life grid (“Aditi”), you know that you can do this manually at the SL login screen, so the “plugin” is simply a convenience to users who are less technically inclined.

I did have strong reservations about installing this plugin, but mainly that’s a trust issue. As in, do I trust Kitely enough that I’m certain there’s no malware in the plugin, for example. I installed it despite my concern, because there are no instructions on how to connect to a Kitely world without the plugin.

Once in my new world, Terra, it was perfectly familiar. I had an avatar, a male one, though I hadn’t been presented with any choices there, and a tiny round island in a vast ocean. It looked like my world was ready to be terraformed and filled with goodies.

The first thing I tried, of course, wasn’t the inventory, but the physics. I rezzed a cube, turned on physics, and dropped the cube from a height. The result: not good. It rubberbanded a few times while falling and bouncing, and oddly ended up in the exact spot where I rezzed it. At a guess, that kind of physics time dilation is a sign that they’re hosting way too many sims per server, and the physics engine is simply overloaded.

Next test: I put a simple airplane flight script into the cube. I encountered a couple of odd bugs in the script editor, where it wouldn’t let me paste overtop of existing text, but I worked around that and compiled successfully. Great… time to fly. I sat on the cube, which gave a status message, as my script should, so that meant the script was running. So far so good.

Touching the throttle, though, led to my avatar being mashed into the sim corner underwater with the camera flailing all over. Standing didn’t work, and teleport home resulted in an error message. So that was my first encounter with Kitely. Technically speaking, the performance falls well short of where it should be to be a usable SL-based VW.

But beyond the technical issues, I have to question the purpose of Kitely. What advantage does Kitely offer a user over Second Life? Certainly, Facebook users can log into Kitely with an existing user ID, but is that really much of a convenience? The Second Life sign-up process is easy and free. Where Kitely seems to suggest that you will eventually have to buy Kitely currency to use their service, you never need to drop a cent in Second Life unless you want to buy land or content.

And this brings up another question. Where does the content come from? Second Life’s user-created content is rich, vast, and arguably matured. While it is possible to upload an entire region based on an OAR file (an entire region ripped from an SL-based VW and saved to a file), the vast majority of Facebook users will arrive to their new virtual world with nothing but the virtual clothes on their back. In this area, Second Life seems to have the clear advantage.

Privacy might be an area in which Kitely offers an advantage, in that you can control who comes in, but Second Life offers that ability as well, albeit only to estate owners.

In the end, I’m unconvinced that Kitely is a viable product. It technically falls well short of Second Life itself, but in fairness, maybe the performance issue will be rectified with more money for hardware, and if it’s used for purely social reasons, like standing around chatting, I’m sure it would be perfectly adequate. And bugs can be worked out, given time. The key issue is that it fails to address any specific user need that Second Life doesn’t already provide or exceed. And for that reason,  I think that Kitely just won’t fly.

I may be wrong here, but Search is supposed to present organized lists of links, right? Isn’t that something that we’ve had for over fifteen years on the web? And somehow that’s beyond the capabilities of LL devs? You can’t navigate easily, the search basically doesn’t return expected results, and you can’t bookmark for later exploration without actually going there and making a landmark. It’s just phenomenally poor design and implementation.

I couldn’t find much with the search function, so I wandered through each of the dozen or so featured links and found a handful interesting but empty locations. Nothing truly engaging. I know there are people in SL doing fun things. I’ve been engaged in SL since 2003. But I can’t, despite my best efforts, actually find them. At that point, I ended up wandering through empty sims for an hour or so.

Essentially, there is no way to get to good content beyond word-of-mouth and shared landmarks. That is inexcusable this late in SL‘s life. We need a Google of SL, and then nobody will say there’s nothing to do in SL. They’ll say there’s too much.

Text editors, including WYSIWYG editors, have over the decades evolved certain standards for common tasks, including word selection, keyboard navigation, cut-and-paste operations, and all variety of basic word processing activities. That’s why when you move from one text editor to another, it’s relatively easy to become productive quickly — after all, you’re already familiar these standards. As a writer, these navigation keystrokes are second nature to you.

What was the reasoning, then, that made the designers at MadCap decide to throw those standards out the window and make up their own? Let me give you a few examples of their bizarre design choices.

• The Home key should move the cursor to the beginning of the line, right? Not in Flare. It goes to the beginning of the paragraph. Similarly, the End key moves the cursor to the end of the paragraph and not the line.
• You might expect the down arrow to move the cursor one line down in the same horizontal position, but you would be wrong. In Flare, the cursor moves one line down and several characters to the right, inexplicably. I’m hoping that this one is just a bug that will be fixed in a future release.
• Your cursor can end up between lines, and pressing delete once will wipe out the entire next paragraph. I’m trying and failing to figure out how that could be useful enough to warrant the risk of accidentally deleting something without noticing it had happened.
• Selecting text is great fun too. You can’t easily select to the end of a line due to the End key’s behaviour, so you have to Shift+Ctrl+right-arrow word by word. That, or click-drag with your mouse.
• The previous point is especially fun when editing long sections of “PRE” tagged computer code snippets, in which line breaks are used in instead of paragraph tags. Press End at any point, and it takes you to the end of the section of code. And you can’t easily insert tabs or indents for code that uses different levels of indentation, which is most code. Essentially, if you want to include any code examples in your document, you have to edit it in a text editor separately and then paste it into Flare. Carefully.
• There’s something odd about the cursor’s behaviour around inline tags, like style and condition tags, where the insertion point becomes a left or right bracket without moving. That’s probably mentioned in their help, I guess.
• If you select some paragraphs then click Bullet List, Flare will not only bullet the selected paragraphs, but the one after too.

I could list more oddities, but I think my rant is running out of steam now. Whew.

Incidentally, writing this blog entry was really quite easy because I didn’t need to use Flare. The WordPress editor actually uses standard keystrokes.

</RANT>

The wastefulness of the morning commute struck me. All these cars roar along choked corridors to get their single occupant to the cube farm on time, while burning vast amounts of fuel and spewing pollutants. And consider the resources and energy spent building thousands — millions — of cars that make the same trip twice a day all across the country. It’s an obscene waste. And none of it is the least bit necessary.

Having spent the last five years working from the remote location of my desk at home, I can assure you that there is no reason why office workers can’t be productive remotely. Using secure software for remote access to the company’s servers and a reasonably fast Internet connection, anyone can be virtually present at the office. Add to that virtual presence an instant messaging and VoIP application, then workers can be available for meetings, presentations, and even casual watercooler chat.

This kind of virtual presence is something that any Second Lifer well knows already. In a world created collaboratively by individuals spread all over the globe, working remotely in environments like Second Life becomes second nature. From our living rooms and home offices, we meet, chat, organize, build. And even though Second Life itself doesn’t lend itself to practical aspects of the workplace, like sharing documents, other software exists that allows exactly that.

So where is the telecommuting revolution that tech pundits promised a decade ago? Why are we still engaging in the wasteful, destructive daily migration to the office towers downtown? What is the resistance?

To employers, it would seem to be a no-brainer. Remote workers don’t use up costly office space and resources. There are no on-site insurance issues. You don’t need to spend money on meals when they work late.

I think in the end it comes down to trust, or a lack thereof. Employers feel the need to keep a watchful eye on their employees when productivity is measured in keystrokes per minute, not in the quality and volume of daily output. If workers aren’t seated in their cubicle and clattering out words at their keyboards, then they simply aren’t working. Part of the resistance on the management’s part is purely emotional, I imagine. Decentralization means a loss of direct control over the minute-to-minute activities of their subordinates. And that means no more leaning on the cubicle wall, coffee mug in hand, with a personal reminder to put the cover sheet on the TPS report.

Somehow, this negative perception needs to change to follow the example of Second Life. Businesses need to change from a centralized, cubicle farm model to a decentralized, remote model. Office workers needn’t be enclosed in a grey stall to work productively. In fact, as I can attest, working from a home office reduces stress, which in turn improves productivity, creativity, and output.

Until the telecommuting revolution arrives, however, I’ll be bumper-to-bumper with the hordes of fellow cubicle dwellers.

Related links:

• The quiet revolution: telecommuting (MSNBC)
• Telecommuting revolution (ZNet)

We need testers who are:

• Familiar with SL vehicles, preferably aircraft.
• Can methodically test a vehicle in a variety of scenarios (even unlikely ones that push the limits).
• Can report bugs in terms of how to reproduce them.

We can’t take everyone, but those who do qualify will get a free copy of the final version when it’s available.

Please IM me (Cubey Terra) in-world if you’re interested!

The answer is, not yet. But now is your chance to do something about that. As of today, I’m releasing the TCS source to the public under a CC license. This means that you can take TCS — the long-established sensor-based combat standard — and make it better. Adapt it to your bombs, missiles, mines, exploding penguins… whatever.

In return, all you have to do is share your updates with everyone. (I’ll provide a link to a place to do that shortly.)

Let’s work together to make TCS even better, and establish a single sensor-based combat system that we can all share.

Get the full-permission TCS 2.5.4 at Abbotts Aerodrome or at Xstreet SL (click here).

At the best of times, SL is a tricky environment to work in. Upgrades and changes to the simulator code can sometimes mean that old, reliable scripts stop working. I just confirmed that the hard way when one of my customers let me know that the automated, looping tours in my Aerius blimp stopped working. Instead of restarting a tour, the blimp would go dead until the owner manually restarted the tour.

That’s kind of weird, especially, since several people tested that feature thoroughly. As tested, the blimp ended one tour, slept for half a minute, then started again. But now, the “sleep” period starts and never ends.

The problem is now fixed in version 1.1.1. To my customers who bought the Terra Aerius blimp and want to use looping tours: just drop me a line in SL and I’ll send you the update (version 1.1.1). If you don’t need looping tours, the update isn’t necessary.