SocialThe Name Game: Display Names and the Law Of Unintended Consequences

The Name Game: Display Names and the Law Of Unintended Consequences

The Lab's new name game has hardly been a ringing success. People really don't like it when you mess with their choices in identity. But since the Lab seems to be listening a bit more of late, it can’t hurt to share some potential solutions.

“The law of unintended consequences is an adage or idiomatic warning that an intervention in a complex system always creates unanticipated and often undesirable outcomes.”

One topic that almost certainly won’t be discussed at SLCC (which began yesterday) is the result of all that messing about with the account signup process and the creation of Display Names. While I hate to say I told you so… Oh wait. No I don’t: this new name game hasn’t quite been the ringing success the Lab had planned.

Tinkering With The God Machine

The signup process and display names change happened many months ago.  I wrote about in October (and said it was a lousy idea then) when I discussed the Tinfoil Hat Theory. The Tinfoil Hat Theory turned out to be remarkably spot on, including the outcome- Facebook wiped the entire marketing plan off their decks due to their own Terms of Service, prompting an avalanche of activity that led to Social Profiles.  

But the problem is that the way display names were implemented – and I have to keep reiterating this, even though it’s nearly certain that yet again someone will miss this important part – not their existence, their implementation was done to align with the goals of that scheme. A scheme which not only failed, but as the Law of Unintended Consequences would have it, created unanticipated (by the Lab, anyway – quite a number of people saw that train coming) and undesirable outcomes.

With the battle over names and ‘nyms ongoing all over the Internet right now, I’m going to note that for that reason alone it was not wise to tinker with the names system in this fashion. People really don’t like it when you mess with their choices in identity.

The previous article I wrote about this describes the changes that were made to the system in detail, but in short, what happened was this: The previous, and long standing two names system (firstname lastname, in which you were given a choice from a limited list of last names) was scrapped in favor of a one name username system, with a “placeholder” surname (which doesn’t really exist except in limited circumstances) of “Resident”. This was done for several reasons.  

  1. The old system was believed to be a cause of signup abandonment.  That is to say that people would become frustrated at the name choice options and abandon their account creation.  
  2. They felt that after 20 million names choices already made, that the options were becoming limited.  
  3. The background marketing plan, in which Display Names, not intended to be unique, could be chosen as the name people would see.  This would allow people to in theory use their wallet name as their display name, thereby giving them a “single wallet identity”, which they believed would get around Facebook’s terms of service (see: Tinfoil Hat Theory.) 

All three of these reasons have proven to be failures with the new system.

What’s more, the thinly veiled reasons given by the Lab at the time the changes were put into place are still the failures now that they were then, and new reasons for this to be a complete mess that no one ever considered have made their way into the fray.

But let’s take this apart one piece at a time.

Signup Frustrations

It was long said that people were abandoning signing up for Second Life because they couldn’t find a name they liked. The list of last names at any given time was limited, though sites like SLnamewatch helped, if you knew they existed (and most didn’t.)

Getting a first-name last-name combination you liked wasn’t always easy. Dropping things down to a single name was supposed to help alleviate that. 

Wrong.

Now it’s significantly harder to get a decent sounding username. All the ones people are likely to want are already taken, at a rate of 16,000 new signups a day. One must go farther and farther afield to get a username they like.

The original system allowed for more uses of common first names with each last name.  For example, with two names there can be Bob Jones, Bob Dufaux, Bob Turntable, and Bob Lightyear. In fact, there can be an endless series of Bobs, as long as you provide an additional surname.  But with one name there’s exactly one username of Bob.  Everything else has to be a variation:  Bobb, B0b, Bob2942…and then I run out of ideas.

If people thought the system was limited before, it’s even more limited now, and numbers after a name is generally considered to be less than desirable. Though it’s easier on the Lab to not have to come up with an endless series of surnames for people, the single name system makes it harder on the users, because they are essentially eliminating 50 percent of the dataset from which to create a name – leading to significantly more limited choices than their had been previously.  

If your goal is to decrease frustration, this is certainly not the way to go about it.  

“But wait!” you say, “it doesn’t matter since you’re supposed to be using display names anyway – the username is not important!”

Wrong again.

Implementation issues

I think the Lab believed (almost ridiculously) that everyone would flock to Display Names and use them in the way they’d envisioned. Neither one of these things actually happened of course, but the latter is a problem (the former is just a silly thing to believe). The reasons why have to do with implementation, and that pesky law of unintended consequences again. 

Part of the issue with display names is that though they’re intended to be changeable (weekly, though you can go back to your username at any time), the VIEWER does not prioritize the *unchangeable* username as the default.  So if you have a large friends list, and say 10 people on it change their display name weekly, you have to hunt to find their names in your friends list over, and over, and over again, since they will not remain in the same place they were previously (and apparently, you’re expected to keep up with all the changes as well.)  

Why the viewer doesn’t have an option to set up sorting by username (as that never changes), I have no idea. This problem was found by third party viewer creators though, and is definitely fixed in Firestorm. However, the official Linden Lab viewer still has no facility to do this.

What happened is people started to turn display names OFF. That was the only way to actually solve the problem of keeping your friends list in a consistent order.  

Of course, no matter how awesome your display name it doesn’t much matter if others can’t see it. But what they can see is Bob2492. We’re back to the limited username problem again. 

People also didn’t necessarily use them as intended. Many people used them in place of flip titlers, coming up with silly titles (not necessarily names) that they never really expected people to call them. But some people have usernames turned off, under the operating theory of “The Display Name is the only thing that matters”.

If the only name they see is the display name, if you called yourself something ridiculous as a joke, you’re either going to be called that, or spend a lot of time correcting people until you revert to your original username (which may not be all that awesome – see previous point.) 

Though some people did change their display name to their wallet name (I know of several, personally), most didn’t. This makes sense given the resistance virtual world users have toward combining their online life with that in their meatspace existence.  This is why the Facebook hookup plan never would have worked anyway.  

Then there’s the unicode abuse.

The reason unicode was allowed for display names was reasonable – it allowed people whose names were not written in western English characters to set a display name in their native language. That’s a nice, inclusive reason to include them, and in fact they have been used for that purpose.

Sadly what they’ve also been used for is to use a bunch of funky looking characters to make your name look “cool.” It doesn’t look cool. It just makes it harder to read.  

Turning your name upside down does the same thing. In a busy location, or even on your own friends list, the use of unicode to simply “coolify” your name makes communication more difficult, not easier, and caused even more people to turn display names off entirely. Unintended consequences strike again.

But the biggest unintended consequence was creating a cultural divide. Since it is obvious who has an account that was created before the change and who has one who was created after, a cultural class system has emerged, pitting old residents against new ones in a way that’s strictly obvious by name. 

In the photo below you can see a variety of things. Some people using display names, some not using them at all. You can see who has an older account, and who has a newer one. And you can see whose name has changed position on their friend’s friend lists.  (Sadly, no one abusing unicode was hanging around the store at the time – but I see it at least five times a day.)

obvious-account-dates

Original Problems Not Solved

When this change occurred we were told that this was in response to what residents wanted. I said at the time that it isn’t – this isn’t what they asked for at all.

What people were asking for were name CHANGE tokens. The ability to change your actual username (as you can over in places like Livejournal.) The current implementation does nothing to actually aid roleplayers, unless they roleplay in only one environment exclusively. It only marginally helps folks who wanted to change their last name to that of a partner.

The poor implementation of Display Names solves none of these problems.

Potential Solutions

But since the Lab does seem to be listening quite a bit more of late, I figure it can’t hurt to throw out some potential solutions. What the hell, it’s worth a shot.

What I’ve always failed to understand is why if they can make one field flexible, they can’t make two flexible. Instead of a single name with no options, why not make two names where both are chosen by the account holder.  

Further, for those who prefer a single moniker, you could make an option for “none”, which would default to the placeholder “Resident” surname.  This would open up a basically endless potential combination of names where the Lab doesn’t have to come up with anything.  This also at least somewhat solves the cultural divide problem since two names will once again be available.  Single names will also still be available for those who want that option (and the more choice that’s offered, the better.)

Though I know that some people liked the “challenge” of coming up with a good name based on a limited list chosen by the Lab, I dislike the notion that getting an account should be a hazing ritual. I prefer instead the notion of the greatest choice possible.

Second, would be to allow the official viewer to sort your friends list by username, all the time. This way no matter what Display Name is being shown or how often it may change, people can still be found quickly and easily via their unchanging username in alphabetical order. Again, this is doable in Firestorm (I don’t know if other TPVs picked it up), but not the official viewer, which seems strange for such an obvious fix.

Though I don’t know what good it will do, it might be an idea to allow people to turn unicode display names off. I don’t love this option, as there’s plenty of people using unicode characters in perfectly reasonable fashion. But it would sure be nice to turn off the display names of those who are only using it to make their names more unreadable, without turning off all display names. 

All of these potential options need to be concerned with script breakage on the back end, of course.  However, as I’ve said previously, if everything is supposed to really be done via UUID, and not names, it shouldn’t matter.  If there’s some technical limitation I am unaware of, I’m sure someone will point it out but from here I don’t really see one.

For those who are interested, there is a JIRA that’s been created on this issue, which mostly focuses on the cultural aspects of the name issue (remember to watch – they’re not counting votes anymore, just watches. Don’t get me started.) As of this writing it’s unassigned:  

jira-bring-back-last-names

I figure if the Lab is in a cycle of change anyway, why not suggest this one? Who knows, maybe it will work this time.

Resources

The 2023 B2B Superpowers Index
whitepaper | Analytics

The 2023 B2B Superpowers Index

9m
Data Analytics in Marketing
whitepaper | Analytics

Data Analytics in Marketing

11m
The Third-Party Data Deprecation Playbook
whitepaper | Digital Marketing

The Third-Party Data Deprecation Playbook

1y
Utilizing Email To Stop Fraud-eCommerce Client Fraud Case Study
whitepaper | Digital Marketing

Utilizing Email To Stop Fraud-eCommerce Client Fraud Case Study

2y