Everybody knows Viewer 2 sucks

By now, it should be news to absolutely nobody that Second Life users hate Viewer 2. Nine months after it was released amid great fanfare, only 20% of the logins on the grid are made with it. It's only within the last two weeks that it passed the venerable version 1.23 viewer for popularity among users, with third party viewers leading the pack substantially.

The only people who won't admit Viewer 2 sucks as far as the user community is concerned is Linden Lab itself. This makes perfect sense, even though it drives users nuts. LL spent seven figures on Viewer 2 development. For a company that size, that's a major investment. They cannot just throw that away. Doing that would make executives lose their jobs, and get the company's board of directors interested - and not in a good way.

I haven't used Viewer 2 myself for more than about 5 minutes. Since my work on SL requires RLV, and Marine Kelley's RLV wasn't available for the Mac, I saw no particular reason to try it. That stayed the case ever since. The one exception was when I started up the display names test viewer to find out for myself just what the fuss was all about (there's another blog posting coming up about this). The user interface so confused me that I quickly logged out and back in with Phoenix.

Still, there's a small but extremely vocal contingent that swears up and down that Viewer 2 isn't bad, just different, and that people should quit whining and learn to use it - and if they do, they'll love it. This is being greeted with about the level of incredulity you'd expect from people whose views are being totally ignored. These folks don't understand that, as long as there's a choice, most of the user community will simply not choose Viewer 2 no matter how much they're told to shut up and eat their Brussels sprouts.

At the other end of the scale are people who see anything LL does to third party viewers as part of a conspiracy to force the user community to move to Viewer 2 whether it wants to or not. They take comments like Oz Linden's "we see third party viewers as a problem to be solved" far, far too literally. What Oz meant was that LL sees TPVs as competition, but the "solution" isn't to destroy them underhandedly, but rather to out-compete them. I've got no problem with this at all. If a TPV can't out-compete LL's official viewer, then it deserves to wither.

Even so, it's plain that the Viewer 2 codebase is the future of SL viewers. LL's adding new features to SL: inventory links/outfit folders, display names, and mesh are just the beginning. Those additions are all being done only in the Viewer 2 code. They're not touching the Snowglobe 1.5 codebase any more; in fact, they've dropped it officially and won't even distribute it any more shortly, if they haven't stopped already.

The reaction to this in the user community is "Fine! Third party developers, just put the Viewer 1 user interface on Viewer 2, and we'll be happy!" This is one hell of a lot easier said than done. To explain why, I need to discuss program design for a moment.

In a project as large as a viewer, proper code design is something that has to be enforced rigorously from the very beginning. Good practice would have had the code implemented in layers, with the user interface layer talking to the layers that do the actual work through clean, straightforward, well-designed and well-documented interfaces. There are all sorts of benefits to this way of doing things, the biggest of which are simply that it makes life a lot simpler when it comes time to add features or fix bugs.

Anyone who's looked at the version 1 viewer code will know instantly they didn't do it that way. Oh, they tried, and there are some things that are cleanly broken out, but the vast majority of the code is an unmitigated mess. It takes me literally hours to find out where something is done, just trawling through it. This is understandable. When you have a program that big that's grown in many different directions over a period of years, it's very hard not to have it happen this way. That's why major programs get total rewrites every so often.

So with Viewer 2. Unfortunately, LL made two critical mistakes when they did it. They contracted out the development, I'm told, to a group in the Ukraine. The first mistake was that they didn't ride herd on them to enforce good coding standards (like the split between UI and worker layers I described). The second mistake was that they didn't pick people who actually knew anything about Second Life from the standpoint of a user.

The result of these two mistakes was a Viewer 2 codebase that didn't work like anything people knew how to use already, and had assumptions about the way it should work at the UI level baked into the lowest levels of the code. For example, the code assumes, deep down, that there will only ever be one information window for a group - any group - open at a time. The way IMs and local text chat are handled, the sidebar, the inspector instead of the familiar pie menus, all are deep, basic assumptions about the way the viewer will work, and they're all embedded in the code at all levels.

One of the other Phoenix developers is in the camp of "just eat your Brussels sprouts". The Phoenix team will be working on a Viewer 2-based viewer, named Firestorm. We've been talking about a UI redesign, and what's even possible. That developer is adamant that putting a familiar version 1 user interface on the Viewer 2 codebase amounts to a total rewrite. Obviously, the Phoenix team doesn't have the resources for that. As it is, we're planning a minimum of six months to put out some version of Viewer 2 with the UI changes we can make practically and with the most-requested features. (We won't have to add bouncing breasts, though. LL's doing that. No really. Quit snickering. You wouldn't believe the number of complaints we get from folks having a hard time getting it to work.)

So what's the Phoenix team planning? Good question, and one we'd love to have the answer to. Right now, we're concentrating on making the current one stable so we can let it go and work on Viewer 2 uninterrupted. Once we get that out the door (and we're really hoping the version we expect to release in a couple of weeks is that version), then we'll get serious about Firestorm. It's not too early to plan what we're going to do, however. To do that, we need to know what's possible, and what the users really want.

Don't just tell us "put the version 1 user interface on version 2!" That's not going to happen. We've all got real lives to deal with and real world constraints on resources. We can't do the total rewrite this would take.

What we need is specifics. Yes, this means you're going to have to fire up Viewer 2 and tell us what it is you don't like about it, in specific detail. I know it'll be a pain. Force yourself. Concrete suggestions for improvement will get seriously looked at, and implemented if possible without rewriting half of the code.

We all know Viewer 2 sucks. What we don't know is why or how specifically to fix it within the constraints we have to live with. That's where you come in.