[Viewer 2.3 Beta Available Today With Display Names and More]

Still unusable because of the broken chat focus. And every time I try to use it I find more brokenness.

Why did they remove the directories from the "Worn" tab in the inventory? If I have two outfits on, because I worn one the wrong way, how do I remove the old one? In other viewers that support 2.x style outfits I go to the "Worn" tab, select the outfit folder I want to take off, and remove it. In 2.x I have both outfits intermixed.

No, don't tell me to put all my outfits in "Outfits" folders instead of "Clothing" folders. I have over 300 avatars, many with multiple outfit options, and "Outfits" is a flat single-level scheme. Finding the right outfit would take me forever. What were you people thinking of?

[Viewer 2.3 Beta Available Today With Display Names and More]

Good to know, they put some thought into mitigation then.

[Viewer 2.3 Beta Available Today With Display Names and More]

Impossible things? How so?

https://jira.secondlife.com/browse/VWR-17011

Hardly impossible. It's something that's so basic that they've fixed it every time they broke it previously.

I guess LL employees don't use text chat any more.

[[GUIDE] What's a skybox?]

Make sure you're rezzing the floor against the chair and not attaching it to your avatar.

[[GUIDE] What's a skybox?]

Why is a mouse when it spins?

Because the higher, the fewer.

-- Children's riddle.

 

The higher your skybox, the fewer neighbors you will see... at least until you reach that zone near 4096 meters where everyone else who's trying to put their skybox out of sight of the neighbors ends up.

[Changes to Display Names Based on Your Feedback]

 I suspect display names are a compromise that allows existing citizens a choice to use the name they wanted to in the first place, and it will allow new folks to just put in the name they want to. I see no reason why it should be a complete revamp of allowing citizens to just change their names.

But just allowing people to change their names would be easier to implement and less disruptive, and would actually allow people to use the name they want - Display names won't do that, because the old user name will always be there.

[Changes to Display Names Based on Your Feedback]

Although I'm glad to know that 'both names' are now planned to be the default, you seem to be saying that those using a Display name that differs from their Username will be able to hide this fact quite easily (in Preferences).

I think you're misunderstanding. There is currently an option to show or hide other people's usernames. This currently defaults to hiding usernames. What I believe Jack is saying is that this will default to showing other people's usernames... but you can still hide them and see only display names for yourself. This won't change how other people see you.

[Changes to Display Names Based on Your Feedback]

This change solves one problem, but it eliminates the ability of people to effectively "change their name" with a display name. It becomes nothing more than a floating titler.

Let's see, how to really fix it? Maybe something like this?

 

• Don't change anyone's existing "username".
• Allow new users to pick unique non-existing user names, with the  same character set (upper and lower case and spaces) as current users.
• If you don't have a "display name" you get the same appearance as in current V2.
• If you pick a display name that's unique using characters legal in a user name, you get "display name" in blue.
• If you pick a display name that exactly matches an existing user  name, you get "display name" in blue (or maybe amber or red), and "username" beneath it.
• If you pick a display name containing characters that aren't legal in a user name, you get "display name" in yellow (similar to the appearance in current V1).
• Existing users can choose a new name (including a "facebook  friendly" single name) for their user name if they want. This is a  one-time deal and costs US$10.00.
• Anywhere in an input field where "First Last" works, "first.last" works as well.
• Finally, existing users can "correct the capitalization" of their existing user name, again, one time.

[Check here if you want more options]

But Prok is right in basic concept... it caused a whole lot of majorly serious problems, not the least of which was CopyBot.

Um, what? How the hell did open sourcing the viewer cause CopyBot, when CopyBot came out well before the viewer was open-sourced?

[Check here if you want more options]

Strictly speaking, the blog post is not about that particular chat functionality, but about the design philosophy of the viewer more generally.

That's because Linden Lab keeps turning the discussion about this problem into a discussion about the design philosophy of the viewer every time it comes up. On mailing lists. In JIRA. In chat. And now on the blog. After a while it seems like they have some other objection to fixing it, and t6his is just an excuse.

That said, if I understand this "trigger issue" correctly, in the new viewer, I'll have to explicitly enable the chat bar for every single line I want to write? -That would absolutely drive me insane, but, well... having no intention of using V2-as-is over my current third party viewer anyway, it is a non-issue for me in the first place, which in itself speaks volumes.

You don't have to explicitly enable the chat bar for every line you want to write. Just every time you do anything that puts the focus anywhere else. Like, clicking on something in-world. You may have to enable it multiple times for one line, then go three or four lines without a problem.

[Check here if you want more options]

And more comments about grand and unlikely schemes, separating the UI from the engine, making the viewer modular, these are side issues.

The big question is why "we don't want to add options" is a reasonable response to a request that an option that previously existed, and that a large part of the user base (both gamers and chatters) depended on, can't be returned to Viewer 2. This is not simply a blithe request that some new functionality that never existed before be added as an option, but that a fundamental part of the user experience that has been maintained for years (and, previously, repaired when it had been broken) be retained.

Why is THIS PARTICULAR option the cause of so much angst from Linden Lab?

[Check here if you want more options]

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.