Applications and Tools, Deep Thoughts, Second Life

Second Life and the User Interface: Toward Strategic Value

The Second Life viewer could be a source of deep strategic value for Linden Lab, but like many of their tentative and opaque attempts at open source, community management and involvement, and Grid improvements it’s instead a floundering off-shoot suffering from a lack of vision and direction.

Now, I come at this from a bias: I’ve spent more time thinking about the User Interface for Second Life and OpenSim than most people – and I’ve long held the opinion that although there’s friction created through the user interface there are far more challenging things that cause attrition in the first hour of a new user: the ineffectiveness of search, the shallowness of Showcase, and now the shifting of tutorials and help off into little buckets on the forums or little neon-lit islands run by our good friend Torley.

In fact, my list of top barriers to Second Life adoption went like this:

1. An unclear value proposition.
2. A poorly constructed outreach effort to both content creators (think gaming platforms and how they outreach to developers) and the casual user.
3. Poor tools for connecting people with people.
4. Coupled with that, a poor registration and orientation experience.
5. And finally, the viewer.

Mismanaged Open Source
But here’s the thing: through the UI contest, I was privileged to witness the talent of the Second Life community. I was able to participate in a process of listening to Residents talk about their own frustrations with the Second Life viewer and saw some pretty brilliant ideas that would both incrementally and, perhaps, transformatively change the viewer for the better.

Rheta’s Transformative Viewer:

However no matter how brilliant the suggestions, even the ‘incremental ones’ (like Jacek’s inventory management system) there is no effective way to work with the Lindens to execute the suggestions.

If there was one positive that came out of the UI contest, aside from the wealth of great ideas, it was in reaction to the Lindens rather than collaboration. While they may have their own plans to redesign the viewer, the reality is that they made a strategic decision some time ago to open source it, but then instead of treating it like an open source project they’ve treated it as a toy given to the user community while they plod along with their own plans.

Now, Jacek and McCabe, two of the contestants, have kicked off their own branch of the open source tree through the “Imprudence Project“. The reason?

The Second Life Viewer suffers from a stifling atmosphere of non-change. This atmosphere emanates from Linden Lab, whose attitudes and policies discourage all but the smallest and most superficial improvements.

In particular, the Imprudence team focuses on three areas in which Linden Lab mismanages the development of the viewer:

* A lack of resources to invest in making significant improvements to the Viewer.
* A burdensome Quality Assurance procedure that punishes any sort of change.
* A vast throng of paying customers who want the Viewer to remain constant and familiar.

This leads to an ineffective viewer, one that includes:

* A cluttered interface that frustrates and confuses both new and long-time users.
* Crude tools that force users into awkward and inefficient workflows.
* Stability and performance problems that make the Viewer unreliable for any real use.

So what happened? In taking the client open source, wasn’t this supposed to be a rich mine of community development and innovation?

My own theory, and it’s just a theory, is that the viewer got stuck in an iterative, incremental trap. The conventional wisdom has become the following: that change and innovation is derived from how the world itself performs and the ability to connect to it rather than the tools used to make that connection.

While Mitch Kapor fiddles around with 3D cameras and residents play around with iPhone clients and light clients it FEELS like there’s innovation on how the world is accessed. But that feeling is based on looking at the viewer as a piece of software rather than a source of strategic innovation.

Agile Software Development and the Viewer:
A Hole in the System

Now, I’m not a software engineer and I don’t really understand the finer points of “waterfall” versus “agile” other than in the broadest terms. But if you want to get insight into the agile software methodology, I’ve found no better source than a presentation put together by Alan Cooper called The Wisdom of Experience. It’s a long one – so grab a coffee and have a read.

With apologies to Alan, I’m going to lift a few of his slides here while avoiding a long dissertation on agile software process. Now, the idea is sound: instead of treating software development as a multi-stage process in which one stage is handed on to the next, it should be treated as deeply collaborative and iterative (check out the 111 slides for a description a little more, um, nuanced).

Carr points out that agile development:

- Is the first indigenous movement among programmers that is about process and people, rather than about tools and techniques.
- Demands involvement by other programmers (pair programming, code review).
- Demands involvement by other non-programmers (users, SMEs, designers).
- Recognizes that programmers can’t do it all by themselves.
- Is refreshingly humble, saying “I don’t know best”.
- Formalizes the fundamental truth that programming is incremental.

And we spot our first problem. If you’re working on an open source client and the reigning attitude is Agile, then first you MUST involve non-programmers, and you WILL buy into the notion that programming is incremental.

Now again, I’m not a software expert, so let’s buy in for a second to Agile, what do I know, sounds OK to me. But I’m struck by the following slide (click to enlarge):

Because what this slide is telling us is that of the four stages of development, the middle two are the ones that benefit most from Agile development. Carr describes the OUTER stages as “fragile”:

“And the two outer stages are the fragile stages. The first is utterly unpredictable and magical. It can come from anyone, anywhere, at any time. You cannot really seek it out, but only cherish it when it happens.

The last stage is fragile because it is so big, so lengthy, so delicate, so difficult, and so critical to the success of the whole, that disturbing it in any way is foolishly, hellishly expensive.

In these two stages, there is simply no advantage to putting lots of people in a room together to work openly and collaboratively, regardless of how intelligent or well-intentioned they are. The construction stage in particular demands quiet, uninterrupted, solitude: programming time.

As you can clearly see, each stage is different, and each stage requires different skills, tools, and temperament.”

And what I THINK is that Linden Lab has abandoned the first stage in the belief that it’s the server code and “world” from which it derives strategic value, and that the last stage has been partly pawned off on the “open source community” and has partly become an offshoot of development changes required by changes to the server.

Let me put this another way: Linden Lab treats the viewer, because it has been open sourced, as an offshoot of the development of the server code rather than as a source of deep strategic insight and value. As such, changes to the viewer ITSELF, when not dictated by change to the server code, is incremental and iterative with shoddy work flow and poor quality assurance mechanisms.

I propose that the viewer itself is an under-recognized source of strategic value.

Measuring User Experiences
Linden Lab has not communicated a clear road map for the SL viewer. They SAY there’s a road map – it’s coming. And they SAY they do constant tests and collect data, we just don’t know what it is. Their recent A/B test of Help Island came under criticism, but regardless, there are no other A/B tests currently in the works.

Carr points out that interaction design is a critical piece of Agile development, and that user and stakeholder research is a key component to design:

“This work consists of observing and interviewing users and other stakeholders, then transforming this raw data into useful narrative design tools.”

Now, one of the things I thought the UI contest could contribute was, in a sense, narrative design tools. They were exercises by REAL users and their designs, their ideas, were as much a narrative about what DOESN’T work as to how to make it better. The contribution of these designs was to a deeper understanding of the user narrative.

And yet – well, two things: one, there is no way to cross-tabulate these narratives to user observations and studies, and two, if the Lab derived any value from the competition they’re not telling anyone.

And maybe I’m being snarky, but it strikes me that after having the entries presented to a handful of Lindens at office hours they might have said, well….one, they might have said thank you. Or two, they might have said “this is useful to us BECAUSE.” Instead, like much of how they operate, it was like they existed in a cone of silence.

But that’s a digression. Because what’s clear from Carr’s comment on user narratives is that for an open source project like the viewer to work, and in order to deploy agile development to changing it, the people doing the work (which includes the Resident community) need DATA.

What the Lab needs to do is either share that data with the folks willing to contribute to the open source development or STOP calling it either open source or agile.

Connect the World is NOT a Big Idea

The Lab’s mission is to connect everyone to a virtual world (and some other blah blah stuff). As such, they focus on standards through interoperability with openSim, improving the world itself (through things like Havok and Mono), and worrying about asset servers the best they can and who will manage your identity.

But it’s NOT a Big Idea in Carr’s model. A Big Idea includes “correctness” (why does connecting everyone matter?) and Insight (What’s the killer insight that drives the purpose?)

In the shift from being a platform to being a services company, the Lab released a key component that will facilitate this to the open source community and has deprived itself of strategic value.

Now, I say this not because I think the viewer shouldn’t be open source, I say it because I believe that their attitude has been that the viewer is an appliance – and as an appliance, they treat the community that wants to develop it with something close to disdain.

Mozilla as a Model?
With Mitch Kapor whispering in Philip Rosedale’s ear and Mark Kingdon focused on broadening the experience of Second Life for a wider audience, it occurred to me that perhaps Mozilla holds hints of how something like this should be managed. Over at Mozilla, they’ve been crowd-sourcing ideas, much like what we tried to accomplish with the UI contest. Have a look at what Adaptive Path put together to facilitate brainstorming for future versions of the Firefox browser (Adaptive Path has previously worked with Linden Lab on usability design for the client. Whether they still do I’m not sure):


Aurora (Part 1) from Adaptive Path on Vimeo.

Mozilla, rather than treating the browser as an appliance to connect to the Internet, treats it as a source of value for the Net itself. And let me give one example: Mozilla Weave, which has been developed against the following Big Idea:

“As the Web continues to evolve and more of our lives move online, we believe that Web browsers like Firefox can and should do more to broker rich experiences while increasing user control over their data and personal information.”

That’s a Big Idea – the kind of thing that drives Agile development in Carr’s model of four stages. And it’s the kind of ‘mission’ with the right attitude and tools that can charge an open source effort:

“This project will be known as Weave and it will focus on finding ways to enhance the Firefox user experience, increase user control over personal information, and provide new opportunities for developers to build innovative online experiences.

Just like Mozilla enables massive innovation by making Firefox open on many levels, we will aim to do the same with Weave by developing an open extensible framework for services integration.”

And the Big Idea is supported by a top-level Design and is further supported by Use Cases (something the Lab seems to go on about at some length but NEVER SHARE) and a Road Map.

A Road Map for the Second Life Viewer
Imprudence will try to right some wrongs. Help them, contribute, join the initiative, there’s lots of ways to help.

But I’m also going to lay some responsibility at the feet of the Lindens. Their response to the UI contest was consistent with their approach to most user contributions: muted, tentative, ungrateful, and lacking specific feedback in a way that would allow the user community to join in the Agile “collaboration”.

I’ll leave my thoughts on why I think there’s deep strategic value in the client for another post. But regardless what I think, the execution of that value in the open source ’stream’ of the viewer will never be derived without:

* A decision as to whether the viewer is truly “open source” or whether the Lab will continue to keep it partly closed and proprietary by making it an offshoot of server development rather than its own value stream
* Sharing current usability data, use cases and design narratives
* Facilitating or properly contributing to an effective articulation of the insight or idea for what the viewer can accomplish (even if the “big idea” is “connect without crashing” then at least it’s an IDEA)
* Development or release of a road map

* Improvement of the construction and quality assurance process flow.

If the Lab is doing all of this, but doing it internally, then they owe transparency to the community, to the Residents who are working hard and putting their heart and passion into improving the Second Life experience.

The User Interface, the Second Life client, has become an orphan – it has its cute moments, we’ve come to adore it (even when we want to wipe its nose), but no one will adopt it as its own, including the Lab who see it (as far as we know) as a source of incremental improvements around which a loose confederation of coders orbit, never quite taking it by the hand to take it home.

4 Comments

speak up

Add your comment below, or trackback from your own site.

Subscribe to these comments.

*Required Fields

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.