Posts filed under "Lessons Learned"
October 12, 2010
First! Randy to be the kickoff guest for new Community Chat podcast series.
Bill Johnston and Thomas Knolls are launching a new live podcast series: Community Chat on talkshoe.
I am so honored to be the lead-off guest on their inagural episode (Wednesday 10-13-10):
|
I’ll be talking with them about online community issues developers and operators all share in common – well, as much as I can in 10 minutes. :-) Click on the widget above to go there – it will be recorded for those who missed it live…
July 7, 2010
RealID and WoW Forums: Classic Identity Design Mistake
Update #3, July 14th 4pm PST: GamePro interviewed Howard Rheingold and myself for a good analysis piece in which I add some new thoughts, including a likely-to-be-controversial comparison to a certain Arizona state law…
Update #2, July 9th 1pm PST: KillTenRats.com just posted an email interview on this topic that I did for them yesterday. There some potentially useful business analysis in there, and more specific suggestions, even if it now feels a bit like residual heat from a flamethrower fest…
Hey Blizzard! I’m a freelance consultant! Just sayin’ :-)
Update #1, July 9th 10am PST: Blizzard has had a change of heart and will not require RealID for forum postings. This is a big win both for the community, and I believe, for Blizzard! The post below remains only as a historical footnote and perhaps a cautionary tale…
Talk about a crapstorm…
Here’s my latest tweet:
@frandallfarmer Quit World of Warcraft. New policy of RealID for forums - stupid beyond belief. #wow #fail #realid #reputation #identity #quit #copa #coppa
That’s too terse, given the magnitude of the error that Blizzard is making, so here’s a longer post…
Identity as Defense?
Blizzard has announced that the upcoming Starcraft II forums will require posts to be attributed to the user’s read-life name, taken from their billing information. As if this wasn’t bad enough, they’ve also said that the World of Warcraft boards will start this requirement soon as well.
They also announced a posting rating system, which sounds like they haven’t read anything from Building Web Reputation Systems, or at least about the massive disasters from combining real names and social ratings at places like Consumating.com, but that’s a post for a different blog. :-)
The idea Blizzard has is a common initial misconception – that people will “play nice” if they have to show their real names to each other. I’m sure they are using Facebook as an example – I often do this in my consulting practice. There is no doubt that Facebook users are better behaved in general than their YouTube counterparts, but the error Blizzard made is to assume that their player relationships are like those of Facebook.
This is critical misconception, and the community is responding with the longest threads in WoW history, and blog posts everywhere.
The Misconceptions
There are a lot of valid (and invalid) complaints and fears about this change – I’m not going to list them all here. What I want to do is point out the fundamental flaws in this model, for WoW in particular.
My 35+ years in building online communities (with and without RealID-like systems) screams out that Blizzard is going to be very, very disappointed with the results of this change. Specifically:
1: Names != Quality
Though this is nominally meant to improve the quality of the community, by civilizing conversation through revealing true names, it won’t because the interesting conversation will simply stop or move elsewhere. Many women (including a Blizzard employee) have already clearly stated that they won’t post anymore. This kind of thing has happened many times before as communities move from Yahoo Groups to Ning or wherever. As John Gilmore said:
“The Net interprets censorship as damage and routes around it.”
2: Brain Drain or “NetNews died for our sins”
Some say that getting rid of (bad) people is what Blizzard wants, so point #1 is a plus. But hold on there! Just owning the problem of driving customers into silence or away doesn’t help either.
Consider the case of Usenet/Netnews, where all the great internet community was until 1994 – when the environment became inhospitable to types of discussions the natives wanted to have, and they left en masse to form private mailing lists, and eventually webblogs. The assertion that a community of those who will reveal their names is somehow better does NOT hold up to any reasonable scrutiny (see next point…)
A shocking number of people who leave will be amonst the best users Blizzard has – and that could kill the quality of content on the forums, just as happened with NetNews. Sure, less trollish posts, but less great posters too. I’m betting there are less trolls to remove than there are good users who’ll leave/not post.
3: Facebook Status != Message Board Participation
I approve my Facebook Friends. None of them are trolls/spammy – or if they are, I block their events and no harm done. All of them can see my real name, status postings, comments, and other personal information. If it turns out I’m sharing too much, I can turn down the disclosure. It’s all optional.
Message boards are public. Readable by God, Google and Everyone. This model requires me to disclose sensitive information to everyone. Completely different.
Here’s the deal. We’re talking gaming here. People will get pissed at each other for stolen kills, breaking alliances, and the price of components – and they want to – no, they need to – have a safe place to express this, to play.
This is my spare time. It’s no other player’s business where I work, where I live, who my family is. Just as it’s no business of my boss, who knows how to Google my name, what I dedicate my off-hours energy to. The Facebook-analogy of Real Identity = Quality Contributions falls apart when applied Gaming. Google + Friends + Foes + Bosses + My Real Name + The fact I have 6 80th Level Characters = Too Much Information.
Facebook does NOT leak this much information, and the US Senate is looking into their privacy practices.
This has also happened many times before. Every time someone new to the net starts a LiveJournal, they don’t know about friends locking until they get asked into the boss’s office to discuss something they read on the journal while ego-surfing. This is how many LiveJournals get owner-deleted!
It is completely unreasonable to expect that people will understand the risks of using their real names on a message board – and if they DO understand, I contend that most people won’t bother posting anything at all.
In short:
- The trolls now get more information to harass
- The best players will leave
- The casual players will panic when they realize that their private-time activity is now public.
This is lose-lose. The worst kind of change. The only upside I see is the ability to lay off board moderation staff as traffic (good and bad) plummets.
An Alternative Everyone Can Live With
There was/is an alternative – described in the Tripartite Identity Model post from two years ago: Implement Nicknames!
Sure, have a top-level social identity, but present it as user-controlled Nickname and allow users to share a variant of their real name – but don’t require it! Sure, if the Nickname is the same as their RealID, feel free to show an indicator, like Amazon.com does with their Real Nametm markers. Allow users to reveal what they wish – even provide incentives for them to do so, but don’t bind full disclosure on them. Even Facebook doesn’t do this!
It’s never too late.
P.S.: I can’t stop being amazed – Asking for help on a forum requires disclosing your real name to God, Google, and Everyone? Come on! You’ve got to be kidding!
February 24, 2010
Grizzled Advice from Business & Legal Primer for Game Development
[Two years ago, I wrote up a few lessons for inclusion in Business & Legal Primer for Game Development. I’d always meant to cross-post it here and was surprised to see I hadn’t already when I went looking for it to share with the folks over at PlayNoEvil in reply to a recent post. – Randy]
Here are three top-line lessons for those considering designing their own MMORG or latest Facebook game for that matter…
1. Design Hubris Wastes Millions
Read all the papers/books/blogs written by your predecessors that you can – multi-user game designers are pretty chatty about their successes and failures. Pay close attention to their failures – try not to duplicate those. Believe it or not, several documented failures have been repeated over and over in multiple games, despite these freely available resources.
If you are going to ignore one of the lessons of those who went before, presumably because you think you know a better way, do it with your eyes wide open and be ready to change to plan B if your innovation doesn’t work out the way you expected. If you want to hash your idea out before committing it to code, consider consulting with the more experienced designers – they post on Terra Nova (http://blogs.terranova.com/) and talk to budding designers on the Mud-Dev (http://www.kanga.nu/) mailing list, amongst other places. Many of them respond pretty positively to direct contact via email – just be polite and ask your question clearly – after all, they are busy building their own worlds.
2. Beta Testers != Paying Customers
One recurring error in multi-user game testing is the problem of assuming that Beta users of a product will behave like real customers would. They don’t, for several reasons:
A. Beta testing is a status symbol amongst their peers
“I’m in the ZYXWorld Limited Beta!” is a bragging right. Since it has street-cred value, this leads the user to be on their best behavior. They will grief much less. They will share EULA breaking hacks with each other much less. They will harass much less. They won’t report duping bugs. The eBay aftermarket for goods won’t exist. In short, anything that would get them kicked out of the beta won’t happen anywhere near as often as when the product is released.
B. Beta testers aren’t paying.
Paying changes everything. During the Beta, the users work for you. When you release the game, you are working for them. Now some users will expect to be allowed to do all sorts of nasty things that they would never had done during the Beta. Those who were Beta users (and behaved then) will start to exploit bugs they found during the test period, but never reported. Bad beta users save up bugs, so they could use them after your product’s release to gain an edge over the new users, to dupe gold, or to just crash your server to show off to a friend.
So, you’re probably wondering; How do I get my Beta testers to show me what life on my service will really be like and to help me find the important bugs/exploits/crashes before I ship? Here are some strategies that worked for projects I worked on:
Crash Our World: Own up to the fact that Beta testers work for you and they do it for the status – incentivize the finding of crash/dup/exploit bugs that you want them to find. Give them a t-shirt for finding one. Put their portrait on the Beta Hall Of Fame page. Give them a rare in-world item that they can carry on into general release. Drop a monument in the world, listing the names of the testers that submitted the most heinous bugs. Turn it into a contest. Make it more valuable to report a bug than to keep it secret.
Pay-ta: Run a Paid Beta phase (after Crash Our World) to find out how users will interact with each other socially (or using your in-game social/communications features.) During this phase of testing you will get better results about which social features to prioritize/fix for release. Encourage and/or track the creation of fan communities, content databases, and add-ons – it will help you understand what to prepare for, as well as build word-of-mouth marketing. But, keep in mind that there is one thing you can never really test in advance: How your user community will socially scale. As the number of users grows, the type of user will diversify. For most games, the hard-core gamers come first and the casual players come later. Be sure to have a community manager whose job it is to track customer sentiment and understand the main player groups. How your community scales will challenge your development priorities and the choices you make will have you trading off new-customer acquisition vs. veteran player retention.
3. There Are No Game Secrets, Period
Thanks to the internet – in-game puzzles are solved for everyone at the speed of the fastest solver. Read about “The D’nalsi Island” adventure in Lucasfilm’s Habitat where the players consumed hundreds of development hours in only tens of minutes.
The Lesson? Don’t count on secrets to hold up for long. Instead, treat game walk-thru websites as a feature to be embraced instead of the bane of your existence. “But,” you’ll say, “I could create a version of my puzzle that is customized (randomized) for every user! That will slow them down!” Don’t bother; it will only upset your users.
The Tragedy of the Tapers
Consider the example of the per-player customized spell system in the original Asheron’s Call (by Turbine, Inc.): Each magic spell was designed to consume various types of several resources: scarabs, herbs, powders, potions, and colored tapers. The designers thought it would be great to have the users actually learn the spells by having to discover them through experimentation. The formula was different for every spell and the tapers were different for every user.
One can just hear the designer saying “That’ll fix those Internet spoilers! With this system, they each have to learn their own spells!” But, instead of feeling enjoyment, the players became frustrated with what seemed to be nothing other than a waste of their time and resources burning spell components as they were compelled to try the complete set of exponential combinations of tapers for no good reason.
What was interesting is that the users got frustrated enough to actually figure out the exact method of generating the random seed to determine the tapers for each user as follows:
Second Taper = (SEED * [ Talisman + (Herb + 3) + ((Powder + Potion) * 2) + (Scarab – 2) ] ) mod 12
[Modified from Jon Krueger’s web page on the subject.]
The players put this all into a client plug-in to remove the calculation overhead, and were now able to correctly formulate the spells the very first time they tried. Unfortunately, this meant that new users (who didn’t know about the plug-in) were likely to have a significantly poorer experience than veterans.
To Turbine’s credit, they revised the game in its second year to remove the need for most of the spell components and created rainbow tapers, which worked for all users in all spells, completely canceling the original per-player design.
Hundreds of thousands of dollars went into that spell system. The users made a large chunk of that effort obsolete very quickly, and Turbine then had to pay for more development and testing to undo their design.
Learn from Turbine’s mistake; Focus on making your game fun even if the player can look up all the answers in a database or a plug-in.
Don’t start a secrecy arms-war with your user. You’ll lose. Remember: There are more of them than you and collectively they have more time to work on your product than you do.
December 9, 2009
Creatures Of Habitat (@1up.com)
There is a loving historical tribute to the role that Lucasfilm’s Habitat played in the history of MMOs at 1up.com:
Creatures of Habitat
What modern day MMORPGs borrowed from Lucasfilm’s ahead-of-its time adventure — and what they still could learn from it.
By Scott Sharkey
After another year of massively multiplayer online game crib deaths, we can’t help but be reminded of the MMOG that started the whole thing back in 1985 — well over a decade before the genre even had a name. Lucasfilm Games’ Habitat remains an unaccountable anomaly in the history of videogames, a multiplayer online world from the days long before the advent of the World Wide Web. It’s the sort of historical oddity that stands out as dramatically as, say, the discovery of a fossilized dinosaur holding a machine gun: Incredible, but pretty damn cool.
…
Hell Is Other People
In addition to being perhaps the earliest example of a graphical MMO, Habitat was one of the first games to embrace the concept of emergent gameplay. Habitat’s designers threw a bunch of strange people into a huge space full of a whole lot of weird toys and items and just watched to see what would happen. It was a kitchen sink approach, in line with their philosophy that “[c]entral planning is impossible. Don’t even try.”
Of course, some of the things that happened were murder, theft, bug exploitation, and runaway currency inflation. The game’s designers advocated a hands-off approach to administrating the world, encouraging players to administer themselves, but they did intervene on occasion. The solutions to those problems (and the debate over whether they even were problems) were enlightening glimpses of the kinds of things that other designers would have to wrestle with decades down the road…
The two-page article is worth the read if you’d like a great short summary of what’s possible when no one tells you that chasing your dreams is a fools errand…
[Comments disabled on this post, please leave them at 1up.com.]
October 19, 2009
Dirty Word Filters Fail (again.)
Elder Game: MMO game development – The Tragic Story of The Cussing NPCs
Champions NPC trips the dirty word filter.
October 16, 2009
Another take on “Smart people can rationalize anything”
Calvin Trillin, pontificating in the NYT about the late unpleasantness on Wall Street.
See Smart people can reationalize anything. Hmmm.
August 11, 2009
Entitlement: When User Empowerment Backfires #octribe
Scott Moore called for posts on the topic of Fostering culture in and around online communities I chose the suggested subtopic: Culture clashes between the community and the host organization.
This is my first #OCTribe post, and I’m running late, so please forgive the terseness. I may flesh this out a bit more over the coming days — randy
This post is directed at social media product designers and community moderation staff.
How much power do you give your users?
- Do you invest special powers in your users, perhaps to help you moderate your community?
- Do you have, or want to have, user advisory groups to help improve your product by providing feedback direct from the customer?
- Do you have appointed (or self appointed) long-term community leaders that are causing you problems but you’re petrified of how much damage they’ll do to your community and/or business?
If the answer to one or more of the above is yes, you’ve been headed in the right direction. But, you need to be introduced to the community moderation thoughts around the term Entitlement.
Matt Warburton has been a senior community manager for eBay, Yahoo!, and LinkedIn and has been recently sharing many of the the lessons he learned with other social media developers and media managers. One of his recent presentations, “Voice of the Customer Programs” detailed some of the benefits and challenges of deeply engaging users for product feedback. Though his thoughts were narrowly applied to creating user advisory committees, several of the issues he raise apply more broadly to online communities especially when some users in are given backstage access to product staff and/or special powers to moderate the actions of other users.
From one of Matt’s Voice slides, entitled Best Practices:
- All participants sign an NDA
- Limit tenure of participants
- 12 month tenure recommended
- Fresh perspective
- Avoid behavior problems/entitlement issues
- Remove non-constructive or disruptive users
- Require direct staff interaction in meetings, calls, and discussion forums
- Require all participant inquiries to go through Community team
Matt learned these best practices the hard away while he was at eBay. When they originally set up user advisory councils, which -amongst other things- gave users inside access to development and product management staff. Originally, they didn’t limit the tenure of a user on this council, and this lead to very bad problems as some of the users came to think of themselves as eBay insiders and became troublesome on their message boards. Some of these users would complain bitterly that they weren’t being listened to, or that eBay was not giving appropriate credit, etc.
Entitlement Defined
Experienced community managers describe this effect as user entitlement – when either early adopters or specially selected users are given special access or power, especially indefinitely. This creates a negative feedback environment in the community: new folks come to see it as cronyism and the established users see themselves as the elite and think that they have some measure of control over the company. This can lead to the company being unable to make needed significant changes, paralyzed by fear that the community backlash will cause irreparable harm. By never empowering special users indefinitely, you can help prevent the buildup of entitlement.
I think Matt’s bold bullets above may apply wherever you encounter entitlement – not only in user advisory councils, but whenever users are granted special powers or access either explicitly or implicitly.
Backlash Can Be Good
Yahoo! Finance message boards are a good counterexample – where the backlash is exactly what the company wanted. The message boards were a mess, anti-Semitism, racism, day trader wannabes spreading scandal and lies about companies – consistently this feature of Yahoo! Finance was listed as the worst. When we added threading and reputation, there was a hue and cry from the community: we’d made it less chatty and more about sharing stock information. We lost 25% of our page views immediately as a very small number of active users left the boards for someplace else they could chat the way they liked. But, something amazing happened, the quality of postings jumped significantly. The masses, who were readers – not posters, were able to provide feedback about what was good and what was not, and those who stayed (or started posting because things got better) started carrying on the conversations that we’d originally intended the boards for.
Lines of Control
There are three categories of control over an application/site:
- There are the things the company always decides on its own – These includes issues related to legal juristiction and government compliance, business model prioritization, branding and marketing, and the order that features and bugs will get fixed. The law of law and the budget.
- And there are the things that the community always decides – this usually includes the social customs of the interaction, what’s the most interesting/useful content, and if they will play with you at all. The law of two feet.
- Lastly there is the great in-between, where both the company and the community work together to figure out what is possible and profitable for the majority. This category is where user action is directly related to corporate re-action and vice-versa. Some common forms of this include creating extra content (tags, links, etc.) and user-moderation of other users’ content. This is where much of the gold in social media/online communities is, but it is a balancing act. If you detect entitlement, it’s a sure indicator that this category has become too broad. This is the law of tit-for-tat.
There must be clear lines about what the users can influence and what decisions belong solely to the company and these lines must be made clear on the site and by all staff that interact with users.
Yes! Empower users! But never forget that power should be limited and scope and time, and come with responsibilities on behavior.
Do not fear getting rid of bad apples (as long as you do it consistently) – they don’t really have the power over their peers that they think and they have been driving away even more users that you never hear from!
October 14, 2008
Context is King: Lessons from Online Communities
Here’s the SlideShare from the talk I’m giving tonight at BayChi. This is the first time I’m presenting this information to the general public. If you can make it, I can only say that the notes I uploaded with the deck are complete, but are really only a guideline to what I might say live – every presentation is different.
If you’ve come here after the presentation, please feel free to comment on this post as an alternate feedback channel.
When the video is available, I’ll update this post with the pointer and share the presentation more widely.
September 25, 2008
Context is King talk@ Baychi October 14th
I’ll be giving my talk “Context is King” at BayCHI on October 14th. Kevin Cheng will also be presenting: “See What I Mean: How to Use Comics to Communicate Ideas”.
Context is King
For more than three decades, people have been mediating communications with each other using computer networks.
Strangely, detailed best practices about how to facilitate online collaboration, communication, and community (aka Social Computing) are not yet in broad practice. Randy Farmer is working on a book that he hopes will remedy that situation by providing detailed patterns and anti-patterns for building online communities in context.
This talk contains many of the core inspirations for that work. He will outline common contexts and describe typical pitfalls encountered by product design and community operations staff when creating and operating social media-laden sites.
This is the first time I’ll be giving this talk to the general public. Of course, this means I’ll have to finally publish it on SlideShare (and blog that here). Any tips for converting would be greatly appreciated.
August 1, 2008
Halo Corpse Block Chattm
Block Chattm in Halo, done with corpses
(via Bryce Glass via Boing-Boing)
[Yes, we’re still waiting on our disk recovery for most of the archives…]