Google's Lively presents us with an interesting scenario. It was literally a checklist of what critics have been saying that virtual environments such as Linden Lab's Second Life absolutely must have in order to make it.
A simplified user-interface, embedded in the Web-browser, content designed by professionals rather than (mostly) amateurs, a 'room' (or contained space) model rather than a widespread world. While it was touted as having no requirement for a separate downloadable client, that wasn't actually true -- it did actually have one, though it was relatively painless to download and install.
In short, it was the perceived holy grail of virtual environment 'must-haves' for success, as so frequently touted in media articles which lauded its simplicity and accessibility. Also, in short, Lively was a failure -- a spectacular one. Spectacular, but not without educational value.
Backed up by the technological expertise and budgets of Google Inc, bolstered by the press who named it the virtual world that would cast Second Life aside, Lively sank like a stone. Lively didn't even last six months from open beta to closure.
It's closest competitor, IMVU launched public beta in 2004, and broached more than 20 million registered users earlier this year, with approximately 600,000 of those active each month (though like most virtual environments, it isn't really very clear quite what 'active' means -- so active users isn't really a useful statistic for any comparisons).
Lively, for all its promise appears to be the shortest-lived entry thus far in launched commercial virtual environments.
If you dumb something down far enough, very few people will actually want to use it. We're not ragging on Lively here. Instead, we're aiming to learn from its principles and performance. Let's introduce a new principle called necessary complexity.
The idea here is that any interactive system has a certain amount of complexity, usually involving the number and type of tasks which can be performed. Obviously, it is detrimental if the interaction interface is more complicated than it needs to be. That just makes things harder.
What's a little less obvious is that reducing the complexity of the interaction interface too far makes things harder as well. Either it makes it hard to perform the tasks, or it reduces the number of tasks which can be performed.
Reduce the tasks and features of a virtual environment far enough, and you have Flickr -- it's alright, Flickr, we still love you - and so do more than a million other users.
In interacting with the atomic world, you have available one of the most sophisticated interaction interfaces available. It has between 60 trillion and 100 trillion basic components, and over a quadrillion discrete mechanical parts. It's called the human body. It allows you to make coffee, paint a picture, have sex, walk, run, sit, read, write, communicate by voice, dance, sing, fill out insurance forms, build or repair machines or buildings, and more -- though not every one of these options is available in every single model.
Imagine trying to perform some of the same tasks if your interaction interface was limited to a two-button mouse. Or just imagine being Stephen Hawking trying to build a shed or brew a cup of coffee, if that helps. The number of steps he has to perform even to ask someone else to do it for him is enormous, because his interaction interface is so limited.
So, ideally the interaction interface needs to be of an order of complexity that is coupled to the order of complexity of the number and type of possible tasks. If it rises above that or falls below that, performing tasks becomes harder. Performing tasks with an oversimplified interaction-interface is like trying to make coffee with one hand tied behind your back. Overcomplicating it, is like trying to instruct five people to build a shed, when none of you have any language in common. Both tasks can be done, but you'd rather that the circumstances weren't nearly so hard. (In both cases, you will note, we use the prefix over- to indicate 'in an excessive manner', just in case you were in any doubt)
MMOGs learned this lesson, albeit it took a long time and was rather halting and painful. The interaction interface is a good match for the hardware (mouse plus keyboard), and for the number and type of tasks and options available to the user. If you've wondered why most of those interfaces resemble World of Warcraft to some degree, it's less a matter of ripping off Blizzard's UI, and more about the recognition of the utility of the interface.
Non-game virtual-environments, however, have yet to strike that balance between the complexity of the interaction interface and the tasks and options that the interface must enable and provide access to.
We are hopeful that the situation will improve over the next few years, but we certainly expect virtual environment interfaces to swing wildly between overcomplex and oversimplified. With so many options available in popular non-game virtual environments, we're not expecting it to be easy to strike the right balance. After all, if it were, someone already would have done so -- and that hasn't happened yet.
