Jump to content

Tools and Technology

  • entries
    86
  • comments
    916
  • views
    92,593

Contributors to this blog

Check here if you want more options

Sign in to follow this  
Q Linden

8,986 views

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.

Sign in to follow this  


192 Comments


Recommended Comments



First, I also have my mini map up all the time, plus my stats.

2nd, I'd agree that open sourcing the viewer was a bad idea, mostly because the real development went outside of the official viewer.

3rd, I'd have to disagree with statements about large merchants. Actually, I almost fell off my chair laughing. Not all large merchants do things the same way or have the same attitude. For the most part, a large merchant got to be large because they are prolific workers, listened to their customers, and caters to them, hence why they have so many. Also, being that they do listen, when they come to office hours, they bring all those customer concerns with them. Profit is simply a product of their hard work, not greed. If the customers actually thought that, then they would not tell their friends to go there. They tell them to go there because they get quality products with quality service. The only way a merchant can make a living off SL is by listening to customers. Any smart merchant understands that real solid growth comes with the total growth of the grid and population. To think differently means you are likely creating your own little bubble, which is likely to break sooner or later. Go checkout some of the creation categories in the forums. If merchants were all greedy, then why would any of them give answers or create tutorials so that others can become merchants or make products themselves?

4th, I think that LL needs polling for certain feedback. It is something that I do, and is immeasurable in what you can learn. Of course, polls need to be worded very carefully and have the proper choices, if there are more than 2 choices. You can't just sit and create a poll in 5 min and think that somehow you are going to get good results from it.

Share this comment


Link to comment

So I'm as annoyed as anyone when I can no longer right-click on the ground and start the "create" process, but have to scroll through a menu selecting two or three options. -- Prokofy

Hmm.... being someone that tends to build at altitude and then lower things to ground level when ready I didn't notice this was gone... but it seems to be back in Viewer2.1.1 now.  Right-click on a prim or on the ground, select and presto. =)

(being the hot-key nut that I am... I've always used ctrl-4 to create prims.  (ctrl-1 through 5 map to the buttons across the top of the edit/build tool:  1=focus, 2=move, 3=edit, 4=create, 5=land/terraform, I never use use ctrl to access the others though)

The problem with enabling grid vs. disabling it if it's not wanted is that newbies would otherwise almost certainly never notice it was there.  As a visual indicator of where objects are in relation to each other... it is very useful, especially for people that are just finding their "XYZ legs".

If you don't want the grid, planar-pull-tabs or axis-drag-arrows... (and I know this is going to sound far too obvious) ... just use the mode in the edit/build tool (my way: ctrl-2, otherwise click the icon in the top of the edit widget).   It will move laterally.  If you hold ctrl, it will move perpendicularly to the camera. =)

Personally, in all my years of being in SL.. the only new feature I've managed to wring out of them was the tab for inventory items... and they sorta claimed they were "already" working on that when I begged for it. 

Getting LL to do what WE want them to do is like every other game of politics.  Being "right" is not sufficient... or sadly... even required.   Being in the right place, at the right time to plant the right seed in the right ear... *SOMETIMES* works, but usually backfires as it grows wild once planted.  Compromises are made, deals are struck, people with influence demand arbitrary changes so that it will fit their 'vision', or just on a whim, the final product looks nothing like what was needed or wanted... but, for whatever reason, it was what managed to make it through the process.

Humans are a deeply flawed species filled with self-confounding tendencies.

Share this comment


Link to comment

"We need new tools, but *not* at the expense of the old ones." -- Darien

Don't get me wrong... I'm not saying that anything has to be removed so that SL can move forward. =)

Problems like search and groupchat are heinous blemishes on our SL experience, they simply must be fixed.   They drive us nuts daily, and a few residents find them sufficient cause to abandon SL.   No where near the number of potential residents that turn away because SL just looks increasingly... well... old.

Windlight was a great step forward, but was never fully deployed.    Mesh is almost here... but way behind schedule.  

I've heard stories from MS Excel developers that, I swear, gave me nightmares.

Ugh... the inventory browser itself...  Hideous.   It doesn't matter what OS someone uses, windows, mac or linux, they each have file browsers, desktops, multiple views, intra-folder sorting, advanced search, "Open Folder in New Window" ... people that use their computer some how manage to figure out their "Pictures Folder" from their "Documents" folder and manage just fine.    Our inventory in SL should follow those exact same familiar and standard conventions, not this massive tree that looks like it was copied out of some old windows registry editor. Grrrrrr. =)

Share this comment


Link to comment

Jopsy, I am not a builder, but I use the build tools every day anyway, to place and adjust houses, to make little things that are simple like decks, etc. So I'm as annoyed as anyone when I can no longer right-click on the ground and start the "create" process, but have to scroll through a menu selecting two or three options. That's what happened in the first iteration of viewer 2.0 in the name of "think of the children" (making it easier for newbies).

That happened because the Lindens didn't seem to realize how much casual use there was of build. But in the name of de-cluttering the menu, they could justify the removal of the "build" button. I don't *have* to have the build button on the front page taking up scarce real estate, I can access it through some other layer of menus, or, if "right click on the ground" is retained, get it that way. I don't have to have "grid" imposed on me every time I build if I'm not a professional builder; that could be accessed through an extra click. And so on. That's the kind of mentality I mean -- framing the viewer so that it is not destroying functionality for those who need it but not imposing hobbles for those that don't.


Prok, i'm not clear on whether you know that you can just use a "Build" button in Viewer 2 now? There are several options you can pin to the bottom bar, just right-click the bar and choose what you do/don't want to appear down there. The Snowstorm backlog also has a feature for being able to move those buttons around on the bottom bar, so you can line them up according to your own preferences.

And for the "grid" being on.. do you mean the one you see visually when building, where prims snap to the grid lines? I ask because, for me, it never comes up by default. When i move things manually (push/pull by grabbing the arrows) it's smooth, no snapping.

Share this comment


Link to comment

I think it is interesting to compare this thread with this one:

http://blogs.secondlife.com/thread/36034?tstart=0

I was impressed with how quickly Phoenix rose from the ashes of Emerald; a slick, professional turnaround within days of a major crisis. Note the high level of customer satisfaction, the relief and enthusiasm among the userbase. When was the last time anyone was enthusiastic about anything done by Linden Lab?

Share this comment


Link to comment

I just don't think LL is hearing anything the masses are saying....Viewer2 is simply CRAP and nobody is going to put up with it.  Turning off support for Viewer 1.23.5 is simply not acceptable!  And if they continue to try and force us to use it, people in DROVES are going to leave SL and go to the alternate grids...I for one.  As far as I'm concerned, LL now does not provide a decent viewer for SL.

Share this comment


Link to comment

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.

Share this comment


Link to comment

 

  • "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.

 

This is wrong on a couple of counts.

1. True random sampling is not expensive. You have a company full of coders. Take a couple of them, who are already getting paid by your company, and have them write it up. Send it to a random number of accounts who have logged in in the past month or so. A simple check for auth is all it takes. It will not cost LL one penny more than they're already paying them to do other important things, like "Display Names" and "Invite your friends to SL" widgets.

2. You have no idea that "most people don't know what they want," because you've done no polling on the issue. If "the average desired change is usually no change at all," then obviously Viewer 2 was something desired by LL, and not something desired by its customers, and the feedback since it's release bears that out.


  • "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).

 

I applaud the Snowstorm effort and think it's a good thing to do. But your solutions are NEVER complete, and are are ALWAYS buggy, just like every TPV viewer out there, and just like the TPVs, we know to expect it from LL as well. Every single viewer LL has put out has bugs. Every single viewer LL has put out was not "complete." If they had no bugs and were complete, new versions wouldn't be necessary. And, when the community at large DOES provide feedback on an unwanted-as-is feature in the viewer, you hand us the following:


  • "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're correct, this isn't the place to have the Display Names debate. This is the place to have the "Linden isn't listening" debate. So, as I believe I brought up earlier in this thread, if you're not going to listen to what we want, why bother giving you the feedback? What good is "working in the open" if no one tunes us in anyway? You're already of the opinion that polling us is useless, we don't want change, we don't know what we want ... please tell us the part that deals with why we should bother?


  • "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.

 

While the 1.xx platform is obsolete - the issue is not with the platform, but with the UI. If the 1.xx UI is obsolete, it's only in your own minds; some very popular TPVs still use it as their base, and even with Emerald off the map you're seeing a significant number of customers using TPVs based on the 1.xx UI rather than the 2.xx UI. I see no reason why the functionality of Viewer 2 cannot be applied to a 1.xx-style UI.

Share this comment


Link to comment

Agree with Ghosty on this...the major problem with 2.xx is the UI.  Until you fix it, please *dont* turn off support for 1.xx, obsolete or not, or we have no choice but to go with a TPV.  Best thing would be an option in 2.xx to use the "classic" interface.

Share this comment


Link to comment

"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."

This is just really ironic right here. What do you call all the v2 releases thus far, as well as the SL Marketplace? Buggy, incremental, incomplete, unsuitable. :=(

Share this comment


Link to comment

Q Linden wrote:

  • "Viewer 2 sucks, ...

The sooner you guys get into the "We think it sux too – what were we thinking?!" mode the better, and you would score big with your customers for admitting it.

Your course of action could be:

  • Freeze the current 2.1.x development in a stable condition and stop there, including no more adding of new "features" like display names.
  • Then take a very good look at the 2.x branch code and re-architect it so you can layer over it a UI that is adoptable to and complies with operating system user interface standards. This will enable you to create user interfaces that at the core complies with the UI guidelines of various Linux distros, Apple's UI guidelines and Windows 7. But more importantly, that will also enable new mobile user interfaces that use touch, gestures, gyros and accelerometers to operate.
  • Provide the Snowglobe 1.5 branch as your official viewer for now, but also direct users at reliable alternatives if they want more options.

A couple hints for the re-architecting:

  • Making the viewer a true Mac OS X UI compliant application is probably the biggest depart from the current code in terms of separation. If you accomplish this you have possibly gone as far as you need in separating the UI from your core code (the version 2 branch). So this is a good case study. It obviously means that you in the future will have to maintain more operating environment specific code, but you will gain in user satisfaction and adoption, and most likely less load on your service desk.
  • Integrating WebKit into the code is in my opinion important. Why? Because a number of the functions that is currently hardcoded into the viewer can be separated out to services that are rendered with html(5) inside the viewer. Profiles, group functions, chat, editors, search and others spiring to mind. This makes it possible for you to scale faster and also iterate faster on the functionality of such features without having to push viewer updates constantly.
  • Drop flash support over proper html5 support.

 

Share this comment


Link to comment

Hi Q.

Thanks for your response to the posts in this blog.  It is good to know that you are, in fact, reading all that we are saying.

I know you don't want to discuss Display Names, or Voice Morphing for that matter,  but imho I think you are missing the point behind why it was brought up in the first place.

Regards of how good or bad an idea it is (i'm in the bad camp) it is the fact that things that we have been screaming about for years that need repairing have taken a back seat to yet another NEW feature.  We don't want new features at the moment, Q. I think you will find that we want the OLD features returned to us.  We do want SL to progress and we're not saying don't give us new features but, please, concentrate on giving us the stuff we really do want and need - a properly workable UI.

From the information in the Snowstorm project list I can see that some of these things are, apparently, being worked on.  We all hope and pray that you will actually be true to your word and deliver what you are saying and that it is not more lip service. We can only wait and keep our fingers crossed.  Unfortunately so many have had their fingers burned for so long that we now have a low pain tolerance and are less and less resistant to being burned.

I, for one, do not envy your task ahead.  You are literally in a "make or break" situation here.  The right moves and you will see people begin to build up some trust and belief in SL again but the wrong move and you WILL lose people.  This seriously isn't a case of people saying and not doing.  People WILL leave - unfortunately a lot already have.

Good Luck Q.   I look forward to seeing what the Snowteam produces.  Don't keep us waiting too long though.  The longer you leave us wondering the worse the speculation will be and the less forgiving people will be if it doesnt meet their expectations.

Share this comment


Link to comment

q, thanks a lot for your impetus.

my 2 cents: "more options"? it's not only the miserable ui. whenever i give it a try, lately out of curiosity with the up-to-date release of snowstorm, also my whole invent became a mess. as predicted, as usual. most funny is the behaviour of these not very well designed viewers when talking about personal equipments: after login, the ao isn't attached, prim-skirts either, left shoe and right earring is missing/not attached, fast-alpha isn't working etcetera etcetera. fixing these issues is time-killing.

actually, i am fully satisfied with the evolution from emerald via emergence to phoenix. admittedly, different user entities have different needs. but with the latest tpv kerfuffle i fear a coming more restrictive policy. a dictatorship of the v2, the "unity-viewer". in my perception, todays situation with the existence of an official slim viewer for the fb people and elaborated ones by third parties for savvy residents side by side is just as much a positive solution for the future.

Share this comment


Link to comment

Again some valid points from Q, and a big nod for stepping up and explaining your position, whether everybody agree with the particulars or not.

Here are a couple of cents from me:

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.

Considering the kicking and screaming on on all sides about who knows what about the "true" use of the viewer, and some vocal parties declaring themselves the "true authority" on what "people" want, I agree that sampling the residents is a dangerous path, but on the flip side, it is arguably all the more important that we get some fairly objectice metrics, and if anybody can gather/provide them, it must be LL. But as you say, that is not a small task which can be done for every single idea being pitched.

One problem with the sample implementation style, though, is that (and sorry for bringing up history, but it is a relevant issue) LL has practically never, ever reverted an idea once it has reached the level of being publicly announced. So we have never had a "sample implementation"; at best merely an advance peek at how things will end up looking in the next official release.

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).

At the same time, it is worth noting how people are willing to put up with all sorts of glitches and half-baked versions as ideas shake out, and people can see a good feature/idea forming.

Whether the Snowstorm project can get into such a groove and get people behind it, I do not know. The original Snowglobe project was billed pretty much exactly as this, too, and was, frankly, a miserable failure.

You have a big problem with the massive headstart some third-party viewers have; abandoning them to start playing around with the Snowstorm/Snowglobe project would be a pretty massive loss of functionality for many.

I am not entirely clear on the licensing for the Snowstorm-related code. Do you still need a release from third-party developers for the code to later be usable for dual licensensing?

The way I see it, you practically need to import (or recreate) some of the "killer features" from TPVs (AO, temp/local textures, radar, build math etc) before Snowglobe is a realistic option for people to start playing around with and use, to give feedback on. As is, it is merely some obscure offshoot which you can play with if you for some reason want to compile your own client; not a realistic option over/alongside the TPVs.

In other words, you have some catching up to do before Snowstorm - and in turn the official "non-quirky" viewer - can succeed, and I am not saying that as a slam against the project, but as an honest opinion on how to proceed.

Share this comment


Link to comment

@Q:

Ok, so this weekend I read and viewed everything published and related by/to snowstorm over the last few weeks.

My perception has changed a bit by this. I genuinly believe now you are trying to change the way you work and you want to involve us as users in the process.

I also understand that this is a major change from your previous way of working and a big change like that cannot be made overnight. I hope you acknowledge that as well. Not only is this a big change for you (LL) but also for us as users. My first question to you therefor is:

Do you understand that your old way of working has created an atmosphere of distrust and unsastifaction for the users, and that you (LL) are the only one in a position to slowely mend our relationship. Not just by telling us that you want to do, but by actually doing so?

Perhaps a redundant question since you implicitly said as much on SLCC. Unless I am mistaken?

Now, if it is known that we "have been conditioned" to respond based on previous experience with you, I think it would be best to try and avoid controversial subjects for a while ;-)

Making a remark about "too many options" during office hours was not the smartest move therefor, and then creating a blog post about is was even worse I think now. I would suggest trying to keep blogpost about actual progress and discussion of features/implementations for now. Try and keep it open and fun. See these blogs as a sort of brainstorm session involving the community.

One thing I still have problems with is this:

The current sprint is working on detaching the sidebar. Where did we get to discuss the way you are doing this with us? I guess the Jira, but I don't think that would be the proper place. I really think that a better approach would have been to work out what you are planning with the sidebar, post that here and let us brainstorm about it.

I undertstand your view on how people have difficulty undertstanding something if they cannot work with it yet. But also consider that some can, and that in a stream of thoughts llike here on the blog there is bound to be an idea or two that you hadn't thought of.

But not just that, polls may not be the way to go, but looking at discussions like the one taking place here, gives you a huge insight in how people think and work. in this thread alone I quickly counted more than 10 posts that tell me a lot about how people use the viewer. Even though that was not the intent of the poster.

But even if those arguments make no sense to you, letting us discuss your ideas about changes before you start working on them at least gives you the opportunity to explain to us why you made that descision despite given arguments. The alternative is to maintain and feed our "expected behavioural response" so we can keep yelling "LL doesn't listen".

again, after reading all about snowstorm I have slightly changed my mind and am at least happy with what I hear. I am not happy yet as to how what is said is being implemented. To keep the discussion simple: You are working on detaching the sidebar right now as I write this, but I have no idea what that practically means. What will it look like? how does it work? What will change?

So in effect, it is still a black box and you are still giving us a release with a "tada" effect (even though it isn't your intention).

Tell us now, in detail the changes that will occur by making the sidebar detachable, and let us share our thoughts and ideas about it, before you start spending time and money on coding.

Share this comment


Link to comment

 

Please allow me to give an example. I see in the backlog you are also working on “VWR-20713: Double-click on land to teleport”

I am taking this because it is relatively “simple” item to discuss and it involves options ;-)

Personally I would rather “auto-pilot” to the spot I double-click instead of teleport. And I know of others who would like that as well. Not only that, but in emerald I sometimes double-clicked by accident and I don't like that either, so we must first define the problem perhaps like so:

When a user double-clicks on ground, one of three things can happen:

  1. The user teleports      to that location.

  2. The user walks to      that location (or flies if the user is flying).

  3. Nothing happens.

 

How do we make it so that we have this functionality and still don't overcomplicate the interface or introduce unnecessary steps/clicks in the UI.

Second question: Is this all the functionality needed or are there other use-cases for double-click on land?

It is just an example. But I think this type of posts will give more positive and useful feedback than posts about design philosophies, no matter how well intended ;-)

Discussing before creating is NOT about having people tell you HOW they want it, but about what they need and more importantly about what they don't want. It is still up to you to translate it into a good product.

Share this comment


Link to comment

Q, thanks for stepping into the arena and defending why you do what you do.  I may not always agree, but I do respect that the positions are considered.

Share this comment


Link to comment
  • When a user double-clicks on ground, one of three things can happen:
  • The user teleports      to that location.
  • The user walks to      that location (or flies if the user is flying).
  • Nothing happens.
  • How do we make it so that we have this functionality and still don't overcomplicate the interface or introduce unnecessary steps/clicks in the UI.

By making it so that if you 'double-click'  WON'T teleport (or walk) the avatar if their mouse is over something with a scripted Touch Action or some other default click action like sit, pay, open, etc.    I tried this feature in emerald and rapidly turned it off because it failed to make this distinction.

Share this comment


Link to comment

I didn't post about double-clicks so we can talk about it here. I posted it as an example. Let's not dilute this thread any further :-)

Share this comment


Link to comment

Q, first of all thank you for taking the time to answer some missives here, and especially thank you for taking the time to read this lengthy, lengthy blog (and it's very obvious you actually did so).  That's something I doubt anyone expected... and I respect that.

That said, I pretty much disagree with your whole answer. ; D

I'll try to explain why, without pounding things into the ground, but doubt I'll be able to be brief and still get the point across properly.  Hope you have a cuppa. : )

 

"I'm not going to defend past behavior; no point."

Agreed, it's not your job to defend past behavior.  We're not belaboring past behavior; we are griping about past behavior continuing in current behavior.  We just use the past behavior as a touchstone to point out that current behavior has not improved.    Linden Lab is still making arbitrary decsions, still going ahead with projects no matter what customers think, still ruling Second Life in a dictatorial, self-serving manner.  I'm not saying that to be rude, insulting or mean.  I'm making a statement of observable fact.  That's why your customers are angry-- and outspoken.

 

"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."

Q, we have said far, far more than "see, it's horrible!"  Customers have stood up and openly told you folks in great detail exactly why we think it's a bad idea.  Are you, the CTO of Linden Lab, unaware of those posts?  How can that possibly be? (am I right... you are CTO, yes? If not, excuse the misinfo on my part.)  Still,  CTO or not, I would think you would be aware of the extensive posts users have left regarding the Display.Names issue.

Experienced users have stated exactly the impact DISPLAY.NAMES will have on the grid once implemented (just like we warned you all about the effect the Homestead fiasco would have on the grid... and that you folks ignored until 5,000+ sims shut down).  If you'd have listened to us early on, you may have cut your losses to 500 sims instead, but nuuuu.  And that's what we're saying Q:  Linden Lab habitually ignores customer feedback.  You're one of the few Lindens I know that has the courage and decency to get out here with us on the front lines (which is why Q, we respect you more than others, even if our feedback in general is very frank).

The comments on DISPLAY.NAMES was not to bring up DISPLAY.NAMES *here*, in this thread.  It was to drive home the primary point we are making Q, namely, that Linden Lab is not listening to its customers (the ones paying the bills)... even when we find ourselves forced to scream our "feedback".

Display.Names isn't the issue Q; it's just a symptom of the disease.

 

"Voluntary polls and votes are basically worthless -- they're completely subject to advocacy and gaming."

Yes Q... if they're conducted by a bunch of clueless chowderheads.  Ghostly already covered this, but I'm going to repeat it:  you get together with a large random sample of users, poll those users specifically for their feedback, and work with the results off of that.  Yes, that takes time, effort, and enough skill to know how to conduct a proper, balanced survey in the first place.  But companies do this every day of the week, successfully.  It's called "market research"... something that we've seen very little of at Linden Lab.  Most of what LL appears to do is, "Hey, we think this is a great idea. Let's inflict it on the grid without asking anyone."   Tell me if I'm wrong. ; )

 

"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."

Poppycock.  I'm sorry Q, but there is always time to do a project right in the first place, rather than doing it wrong-- and redoing it and redoing it wrong over and over.  There is nothing about a customizable interface, that would take any more time or be any more difficult to do than any other coding project.  What it does take however, is a coding and management staff that doesn't constantly make excuses... and then keep foisting time-intensive and costly inferior product on their customers.

(Again, I'm sorry for being so blunt, but you have to realize we've been telling LL this for years, until we're blue in the face.  We are way past being "PC" in such discussions.)  Q, I've been a businessman all my life.  I know when to call an excuse an excuse, and I know how to get a job done when it needs done.  From what I've observed, Linden Lab doesn't.  The company is so tunnel-visioned it doesn't see the simple and obvious solution standing just to the side.

I'll pass on some wisdom here my father passed on to me:  Do it right the first time, and you won't have to waste time re-doing it later.


"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."

I will second what Ghost said already: Linden Lab has never created a product that is reasonably bug free, met the needs of its customers, or that is "complete and suitable for all users"... and frankly I don't think you folks will ever do so.  Linden Lab constantly "ships buggy, incremental work".

To once again be blunt:  Linden Lab has a long history of releasing on the main grid shoddy program design and coding, full of bugs that then remain on the grid for years.  So please, don't tell us you can't use TPVs because they're supposedly buggier and more seat-of-the-pants than Linden Lab coding.  You folks can't even get chat and group notices right.  That's just plain embarassing.

Frankly, the company could learn a trick or two from TPV coders.  They have managed to accomplish something that Linden Lab has totally failed to achieve:  They have given customers what we want and what we need in a reasonably bug-free format... far more bug free than comparable LL products.  Not only that, they've done so in a speedy and timely manner...and they fix bugs.  Seems to me they know more about what they're doing than Linden Lab.  So your company might do well to incorporate some of their ready to use coding in your product... even if you have to pay them for it (which is only fair).

 

"Well, we've said it before -- we know we missed the mark with some of 2.x -- but it's our base going forward."

I understand.  So do it the right way, and stop doggedly insisting on retaining problem areas that users have repeatedly screamed about.  You folks are Ahab following the White Whale.   So go ahead, pursue 2.x obsessively.  Just do so the right way.

You want to use 2.x as the base... go right ahead.  But for heaven's sake, fix the interface.  Otherwise, well... remember the Homestead fiasco...?  (What's it take for Linden Lab to learn a harsh lesson... another 5,000 sims shutting down?) Back then people told you folks we'd shut down sims.  Linden Lab ignored us.  We shut down sims... thousands of them.  Now people are telling you, "Force 2.x on us, and we're leaving."  Pardon me again for being blunt Q, but what's it take for LL to get a flippin' clue?

 

"'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."

Yes, the cat is out of the bag.  What we (the people) believe does matter... because the people took that open source snafu and created your stiffest competition to date.  Ergo Q... open source wasn't a "philosophical question" for Linden Lab... it was a boneheaded tactical business blunder, one that I and other professionals recognized as such the moment Linden Lab announced plans to do so.  But then, like now, Linden Lab didn't care what we had to say about the matter, so we stood back and watched as Linden Lab in a self-inflicted one-two punch (open source viewer and homestead fiasco) put your competition on the map... where before you pretty much had none. That doesn't sound like a "philosophical issue" to me.  It sounds like suicidal decision making.

Do you folks now begin to understand the consequences of ignoring your experienced customers?  Don't get me wrong; it's your company.  You folks don't have to listen to anyone.  Linden Lab can make its decisions however it wants.  But... we customers do hold the purse strings.  And in the end Q, it will be us, not Linden Lab, that makes the ultimate decisions... one way or the other.  That's the point I and others have been trying to get across for years.

 

"In short, we do care what you think, and what you say, and it's because you care that these discussions get contentious."

In this we are in agreement, Q.  Again I ask your toleration in my being blunt above.  NONE of this was aimed at you personally. You're here.  You took the time to read this blog.  You answered us. Whether we agree or not, however we respond, you can know Q, that most of us appreciate you talking with us here.

All that we've ever asked of Linden Lab is that customers have some say in the decision process.  Why?  Because those decisions affect us, they affect our businesses... and those decisions will determine the future of Second Life.

In a way, we are all investors in this board.  I would have to believe in fact, that customers as a whole have invested far more than the heaviest venture capitalists in your firm.  Not only that, but we're out here, in the trenches, 24/7/365.  We know how SL works, we know how it should work, and we know how we need it to work.  No company that hopes for a profitable future should ignore that incredible wealth of knowledge... especially when ignoring it can lose that source of that knowledge... and the profits along with it.

Thanks for listening Q.  Expecially to cranks like me. ; )

But please... do listen.  There are a lot of folks out here telling you folks the same thing... over and over.

 

 

 

 


Share this comment


Link to comment

No, there's no sizeable population that "needs" double-click to move on the ground or "teleport".

That's a geeky gamerz affectation from MMORPGs -- Raph Koster rushed to put it in Metaplace, and it was only annoying and confusing.

In the SL setting, it's double annoying as clicking on the ground now brings "create" or "about land" menu.

Why are the Lindens working on this sort of thing without REALLY canvassing the *bulk* of the user population that has not asked for it and doesn't need it?

It's a MMORPG hangover and the discredited Emerald geeks putting it in their now-banned viewer doesn't mean it "has" to be brought forward to 2.x

This is exactly the sort of thing that I mean by asking Q exactly what is hiding under the hood of the idea of "more options". If all it is is catering to special interest groups like this, why are you doing it?

Share this comment


Link to comment

Again: most people ignore the minimap because it's rotating is confusing and it's hard to orient because it contains no landmarks on it visibly like the regular map, which you can also pull up and also use to see if there are other people on the sim.

Many, many people use Mistitool to let them know if another avatar is approaching or lurking. They don't use the mini map because it gives no names. It doesn't supply enough information.

Certain oldbies, long-time gamerz, geeks, they swear by the minimap because they are people who like maps and directional interfaces in RL, too. But most people in America are poor in geography, especially women, and don't use maps. Googlemaps has spoiled them further; they don't have to read maps now, the map reads them...

A simple poll will show this, so I'll do one inworld soon.

Share this comment


Link to comment

"I didn't post about double-clicks so we can talk about it here. I posted it as an example. Let's not dilute this thread any further :-)" -- Pentasis

Considering how utterly ineffective asking people to stay on topic is in these blogs... one could say that posts asking not to dilute the thread ... also dilute the thread. ;-) ;-)

The point is... whether LL will embrace adding options... or stick to a "We know best, you get what we give you." model of viewer that forces us to adapt or resort to TPV's. 

Double-click-move or double-click-teleport is a perfect example of the kind of feature that if implemented MUST be made "optional" because many people want it... and many people DON'T want it.  It's relatively trivial to implement, but the sticking point relevant to this debate... "Does the viewer need yet another option that requires LL to forever support both click-to-tp and no-click-to-tp?"   And whether or not adding simple optional features like this makes viewer development too costly in terms of development, testing, etc.

Share this comment


Link to comment

×
×
  • Create New...