MetaPundit

Leslie: A Rough Sketch of a Useful, Evolved LSL

Tue, 19 Mar 2013 13:28:06 -0400

LSL/OSSL were and are responsible for imparting a great deal of the interaction magic which has made SL and Opensim be what they are today. However, the language (they really are the same, just with a few different command sets) is hobbled in a few ways which really prevent it from moving past the stage of a toy language and into the realm of a useful language which could be used to develop serious functionality.

Additionally, the current way LSL/OSSL is structured, it is strictly bound to platforms very much like SL/Opensim, meaning that there is a catch-22 of adoption. Fewer users mean fewer scripters which means fewer things done with the language that inspire new users to join.

As I shift my focus to OHM (which will also need a scripting language), I’ve been designing a new hypothetical scripting language based very heavily on LSL that solves some of these problems and a few more. I’m calling it Leslie (LSL-Evolved).

Here’s how Leslie differs from LSL:

All platform-specific commands are stripped from the command set. Leslie doesn’t implicitly know about or care about regions, agents, etc. This not only makes Leslie easier to learn, it makes it far more portable to other contexts.
The addition of a command module add-in system and commands to detect the presence of modules. Platform-specific functionality can be mixed back into scripts through this feature, as well as novel functionality provided by other modules.
Commands to handle the execution of the script, such as the ability to kill the script, or start another script included in the object. The Leslie model does not assume that all scripts are automatically running, and these commands allow for a much more intelligent use of system resources, provides for compartmentalized code and adaptive behavior based on modules present in the environment.
Boolean variable type to replace the cute but ultimately badly designed use of the integer type for boolean operations.
An external template-based structured data-type similar to flat JSON. This frees programmers from having to rely on strided lists for any kind of complex data representation. It also allows Leslie to have struct-like data but without resorting to dot notation and maintains the asynchronous data and event model LSL already has.

These differences are designed to make Leslie portable, expressive, and useful to professional programmers while retaining much of what makes LSL already work. The result for environments like SL/OS would be increased functionality, better memory footprint, and utilizations of the platform which simply haven’t been feasible up to this point. I plan on documenting Leslie more in the future, especially the struct model which requires more explanation. This is by no means a finalized design, and I would love feedback from the community on Leslie.

The Point of OHM

Sun, 24 Feb 2013 01:55:22 -0500

As I work on designing the specifications for OHM, I can’t help but think that many would ask me what point I saw in such an undertaking. It’s an excellent question, and one which I struggled with for some time. Indeed, it was one of the main questions holding me back from embarking on the endeavor.

The point of OHM is mostly this: The world sorely needs the collaborative social benefits that a fully realized Metaverse could bring, but it hasn’t received such a Metaverse yet for a host of reasons:

Most Metaverse implementations currently are too inflexible to be useful beyond a certain small range of uses.
Building/Deploying a virtual world platform is still a massive undertaking, so most who do end up focusing on implementations and deployments designed to make money to recoup the costs of the effort. This generally leads to closed systems.
There is very little effort being expended on building a set of shared protocols for a Web-Scale Metaverse. Such protocols would lay the foundation for true interoperability.
The repeated media hype cycles focusing on various implementations have drained a large degree of the general public’s enthusiasm for the Metaverse. Breakthrough usefulness will be crucial to countering the public’s well-earned skepticism.

I feel that the point of OHM is to address these problems head on. OHM is designed to be flexible to be used in a very wide range of ways. It is designed to have minimal startup costs, allowing for a more open ecosystem of implementations and deployments. OHM is also fundamentally a set of shared protocols and specifications much in the same way the Internet is. This gives developers a shared set of blueprints from which to work and reduces the amount of wheel-reinvention necessary. Finally, OHM is designed to quickly evolve to hone in on what is useful to users, allowing for the conversation on the Metaverse to begin afresh.

This is not a small undertaking and I recognize there is a very strong possibility of failure. However, I believe we have only barely glimpsed at the transformative potential of the Metaverse, and I gladly vest myself in this effort to deliver that potential.

Beyond Virtual Feudalism

Sun, 24 Feb 2013 01:17:31 -0500

Right now, the Social Internet (of which I will include the Metaverse for brevity) exists in a state of virtual feudalism. We as users inhabit kingdoms of proprietary service ruled over by rulers of largely unchallengeable authority. Through our participation in these services, we create value for the kingdom, but rarely if ever does that value move anywhere but to the lords of the land. While these kingdoms rise and fall, rarely do those but the lords of the land wield any true power.

These kingdoms are sometimes not absolute in their insularity and may in fact allow their subjects to interact with those from other kingdoms. However this is allowed only so long as the keepers of the kingdom deem it beneficial to the might of the kingdom.

This mentality of kingdom-first preempts even our fundamental rights as humans (to privacy, freedom of speech, etc). Dictates may be passed down without notice, and forces brought to bear without recourse.

To say this is the natural way of things or that the Social Internet mandates such authoritarianism is absurd. Our rights do not end where our fingers touch the mouse, keyboard, or touchscreen. There is no natural order which mandates that such monolithic empires of services are the only way.

We are in need of a Renaissance. We need services which start with an absolute guarantee of individual sovereignty and which build from their to form larger woven patterns of association. Efforts such as Diaspora* are a good start, but are only just that: a start.

This position is not a new or singular one. The technology to deliver us from virtual serfdom already exist. The tools are in hand. We must now use them to craft a better future Of the Users, By the Users, and For the Users.

Working on OHM protocol stuff, feeling pretty decent about the...

Sat, 23 Feb 2013 17:38:11 -0500

Working on OHM protocol stuff, feeling pretty decent about the progress.

Open Protocols as Literacy

Fri, 15 Feb 2013 13:46:11 -0500

Open protocols are important for the same reason literacy is important.

When literacy in a language is low, the conversation can only occur between a very limited set of individuals and the discussion tends to stagnate. The language also becomes stiff and difficult for an outsider to learn. Conversely, when literacy is high, the discussion retains its dynamism and the language remains approachable.

Open protocols provide a down-payment on the literacy of developers to be able to collaborate on large complex software systems, such as those found in the Metaverse space. To my mind, the Metaverse space has largely been suffering from a literacy issue. This is one of the reasons why I am focusing first and foremost on protocols as I design OHM.

Gabe Newell gets the future of the Metaverse. Gabe’s talk,...

Fri, 08 Feb 2013 10:33:28 -0500

Gabe Newell gets the future of the Metaverse.

Gabe’s talk, while undeniably rooted in Valve’s investment in Steam, hits on several key realizations that I believe are very much relevant to the future of the Metaverse:

Players are also creators and should be rewarded for their creations
Games and Applications are fundamentally the same, and must migrate into a connected ecosystem
An open system is better for innovation than a closed, curated one.
It’s better to push functionality out to the edges of a network, smart clients are better than thin cloud streaming services at scale.

There are other, far more nuanced points he makes in the talk, which is why it’s worth truly listening to. Too many accounts of the talk focus on his tangential plug for Linux, which while welcome and important, completely misses the philosophical thrust of his speech.

Personally, I find myself emboldened by Gabe’s speech, as it reenforces several key assumptions and opinions I have been using while designing OHM.

The OHM Protocol Design Blog

Thu, 24 Jan 2013 08:36:59 -0500

The OHM Protocol Design Blog:

This is the blog where I’ll be crunching over the various aspects of OHM as I work on generating initial draft specifications of the protocol(s).

Dear Opensim, It's not you, it's Me(taverse Protocols)

Wed, 23 Jan 2013 21:54:58 -0500

Dear Opensim,

It’s time we sat down and had a talk. I’ve been putting off telling you this because I didn’t want to hurt you, but I can’t keep hiding this from you. The truth is that I’ve found someone new and we’ve been very involved for some time now. It’s name is OHM, and it’s a set of open protocols for building a web-scale Metaverse. We’ve been together for several years, and things are starting to get serious.

Now please don’t blame yourself, you’ve been wonderful and the things you do make you special, never doubt that. The fire’s gone out on my end of the relationship because I’m just not the kind of guy who can settle down with just one virtual world implementation, even a special one like you. I need more freedom to evolve and grow than you can offer Opensim, and if I stay I’ll only get pent up and frustrated. You don’t deserve that, and I don’t think its good for me either.

Even though I need to move on, I’d still very much like to remain friends. After all, it’s not that I don’t like you, it’s just that I can’t keep pretending that I’m faithful to you. I hope you’ll come visit some day, I think you’ll really like OHM once you get to know it.

Take care of yourself Opensim, after all there’s no one else in the world quite like you.

I Don't Want To Be Part of Your Fucking Ecosystem

Fri, 30 Nov 2012 17:26:17 -0500

I Don't Want To Be Part of Your Fucking Ecosystem:

An excellent article with a message which definitely applies to the Metaverse space as well.

Tami Baribeau: What Captivates Me About Second Life

Mon, 05 Nov 2012 22:19:34 -0500

Tami Baribeau: What Captivates Me About Second Life:

Sharing this lovely piece by Tami Baribaeu because it does a wonderful concise job capturing why I personally love virtual worlds and one of the many reasons I’m such an advocate of Opensim

cuppyinsl:

I’m not an expert on Second Life, far from it in fact. Excluding yesterday, it’s been over a year since I have logged in to explore it. Every time I return I ask myself why I waited so long, because I always enjoy my time I spend in the world. Perhaps a bit too much and my self-preservation kicks…

OHM - Beyond the HyperGrid

Sun, 14 Oct 2012 21:25:51 -0400

Up until now I and most others have awkwardly used the terms HyperGrid and (Open) Metaverse interchangeably as though they were the same thing. The more I think on this, the more I am convinced this is short-sighted and only serves to confuse things.

The HyperGrid is not the entirety of the Metaverse and shouldn’t be. It’s tempting to think of it as such, but ultimately, the HyperGrid is just a Opensim-centric prototype of what should be a larger vision.

There are and will be other platforms which provide equally compelling solutions to the challenges of the Metaverse. The end goal must be to create a seamless open system in which a Metaverse user can interact with and move between a wide variety of these platforms.

It is with this in mind that I propose a new term to describe such a system:

Open Hyperlinked Metaverse (“OHM”)

OHM makes no suppositions about whether the worlds linked together are Opensim, Aurorasim, RealXtend, or Wonderland. It assumes only that it is an open network of virtual worlds which allow travel between each other much like the HyperGrid allows travel between compatible worlds today. Indeed, OHM may end up as an advanced version of the HyperGrid protocol, evolved to expand it’s assumptions to facilitate a wider variety of worlds.

The name OHM also has some nice features:

It’s a lot less clumsy/wonkish to say than “HyperGrid” or “Metaverse”.
Ohm is a measurement of resistance, to remind us to favor the Path of Most Resistance
Also having to do with resistance, it reminds us we are building the Open Metaverse in direct opposition to the walled gardens from which the effort first arose.
The sound of OHM has strong ties to the concepts of unity and transcendence found in Buddhism and Hinduism which reflect the ideals of a fully fledged Metaverse.

The features of the name not only make it easier to talk about such a big, complex topic, but also speak to the larger vision and causes that we are aspiring towards.

I would love to hear your feedback!

The Path of Most Resistance

Sun, 14 Oct 2012 17:54:00 -0400

The path of least resistance is tempting, seductive even. It lulls us into doing the bare minimum and following the easiest path. It doesn’t ask much anything of us, it’s comforting, predictable, and seemingly safe. That path is not the path the Metaverse should take, because it’s a long gentle path into oblivion. We need to take the other path, the one that’s nearly a sheer cliff and has no clear markings. We need to take the Path of Most Resistance.

The Path of Most Resistance means asking ourselves the tough questions about what’s not working with the way things currently are and then fixing the problems. It means keeping a strong spirit of imprudence and scepticism, challenging what we think we know from what we can actually prove to be so. Sometimes it means rebuilding something from the ground up because we just can’t keep slapping patches on the old version. It means trying things that we know may not work.

Let’s not kid ourselves, it’s the route that most people avoid and will go out of their way to tell us to avoid as well. It is also a path which will be hard, confusing, and sometimes even scary. But the destination at the end of the Path of Most Resistance is worth the struggle, the risk, and the uncertainty. The destination is the fulfilment of seemingly impossible dreams and the utter reshaping of the world around us.

We can follow the Path of Least Resistance and let the dream of a Metaverse fade into the night, or we can choose the Path of Most Resistance and usher in a new dawn.

Announcing GridHelp!

Mon, 17 Sep 2012 01:15:01 -0400

Right now, getting help with things related to Opensim is a bit confusing and scary for new users. Because Opensim is so new, there’s a lot of possibilities for things to go right and even more for them to go horribly wrong. There are a lot of good resources for Opensim, but no easy place to find them. New users who don’t know a region from a viewer are the ones who need the most help, but have the least idea where to go to get that help.

I’ve started a new website called GridHelp! to try and make that better.

Here’s the three things GridHelp is going to provide:

A Q&A service that lets users post a question and solicit answers from the community
A Knowledge-base wiki filled with fleshed out solutions to common problems and resources throughout the community
Tutorials and FAQ articles written in plain English for normal people

GridHelp still very much under construction, but it’s up and running and ready for action. You can follow GridHelp on Twitter for updates and to ask questions. To ask a question from Twitter, just send a tweet to @GridHelp use the hashtag #needHelp.

Introducing PubSubmarine

Sat, 15 Sep 2012 16:17:13 -0400

If you’re like me you like the idea of making big, complex things in Opensim. You’re probably also frustrated that there’s really no good way to pass messages back and forth securely between objects. What should be a simple procedure suddenly turns into a horrendous tarball trying to work around the limitations of Opensim’s messaging model. This shouldn’t be the kind of thing getting in the way of creators with big dreams. I decided to try and fix all that.

Building big things in Opensim shouldn’t make you want to pull out your hair.

(Image by music2work2 on flickr)

It’s my pleasure to introduce PubSubmarine, a simple secure script messaging system.

PubSubmarine is a region module that makes it easier for objects to create,share,and use secure communication channels called Topics. It does this by adding a few more custom commands to the scripting language that let script writers quickly and easily tap into PubSubmarine’s power. Like the name hints, PubSubmarine follows the Publisher/Subscriber model, meaning that many scripts can subscribe to a topic channel and all get the same messages. It also means that neither the broadcasting scripts or the subscribing scripts need to know the identity of any other script.

One of PubSubmarine’s main priorities is security, and therefore it’s been built so that only the scripts with the right authentication can access the topics. Authentication is split up between publishing and subscribing, meaning you can decide who can broadcast and who should just listen. Unlike chat channels, PubSubmarine passes messages to subscribers anywhere in the region regardless of distance. It uses the link_message event to pass messages, meaning messages are efficiently delivered and only to the intended recipients.

How easy is PubSubmarine to use? Well, here’s a simple script that makes a new secure topic and publishes “Hello World!” to that topic every time it’s touched:

string masterKey;
default
{
    state_entry()
    {
        masterKey = psMakeTopic(“MyTopic”,”theSubKey”,”thePubKey”);
    }
    touch_start(integer touches)
    {
        psPublish(“Hello World!”,”MyTopic”,”thePubKey”);
    }
}

That’s it.
Here’s a companion script that subscribes to the same topic and says the message out loud:

default
{
    state_entry()
    {
        psSubscribe(“MyTopic”,”theSubKey”);
    }
    link_message(integer source,integer channel,string message,key topic)
    {
        if(topic == “MyTopic”)
        {
            llSay(0,message);
        }
    }
}

It’s that easy.

PubSubmarine is still not quite ready for release, I’ve got a few things I need to polish before it’s ready for prime-time. For instance, the recent release of Opensim 0.74 means I need to add the actual commands shown above instead of using the horrible clunky modSendCommand() method. I’ll be keeping you up to date with it’s progress. In addition, I’ll be posting up some more in-depth documentation on how it works.

This article just barely scratches the surface of what PubSubmarine is capable of, and I can’t wait to see how others will put it to use. Let me know in the comments how you think you’d use it, or how I can shape it to make it even better!

Writer’s note: Apologies for being silent as of late. While I hope to eventually be able to turn my full energies toward the Metaverse, I am currently at the mercy of a new schedule which leaves me on a fraction of the day to focus on much outside of work and family. Watch this blog and my twitter account for updates as I shift things around.

About Feedback

Fri, 17 Aug 2012 21:30:52 -0400

“Let me never fall into the vulgar mistake of dreaming that I am persecuted whenever I am contradicted.” -Ralph Waldo Emerson

Thank you to everyone who helps to turn my occasionally unhinged diatribes into serious discussion. Thank you for sharing your insight and your honest opinions, they are more valuable than a million ass-pats.

Five Reasons for Smaller Regions

Fri, 10 Aug 2012 14:55:00 -0400

I’m going to propose something heretical: Rather than focusing on making mega-regions, we should be focusing on making smaller ones. Specifically, regions with a quarter of the footprint of what is the current standard.

Why? Funny you should ask.

Quick note/disclaimer: These are largely the result of study/research from a moderate distance from the actual nuts-and-bolts, so many of these points may have issues with them. If you think I’ve gotten something wrong, feel free to join the conversation in the comments and point out where I’ve gone awry.

Reason #1: Regular-sized regions are too much for small projects

The open Metaverse is (for now) largely composed of driven individuals creating small projects for themselves. 256m x 256 m is too much room for most of those projects. Dropping the size of regions will help greatly to combat the dreaded sprawl-bloat of mostly-empty regions which plagues grids everywhere.

Reason #2: Quarter-sized regions = 4x the population density

Note: There’s some contention over this, check out the comments.

A common gripe about OpenSim is the fact that you can only fit around 20 people to a server before it gets unstable and crash-prone. By making regions which are 128X128, those server resources are in effect quadrupled, allowing more users to occupy the same land footprint. This is critical for pushing the social aspects of OpenSim, which in turn is critical for the long-term adoption of the open Metaverse.

Reason #3: Smaller regions are better for web and mobile

OpenSim, in it’s current incarnation, is incredibly punishing for even well-provisioned gaming computers. If the open Metaverse is going to expand out to the web via WebGL and to mobile devices, it needs to go on a serious computational-resource diet. One good way to start is to chop down the size of the regions. Generally speaking, smaller regions will contain less things for a mobile or web viewer to draw, making them far more manageable.

Reason #4: It forces us to deal with region crossings

One reason we have gravitated toward mega-regions is that we hate the horrible, unreliable experience of region crossings, especially for anything involving vehicles or complex scripted objects. Mega-regions are a way for us to avoid dealing with that problem. Avoidance is bad when it comes to critical technical challenges like this. Smaller regions give us an intervention and force us to face the challenges head-on. Whatever the end solution may be, it’s one we can avoid for only so long before, like an overdue bill, it bites us suddenly and painfully in the posterior.

Reason #5: The size of a region is completely arbitrary

There is literally no technical or practical reason why regions have to be the size that they are. The only reason they are the size they are is that regions are 256m x 256m is that was the size that Linden Labs decided (quite arbitrarily) was the right size. It played well into their model of sub-parceling regions for rent or sale. That model worked for them, but Opensim is a completely different beast subject to completely different economics. When anyone can run their own region for free, there’s a lot less demand to rent a fraction of that region from the owner. The region size could be anything, the only limits are the performance of the server running it and the load being placed upon it.

So, let’s recap: Smaller regions can make the Metaverse more social, more populous, more mobile/web friendly, less sprawl-tastic, more seamless, and do away with a outdated arbitrary convention put in place for reasons that have no bearing on the current realities of and open Metaverse.

What say you?

The Trunk Test for Grids and Regions

Mon, 06 Aug 2012 23:26:38 -0400

This post is part of a continuing series taking the seminal web design book “Don’t Make Me Think!” by Steve Krug and applying the lessons to the design of virtual environments (with a focus on the Opensim platform)

Now that we’ve gone over how to treat the design of a Landing Zone like the design of a website’s home-page, let’s go over what happens when the user doesn’t arrive through the front door. Like with a website, it is possible and indeed common for users to arrive in a region or grid in a place aside from the landing zone. Generally speaking we’d all like users to arrive through the landing zone, but often we have very little say in the matter. So how do we ensure that users aren’t disoriented or lost and can can quickly find what it is they’re looking for? On a web page, we have a navigation bar which contains strategically selected links to other pages. In a virtual environment we generally don’t have that option. Instead we need to opt for a more concrete metaphor for navigation, which in many cases is a healthy dosage of good old paths and signs.

But how do we make sure that we’re ensuring that the signs and paths are doing their job? Krug has a test for questions like this called the Trunk Test. In the Trunk Test, the user is blindfolded, locked in the trunk of the car, driven around for a while, and then dumped on a page in the bowels of a web site*. If the site is well designed, the user should be able to quickly get answers to these questions:

What site is this?
What page am I on?
What are the major sections of this site?
What are my options at this level (within the site)?
Where am I in the scheme of things?
How can I search?

With the possible exception of the last question, all of the answers for these questions can be designed into a environment. The use of themeing and well integrated signage that shows the user where they are and where they can go next are the key to making it obvious to the user where they are and where they can go from there. Paths and signs do not necessarily need to be utterly blatant or disruptive to the experience. Indeed, they should be as unobtrusive as possible. For instance, many paths can be handled by way of visual cues (like cobblestones) suggesting a path rather than a cattle-chute which makes the user feel locked into the path. Likewise signs can and should be integrated into the surrounding environment, present, findable, and readable when the user is looking for them but not dominating the experience.

This being said, there are times when you do want a cattle-chute and you do need big freaking signs. Use your judgement to determine when the right time is for that and what level of obtrusiveness matches the needs of your experience. If you absolutely need users to go from one point to another in order without deviation, or absolutely need to force them to make a Path A or Path B decision, then you probably need to be more obtrusive. Users are fine with strong cues and forceful guidance as long as they feel it’s justified. Put yourself in user’s shoes and think about how they’ll perceive it. Better yet, get some people to test it out and find out directly from the horse’s mouth.

In regards to the last question, this is an area where there is a need for a technical solution that to my knowledge doesn’t exist yet. The ability to be able to search for things in a environment using a search bar is something which would allow users to quickly narrow in on what they’re looking for rather than stumbling around growing progressively more frustrated. I have some ideas for how something like this might work which I hope to share soon. Until we have a system that does this, we can make do with a signs that allow the user to teleport directly to their destination. This at the very least allows users quickly searching for specific things to narrow in on what is hopefully the right area to look for them in.

*Krug uses this metaphor top point out that the web experience is very much like this, where the browser will whisk the user away to a destination in parts unknown. The Opensim experience is much the same way.

A Foundation for the Future

Sun, 05 Aug 2012 14:25:17 -0400

Continuing along with my earlier post about the need for a new baseline viewer, I felt it would be a good idea to list out some of the key goals (as I see them, feel free to add your own):

We need a viewer…

That’s easier to use
Tailored to the realities of an open Metaverse
With a license which is compatible with that of Opensim (i.e. not a viral GPL license)
That allows the experience to be taken to other, non-desktop platforms
That allows developers to focus on pushing the boundaries of what’s possible, not forcing them to polish existing features
Allows for rapid evolution of what the Metaverse experience can be
That makes developers and users’ lives easier
That makes it easier for non-programmers to participate in the development process

Like I mentioned in the earlier post, I think I’ve found a good fit. It’s a young, actively developed game engine that uses the MIT license. It’s powerful and flexible (capable of running on android and iOS along with the Big Three desktop OS’s), and the brainchild of one of the developers of the RealXtend platform*.

I’d like to introduce you to Urho3d (Hero for those who aren’t up to speed on their Finnish).

The page doesn’t do a particularly good job selling it’s potential, especially to those without a technical background (a tragic commonality among young, promising open source projects). In summary for those who don’t want to wade through the details, Urho3d is already incredibly well-featured, with many of the features already present in current viewers. In addition to those features, Urho3d has some which have been on the wish-list of many Opensim users for some time, including AngelScript and client-side physics (courtesy of the Bullet physics engine, includes ragdoll!).

I’ve taken the liberty of making some screenshots of the very simple demo scenes included with the engine to give you a flavor of it’s capabilities, even at this early state.

I believe very strongly that if a group of developers from both the viewer and server community collaborated on crafting a viewer out of Urho3d, the Opensim ecosystem would be well on the way to breaking the shackles of the past which currently hog-tie it. There are of course some hurdles that would need to be cleared to make Urho3d compatible, but those are for a more technical discussion elsewhere.

We need a new baseline viewer if we’re going to seriously champion Opensim as the path to a fully realized open Metaverse. Without a strong foundation to build upon, the effort will be perpetually crippled. Urho3d fits the ticket and would prevent us from having to start from scratch. To me, that sounds like a win-win scenario.

*RealXtend, for those unaware, is a virtual world platform which initially started out as a fork off of Opensim. Their platform offers radically more flexibility, but as of right now lacks any method for linking worlds together into a network.

The Landing Zone as Your Home Page

Sat, 04 Aug 2012 11:02:35 -0400

As promised, I’m starting a series of posts taking some of the excellent lessons in “Don’t Make Me Think!” by Steve Krug and exploring how they relate to the Metaverse. Up first on the roster is appropriately about first impressions. The home page of a website is a critical piece of the site’s experience. In many ways it acts as the backbone upon which all of the other pages in the site are built. Because of it’s importance, and the tendency for home pages to become cluttered messes, Krug points out that they need to serve one core need: conveying the big picture. To this end, he counsels that at a glance, a good home page needs to quickly answer four questions:

What is this?
What can I do here?
What do they have here?
Why should I be here (and not somewhere else)?

I feel like there is a strong equivalent relationship between a web site’s home page and a region’s landing zone, the place in the environment where a user first rezzes upon arriving. In specific, the area of the landing area within the immediate field of view of the user is very much like a home page. Well designed landing regions make it very easy to quickly find answers to the four questions. Bad landing zones immediately make the user feel lost, confused, or disoriented, three emotions you generally want to go out of your way to prevent your users from feeling. Lost, confused, disoriented users quickly either become frustrated users or defeated, log-off-and-wonder-why-they-even-tried users. If your landing area leaves users scratching their heads, you’re probably blowing a good deal of your chances to show them later why they should give a damn about the region you’ve built.

So how can you make a good landing zone? I have a few suggestions (feel free to add your own in the comments):

Figure out what direction your users are most likely going to rez in facing. Focus on using the area they’re facing to present your regions’ case.
Use simple, easy to read signs that match the flavor of your region/experience that quickly help answer the four questions.
Make it clear where the user can/should go next. It’s your job to shepard them out into the wider experience.
Make sure the assets in your landing zone load fast and reliably, otherwise you’ve defeated teh purpose of the landing zone altogether.
Use the PRFCT model to guide your answers for the four questions. You’ve managed to get the user to your region, make sure they get to see why they should stick around.

For the next DMMT post, I’ll be go over what Krug has to say about what to do when a user doesn’t come in through the front door and how to design a region to make sure a user gets clued in quickly.

The End of the Beginning

Fri, 03 Aug 2012 16:17:17 -0400

Earlier this afternoon, Nebadon (the current head of OSGrid) posted some rather significant news.

Linden Labs has removed the ability for Opensim to peacefully coexist with Second Life. They do not intend on fixing this breakage, for reasons allegedly due to their aggressive march toward the use of the proprietary Havok physics engine. They are severing the proverbial umbilical cord.

To some, this may be seen as a time to fret, I say otherwise. For some time, the open Metaverse has been held back by the close bonds between Second Life and Opensim. Features and improvements that could be implemented have been sidelined or shelved because it would break compatibility with Second Life. Opensim developers have also had to develop on a proverbial treadmill, always responding to implement a feature released by Linden Labs to maintain compatibility. No longer. If Second Life is truly closing the door, then we are free to walk our on path, to craft a fully realized Metaverse. Maybe one day Second Life will reopen its doors to the Metaverse, but it is my hope that when it does it will be as a equal participant in a vibrant and thriving network of worlds.

We knew this day would eventually come, perhaps a little further down the road than today, but we have known that eventually the vision of the open Metaverse would outgrow the limited ambitions of Linden Labs.

It’s the end of the beginning, and the promise of the future is bright. Don’t forget your sunglasses.