Creating a great viewer may not be a democratic process, but it can be a transparent one. Or that’s the perspective of the Snowstorm team whose goal is to turn Second Life Viewer 2.0 into the gold standard for accessing the virtual world.

I had a chance to sit down with Q and Esbee Linden today to ask how things were going since Snowstorm was launched at the Second Life Community Convention a few weeks ago, and I came away with a greater sense and assurance that they’ll deliver a better viewer, and that they’re going to try really really hard to do it in a way that users feel their perspectives are accounted for and that they are listened to.

Now, with all the talk of scandals lately about viewers I’ve been quietly committing one of my own: because I’ve actually started using Viewer 2.0.

After my initial test drive when the viewer was launched I quickly abandoned it. There were features that appealed to me, I was initially convinced that it could ease new users into Second Life, but it was, well, scandalously not yet ready for prime time, something only visible after, um, trying to DO very much with it.

But over the past few weeks I’ve started using it regularly, primarily because my customers do and because Second Life Shared Media (SLSM) has become a required component of most of our projects.

So while I was using 2.0 in a sort of “well, I guess I better” frame of mind and that truly, really, I mean it when I say it was SLSM that forced me to do so, I find myself actually starting to like the damned thing (especially with the latest release).

2.0 Dysfunction
Now, don’t get me wrong. There are STILL some things that are scandalously wrong with it (ignoring other things like search, which is separate from the function of the viewer itself). They are the sorts of things that, well, totally baffle me. I mean, how did the Viewer get to the point in the first place where there are mountains between you and trying to get something simple done?

For example, the fact that the Viewer closes an active search is, well, hideously wrong on so many levels.

Say you’re renting land: you open search, you input your price or region size parameters, you click on the first parcel that you may be interested in renting, you arrive, you decide it’s not for you and….and you need to start ALL OVER AGAIN. The search window is gone, your search criteria is lost.

Now, maybe there’s some setting somewhere, or some logic as to why this is. But I went to rent a plot of land and gave up, logged into the old viewer, and did it through that.

But that’s my little footnote: I’m starting to like Viewer 2.0, my customers like it (and training them on it is definitely simpler), even though there are some things that drive me round the bend.

What’s Next
Is there hope, however, that these kinds of things can be fixed with the launch of Snowstorm? Doesn’t it take insight into what users actually do if you’re going to make the experience ‘fast, easy and fun’? Those are some of the questions I put to Esbee and Q Linden earlier today.

By bringing all of Linden Lab’s viewer development into one initiative (the open source Snowglobe project and the ‘main’ viewer were previously separate things) and deploying a Scrum methodology, the Lab is putting all of its eggs in one basket, as Q said.

The interview covered a lot of ground. I suppose of particular note (to me, anyways) was the commitment to testing the Viewer on low-end machines that are below the system requirements for Second Life, and clarification of the process by which users can contribute their ideas and insights into improving the viewer.

My interview with the Snowstorm team took place, um, here.

Dusan Writer: One of the complaints about Viewer 2 is that it often seems like it was created without a lot of knowledge of how users actually interact in Second Life. How do you respond to that, and how will the Snowstorm team make sure that it’s relevant to, well, actual users?

Esbee Linden: As you know, prior to Snowstorm, we went about a lot of our user studies in a different way during the initial development of the viewer. A lot was done up front, and as you know we were working with an outside firm as well to map out user scenarios.

During that process, we identified our target users for Viewer 2 and the main focus was on the new user and understanding some of the pain that they go through in integrating with Second Life. I remember coming in to Linden Lab during the middle of that study. As well, during the development of Viewer 2, we were doing constant testing with a resident group that had been selected by our community team. But it was a pretty small group.

But things have changed a lot. First, we’ve clearly defined a product owner, which is myself. During the development of Viewer 2 we had several people who were sharing the responsibility for its development, but that’s now clarified and I’m the dedicated product owner – a significant shift, giving focus and accountability.

Now, in my job as product owner, it’s my responsibility to ensure we’re getting the right input and bringing that back to the team. This includes doing a LOT more one-on-one discussion with residents, to try to make the collection of feedback easier, and to reach out to specific groups. For example, I’m working with Virtual Ability to collect feedback on how to make the viewer useful to that community.

I work very closely with other teams in Linden Lab to make sure that I can connect with specific communities and Residents. That process of reaching out and listening is an important part of what I do.

Q Linden: I should point out that although Esbee is the primary representative of the community perspective on the Snowstorm development team and that she’s an unusually good one, we also have people inside the Lab itself who are very active in giving us feedback and ideas. I have an in-box full of things from people inside the Lab about what’s wrong with the viewer.

And these aren’t Lindens who don’t use Second Life. Lindens use Second Life and many of them use it for personal interests and are often very strong representatives. As an example, there’s a Linden who’s a part of the Tiny community and can really represent ways in which the viewer can affect those Residents.

This idea that Lindens don’t use Second Life is patently untrue.

Esbee: Actually, it can be hard at times to switch from Resident hat to a Linden hat. As a resident I spend a lot of time building, I go to clubs and know a lot of club owners, and that’s where my love of Second Life comes from – from building, scripting. And sometimes I need to put my Linden hat back on and realize that we need to prioritize things even though my Resident hat totally gets that there’s something that feels like it should be fixed right now.

But what’s great about my position is I get to work with people who are using the viewer in a lot of different ways. So they’re always helping to flesh out our backlog. But also, other teams in the Lab are also doing viewer work….Snowstorm isn’t the only team doing work that affects the viewer. In particular, we’re focusing on smaller, faster iterations.

Dusan: I knew you as a Resident first, Esbee. And I have to say it’s really encouraging to know that the person representing the community viewpoint on the Snowstorm team was a Resident first. But let’s take your club owner example – say I AM a club owner, or I organize Metanomics. And I want to let you know what drives me crazy or what I think needs to be fixed. The way Oz presented it at SLCC made the whole process seem incredibly cumbersome. Can you explain how a typical user can have their voice heard?

Esbee: We’re working on and will continue to work on all kinds of ways to make sure that Residents can express their opinion and contribute. To start with and this is important: almost everything is public, which is a major change.

The backlog, for example, is public. Anyone can view that and it has a list of all of the user stories that we’ve currently prioritized as a team. It’s my job to review and remove and share user scenarios with other members of the team. Anyone can read this at any time.

Now, in order to get something on the backlog it needs to come from me. Now, Oz talked at SLCC about a more formal process related more to the open source process for Snowglobe. But anyone can contribute in both formal and informal ways:

- Come to my office hours which are held weekly, and where we review the backlog. Last week for example, we focused on the chat functions of the viewer. You can come and contribute to the discussions.
- You can bring more formal proposals to office hours
- You can e-mail me directly
- You can join and contribute to the open source development list

Finally, there are a ton of feature requests in the JIRA and Snowstorm has taken over all of the items related to the Viewer in JIRA. We’ve been spending a lot of time re-triaging the JIRA so we make sure we’re looking at resident requests from the last few years and addressing things that may have been in the queue for a long time.

Now, since we made the announcement my in-box has been completely flooded so I can’t respond as quickly as I’d like to all of the ideas and comments. But there’s a second tab in the backlog where I’m putting ideas and am making notes on those as they come up so ideas aren’t being lost and everything is being captured.

Another thing that I’m doing, by the way, is integrating other team’s backlogs. Making sure that the other product development teams and Scrums inside the Lab feed information to us, and that I communicate with them frequently to make sure their insight is included in how we prioritize the backlog.

Q Linden: The work of re-triaging the JIRA was something both Esbee and I were going to work on through August and then I got sick. Esbee has been trying to get the info out and organized and arranged and its been a really amazing job considering she’s been doing the job of two.

I should make a comment about the JIRA itself. Because one of the things that’s been an issue is that JIRA 3 made it a challenge to deal with issues in bulk. You can carry on about a single issue but when you have a massive amount of information and it was difficult to establish relative priorities.

On September 7th we’ll be launching JIRA 4 is and with it we’ll be launching the GreenHopper plug-in. GreenHopper is a tool that allows drag and drop manipulation of collections of info into priority, task groups and Scrum order etc. It gives us a much easier way to manipulate common info.

(Ed: GreenHopper is an Agile Project Management plug-in designed to make the work of Scrum teams more efficient).

But with the launch of JIRA 4 we’re also doing something else. Because one of the things that people don’t understand yet is we really are truly going open. We’ve closed down the internal JIRA and everything is going public. The general structure is to default to public information with the exception of a few things like security issues. We’re going to be able to, in public, gather and arrange the JIRA data so the stuff now in spreadsheets can be in one place and I think that will be good for us as a team and the community as a whole.

Dusan: OK, so you collect ideas and information from JIRA, from office hours, community outreach, e-mails. But how do you prioritize? How do you choose what comes first and what has priority?

Esbee: There’s are a number of ways this is working.

It’s important to understand that Snowstorm is just one Scrum team. So there are, for example, features being developed for Second Life by other teams and their work gets integrated into the Viewer. So what I do is take the user stories that are generated from community and internal feedback and talk to other product owners across the Lab so that I can make sure it doesn’t conflict with what another team’s doing.

Now, say someone comes to me with a request or complaint or bug or comment about search. I don’t ignore that, but I’ll take to the search team. It wouldn’t show in our backlog but I’ve been letting people know what I’m doing with them and I’m committed to letting Residents know that their requests aren’t being ignored and being triaged to the right team.

Now, once something gets on the Snowstorm backlog (in other words, it doesn’t belong with another team) we have to prioritize.

Philip has been talking about our focus on making Second Life fast easy and fun. So that’s the main priority: how to make Second Life fast, easy and fun and we rank the backlog that way.

After that we look at how big a project, is it one sprint, do we need help from server resources internally.

So, first priority is focused on the resident/customer and fast/easy/fun and then we look at the technical side and what it will take us to implement. We’re extremely focused on high value/low cost fixes right now as opposed to big long term projects.

Q Linden: High value and quick wins are really important to us right now. And not just for the user experience. We want to get the kinds of wins that really make a difference quickly because it helps our team to exercise the process and show that we can execute.

That includes learning and improving and proving it to ourselves. This is a new process, it’s transparent and open and we want to prove it by doing it not by talking about it. So we’re deeply focused on accomplishments, transparency and just getting the job done.

There will be lots of debate about long-term things we need to do with the Viewer but right now we’ll focus on short term wins and prove to people that we won’t just disappear behind a wall and will be really actively engaged with the community and with improving their Second Life experience.

Dusan: So Snowstorm is an open source project. What do you hope to accomplish with the open source community in general?

Q Linden: It is an open source project and hiring Oz has been a really good thing for us. He comes from a background with classic open source projects and can manage them in a way that an open source community will recognize.

To be honest, we’re as competitive as anybody. We want our Viewer to be the best viewer there is. And our goal is to show people that we have a process and if they have an idea they can get it into our code base. Already, a lot of people are giving us real code and our internal developers are doing code reviews and we’re really starting to see community code contributions gain some traction. If people can see the code, make changes and then see that we’ll accept that code that’s what will give us the most effective Viewer.

Dusan: With regards to Third Party Viewers (TPVs), how do they fit in to the ecosystem of what you’re doing? What’s their role in all of this?

Q Linden: What we would like to see is that Viewer 2 is the preferable code base from which to start. You’ll get new features fastest through that code base. It has the best quality code and the build’s the easiest. We’re putting all of our eggs into the Viewer 2 basket and that’s the place that we’re supporting.

Take for example changing some element of our protocol. Multiple avatar attachments is an example. Emerald solved this problem by creating additional points. But this has a variety of technical issues. We have the ability to create a standard that fits into the architecture of Second Life better because we can integrate the Viewer changes with server changes.

Since our protocols are controlled at both server and viewer, we’re going to bias towards doing those deep technical things because we can do them right and that’s how we want to see that proceed.

So we hope that TPVs will build it on our code base because you’ll get those features for free but if you sort of develop around us on issues like that, support might end up disappearing.

But now, unlike before, you’ll see the protocol evolution done in the open. This helps TPV developers to make decisions – they can see that something is on our radar and they can know that we’re working on it and will be better served.

Dusan: One of the things I still get confused about related to how you prioritize is connected, I guess, to the way you can vote on issues in the JIRA. Does voting drive decisions on priorities? How much attention should be paid on how many votes something gets in the JIRA?

Esbee: I think that voting can set unrealistic expectations. Voting can be great especially for new feature requests. But the trouble that we run into is when you see a split on an issue. Just as an example – this week we talked at office hours about chat. One discussion point was around whether local chat should always take precedence when interacting with the viewer. But if you did that, you wouldn’t be able to use the WASD keys on the keyboard to move your avatar. Now, half the people thought this was OK, and half thought it was a bad idea.

Going out and speaking with residents often gives us better information as does user testing. We’ve been doing a lot of that lately, watching residents at different levels of experience complete tasks.

We have a usability lab and our experience team runs that and does all sorts of testing across Linden Lab products. We bring in new, relatively new, and existing residents. Anyone from the Lab can tune in to those tests which are streamed and see how it’s going.

For example, we’ve been working on being able to tear off the sidebar tabs in the Viewer and the testing immediately showed us some flaws. This helps our development team to move faster.

Dusan: I know that a lot of people react quite strongly to the side panel in the Viewer. So tearable side tabs sounds good. But what else can we expect in the next while as far as changes to the Viewer?

Esbee: Well, one of the main things is to allow a lot more customization. Tearing off the side tabs is an example of that and we’re working on a design for that. But that doesn’t fully address the need for more customization.

We’ve done small things – for example, if you right click the bottom bar you can now add and remove buttons to customize what’s there for you. This fits in to the broader need to give more of a 1.23 flexibility – to allow floating windows, to give them that type of flexibility, to allow multiple instances of the side bar tabs. We want to allow you to dock floaters at the corners. And we’re working on allowing windows to be outside of the main viewer window itself.

We want to make it easy to save layouts for different purposes. So, say you have different floaters open when you’re scripting or building versus say dancing in a club. You should be able to save those layouts and call them up again.

But more broadly, we’re working with other teams in the Lab to sort of socialize those changes and ideas with the other teams. There’s work being done in other teams that will use these ideas around customization.

But a really significant difference in how we work now is that we’re totally open. There’s work being done by the user experience team on these customization ideas and they’ve been doing some really cool sketches and coming up with great ideas. We’ll blog those sketches, be open with them, get early feedback, show people what we’re thinking. This will be a great way to show people how ideas evolve and change and how feedback is important.

Dusan: When I first started using the new viewer I had low frame rates and crashes. Now, I have no idea if it was the viewer itself, but I’ve certainly seen a significant improvement. How is Viewer 2 doing related to stability?

Q Linden: Stability has been a big focus and we can track a lot of stats about crash rate and various other measures.

It’s an interesting problem because stability has to do with things like driver issues and we sometimes have to wait until we see a viewer in the field to really understand how stable it will be and that’s because our product hits the field in ways we didn’t anticipate. We can run into strange hardware, drivers, that sort of thing.

We put a lot better tracking into the system and we’ve switched to a stack tracing mechanism that works more effectively and we’ve bought a lot of low end hardware and more testing on kinds of machines that are below minimum spec.

Viewer 2.12 is actually quite a bit more stable and is approaching the stability of users that have Viewer 1.23 and who typically restrict themselves anyways in the activities they do to avoid crashes.

But a significant difference is that the machines we now test on include machines that are below the required system specification for Second Life. We may WANT users to always meet the system requirements, but they don’t always do that, and so we now test on low-end machines below specification.

Esbee: Overall, while Snowstorm is still really new and we’re still figuring out the best way to work, we’re trying to be as open as we can, you can come to all those meetings, view the backlog, reach out, e-mail us, and we’ll continue to reach out ourselves, blog about what we’re doing and really try to communicate where we’re headed.

Q Linden: And at the end of the day, we’re committed to proving it by performing.