Tools and Technology

This is a stimulating collection of thought. I am happy you spoke ambiguously, Q, otherwise I may not have been drawn in.

When I think of a tool, the archetype of "tool", I go to the image of the knife. In many ways, more powerful than a lever or a wheel in terms of human culture.

On a camping trip, I want a Swiss Army Knife. In the Surgical theater, I would want my physician to have a scalpel. At the dinner table, I want a still different edged tool.

Understanding in a simplistic way the multi-varate test modern applications must meet in the wild, and how stacking tolerances in sytems rapidly can cause good designs to fail, I am almost thinking that somewhwere along the timeline, a multiple experience menu needs to be provided that will allow a user to select among a group of speciaized viewers.

Said differently, on initialization of each run, a pre-run loader asks the Resident to "Choose an Experience Style" and offers choices such as 1) Socialization and Shopping 2) MMORPG 3) Machinima Production 4) Content Creation, etc. The Pre-run loader then continues intialization with a Viewer load that has a viewer optimized for the Experience Style the Resident has selected for the inworld session. A Viewer Widget to "Change Experience" could allow the Resident to have the local machine change the  Viewer load mid-session, holding the inworld session in placerholder fashion, and without the usual session intialization to  authorize, download and etc.

 

I suppose I need to understand where you are in this dev now. You have managed to pique my interest.

Introduce UI Settings Navigator.

me=>preferences=>setup=>User Interface:

Checkbox
Novice Standard Power Custom1 Custom2 Custom3

Custom will open the file navigator so you can browse to Kirsten and the viewer becomes the Kirsten viewer, the checkbox wil change it's name to Kirsten.

Yoz, you wrote that you wish to reduce QA costs.

As a developer, I wish to increase viewer reliability through automated regression testing, and that would reduce your QA costs at the same time.

By far the best way to automate viewer regression testing is to ride on the back of a project aimed at delivering a viewer extensions / plugins system, because that would kill several birds with one stone:

• Reduce viewer complexity by refactoring much of the slower code into client-side scripts;
• Reduce UI complexity by loading only those plugins needed for UI features at any given time;
• Raise reliability because client-side scripts would be written in a safe scripting language;
• Raise reliability because shared state multiprogramming would be replaced by processes;
• Harness multicore easily and safely because the hard work is done by the operating system;
• Increase flexibility because small scripts are much easier to write than monolithic C++ code;
• Satisfy the community much more because users could tailor the UI to their requirements;
• Improve viewer structure by defining an internal API to which the scripting calls are bound;
• Greatly enhance your QA because client-side scripts can perform unit and functional tests.

Since this direction helps to limit viewer complexity as the number of options rises which so worries Q, and directly assists in automating viewer QA which is very likely to reduce your QA costs, don't you think it would be an excellent project to commence immediately, even without considering its many other benefits?

Q, I hear what you're saying in this blog, and I sympathize. I'd like to respond (although I doubt Linden Lab will even be reading this message; there's only so much time in the day after all).

This blog is the first you've written that doesn't impress me.  Why?

Because as a business manager with decades of experience, I learned where to draw the line between legitimate concerns, and whining / making excuses.  Please take no offense at that.  We ALL make excuses and whine from time to time.  The good manager knows when that is necessary as a steam-release... and when to tell people to stop making excuses and do their jobs.

If I may, please consider:

Yes, options are tricky.  Menu balancing is tricky.  And I will certainly agree that with the wide variety of people on SL, you are not going to make everyone happy.   That all agreed, let's take a look at some realistic concepts:

* Nothing, but nothing, is going to make this viewer "easy to use".  That is a fallicy, the Holy Grail that people keep preaching about but just isn't going to happen.  It can be easier to use, but the very nature of the beast means there is going to be some kind of learning curve that newbies are going to have to experience.  That realized, the key is to make that learning curve as fast and pleasant as possible.  You are not going to accomplish anything by crippling the viewer in any form, reducing its power, or reducing the size and complexity of the menus.  There are other ways to accomplish newbie initiation.

* That stated, there are ways to improve the viewer layout, make it easier to use and more intuitive.  At this time, the current viewer isn't all that intutive.

* You mentioned that many people don't even know what the options mean.  Well, FIX THAT.  Every single option on that viewer, without exception, should have a little question mark info circle that would thoroughly explain the related option, or at the very least send someone to a webpage explaining the more complex ones.   Those instructions should be written in plain, easy-to-understand language.  They should be informative, so that the user knows exactly what that option does.

* Menus can certainly be arranged in more sensible order.  You mention people don't all agree as to what that order should be.  Technically, yes.  Generally... poppycock.  The functions that we need are pretty much recognized throughout the experienced user community.

* As an example, Draw Distance should not be relegated to a hidden area of the graphics part of the preferences menu within the Edit menu.  That is a simple, basic, easily-recognized statement that users have already established.  Hippo places the draw distance tool right on the Camera Controls (which for the record should always be on the screen or at least default to ON, because people are always using that particular control).

* No menu should be hidden, period. Just because something is "Advanced" doesn't mean we won't be using it on a regular basis.  You can place seldom-used menus as sub-menus of the Advanced menu-- which should be visible along with the other menus at all times.

* Removing industry standard menus such as FILE, EDIT, VIEW and TOOLS... menus that are used by every Windows and Mac and Linux user in the nation and have been for years, was an extremely poor decision.  If those were to be changed at all, it would need to be with menu titles that are very SL-specific and very intuitive, such as COMPUTER, OPTIONS, CAMERA (but how would that be better than VIEW?) and well... TOOLS (it's hard to find a more intutive word than TOOLS folks).  "ME" as a menu absolutely does not do the job, and reeks of reference to Windows ME... which has one of the worst software reputations in the history of comptuers.  I mean, someone really needs to get a clue on that one.

That's all I'll say at this time.  No need to drag this out.  Bottom line Q... while there are a wide variety of opinions out there, in general the general user has general needs, all of which can be rather easily met by an interface designer with a little bit of common sense.  It's not rocket science (not even close)... it's layout and design of a user interface.  The functions are already there... it's just a matter of shifting menus to make those functions more easily accessible, intuitive and usable.   That should not be something that causes people to lose sleep, and it's certainly not something for public whining by LL staff.  So please forgive my being blunt, no offense intended at all.  I do sympathize.  But rather than this being one of those "legitimate whine" situations... this may very well be one of the "buck up and get 'er done" situations.

My recommendation:  Linden Lab should start applying a little less marketing blue sky in their decisions, and a little more "what would I as a customer want?" end-user common sense.

If you happen to read this, thanks for listening.  If not, well, another 15 minutes of my life wasted. ;D

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

That's putting it out there on the table Alexander.  Fairly accurate statement that isn't insulting to Linden Lab (well it is, but...)  but is rather accurate.  It is pretty apparent LL has been out of touch with their users for a very long time.  That reality is causing them repeated problems, and causing customers even more propblems.  Just wanted to state I have to (sadly) agree with this comment.

Sometime back someone suggested that the reason LL doesn't understand customers is because they're not out here in the trenches with us.  I think that is a fairly accurate statement.  They have no idea what we go through every day (with the possible exception of Torley), and they have no idea what it's like to use this system on a daily basis, or how system problems impact user experience (especially since viewer 2, which is just a horrendously bad concept and product that should have never made it off the drawing board-- and would not have if LL did understand what we need).

You stated it well:  they should not at all believe they have any clue  what their users want and need.  There is actually a reason for that:   they usually don't ask us,and when they do, they usually don't listen.  After all we're just customers.  What do we know?

* Removing industry standard menus such as FILE, EDIT, VIEW and TOOLS... menus that are used by every Windows and Mac and Linux user in the nation and have been for years, was an extremely poor decision. 

Agreed!

Why?

Two words: EXPECTED BEHAVIOR

Every time a user must unlearn behavior that is consistent across applications in his operating environment, he gets frustrated. This is particularly true for new users, where this significantly can raise the barrier of entry.

well, even how it will end, I bow and be thankfull, Yoz. 1st time now, that I feel taken seriously.

Thank you that you take the time to listen to us and to answer us, that is really really apreciated.

 

*smiles at Yoz and bows

What Desmond said!

Wow, people. I'm amazed at the way folks are misinterpreting what I said. Some of it is, I'm sure, deliberate, by people who have axes to grind.

All I tried to do was explain why options should be a last resort. Nowhere did I say we won't have them.

I welcome your blog post, however I don't think it's so much people having an axe to grind, some people read things differently, go to any forum and you'll see people taking something someone said the wrong way, or not in the manner the other person intended. Whereas I don't agree with you that options should be a last resort, I do agree that options are in themselves added workload and problematic.

Regarding the various accusations of condescension and not listening to our customers, how about a little reciprocity? I'm trying to have a somewhat nuanced, open discussion, explaining some of Linden Lab's desires and constraints, and what I get in return seems to be an attack because I haven't simply agreed to some hypothetical ideal. I'm listening and trying to engage, are you?

Please, let's assume good intentions here. If we all listen and comment with respect we'll get farther.

Many things Linden Lab do are full of good intentions, it's when people point out flaws and don't get listened to that the problems arise, you have a whole sackload of users, you're never going to please all of the all of the time, but when people point out glaring flaws and they get ignored, then you're going to run into conflict.

Two Jira's that highlight this:

http://jira.secondlife.com/browse/WEB-1819

A user even developed a fix for this, it worked for a while but someone at Linden Lab is absolutely determined not to fix this issue, they haven't even tried to give a proper explanation of why they won't employ the fix.

http://jira.secondlife.com/browse/WEB-2001

The infamous search maturity ratings bug, fate even dealt a kind hand here, the Jira was reported a full month before search was rolled out into the wild, at the time of the report it was only a viewer 2 issue and due to other issues the planned search rollout was delayed and yet, despite this serious bug, they went and rolled out search anyway.

These are the sort of things that lead people to say you're not listening, by the same token you're right to ask people to listen to you and point out that this process is a two way street, it has to be for it to work.

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.

Adopting a requested change in the most minimal and limited way will obviously and necessarily incur additional change requests (changes to the change). I don't think it's out of bounds to see your position as equavlent to, "there isn't enough time to do it right, but there's plenty of time to do it over."

I agree with Q's initial post. Shuffling all kinds of decisions off to some huge "Preference" page the user must go through to get what they want is a bad idea, and a sign of a bad design. (And we also need to differentiate between options and features in this discussion).

Taken alone, in context of software design, and out of context of Viewer 2 development, there's little to criticize.

However:

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.

Many people had many different ideas and hopes for features in Viewer 2. But I think the one thing everybody expected from it was exactly this.

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.

Ironically, one of the major criticisms of Viewer 2 is removing exactly this sort of philosophy, doing away with dockable windows, which is a well-understood, unobtrusive way of giving the user choices at their fingertips in the interface itself; a sort of meta-interface you can use to adjust the interface. Instead, Viewer 2 specificaly shuffles such choices off in a preference tab, if giving them at all.

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.

Again, the forced modality of Viewer 2 grates badly against "understanding the use cases".

So as I read your post (admittedly possibly with a bias), you indirectly explain why Viewer 2 was a failure on both the architectural and design front (despite some good features; I am not arguing that).

LL's stubborn insistance that "we'll like it once we "get it"" has a lot of people angry, and considering that we were literally (and condescendingly) told exactly so by Jack and Wallace in the last controversy over display names, it's not hard to see why your post will be read in that light.

And in the case of the viewer, considering how people flock to 3rd party viewers rather than Viewer 2, I think it is also safe to say that it is not just a matter of people bitching on principle about changes they haven't seen yet.

My concern with this blog post is that I don't see how resistance to adding an option is a reasonable explanation for the push-back from LL against fixing the problem that started this whole discussion. They have added options for far less important features, including a whole new UI for the location bar (the mini location bar) and for controlling buttons on the bottom bar. So why is focus on the chat bar such a big deal for LL?

The underlying problem is that in 1.x viewers there WAS an option to display or hide teh chat bar. When the chat bar was displayed, focus was always on the chat bar. When it was hidden, focus was lost. Occasionally LL has broken the focus part of this functionality, for example with the Communicator box and the Voice viewer, but each time people complained and after a few releases it was returned.

Linden Lab removed the option to hide the chat bar, but for many people (both people who used the chat bar exclusively, and those who used it sparingly) the point of hiding and showing the chat bar was not saving space on the screen, it was controlling focus on the chat bar. Rather than leaving the option in place (either with a checkbox in a preference screen, or with some visual cue such as a pushpin), LL simply removed both related functions.

But if you read the JIRA entry, VWR-21506, you'll see a continued apparent misunderstanding from the LL side. It just doesn't make sense to me. I don't understand what's going on. I honestly can't see how this specific issue is suddenly where they have to draw the line on adding new options.

I have noticed that, in addition to what I have expressed, a few other Commentators are going to the thought of a top level use case choice input by the resident.

There was the skinning option, and then mine and another's use case selection schemas.

You know, the first few orbital missions of the united States' Space Transportation System were conducted under a configuaration in which the Flight Computer had only 4kb of RAM. The microwave radio modem was pretty warm most of the time, loading and unloding small modules and data sets sent from the surface of the earth.

I just note this, as, with the advent of cheap memory, and huge PC real estate, the trend toward monolithic coding has created bloat. Developers are not so constrained nowadays with a tiny footprint on RAM. There are acres of memory that can be used to store these huge applications.

I have not really considered this to be advancement of the state of the art. In the days of real microcomputing, it was absolutely essential to have only active program routines in RAM, the rest sitting on peripheral volumes and loaded, as needed, and craftily hidden and nexted in branches and loops where a user input, or a screen wipe or screen change would involve the user for the tiny delay whiile a needed module loaded in.

So, with a Second Life Viewer design, we see a similar premium in real estate and resources on the client side, and it seems proper small system application modularity would help both efficiency and correctness, enabling simpler QA proceedures through easily proveable modular structure.

The danger in this approach though is in team forming. It must be around features or options of the whole UI and not the modules. Organizing on modular teams compartments the flow of development information far too much.

As for the question of more features versus a more streamlined interface, I'd agree with the statements that LL needs to cater to two distinct groups. Content creators and casual users.

For the average user, the SL interface should be sleek and game-like. Fun, friendly, and encouraging of socializing and exploring.

Content creators need an interface more like you'd find in pro design tools like Photoshop or 3D Studio. Lots of features and controls allowing them to create the avatars, environments, and other content that everyone enjoys as efficiently and easily as possible.

You cannot meet these needs with a single interface without running into conflicts.

I think that, in addition, due to the broad user base with varying needs, wants, and goals, it would help if the interface was modular, letting people easily install plug-ins rather than relying on scripted attachments which add to the server loads. Sure, it would be a lot of work to create a modular interface like that, which is why LL should have been looking into it years ago.

I believe  LL faces a broader issue when it comes to features. Specifically the needs of the user base and how certain features and UI decisions directly impact the quality of the SL experience in various ways

. For example. Pretty much every third party viewer has displayed more or less accurate avatar height for the past year or two. LL only added this feature with Viewer 2.1. When LL added it, their version was broken. LL knew it was broken as they added it. LL even knows why it's broken but still chose to implement it broken

This is a feature the official viewers should have had first, before SL ever left beta. Before SL opened to the public. Arrives more than seven years late, and broken, where the TPV community has already done better.

  The lack of this feature in the beginning created a lot of confusion regarding avatar height. The broken feature LL recently implemented encourages over-sized avatars (By telling people they're much smaller than they actually are). Scale in SL is a mess because of this (and a couple other problems) which directly impacts how we, as users, design and build environments in SL. Specifically, it has led to drastically smaller and less detailed environments. It puts off professional designers who might be intrigued by SL at first. It directly leads to SL's poor reputation as far as visuals.

Simply learning to recognize issues such as this one (And there are many others I could point out) would have as much or greater an impact on SL's visual quality as the introduction of mesh imports.

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.

Thanks for the reply, Yoz.  I would agree with the idea that you present. The problem is that after 2 1/2 years of being on the receiving end of LL's decisions, I have no faith that this will be fact.  Even if you do get QA mean and lean, will you still be working on customer requests, or will you be off onto the next 'display names' fiasco, using that as an excuse as to why you can't do customer requests yet?

I hate to sound negative, especially as I had such high hopes when I first heard about V2.x, but like the majority of people on this blog, I have lost faith in LL's decion making process, and a few teaks and 'bells and whistles' on the V2.x UI will *not* return that faith.

And to be honest, Q's attitude towards us has not made us feel warm and cozy inside.

And to be honest, Q's attitude towards us has not made us feel warm and cozy inside.

His attitude is fine, it was a sign of honesty, he maybe should have kept it to himself but it's refreshing to see a reaction like that, it shows he's human and it also shows he's not bullshitting us, I'd rather someone was straight like that rather than than talking through the side of their mouth.

Programming good end-user software is as much Art as it is Science. But the real "bottom line" that must always be considered is this: "Designer/Programmer Time is Free". I know that sounds untenable, but it is the hard truth of any good end-user program. The amount of time the Designers and Programmers spend creating the right balance of functionality, personalization/customization and ease-of-use are negligible in comparison to the amount of time (and frustration) end-users will spend working around a poor design.

If it costs 40 hours of Designer/Programmer time to design and code a specific feature, that is equivalent to 400 users spending six minutes each. With software that has the intended audience size of an SL Viewer where the end-user counts can reach into the 10's of thousands, that 40 hours divided among those users is insignificant. (For example, 10,000 users would equate to 14.4 seconds each.)

This is why you must carefully consider leaving a feature out. If ANY part of that decision is "it will take us too long" then you need to also consider how much time creating it will save your end users. Will your expenditure of 10 hours save your users a minute of time each? !0,000 users at one minute each is the same as 60,000 minutes or 1000 hours of end-user time. You can easily see that those 10 hours have a "Force Multiplier" of 100 immediately ... and that is just the FIRST use. If end-users save one minute each time they perform that function and it is something they must do often (say once per day) then you must also consider how many days you expect them to use the software. One year? That's only 270 days (assuming work week schedules) so the Force Multiplier of 100 suddenly becomes a Force Multiplier of 27,000!! In other words, 10 hours of Designer/Programmer time is equivalent to 270,000 hours of end user time SAVED over the first year.

This attitude that "it adds complexity" or "it gets too complicated" or any other excuse is just that .. an excuse. Software and computers exist for one purpose and one purpose only ... to make something possible to do for a human that could not otherwise do it. It does NOT exist to coddle the programmer or save the Designer time ... their efforts to create the software are insignificant in creating good end-user software.

Spend the time during the Design phase. Spend the time during the Programming phase. SAVE your end-users the time during the much longer and much more important USE phase. They will appreciate you taking the time to consider their needs and the fact that you put their needs ahead of your own desires or preferences.

The only value is a product that delights and engages the customer, and which causes the customer to want to spend money for the product, and to invite friends to use the product.

That must be real, deliverable delight.

I agree with most you say, but

2. Go back to 1.23,

They are very adament about not doing this, and I suspect this is because the code-base of vwr 2.x has some stuff that is needed in the near future and which is missing from 1.23 and which is probably not easy (if not near impossible) to integrate in 1.23 without spending huge amounts of time and money on it to rewrite it.

This is also why (when you read between the lines) they are confident use of TPVs based on 1.x will decline and we will adapt to 2.x.

The best course of action would be to rip the code-base and the UI-code of the viewer apart from each other, but it seems nobody had the foresight to have the viewer developed modularly at even the higherst level. So I suspect the UI-code is mostly integral to the base (which I think is not even the fault of LL for the most part but of the software c ompany that wrote the viewer, since modular design is a good idea in most cases).

In dutch we have a saying which is, roughly translated: "from behind you can look a cow in it's arse" which means that it is easy talking afterwards. Unless some TPV party is willing to rewrite 2.x so that major parts can be seperated and redone in a plug-in kind of argitecture, I really think that we are "doomed" to having to work with this "turd".

One thing I am sure of, LL will not revert back to 1.x no matter what, and any TPV viewer based on 1.x will slowely become obsolete. TPV should really consider jumping on the 2.x wagon so they can at least give us a better alternative to the official one, once we must switch, and mark my words, switch we must, sooner or later because of newly introduced features that everybody will want to and need to use and will never work on 1.x.

Oh I agree with you Pentasis.  I don't expect them to go back to 1.23.  I just wanted to make sure enough people had suggested that so that LL has no excuse when their ship sinks. They won't be able to say they weren't told.  ; D

I do disagree that there are aspects of 2.x that can't be implemented in 1.23 without huge amounts of time and money.  It will take time and money, to be sure.  But more than is being currently spent on 2.x?

2.x has far more wrong with it than just interface.  Look at it this way:  Linden Lab worked on 1.23 for some 7 years and still didn't get it right.  It still contained problems with texture loading and other major issues.  So we're to expect this company, that can't perform simple debugging, to get it right by starting all over from bare code?  Like 2.x isn't going to have new, nasty problems all its own?  (And it very obviously does).

No, I'll still posit that updating 1.23 is still the wiser course.  It may be going back to the drawing board... but at least that drawing board still has most of the equasion already written down.

Will Linden Lab do that?  Of course not.  They've already shown themselves to be (please forgive my being blunt) stubborn blockheads.   They have stated emphatically they will never scrap 2.x.  They remind me very much of Captain Ahab chasing Moby Dick, determined to stay their course to the bitter end.

I would agree with you that the best option overall would be to totally re-write and re-design the v2 UI... if the core of v2 was stable and bug-free. It isn't. It isn't even close to it (as would be expected from LL... that typicaly writes majorly buggy code, releases it to the main grid and then fails for years to debug it).  If I thought LL had a chance in a bigagillion of writing solid code, I'd say, "Sure, redesign the v2 interface and go for it".  But I think you and and everyone else here knows that is just not going to happen, for two reasons:

1.  Linden Lab couldn't write stable code (or at least debug it properly) if a gun was pointed to their heads.  (I'm sorry, I'm just calling out "The emperor has no clothes". LL coding snafus are historcially documented.  I mean, after 7 years, they still can't get CHAT to work or deliver a simple group notice.  This is simply a company that does not follow proper coding and debugging procedures-- and it shows.)

2. They're just not going to re-do the v2 interface, period.  They're just as stubborn on that as they are reverting to 1.23 and starting over.

What I recommended to Q above wasn't recommended because I feel LL actually stands a chance of doing that.  It's pretty obvious from historical MO that Linden Lab is going to do flat whatever they want, no matter what users suggest (or even insist on).   My post was nothing more than pointing out what would actually work... a plan and concept that would succeed IF they decided to implement such.  Of course they will ignore that suggestion.  Of course they're not going to implement those 5 points.  They never do.

Doesn't mean we aren't right. It just means LL is stubborn.  ; D

So they decide to ignore that post... as they have ignored hundreds of others.  They decide to do just what they want to do... as they always have.  They'll pay the price for their decisions... just as they did with the Homestead fiasco... and still are. They won't be able to say they weren't told, or that we didn't offer alternative courses of action.  We did.

Ciaran: "His  attitude is fine, it was a sign of honesty, he maybe should have kept it  to himself but it's refreshing to see a reaction like that, it shows  he's human and it also shows he's not bullshitting us, I'd rather  someone was straight like that rather than than talking through the side  of their mouth."

 

I could not agree more Ciaran.  Q is one of the few Lindens that gets out here and talks with us.  In this case, he openly stated what his opinions are, and asked us if that's right or wrong.  We keep asking Linden Lab to ask us for our opinions.  On the very rare occasions they do-- as in this one-- we should answer.  It doesn't mean I won't tell him exactly what my opinion is... it just means I'm not going to kick the horse for galloping.

 

To Q:  You have asked us what we feel about the interface issues and I already stated one opinion.  But I'd like to briefly make that opinion more clear and precise, for the specific intended benefit of SL and LL overall:

1. Scrap viewer 2.  Period.  Seriously-- this is a crappy product.  As one user stated, you're wasting money and man-hours trying to shine a turd.  I'm no amateur Q.  I've been on SL almost 6 years and before that I was a professional corporate consultant for some 25 years.  So trust me in this: v2 sux.  Scrap it as a failed project.  It happens with any corporation.  Smart managers have the sense to recognize a hairball project when they see it... and have the basic courage and strength to trashcan the thing.  Scrap v2.  Then...

2. Go back to 1.23, add all the really kewl features (such as invisible skins and tattoo layers and the other goodies)... and simply re-arrange menus so they are more intutitive (I covered that in my previous message).  Add the really kewl features people like with Emerald and Imprudence and Hippo.  The code is already written... all you have to do is double-check it and plug it in.  Isn't that why you made this code open source in the first place?

3. Add ? buttons to every single menu option so that people can click those buttons and find out exactly what those options do.

4. Stop hiding the ADVANCE menu. Put it right out there where people can use it if they want to.  Then listen to us power users as to what features we want in accessible buttons right on the main menu... such as draw distance and default-on camera controls (that everyone uses just about all the time).  Ask the power users what is needed.  We know through years of experience. We'll tell you.  Or don't ask us... and continue flailing about like you are now, and ticking off customers, and losing 500 sims in 45 days.  You folks' choice.

5. If you really want to do something special, use the age-tested method of having BASIC and ADVANCED menu setups. When someone joins SL, they would have a basic, simple to use menu system that helps them get around and function without being overwhelmed by extras.  Then when they get confident with that, they can hit a very visible "Advanced" button, which will display the full expert menu system in all its glory.  That is a simple thing to implement.  I'm surprised it hasn't been done already.

 

Q... these things would work.  These things would solve the problem, completely.  These things would make customers happy, and they would cost Linden Lab less than your current course of development.   There is no down-side to this except for maybe a couple of managers having to swallow their pride and be humble enough to admit they were wrong with v2 (you've already done that Q.  Others need to follow your example).

For the most part, it's a WIN-WIN-WIN-WIN-WIN.   So my opinion and advice, after being a power-user on SL for almost 6 years... just do these things.  Linden Lab needs to wake up to reality and take the sensible, logical course.  Stop wasting money and time on a failed product.  Start over and do it right this time.

But overall, my #1 piece of advice is this:  Linden Lab needs to get its collective head out of its collective backside, and start paying attention to what customers are saying.  You folks aren't on the right path.  You've got it wrong.  That is why recent blogs have been so extremely negative. That is why customers are rebelling. That is why they are jumping ship.  That is why your sim count is dropping.

Linden Lab:  Listen to your customers.  Otherwise... they'll stop being customers.

His attitude is fine, it was a sign of honesty, he maybe should have kept it to himself but it's refreshing to see a reaction like that, it shows he's human and it also shows he's not bullshitting us, I'd rather someone was straight like that rather than than talking through the side of their mouth.

Please understand, I was not questioning his honesty or anything of the like..

However, when I first read the post, my initial reaction was 'LL took out some options, and now we are going to tell you why', which is typical LL. But his reply that we had 'axes to grind' after asking for our opinions did not settle well. Honest?, no doubt... called for? No.

It just reinforced the my feelings that 'LL asks, but doesn't listen'.

(Wayfinder, this isn't really a response to you alone, but is related to your post.)

I hear a lot of people pining for 1.23, but we also all know that isn't happening. Honestly, we're closer to moving on to V3 than going backwards. It seems that V2 may actually end up more like a V3, but the name could/will still be an issue.

Yoz, Q, et al... it may be a decent idea to redesign V2 and re-release it as V3 (assuming there have been enough significant (and visual) changes). The Snowstorm project could create a Viewer 2 that people would love, but they will still shy away from it just because of the name "Viewer 2".
Almost like a Windows Vista issue. It didn't matter what they did with it, it wasn't going to be widely adopted due to it's image from the get-go. They moved on to Windows 7, with enough changes that made it usable and reliable. From what i understand Vista isn't much different from 7, the main difference being that 7 works how people wanted Vista to work. (As i like to think of it, 7 is what Vista was supposed to be)

I think there's been just a tiny bit of confusion ... "going back to 1.23" clearly isn't going to happen, but there's nothing saying that the 1.23 interface can't be applied to the v2.x codebase. The biggest complaint I and everyone else has had, as far as I can tell, is the interface. The features haven't been a problem.

Going back to a v1.23-style interface absolutely can be done.

I think there's been just a tiny bit of confusion ... "going back to 1.23" clearly isn't going to happen, but there's nothing saying that the 1.23 interface can't be applied to the v2.x codebase. The biggest complaint I and everyone else has had, as far as I can tell, is the interface. The features haven't been a problem.

Going back to a v1.23-style interface absolutely can be done.

 

I'd rather see a whole new interface (or interfaces) developed. Forget 1.23, forget 2.0.. maybe hold a contest for Residents to design what they would like the interface to look like, then base Viewer 3.0 on those designs. They wouldn't need to be functional, they could just be a scanned in drawing.. just to give the idea of what we would like it to look like.  (Yes, i know there would be a ton of different ones, but i mean... having such a repository would result in some general ideas that are most coomon.)

Because honestly, i don't think either design is the best one that could be used.