ivantohelpyou

The virtual stores are empty. The design simulations are kludgy and represent the ultimate exercise in pointless boredom for users who want to indulge their ultimate fantasies, not decide between olive green and stainless steel for a new refrigerator.

InformationWeek, Feb 24, 2007

In an earlier post, I tried to fit the content-structure-layout-behavior Web design paradigm onto the Second Life world. Now, I'm not so sure that's the way to think about it.

The SL world itself is comprised of a database of scriptable objects. Let's take the simple example of a box that (1) changes to a random color whenever touched, and (2) counts the number of visitor touches. Here are the key properties of the box :

• Ownership
• Location in x-y-z space within the SL grid.
• Outline of object in 3D space
• Texture and lighting
  
• Scripted behaviors

Fundamentally, when I create a scripted box object in Second Life, I am using a proprietary interface to add an object to the SL database. That's the back-end.

On the front-end, access to this object is limited to registered users of a custom browser, i.e. the Second Life client. You can't fetch an object to display within the context of a Web page or an environment outside of Second Life. Instead, you have to log in, create your avatar, and then navigate to a proximate area to a given position in x-y-z space in order to interact with any given object. Making this slightly easier, Second Life does have a Webmap API that can display maps within a webpage, or spawn the Second Life client to go to a specific point.

Imagine a command-line interface for Second Life.

% login as ivan
You are logged in as Ivan
% move to SLPoint('ahern',128,128)
You are there.
% look around
You can see the following object(s):
# X Y Z Name Appearance Actions permitted
1 100 200 0 touch-me box {Color}R:255;G:0,B:0 [touch]
2 200 600 20 Wilma Furry Female, Furry [more] [chat]
...
% touch object 1
Object 1 (touch-me box) has changed Appearance {Color} to R:0;G:0;B:255.
% say "Hi" to 2
Chat initiated with Wilma Furry.
CHAT: ivan says "Hi"
%
CHAT: Wilma Furry says "hello"
%

Doesn't have quite the same curb appeal as the visual version, but it's pretty much the same idea.

Now, imagine that you could query the Second Life object database without having to use the graphical front end.

/* Find me all of the people in SL who knit */
SELECT username
FROM users a
WHERE "knitting" IN a.hobbies;

/* what are the locations of the tallest objects in Second Life */
SELECT x, y, z
FROM SL_object IN
SELECT max(z_top - z_bottom)
FROM SL_object;

Here's another question: what would a search engine spider look like in Second Life? Through the standard interface, there's no such thing as an invisible visitor. It would have to be something like a flying pig that runs a Zamboni pattern around the rink, navigating into structures as necessary to take snapshots of everything it sees. Alternatively, the flying pig could start at known sites and operate by certain heuristics, such as teleporting to each event or following people around. These approaches have obvious limitations compared to the ability to poll the database directly.

Considering these thought experiments, here are the capabilities I'd like to see in Second Life:

1. API to load any Second Life object through a standard Web page (preferably flash).
2. Navigation and content accessible through a text-based, screenreader-enabled interface.
   
3. Browser integration with Second Life worlds
4. Search engine readiness for Second Life worlds
5. Second life visualizations of non-SL activity
6. Versioning of SL objects
7. Runtime, server-side compilation of SL objects based on visitor properties, i.e. PHP for SL
8. Separation of object access from presence
   

Finally, returning to the model of content-structure-style-behavior, we might add a fifth layer: visualization. This would hew to the linked ideas of progressive enhancement and graceful degradation.

We should have a Web where all sites can be viewed as simply structured text; as layout-driven text using CSS; with smoothly-functioning interfaces using JavaScript, AJAX, Flex, or other frameworks; and as a 3-D visualization.

Use case:

1. User conducts a search for "hotels in San Francisco near Moscone Center on 14-18 April"
2. System responds with a list of hotels, addresses and price ranges.
3. User clicks on "view on city map"
4. System spawns SL client with a a map of San Francisco highlighting hotels.
   
5. User does a fly-by, sees that hotel #1 has great views from the 5th floor up, and that hotel #2 would require a walk up a steep hill.
   
6. Back in browser, user clicks on "Show rooms for hotel #1."
7. System refreshes SL client with roofless cutaways of the available rooms, laid out in a row.
8. User flies over each room, decides on one with the ideal configuration, does a brief walkaround, and presses the "make reservation" button.

Much of this should be possible with the recently-announced open-source client for Second Life. We'll see!

Labels: second life, visualization