Q Linden

Today we launched Viewer 2.5, now out of Beta. The most significant update is a new, web-based profile system, which allows profiles to be viewed and edited both on the web and in the Viewer. For example, here's mine. Please note this is just a starting point for the web-based profiles; we’ll be doing a lot of work to refine the usability and make them richer over time. In response to your feedback from the early beta versions of Viewer 2.5, we've added some privacy settings that will allow you to control just how public your profile is. Once you’ve logged in, click on “Privacy Settings” in the upper right corner of your profile. Group settings set in the Viewer will be overridden by these group privacy settings. "Everyone" means that the information is available to the whole Internet and can be picked up by search engines. "Second Life" means that the information is available to all Second Life Residents who are logged into the website or inworld. This is the default for all existing Residents using Viewer 2.5. "Friends" means that only your Second Life friends can see the information on the web and inworld. This is why we have a beta process--to address concerns and improve your user experience. We will continue to iterate as we get more feedback. Thank you for all your help and comments. Please attend the Viewer 2 User Group meetings if you would like to share your thoughts and feedback directly with me and the Snowstorm team. Viewer 2.5 also has some other new features. The one I like best is that you can now have your Favorite landmarks also appear on the login screen, so that you can log directly into your favorite locations. Torley made a video about this, so check it out! We've also improved some texturing performance and fixed another batch of bugs. Watching the internal data, we've already seen a noticeable improvement in stability and performance--on par with Viewer 1.23. Download Viewer 2.5, try it out, and keep the feedback coming! And, if you Twitter, please use the hashtag #slviewer2. Helpful Links Download Viewer 2.5: Windows | Mac | Linux Viewer 2.5 Release Notes SL Forum on Viewer 2 SL Answers on Viewer 2

You're in luck. The chat bar is now resizeable (just drag the space to its right).

Well, sorry, Hitomi. That was my fault. We just figured out the actual problem last night and I failed to ask to have the release notes updated.

Thanks for the good wishes; I'll pass them on. We're going to miss Esbee. But Snowstorm continues. We'll keep you posted on our plans.

In addition to many grid enhancements that FJ shared last week in his technology update blog post, the Viewer 2.5 beta cycle begins today. Viewer 2.5 Beta 1 is now available and includes several new features, usability improvements, and bug fixes. Improved Web and Viewer Resident Profiles The biggest change in Viewer 2.5 Beta 1 is that we've replaced the Viewer-based profiles with web-based profiles. You can access the redesigned profiles on the web using your Second Life user id and in the Viewer itself. For example, here’s mine. In the Viewer, profiles now open in a web browser and you can open as many profiles as you like at the same time. And, if you wish, you can even connect other social identities from Twitter, Facebook, and LinkedIn to your profile. Logging In to your Favorite Locations A long-standing feature request has been the ability to access some of your favorite Landmarks from the login screen, so you can quickly teleport to places inworld. In the Viewer 2.5 Beta, we've added a preference that gives you access to the Landmarks on your Favorites Bar from the Login Screen. To use this feature, go to Preferences > Privacy and select the check box labeled, "Show my Favorite Landmarks at Login." If you log off and then restart your Viewer, then you'll see a list of your Favorite Landmarks in the "Start At" drop-down box on the login screen. Also, when this feature is enabled and you share a computer account (login) with other people, they will see your list of Favorites if they run the Viewer 2.5 Beta. Decompression Performance Improvements For a long time, we’ve used an older version of the Kakadu library known as KDU to load textures and images in the Viewer. The KDU Library has been updated to version 6.4 in the Viewer 2.5 Beta, which allows the Viewer to take advantage of significant decompression performance gains; our preliminary measurements gauge the performance gain at 30% for decoding images, which should translate to a visible improvement in rezzing time for complex scenes. Please note that per our support policy, we’re also deprecating Viewer 2.1.1 today. If you’ve been running Viewer 2.1.1, you’ll be prompted to download the latest Viewer release. To stay up to date on future deprecation announcements, please subscribe to @secondlife on Twitter. As always, we want to know what you think of the latest beta so please keep that feedback coming. Share your impressions with us on Twitter and use the hashtag #SLViewer2. Helpful Links Download Viewer 2.5 Beta 1:Windows | Mac | Linux Viewer 2.5 Beta Release Notes SL Forum on Viewer 2

Well, I guess I put my foot in it, didn't I? I was frustrated that my attempts at communication seemed to be misunderstood both in content as well as intent, and I let it become visible. I apologize to anyone who was offended. I will continue to try to be both honest and open, but I'll also try to remain positive. Reading over the responses (thank you all!) I see a few themes: "Linden has never listened to its customers and this post is just further evidence" I'm not going to defend past behavior; no point. This post is an attempt to both explain and start a dialog. I'm here to listen and to speak too. We do have a point of view, and commercial interests. We recognize that our job is to satisfy our customers -- the question, as always, is how to satisfy the greatest number, since we'll never succeed at satisfying all of them. There was no shortage of suggestions in this thread, and I have (ouch) read them all, even if I don't respond to every one. (It is, after all, a holiday weekend. ) "Linden isn't listening now and Display Names is evidence"I'm not on the Display Names team, so I'm not going to comment on it, except to say that pointing at something and saying "see, it's horrible!" isn't actually very convincing. But this blog post is not the place to have that debate. "You should poll people before doing anything new"I completely disagree with this, and yes, I know saying that will make me some enemies. The only polling worth anything is true random sampling and that's both expensive and doesn't help with design. Voluntary polls and votes are basically worthless -- they're completely subject to advocacy and gaming. Without a sample implementation to try out, most people (I didn't say everyone, so please don't accuse me of that.) don't know what they want. The average desired change is usually no change at all. In general, I think we want to try things out in some sort of "real" form, which is what Project Viewers are for. There are many ideas people have for what would make a better viewer. Some of them come from Lindens, some from residents. Snowstorm is trying to put all these ideas on an equal footing and implement as many as possible, as quickly as possible. "One size fits all is the problem - we need a customizable viewer"I actually agree with this point, and I do hope we'll get there. But there are a lot of ways to do this badly. I think it needs careful discussion and a fair amount of time. I don't think now is the time for such a large scale project. Please, let's let Snowstorm gain some traction first on the small stuff, and then we can talk about bigger goals. But we'll start talking about it soon. "Watch what the TPVs do and do that"TPVs can afford to try partial solutions and see what sticks because they usually address an advanced use case. They can ship buggy, incremental work because their customers know that's what to expect. Our official solutions need to be complete and suitable for all users, including newcomers. (Yes, it's acknowledged that we haven't always succeeded at this, but it is our goal). We can learn from popular features in TPVs. But we intend to lead as well with new stuff that's not in the TPVs. Snowstorm is trying a similar approach to TPVs - and more than just with Project Viewers. Because we make the development builds available, you can try work in progress and see new features take shape. Some features are still half-baked, but you can try them and provide feedback to make them better (which you can't always do with a TPV). "Viewer 2 sucks, throw it out and go back to 1.23"Well, we've said it before -- we know we missed the mark with some of 2.x -- but it's our base going forward. It's not a complete rewrite as some have indicated -- but it has some major architectural improvements under the covers. I know a lot of people don't like chunks of the UI, but we're going to push forward and fix it, not go backwards to an obsolete platform. "Open source is the problem"This is a philosophical question, and whether you believe it's true or not doesn't matter. The open source cat, so to speak, is out of the viewer bag, and no amount of coaxing will get it back in. Personally, I happen to believe that encouraging an open source infrastructure for virtual worlds is good for Linden as well as the larger community. I also want our viewer source to be the base from which most of the open source viewers are built. But that will happen naturally if we succeed with Snowstorm, not through some manipulation of the market. In short, we do care what you think, and what you say, and it's because you care that these discussions get contentious. Let's stay engaged and keep talking. I'll be blogging more, as will other members of the Snowstorm team.

Wow, people. I'm amazed at the way folks are misinterpreting what I said. Some of it is, I'm sure, deliberate, by people who have axes to grind. All I tried to do was explain why options should be a last resort. Nowhere did I say we won't have them. Regarding the various accusations of condescension and not listening to our customers, how about a little reciprocity? I'm trying to have a somewhat nuanced, open discussion, explaining some of Linden Lab's desires and constraints, and what I get in return seems to be an attack because I haven't simply agreed to some hypothetical ideal. I'm listening and trying to engage, are you? Please, let's assume good intentions here. If we all listen and comment with respect we'll get farther.

In the Snowstorm Product Backlog Office Hour Wednesday, I commented that "I think options are bad for users and bad for code quality". If you read that whole transcript, you can probably see that it was interpreted badly. The most extreme variant, reported by someone who was watching in-world chat afterward, held that Linden Lab wanted to remove all options from the Viewer. Let me start by saying that is not the case and never would be, nor is it something that I or anyone at Linden Lab has ever seriously contemplated. However, I still stand by my original comment -- options are problematic for lots of reasons. Let's see why: First, every option has to have a way to control it. In many cases, you have to have multiple ways to control it. From a user interface design point of view, that means creating option interfaces. For the SL Viewer, those are a) the preferences dialog, b) the debug settings, c) checkable menu items, and d) options within dialogs that control other features. You'd normally like to put options with the things they affect, but screen space is always at a premium and many options are only changed infrequently. So instead, we group options together in a preferences dialog. But there are enough of them that it becomes necessary to create some means of organizing prefs into a hierarchical structure, such as tabs. But as soon as you do that, you find that you have trouble because not everyone agrees on what the hierarchy should be. What tabs should you have? Where does each option go? When you get too many options for one tab, how should you split them up? There's no one answer and there's rarely a right answer. And then, once you have a place to put them, you have to decide what to call each option and what the default is. And if those decisions were easy there wouldn't be a need for an option! Second, options add complexity to the interface. Every time you add an option, you add a decision for the user to make. In many cases, someone might not even know what the option controls or whether it's important. Too many options might leave someone feeling that the product is too complex to use. Third, options add complexity to the code. Every option requires code to support all of the branches of the decision tree. If there are multiple options affecting the same feature, all of the combinations must be supported, and tested. Option code is often one of the biggest sources of bugs in a product. The number of options in the Second Life Viewer renderer, which interact not only with each other but with device drivers and different computers, make it literally impossible for us to exhaustively test the renderer. We have to do a probability-based sampling test. You could say that it's our problem to deal with that complexity, and you'd be right, but every additional bit of complexity slows down development and testing and makes it harder for us to deliver meaningful functionality. Fourth, options that are 50-50 probably do need to exist. Options that are 90-10 are addressing an advanced (and possibly important) use case. Having them in the preferences interface promotes them to a primacy they probably don't deserve. Finally, adding options has a snowball effect. Having a small number of options is good, but having too many options is definitely bad for the product and for the customers trying to use it. Sure, advanced uses need advanced features, but we don't have to make everyone confront all of the complexity. Add all of this up, and I think it becomes clearer why I said I didn't like options and would prefer to find alternatives. So why have options at all, then? Because different people legitimately have different needs. Advanced users vs novices, or landowners vs shoppers. We get it. But it's also often an indication of a design that needs work. There are alternatives to putting more checkboxes on the preferences screen: a) Allow entire user interfaces to be "plugged in". This requires a major architectural change to the software. Although we've talked about it, it's going to be a while yet before we get there. b) Allow options to be controlled close to the point of use. As I said above, this can clutter the interface but can be effective. c) Make an interface that covers all use cases. This is the hardest of all, requiring real understanding and design, but is usually the right answer. In short, I often consider adding a preference to the prefs panel to be the wrong answer to a real question. It's not that we don't consider different use cases, it's that we're trying to cover them in a better way. So this has been my attempt to explain the thinking behind a statement like "options bad". I hope it's helped -- has it? Tell me in the comments.