Jump to content

Tools and Technology

  • entries
    86
  • comments
    916
  • views
    93,219

Contributors to this blog

Check here if you want more options

Sign in to follow this  
Q Linden

9,047 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



I am not an engineer. I have been in Second Life almost daily for four years. I have found the Emerald viewer to be the best designed viewer (most intuitive, most powerful, most flexible, most intelligent) I have used so far. Conversely, I have found the LL 2.1 viewer to be the worst viewer I could possibly imagine.

Between 1/3 and 1/2 of your residents share my opinion.

You don't need to be a rocket scientist to reach a conclusion from this information.

Edit: I have just switched to the Phoenix viewer (the new Emerald). Works like a charm. I won't be contributing to the Snowstorm Project because I no longer believe that Linden Lab has the design skills or technical capabilities to produce a viewer. I increasingly see Linden Lab as a Soviet ministry instead of a commercial enterprise.

Share this comment


Link to comment

You guys really need to give the client installation more thought, and starting treating it mostly like an OS  install.  You have "recommended" install, based on the user's system hardware, plus "advanced/custom" install for everyone else. Then approved TPV's can also be in the install like Web PI 2.0. Let's work on breaking down options, putting SL & TPV in one platform installation, and let us do what we do best.

Share this comment


Link to comment

@Ceera.Murakami

Your post pretty much sums up most of what I find infuriating with V2

Common tasks took more mouseclicks, or became flat out impossible. Multitasking is almost completely impossible in 2.0, for example. And throwing even more things into that modal sidebar makes no more sense than a Swiss Army Knife with 5,000 blades that is three feet wide, welded to a post. It becomes unusable.

is particulaly pertinent.

Using V2 is like trying to eat your dinner with your knife and fork welded together.

@Alx Harrop

Again, everything you say fits in with my thoughts, especially...

Another thing I really hated was getting people's RL info right in the face (with RL pics!) when checking their profiles. As a role player, that really messes with immersion. RL info contrasted with RP info = really bad.

 

I really want a better viewer than the v1.x codestream but v2.x will never be used by me whilst the sidebar can only deal with one task at a time.

 

Having few options is probably a good thing for people starting off but as people get more confident and more skilled, they want to be able to customise their workflow better. There's so many different interest groups in SL that there's no way everyone will be happy with a limited set of options so you simply have to bite the bullet and aim to provide the ability for these groups to work out their own workflows. If that means more options, dialog boxes and preferences, then so be it.

Share this comment


Link to comment

As a reply to the OP, I also think that there can never be too many options. As many people there are on SL, each would have a different idea on the ideal interface. Viewer2 IMO fails miserably. I had an easier time with the HIPIHI viewer and that was all in Chinese. I think you need to drop the browser idea and look at CAD or even word processing applications. One of the most powerful aspects in these programs is the ability for the user to highly CUSTOMIZE the UI. Maybe you can take a lesson from those developers: Provide a basic interface (the 1.XX is not all that bad) but provide the ability for the user to add buttons for the features he/she wants, dockable to any of several places on UI at their discretion. When working in CAD I often customize the UI to suit the project.

 

SO LOTS OF OPTIONS AND LOTS OF BUTTONS AVAILABLE AT OUR CHOICE. However, after a week in SL (or less) a person does not need full words in large buttons for "Communicate", "Fly", "Snapshot", "Search", "Build", etc when a small graphic on a small button would do. I drool at the thought of how I could organize the bottom on the 1.XX viewer if I could only customize it. I'm sure my interface would differ greatly from any other on SL but it would work great for me and that's the point of a UI.

 

I have not read all the posts, but I believe that there is one more point you have ignored and was not mentioned in the idea of "fewer options". Fact of the matter is that if you don't include a popular option in the UI, people will market it in a HUD. Off the top of my head I would mention AOs, Radars, NPVs or Phantom Avis, TP history, etc etc etc. The list could go on & on. If these features are not included in a viewer they will unnecessarily consume script memory which LL says will be limited per Avi in the near future. Make sure that in the processes of lightening your team's workload by limiting options you don't again shoot your bosses in the foot as seems to be the LL tradition. It would be a welcome change if Project Snowstorm grew to a blizzard rather than just another snow job.

Share this comment


Link to comment
I had an easier time with the HIPIHI viewer and that was all in Chinese.

I laughed when I read this because I had the same experience!

I drool at the thought of how I could organize the bottom on the 1.XX viewer if I could only customize it.

YES.

Share this comment


Link to comment

Q, I've extended to you the courtesy and respect of frank honesty.  If I thought less of you, I wouldn't waste time here.

My point (I don't know about others) might have been a bit too subtle.  Let me spell it out as clearly as I can.  And to be crystal clear: this is meant in an *entirely* constructive manner.

 

That said: let me try to clarify.

a) The Options question comes about from trying to design the perfect viewer for everybody.

b) A one viewer design for everybody probably isn't going to work out very well for anybody (I think this is somewhat obvious)

c) The complex, optioned solution has always been there.  In stark terms: there have been X hundred million hours of user experience with the old style viewer and its dizzying array of options.  Could it be better?  Sure.  But changing it substantially makes about as much sense as forcibly swapping querty keyboards for more efficient dvorak ones.

d) For the simple viewer, embrace the simplicity you are looking for.  Strip off nearly everything except what a brand new user would need in the first ten minutes and put an "Advanced" button to toggle on there, when they are ready for more.  That's about the only way you'll get close to a universal viewer solution.  And that advanced view should look fairly familiar to oldbies.  It doesn't have to be exactly the same.  But if it's not close enough, they will keep doing exactly what they are doing now: ditch your design entirely for third party viewers.  Rendering the entire effort a waste of time.

* * * * *

Hey, it's a holiday weekend, this is a text discussion where tone is hard to read, and by posting on the blog as a Linden it risks earning the legacy of all who have gone before you: the residents have a nearly knee~jerk expectation that they will be ignored, in lieu of some very bad decisions to follow.

This isn't your fault, it's just a painful reality of customer~facing communication here in 2010.  As technical people, you aren't (really) being paid to pet the customers, you are usually hired on to get the job done right, and get it done effectively.  Most corporations would shield people in a job like yours behind management, focus groups and locked doors.  Linden Research is different.  As such, we all have to act differently to take advantage of this.  I'm not going to be thin~skinned about a frank reply from you... and likewise, you can't be thin~skinned about what we say.  Even if some of it doesn't seem constructive.

As for what Yoz is saying there... I get it, and I think most of us get it.  There are ridiculous numbers of longtime industry professionals here.  I've had to design life~critical user interfaces myself (most of which have been maintained as effective since the early 90's) and face far worse feedback than this.  It's not fun, it's a job.  My end users were automotive, industrial and military,  often operators of heavy equipment or infantry warfighters ~ they didn't 'do' subtle or gentle feedback.  I've managed engineering departments with several design teams, and my background is lightweight compared to some of the other people posting here.

But even though what Yoz is saying is true... it's not enough.  Yes, QA is a challenge.  But it can't be a deciding factor, unless you want to turn out something less useful to the average user than a third party viewer knocked out by some college student over Code Red, cold pizza and Hacker's Quarterly.

If you need QA help... simply call on your greatest resource ~ us.  I was one of the, oh, maybe 100 people who previewed v2.0 when it came out, and then next thing you know... it was out.  We shouldn't have been 100 people, we should have been 100,000.  The incredibly early (and largely adopted) suggestions we made in Preview weren't acted upon until the viewer was made the default viewer anyway... this was clearly a case of "we the designers are right, you the users are wrong and you guys will just have to adapt."  Development was done right for years the traditional way: all users were provided both a stable version and a newer, less quality assured version to download and give feedback about.  It's time to go back to that.

As someone who does business on the grid... I'm forced to use whatever the standard official viewer is, due to liability concerns.  Like it or not, we are stuck with each other; I can't afford to put my account within range of a malicious coding team.  A *lot* of us are in the same boat.

We don't want to be contrarian, but on the other hand the v2.x decision was like being told we will drive a minivan in the future (or take our chances on say, Emerald) when what we needed was a four wheel drive pickup truck.  It's not just harming us directly, it's interfering with taking care of our resident customers too.  So yes, it's likely you'll see some passion on this issue.

It runs deep.  One resident on my estate had an entire course curriculum designed around v1.x, with university students trained and in process.  With the forced change, she had *zero* time, grant money or classroom hours to switch over.  Hey, change is necessary sometimes.  But it was brutally clear to her that she wasn't dealing with a reliable corporate partner after that experience.  I'm sure you can guess where her expectations are right now, and what selection of viewers she will use.  Presuming she stays.  This is where business 101 matters, and overrides all technical considerations.  She was training entire classrooms of students in the use of your product.

If I could, I'd buy your group a round of your favourite on a Friday afternoon... and just might, if I find myself in the area.  All I ask is that you guys are completely straight up with me (and it seems you are, so far ~ I'm not thin skinned) and I shall be competely genuine and honest with you.  That's the highest form of respect I can show.

Desmond Shang
Independent State of Caledon

--||-

Share this comment


Link to comment

Regarding the various accusations of condescension and not listening to our customers, how about a little reciprocity?

 

You are likely feeling the sting of years of resident frustration.  I would be willing to bet a large amount of the backlash you will see over this will come from a multitude of LL actions (and inactions) over the last few years.  From my own personal experience, it seems that LL has become more and more distant from SL's residents, and the disconnect between Linden Lab and its customers becomes more and more evident with each major announcement we receive.

Regardless of whether much of the frustration you are seeing is born from your remarks and subsiquent interpretation or not, many of those commenting have a laundry list of legitimate reasons to be upset.

 

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.

 

This is the problem.  Most of us don't care what Linden Lab's desires are.  We are the customers, and we want Linden Lab focused on OUR desires (especially those of us that have Premium Accounts and own land).  Linden Lab has been struggling with this basic conflict for years.  We provide the content, we provide the economy, we provide nearly all of the appeal that Second Life offers, and yet it seems that we are the last people to have a say when it comes to huge changes to the service offering.

 

I'm listening and trying to engage, are you?

 

Many of us are willing to engage Linden Lab in meaningful discussion relating to features and changes to them.  But may of us feel that we are shouting at the rain most of the time.  It keeps falling no matter how much, how loud, or how often we scream "STOP!!"

One thing I can say for certain... I am tired of seeing friends leave.

Share this comment


Link to comment

Well, to be honest, if you really plan to gain users back to use the LL viewer, than you will have to make options to change the UI.

The V2 UI is what drives the most away, the sidebar is for many users a just terrible thing, its big, uncharming, all is pressed into, the functions are harder to use, and so on.

My dad teached me, that "learning from the best" is always a great way to improve, so, look at the very successful TPVs, learn from them.

Share this comment


Link to comment

Q, I think some of the problems here is language. Options and features, to many of the users, mean kinda the same thing. This might need to be explained more.

Consider that these forums are used by many different people of many different backgrounds and ages. Plus, with so many things that are not working as expected, ie search, no Lindens should realistically expect to be given any kind of cheery responses.

Last point - Forgive me if I'm wrong here, but the issue of options came up because of the WASD discussion. Moving about within a virtual world is a key area of development, and 1 that easily makes that world sink or swim. Chat is also 1 of these key areas. SL did much better in these areas, in the past, which still puts it way ahead of places like BM. WASD screws up both of those key areas. If there is 1 most important area where options are major, I'd say it is here. Personally, I use a 5 button mouse and connect the 2 extra buttons to my forward and back, with jump being on my middle scroll button. I turn by grabbing my avatar. This is what I meant by saying I don't touch my keyboard, unless I'm chatting.

On a sidenote, I did see something about the key.ini changes we can make, and I love the idea of playing around with this. It would be cool to make this and internal viewer thing, where as we can alter this by adding a notecard to a window, much like the internal AO inside emerald.

Just my thoughts

Share this comment


Link to comment

A few thoughts on the OP:

Preferences - Instead of piling everything into Preferences, i like the more intuitive idea of using a right-click menu for UI options. Just right-click on the affected area (as Aquarius described so well! Not to mention the idea about easily changed UI colors!!) then have a small pop-up menu to use for customization.

Side-bar - What if the side bar was positioned to rise from a bottom tab instead of a side-bar, or maybe a drop-down bar from the top (length-wise).. although that may take up to much "real-estate".

Viewer focus - It's also not a bad idea to consider either seperately focused viewers (i like to call them "focae", a word i made up) or "plug-ins"/"skins" where you can change the viewer set-up on the fly (probably preferable, even though harder for sure). Might be easiest to compromise the two ideas.. have one Basic viewer, all easy-peasy stripped down fun viewer (no focae options); then one Advanced viewer, which would then have further focae options within it.
(Gavin makes a good point about seperating the UI in a manner that would allow greater and easier distribution/availability. Not sure how hard that would be to do, but sounds like it could definitely be worth it in the long run.)

Chat/Movement - I noticed the chat/movement discussion and was thinking how i started using the WASD movements more commonly, as of recent. It's more intuitive as that's a common interface for movement among the crowd which is used to 3D environments on a computer, such as MMOs. I like being able to use them to move, then just hit "Enter" when i need to chat. Intuitive.
(As an aside, i'd like to see the "Q" and "E" keys allowed for movement as well, so we can have both turning and strafing movement, instead of using Shift-A/D)

Snowstorm? - On another note, i thought the Snowstorm project was all about including Residents in the development and coding of certain viewer properties? Wasn't that what it was about? Kind of like a half-way point between V2 and TPVs? Or am i missing something? It seems i hear a lot of people asking for us to be included, but i could swear that's what Snowstorm is already doing.

Complexity - As for things being complex and how that can work against Resident/user satisfaction, i can understand this, too. I don't see you saying it won't be done for that reason, more that it should be considered when figuring out the best way to move forward. Making it easier for you, in this case, does make it easier for us... when that means the viewer has less work to do, which means it has a higher chance of working well and properly.

-

@Pathfinder - Lord Frith! : )

@Winter - Excellent post! Some really valid points in there! Especialy how the community is already riled up and, while hard it may be, to try to glean what the real message is behind it all. (I, also, am excited to ssee what's been happening in Snowstorm.) Thanks for that awesome post!

@Q - I hear you and see no fault in a developer defending themselves. While i can certainly understand that people would be frustrated at this point (yes, that's put lightly), i can also see what looks like LL, and you, holding out a hand to try to work together more symbiotically than has been done in the past couple years. Basically, it's ok to be mad, but let's not hate on each other.
And for what it's worth, i thought the initial post sounded quite open and inviting, while defining what you wanted to hear feedback about. That wasn't to hear what's wrong, but asking to hear how it can be better. (And thanks to Winter for reminding me... i hope you're doing well and feeling amazing. You're call into SLCC was above and beyond, thanks for making us all get a tear in our eye. : P)

(Lindens can get frustrated, too. It's not easy to have a large chunk of  the responses practically yelling at you and telling you how badly you're doing, knowing the only answer that would make everyone stop yelling is to tell them that LL will do everything they ask for, every little thing without question. The problem is, also knowing that such an appeasement could never happen. Just like when Bruce said "Yes" to all of God's prayer-mails. Not necessarily the best idea.)

Share this comment


Link to comment
Sure, advanced uses need advanced features, but we don't have to make everyone confront all of the complexity.

Talking about preferences, I would prefer a check mark like 'show expert options', so you can keep functionality where it belongs and everybody knows to mess with it at own risk. Also a good way to show some experimental stuff to technically versed residents. Just make the difference clear by coloration or w/e. What I can tell from TPVs is, that whatever a dirty mess of options it may be, some alternative features become famous by word of mouth anyway, as soon as it's easy to trigger. Certainly I would add the ability to reset all preferences to default (after crash).

Anyway, from a creators point of view I prefer to have the same experience like the majority of residents. So I really hope you guys will fix the UI first, like floating windows and stuff. In a short term I would be happy to see more contrast/coloring. Especially for the building panel. It's tiring to handle it with all this gray in gray. Well, keep up the good work. I'm curious what may come up.

Share this comment


Link to comment

Hi All, la here. Don't post often, well *almost* never.  BUT, as some may know, historically "present" and  heavily vested, just trying not to be as much of a flammer as one of my neighbors tends to be .. usually. However, this latest forced upgrade with preset options changes bothers me greatly! I serve newbies and serious teachers, graduate students and academics in particular. Have to say, the new default to "absolutely lowest" graphics denomenator is absurd and completely out of touch. Options there, hidden or not, when someone starts up the system for the very first time, setting their default view to show a system that looks like virtual worlds circa 1980 is, well, you substitute your own word. Try it. Power user is nice, but have you taken a look at what a good old relatively older virgin system suddenly sees with the new download when the old one saw everything just fine. Seriously, circles become octagons. Brilliant, not!

If you are trying to worry about keeping the new users around, making them figure out all your graphics options to even see anything remotely as well as we all have been seeing for 5+ years is rediculous! -la

Share this comment


Link to comment

Q,

   I really do not think problem is "accusations of condescension" so much as the fact that we have been through this "input" exercise many times with little or no effect on Linden decision making. That said, I will try again.

  Options, no matter how you classify them are the essence of SL, this is after all still our world / our immagination. None of us has any desire to live in your, or anyone elses vision of what SL should be.

  I would suggest you put your pride in your bottom drawer and take a serious look at Emerald and it's variants, the reason it was / they are so popular is Options, if they could do it, you surely can!!!

  As for Viewer2; if you have not gotten the messages, general and specific by now there is no point in me reiterating them. As it is now it is usless to me in spite of a few nice features.

  Please keep working on it, but this is not a one size fits all world. Keep as many options as possible and LISTEN to your paying customers. We are willing to help but we are tired of being ignored.

Share this comment


Link to comment

Q: I'm not going to add to the comments above about the relationship with people who are trying to give you feedback.  The many, very well-written posts have expressed the situation perfectly.

 

I will however comment on the technical matter of UI options, because I believe that you are almost entirely wrong about this.  The issue splits into two parts, presentation and implementation.

 

PRESENTATION

 

For a user, options only introduce complexity and confusion if they are presented randomly or illogically, and without any means of self-help.  Even a small number of options can be badly confusing if presented randomly, yet nobody would suggest that a supermarket is confusing just because hundreds of thousands of items are on offer.  Humans are extremely good at scanning large number of items, especially if you give them cues or hints.

 

It is the job of a good UI designer to ensure that all features are presented in a way that is as clear as possible, which is not easy, but it's a discipline with many years of study behind it.  To suggest that we're reaching a point where more options would go beyond what can be presented cleanly seems to be false by simple inspection, and you have not justified such an arbitrary position in any way at all.

 

What's more, the UI designer has a number of powerful weapons at his or her disposal which have not yet been deployed, or have been used poorly so far.  In addition to classification or partitioning into submenus and subpanels and tabs, GROUPING and HIGHLIGHTING within a given panel is a very powerful technique which is almost unused in the viewer, yet it can convey a large amount of semantic information and helps trigger our highly evolved pattern matching abilities.  (And it looks pretty too!)  We should use that a lot more, instead of making Preferences tabs all look visually similar.  To a degree, grouping and highlighting can be applied to menus as well -- Debug Settings certainly needs that.

 

Another very powerful weapon at our disposal is VISIBILITY.  If you care to look at this Jira I filed a day or two ago -- http://jira.secondlife.com/browse/VWR-22781 -- you'll notice that *visibility* of each UI element is one of the UI attributes held in configuration data stored under each preset.  This is important, because there is no better technique for simplifying an UI than making parts of it disappear!  Visibility control should be hierarchical so that entire sections of the UI can be made to appear or disappear for a given preset.  Couple this with a user being able to drag any desired visual elements to user-defined panels or edge frames and you have a formula for making UIs as tiny and as simple as the user wants at any given time.

 

What's more, the latter offers "user-definable UI design" -- you don't have to get it right (an impossible task anyway) because layout and visibility are in the hands of the user, and you only need to provide UI infrastructure.  It also makes your 50/50 vs 90/10 argument entirely moot, because it has the potential to satisfy everybody independently.  I can't stress enough that there is no single UI layout that can satisfy everybody *simultaneously*, at all points of their day, so looking for a single median or a single subset is a severe mistake.

 

Finally, we have not even begun to use UI assistive technologies, such as searching for UI entries by name, or providing multiple views into the UI classification space, nor adaptive technologies such as contextual selection and UI learning.  Nor have we even begun to explore what pluggable extensions can bring to the table as a means of improving the UI for users.  These are very early days, and suggesting that we can't handle many more options without trouble just makes no sense at all.

 

IMPLEMENTATION

 

On the development front, I'm puzzled by the objection to more options.  Nobody codes options handling as a huge chain of if-then-elses anymore (well, nobody worth employing anyway).  Instead, options handling in non-trivial applications is typically callback-driven in the UI, and complex optional runtime functionality would typically get refactored into a semi-formal control mechanism like a state machine to prevent it getting out of control.  Callback dispatch and state control tables are inherently extensible without a complexity explosion greater than linear (as long as you pay some attention to state isolation which is a normal feature of OOP), so I'm puzzled by the expressed worry.  (The state explosion you described in your renderer code sounds like you're using too much shared code and not enough specialization.)

 

One area that does suffer enormously from complexity explosions is concurrent programming, and if you continue to use shared memory multiprogramming in the viewer then you will pay dearly, but that is your choice.  The right way to do it is to let the operating system handle your concurrency and provide hardware-guaranteed state isolation in processes.  We have discussed this approach many times over the last 2-3 years, and more recently the same topic was examined in the opensource-dev discussion about client-side scripting in February and March.  Since you have used this technique for media handling already, I am sure that you understand the benefits, so I would expect you to refactor more parts of the viewer into separate processes to reduce monolithic complexity and eliminate shared memory multiprogramming.  This kind of refactoring during program evolution occurs in all non-trivial software, and if having more options means that you have to tackle it earlier rather than later then this is a very good thing, since less effort will be wasted in a non-sustainable direction.

 

Very helpfully, your "alternative a)" tells me that there is a ray of light at the end of the tunnel:  you recognize what needs to be done, but you say it's a long way off.  That's a reasonable statement when work has actually started but the timeline is long, but otherwise it's simply a brush-off even if unintentional.  The road to coding hell is paved with good intentions, and the longer you wait, the more likely you are to end up in that hell.  We need to start on a viewer extensions / plugins system right now, not later, because as you rightly suggest, that's a known path to the desired goal.  Now that we have Snowstorm and a framework for open design, planning and development, I'm hoping that we can start on this work immediately.

 

Before I end, there is a cross-cutting issue that needs to be highlighted.  As I wrote in the Jira, virtual worlds inevitably evolve and become ever more complex, and UIs need to evolve and grow similarly in order to interface with all the features of those worlds.  This cuts across presentation and implementation alike.  Growth in features and hence options cannot be avoided --- we just have to deal with it.

 

PS. I suggest that the "Options are bad" argument be left to the mists of time.  It's more useful to replace it with "Let's work on multiple ways to refactor this monolith before it gets (even more) out of hand."  This addresses both presentation and implementation problems simultaneously.

 

Morgaine.

Share this comment


Link to comment

Q Linden wrote:

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?

 

Q, there are a few things, you as a company, needs to quickly get a handle on in your communication before this snowstorm develops into a blizzard:

  1. It is more than likely that the number of people making their entire income in SecondLife is substantially higher than the number of Linden Lab salaried staff. If you add to that the people who make a significant portion of their monthly income in SecondLife, you are looking at 2500+ number (according to your last resident profit distribution stats.)
  2. You, as a company, are totally dependent on the content providers in SecondLife. Without them, your company would become irrelevant to the customers you try to attract.
  3. For a good section of your customers – the section who provides the bulk of your income, you are not much more than a platform / service provider from which they expect stability, performance, support and reasonable protection of investment.

The reason why you get the reactions you get from the above section of your customers, is that a number of the initiatives you have – let me say, sprung on these customers, such as viewer 2, changes in search and the SL Marketplace, significantly impacts, mostly negatively, these customers ability to make business in SecondLife.

What you in essence is doing is taking away the tools of the trade these people use more or less every minute in SecondLife in the process of doing their business. The business you, as a company, is 100% dependent on for your existence.

---

You know what?

After seeing your colleague's response earlier in the thread, the prospect of creating a new avatar to participate in the anniversary of an alternative viewer, on another grid, seems so much brighter than continue to flog this dead horse that viewer 2 is.

Share this comment


Link to comment

Naturally, there needs to be a good ballance. But if there are doubts, customer satisfaction should win.

I absolutely agree. What I'm talking about is the part leading up to the doubts: is the requested change worthwhile? Like most work, this is a costs-versus-benefits judgement: The costs are the time and money spent on designing, developing, testing and maintaining a change; the benefit is (amongst others) the increased customer satisfaction.

What I was trying to say was that testing and maintenance are a far higher cost than many people think, and if we can bring those costs down, we make it much easier and quicker to make the changes that people are asking for. The way we bring those costs down are by making those changes in a way that adds as little complexity as possible. I'm not raising QA cost as an issue because we're lazy; it's because we want to be able to do more of what people are asking for.


It's off topic here, but from some of the JIRA comments from the Marketplace team I got the impression their primary goal was to write as little code as possible. Generally speaking, if thousands of users suffer because one programmer made his life easier, there's something wrong. Don't let that happen with Snowstorm, please.

If the goal of the Marketplace team was really to write as little code as possible, we wouldn't have a Marketplace; we'd have a Desktop Tower Defense high-score table. The goal of the Marketplace team, like any good software engineering team, is to write as little code as possible to meet the project requirements. These requirements may change as time goes on, and as feedback comes in. (Pretty much every bug report can be categorised as either "This code isn't meeting this requirement" or "Please change the list of requirements") But "less code" is a vital tactic in software development. Less code* means less complexity, less friction for making changes, easier test coverage, and fewer hiding places for bugs.

* "Less code" has an implicit "written sensibly" after it, to fend off the inevitable arguments.

Share this comment


Link to comment


Your saying that by ignoring the changes your customers want, it will be quicker and easier to get through QA, and that will mean you being more responsive to your customers... yet how can you be responisive to your customers if your ignoring them in the first place, just so you can make QA quicker and easier???

That's not what I meant at all; sorry if it was confusing.

We don't want to ignore the changes that customers want, just the opposite: we want to make more customer-requested changes, and faster. Helping QA to be as fast and easy as possible is both a vital part of achieving that, and vital to ensure that changes don't introduce new bugs.

Share this comment


Link to comment

Options aren't so much bad, they're problematic, I think that's what you're trying to say, they're problematic for designers and users but they are required to help the user experience.

An overly cluttered user interface will put users off and having advanced options openly on display will lead to people changing things they don't understand.

The challenge for you guys is finding out which options are most commonly used, personally I don't think "Highlight Transparent" should be an advanced option, I use it frequently enough to see it as a more general option but I can go weeks without needing to use it, ideally I would be able to setup my own regularly used options menu, but that throws the ball back to you guys to design an interface that can be used that way and you probably have better things to do.

Share this comment


Link to comment

Well, in the case of the marketplace it would be interesting to see who you think your customers are, and how the requirements were put together?

Code can be as complex as it wants if the outcome (in this case for the marketplace) is reduced cost of doing a transaction (for the merchants) and better exposure and brand management to drive more transactions. I don't see you have achieved any of these outcomes.

Share this comment


Link to comment

Some have explained much better than I could what the problem is Q. Basically users feel ignored. They have been talking and giving feedback for years. In fact they are showing you what they want through TPVs.

If you (and LL) want to take one BIG step towards gaining trust, continuity and respect I would suggest you do the following:

1) Download all TPVs and make a list of the features they have.

2) Extract all viewer related jiras.

3) Make from this a list on which everything from the above is mentioned (save the impossible ones).

4) Let users vote for each feature to prioritize the list.

5) Then tell us that you put everything in the viewer even though it will take some time.

6) Explain choices you make in depth, we are not stupid. You can trust most of us to have some technical insight or background, and if not we are always happy to help explain things to each other.

Last, but not least. The changes that are happening lately are affecting users at an emotional level. Keep that in mind. The only way to regain  good relationships between LL and the users is by not only listening to us, but also to act on our words.

But I can also understand that your job isn't easy. You probably have been given a limited amount of resources with which to work. I know we are barking at you while we should be barking at someone at a higher level. You are in the same boat we are in, trying to make the best of the legacy left to us from the past 2 years or so. In that respect LL is like a "black box" to us. The users are only confronted with what comes out of the box, and based on that we must guess at how it works inside. In no way can we act on something before it exists, and at that time it is usually too late since the desicions have been made and the budgets have been distributed.

Look Q, I am sure you are a nice person, I am sure you love your job and I am sure you want to do the best you can. But face it, as long as your boss doesn't give you permission to give the users what they want, you can only deliver something good to your boss but never to us. I am all for transparency, but if it means you just tell us what you do and don't do, and not act on our words, then why throw away the money? I am sure LL will be happy with the viewer when it is ready, but will it matter if the users don't like it?

Oh sure, at some point we will stop whining about it. Not because we have grown to like it, but because we start to realize that whining doesn't bring us anything.

You know, a good start would be to promise us here and now that you will give us a better interface. Since that seems to be the biggest hurdle to get the code base accepted. Don't just do it by saying it, but give us visual ideas, compositions, sketches, whatever. And show us in those sketches that you read all our input (which is a lot!) Give us a timeframe.

Then, consider my earlier proposal of making a list of all other features.

It's a simple idea, and although I understand it is a lot of work, I truely believe it is the only way you can get us to take LL seriously again.

Share this comment


Link to comment

The V2 UI is what drives the most away, the sidebar is for many users a just terrible thing, its big, uncharming, all is pressed into, the functions are harder to use, and so on.

This is why one of the first bits of work that Snowstorm took on was to make the sidebar detachable, and give users more control over how it's arranged and used. That work is nearly done, and you'll see the results very soon.

Snowstorm has plenty of work lined up based on the feedback we've been hearing from customers, and the successful features of other viewers - take a look at the project backlog to see what's coming. (Note that the main chunk of the backlog - below the first 7 lines - is not arranged in any kind of chronological order.)

Share this comment


Link to comment

If you (and LL) want to take one BIG step towards gaining trust, continuity and respect I would suggest you do the following:

1) Download all TPVs and make a list of the features they have.

2) Extract all viewer related jiras.

3) Make from this a list on which everything from the above is mentioned (save the impossible ones).

Please see the Snowstorm project backlog, because it's made (and still being made) by doing the above. That backlog is what the Snowstorm team has already started working through.

Share this comment


Link to comment

Please forgive me if my words sound wrong, english is just not my native language and I often have to settle for other words than I actually want to use, but:

I read the backlog. It is a first step, I agree. But by no means does it radiate a sense of "confidence". It is missing a lot of input that has been given and asked for in the past, but much more important:

It doesn't show us anything.

Please, please, please. Tell and show us BEFORE you make a desicion and start coding. Show us how the changes in the UI will look and work so we can give you constructive input instead of having to complain about it afterwards.

I cannot emphasise this enough, the UI is the most important first step. Give us a that, and your promise to implement the most asked for features after that and we will be happy. But (and I am sory for this) because of all the trouble over the last times, it would really help if you gave us visual input, clear timelines and a voice in it before making a move. It is about regaining trust as much as about a good viewer.

Share this comment


Link to comment

The attitude shown in the post is simply arrogant.

If you (LL) had proven to be capable of creating a good Viewer, I wouldn't be saying this
BUT as long as you still cannot manage to compete against your own old 1.x Viewer and far less against the TPVs, you should probably not assume to know anything about what your users want.

To be able to get rid of options means to spend a lot of time and a lot of money on reserach and good UI Design. Something that Apple tends to get right most of the time and something that you have proven to be horrible at.

Deliver a UI and Viewer Layout that is superior to 1.x for the vast majority of people and I think the need for options will go down substantially.
Continue with this chaotic way of managing the UI and you'll continue to see TPVs with lots and lots of options to remain popular.

Edit: On an unrelated note, I personally use 2.x and think it has introduced some amazing changes "under the hood" - it's just the UI that's "less than perfect"

Share this comment


Link to comment

×
×
  • Create New...