Heard That One Before, Part 3: System Viagra

This post is part of a series of things that are just not useful to say when you're working with Phoenix/Firestorm to troubleshoot an issue. For background, the series begins here.

3) "My computer is brand new / has 20 gigs RAM / has a graphics card that can beat up your graphics card / is on a super-speed connection / could launch a space shuttle if I told it to / has some other uber-awesome characteristic that ought to make it unrealistically powerful in SL."

…or what I like to call System Viagra. This is the reaction we sometimes get in response to the mere suggestion that the problem might be related to the user's system, as if their hardware were an extension of their (figurative -- we get this from women too!) hardware.

There are variations. In one, folks get offended if you suggest they shouldn't be maxing out certain settings. Or sometimes they enter the conversation already convinced the problem lies with the grid or the viewer's failure to adapt to their computer's demands. As you can probably surmise, having a ridiculous ego about your machine is deeply unproductive to the troubleshooting process.

We do want to know what your system is when we're helping you, but there isn't a direct relationship between how new or high-quality your equipment is and whether or not you have problems in SL. That's kind of like saying that the problem with your Ferrari can't be under the hood -- or in the driver's seat -- because it's a Ferrari.

Of course certain components can give you somewhat better performance than average. Of course people spend a lot of money on "gaming systems" to use with SL and MMORPGs. But newer/bigger/better/faster/more doesn't make you exempt from any troubleshooting step. It doesn't make your computer magical or give it superpowers. It doesn't change the rules for you.

Perhaps a particularly sticky area is the realm of comparison and the "But it gets twice the FPS on < other viewer or virtual world X >" remark. Saying, "Firestorm should get the same performance as Phoenix" is comparing apples with oranges. The codebases are different, and different results are entirely normal, albeit inconsistent. Comparing Firestorm with the client you use for World of Warcraft or another MMORPG is more like comparing apples with… well, sauerkraut. Not that there's anything wrong with sauerkraut; it's just not apples (though apples and sauerkraut can go pretty well together in the right salad, but I digress). 

Even without faulty bases of comparison, sometimes folks get full of "should" for arbitrary reasons. As in, "I 'should' be able to run my bandwidth setting up to 10,000," or, "My computer 'should' be able to run on Ultra with shadows all the time because it has so much RAM." Don't be full of "should."

An ironic bit is that sometimes those on the strongest System Viagra prescriptions end up with loads of presumably "performance-optimizing" software on their computers. Some of these behave very poorly with Second Life and may even drag performance down or increase crash rates. Part of the troubleshooting process will be to ask you to turn these off.

Here are my tips for avoiding the System Viagra effect while troubleshooting:

i) If you start with assumptions about how your computer "should" or "is supposed to" perform with Second Life, then you're setting yourself up for issues. Instead, listen to what your computer wants to do. If you learn how to respect it, you may find you have much more control over your performance than you realize. The more you know about different settings in your viewer, the better you'll be at this, as well. Just remember the golden balance: higher settings mean slower performance. For everyone.

ii) Put things in perspective: an FPS of 50 is amazing regardless of what you used to see. If you complain to me that it used to be 100, I will whip out my very, very little violin and shed a single eensy weensy tear. At 50, you're still getting twice the framerate you see in the movie theater or on television. If you dropped from an average of 30 to 10, then I would be much more concerned and motivated to figure out what's wrong.

iii) Know the proper bases of comparison. When it comes to Firestorm, the best comparison is Viewer 3, whatever version of it is closest to the version of Firestorm you're on. If there is a significant difference between those two, while in the same locations and surrounded by the same number of avatars, then is the time to be concerned about viewer issues.

iv) Always troubleshoot performance issues at moderate settings or lower, not at the settings you might think you "should" be able to get. If the problems go away at Mid level graphics, then I'm sorry to say that your system ego may need a little deflating.

Well, not really that sorry, if I'm being honest. System ego is one of the sillier barriers to troubleshooting.

Tune in next week for 4) "Fine then, I'll just use a different viewer."

Heard That One Before, Part 2c&d

This is an installment covering a series of statements that members of the Phoenix/Firestorm support team hear fairly often and that are more likely to pose barriers to troubleshooting than to help the process along. This is because they point to misunderstandings about the way that viewers and/or issue-fixing work. For more of an intro, see the initial post on this topic.

This is also a continuation of last week's post, on the statement:

2) "A lot of my friends / people I've talked to / people in this group are having the same problem."

…which comes with a bunch of possible underlying implications. Here I want to address these two:

 * "…so I must belong to a group that your developers don't care about."

 * "…and I need to tell you this because I'm more in touch with the wide world of SL than you must be."

c) "…so I must belong to a group that your developers don't care about." This one's far less common than the first two, but I wanted to touch on it because I hear this mostly from Mac users. Poor, downtrodden Mac users. You are my people. And "poor, downtrodden" was pure sarcasm.

There are a few who pop up on a regular basis -- well, ok, just one in particular comes to mind -- one who blames every single problem he has on the fact that the viewer (or SL) supposedly isn't designed with Mac users in mind. Never mind the fact that a good portion of the issues he complains about are affecting Windows and Linux users as well. But he can't be arsed to pay enough attention to the other reports we hear in Phoenix/Firestorm Viewer Support to know that.

While there are certainly some issues specific to Macs, they don't, in my experience, outnumber the issues that are specific to the other OSes. If anything, they may be proportionally fewer. Meanwhile, issues that only affect Windows are relatively invisible as OS-specific issues; instead, they simply get labeled as "issues" or are referred to by the graphics card or driver they mainly affect. So when folks on Mac Snow Leopard couldn't view shadows on Firestorm 4.0, it was called "a Mac issue." But when Windows users with ATI 3000-5000 series cards were seeing pink textures on Firestorm 3.3, it was called "a driver issue." (They were both driver issues, but the Mac users in question could only have updated their drivers by upgrading their OS to Lion or the still-unsupported Mountain Lion; Windows users can update drivers and OS independently.)

As for the issues that are system-specific, do your research before complaining that it hasn't been fixed yet because of the Mac factor. There's a profile-opening crash on Phoenix that only affects Mac. The fact that it hasn't been fixed yet has a lot more to do with the fact that no development work is being done on Phoenix right now than it being Mac-specific. The devs are focused on Firestorm and have been for many months. Sorry to be the bearer of bad news, but Phoenix issues in general might never be fixed, so you might want to find a Plan B.

Sometimes the group in question isn't Mac people, though. Sometimes it's an inworld community. I spoke with someone at one time who was having general performance issues. This is not an uncommon thing to handle, but he insisted that everyone he knew was having the problem and so he flat-out refused to try anything that implied (in his mind) that the problem was individualized. Ok, I said, then you should file a JIRA and have your friends comment on it. The devs can determine if there's something you all are doing in common…. But no. Flat-out refused to do that, too, because he didn't want to have to check it. Not kidding. That was his reason.

I suppose I could have also gone around to all of this guy's friends, gotten their system info individually, and polled them about their use habits so that I could analyze all the data and come up with some carefully calculated conclusions about why this group of people were having a problem that normally occurs to a sprinkling of isolated users for highly individualized reasons, but, uh… no.

This particular group had a serious case of hivemind going on anyway. Apparently they all had to be using the same viewer at all times, and if I (this user did indeed imply that their future use of the viewer was in my own two hands) couldn't fix their collective Firestorm problem, they'd use something else. Enough said about that.

And that, actually, is the implication of "All my friends are having the same problem" that I was almost (but not quite) too tactful to bring up: collective reinforcement. The fact that it's downright uncanny when a specific group of individuals end up being the only ones among our many, many users to have a certain problem. If it's not a more general viewer problem, and it's not attributable to habits you all have in common, sorry to be so blunt, but it's either one person exaggerating the extent of the problem or a group of people reinforcing each other's hypersensitivity to something that they just can't all realistically be experiencing to the same degree.

The current version of Firestorm has an insanely low crash rate. Insanely low. I can't say what it is in numbers, but the viewer has been at the top of the TPV list (which is ordered inversely by crash rate) since release. And yet we still get people who tell us, "This is the crashiest Firestorm ever!!! My friends and I can't stay on it!!! Fix your damn viewer!!!" Sweeties, you don't need to do that. If you're experiencing crashes yourself, we can try to figure out why. You don't need to make exaggerated claims about your friends to make us take you more seriously; there's a good chance it'll have the opposite effect.

Incidentally, this subtopic melts nicely into the last reason people sometimes say, "All my friends are having the same problem":

d) "…and I need to tell you this because I'm more in touch with the wide world of SL than you must be." Hang on one second.

HAHAHAHAHAHAHAHAHAHA.

Ok, I'm composed now. Sorry, but this one doesn't even make sense. Still, I pick up on this vibe sometimes. Once, I was handling a support ticket with someone who, when my first suggestion did not work for her, filed a new ticket, saying, "Get me someone who spends some time in SL to help me." I refrained from replying to her with the actual number of hours I spend inworld. It's embarrassing to admit even to SLers. Really. But somehow there is this assumption that "residents" and "support" are mutually exclusive categories, the way they are with *cough* some outsourced support-providers who are *cough* not us. If you didn't know it, though, folks on the team were invited to join specifically because we are typical residents with an atypical degree of insani--I mean, interest in helping people.

Second Life does tend to consist of a wide variety of subcommunities, though, all with their separate concerns, norms, and ways of using the viewer and the grid, and it can be surprisingly fragmented. So it's not unusual for you to take certain activities and other things for granted as just part of what SL "is," while it may be totally foreign to others.

For instance, I posted a research blog post about subcommunities once, with Gor as an example, and a couple of people who responded said they'd never heard of it before. I have no connection to Gor, but it seems so ubiquitous that if you've been in SL for any length of time, you'd probably have run into it. A lot. But if you generally hang out with the same people and do the same things all the time, that's not necessarily true, and it doesn't make you out-of-touch. Well, maybe just a little.

On an individual level, too, people fall into viewer-use habits and can't imagine how other people do things differently. You might end up describing an issue that affects people in your subcommunity and not a whole lot of others. If that's true, then let's figure out whether it's a bug that affects behavior more common for you than for most, or whether it's a support issue related to your community's habits. Yup, that last part implies what you think it does -- that, going back to scenario A from last week, a common problem may nonetheless be something you caused or, at any rate, need to do the work of fixing.

Once in a while folks tell us that a change that was made is to the detriment of not just themselves but to everyone like them. Be careful of how you represent yourself and others when it comes to communities, though.

When Firestorm was still in its early development, our devs found a way to solve a most annoying problem with the V2 design: that of having more than one group profile open at once. The old sidebar behavior prevented this, so when the devs found a way around it, it was a big deal and very popular (relatively speaking -- FS didn't have big numbers a year ago). One thing we've learned over time, though, is that no matter how popular a UI change is, there will always be some who liked it better the old way, and so most of the time our devs build in options. This was an exception.

Sure enough, a few months after this change to group profiles was made, I spoke with someone who hated it. She preferred it when one group profile would replace the next when opened because it made it easier to spam group chats with event announcements (I don't think she used the word "spam," but the rest was as stated). Rather than presenting her complaint in terms of personal preference -- which I honestly would have had more sympathy with -- she decided to claim that her preference represented that of the larger population of event hosts. As if we neither had any on the team nor came in contact with a single one over the months since the change went in. Maybe I'm just not spammy enough with my events to qualify as a true host, but it's more likely she was just trying to generalize the impact of her gripe in order to make it sound more legitimate.

If it is true that your issue would be a popular one and that an entire community is being overlooked, well, the proper means of communicating that is through the JIRA. After you create your feature request or bug report, you're welcome to point other affected people in its direction. Unlike on Linden Lab's JIRA, votes on the Phoenix/Firestorm JIRA are taken into account (albeit alongside a number of other factors, such as dev ability and availability, prioritization of other issues, and whether action is needed from Linden Lab). Some roleplay communities have been communicating their needs in this way since the non-RP-friendly early history of Firestorm and thus their needs stay on the radar.

So in a nutshell, the people on the support team tend to be exposed to a lot more than the average SL user just because we help people from all corners of SL every day and come from a huge range of communities ourselves. But there will still be things that are totally normal to you but we haven't dealt with before. More importantly, you never, ever have to use the "All my friends" line to convince us to help you. It's completely unnecessary, and if it's an exaggeration, it will be counter-productive. Let's just learn how to touch base with each other and get your problem solved.

Look forward to the next topic: 3) "My computer is brand new / has 20 gigs RAM / has a graphics card that can beat up your graphics card / is on a super-speed connection / could launch a space shuttle if I told it to / ."

Heard That One Before, Part 2a&b

This is the second installment covering a series of statements that members of the Phoenix/Firestorm support team hear fairly often and that are more likely to pose barriers to troubleshooting than to help the process along because they point to misunderstandings about the way that viewers and/or issue-fixing works. For more of an intro, see the initial post on this topic.

We occasionally speak with users who need help with an issue and who, for one reason or another, decide to throw this in:

2) "A lot of my friends / people I've talked to / people in this group are having the same problem."

First, you don't have to use this to justify the importance of your issue. We'll help you if we can, even if you're the only person with a certain problem.

Second, if something is affecting a lot of people, you can trust our team to know that better than most. With thirty team members in English alone (more than twice that many when you include all nine language teams) each talking to dozens of people each week and to each other about them, we often find ourselves aware of grid problems even before the Lindens are. Certainly, we won't know the brand new ones right away. But if it's an issue prevalent enough for you to be able to say that "A lot of people are having the same problem" with accuracy, then yeah. We would know about it.

But the fact that we probably know it is not the reason this statement is in a list of things we don't need to hear. It's because of the oft-underlying implications, which may be any of the following:

 * "…so the problem's not at my end, it must be the viewer."

 * "…so why isn't it fixed already?"

 * "…so I must belong to a group that your developers don't care about."

 * "…and I need to tell you this because I'm more in touch with the wide world of Second Life than you must be."

Let's discuss these a little more. It's a lot to swallow, so this post will cover the first two, and I'll get to the other ones next time.

a) "…so the problem's not at my end." Maybe, maybe not. Just because it's common doesn't mean that it always has the same cause or that the cause is out of your control. And some people hate to hear this, but even if you didn't cause it, you're probably gonna need to do the work to fix it. Here's an everyday example:

Bake fail?* Server communications problem often aggravated by sim conditions, connection quality, and occasionally non-ideal viewer settings, among a bundle of other things. The most consistently common complaint, if not the most common, period. In the end, though, it doesn't matter where it came from; every known fix involves your active participation. And there's zip that can be done at the level of viewer development to prevent the issue.

So. Common issue? Hell yup. Viewer problem? No sirreebob. Something support can help you with? You bet your pretty little patootie, but only if you're gonna hold up your end of the process. Yeah, sorry, there's always a catch.

The conclusion of "so the problem's not at my end" doesn't start and finish with bake fail, of course. Denying that you can play a hand in the solution doesn't help the troubleshooting process. Sometimes we are accused of the reverse, trying to push "fault" onto users. Lemme tell ya something: I love it when I can identify a viewer bug. I want to be able to say, "Sorry, I can't do anything for you, it needs to be fixed in the viewer." Why? Because when it's true, it's a solid answer that saves me a buttload of support work. When I opt to take a closer look at causes and solutions that you, the user, can work on, it's not because I don't want to acknowledge that our precious viewers don't have problems (LOL); it's because factors that you have control over need to be ruled out before any progress can be made. It may turn out to be a viewer bug yet, but the work needs to be done to determine that. And "A lot of people are having the same problem" doesn't remotely qualify.

b) "…so why isn't it fixed already?" Dunno. Is there a bug report on it? This topic is a really good one for delving into the differences between the two main divisions of our overall organization: the support team and the development team.

If it's a problem that the "Why isn't it fixed already?" question even applies to, then it's not something support can control. If it is in fact a viewer bug, then we might be able to help you find workarounds, depending on the issue… but the only true "fix" would be the developers' domain. And for that you need to be filing and watching JIRAs. There's no alternative.

I know, I know, but you hate JIRAs. They're annoying to write, hard to read, prone to trolling by pseudo-know-it-alls, and you're not sure if anyone even looked at yours. Plus, some dev might come around and ask for more info, and then you have to do more work??? Pffbbt.

Or to put it as some do, you might be of the mind that "JIRAs don't work." Well, that all depends on what you expect them to do. They won't bring overnight change, but nor does complaining to the support team or trolling the group with "Why hasn't this been fixed yet?" All the JIRAs get looked at individually and eventually triaged. However, it probably won't go as quickly as you hope it to. Though it depends on the topic, support is usually fast; in comparison, development is sometimes really, really slow and is always affected by what else is on the docket. Something you report now might not be implemented for months. That's not the same as "not working." After all, it's still a lot faster than if you didn't file it at all.

I think one reason people are more likely to jostle support than file JIRAs is that they feel more comfortable when they have someone to talk to directly about their issue; if you can see the work happening, as you can in the kinds of issues that support can help you with, then it feels more real than if you have to wait ages for a release with your fix in it. That sense of comfort is understandable. I, for one, won't fault you for wanting that one-to-one contact, as long as you're aware that you can't speed up the bug-fixing process by talking to me. What I can do is help you get more comfortable with filing and commenting on bug reports. I'm happy to do that -- just ask!

If it's true that "a lot of people" have the same problem, then they'll appreciate you for it, too. As I said up top, there are other reasons we hear this statement. Tune in next time for a couple more.

* "Bake fail" is the term for a broad category of avatar rezzing problems. Some use the phrase just to refer to avatar texture rezzing; others include failure to load body parts as well. The broadest definition may include: ruthing, clouding, avatar partly or fully transparent, blurry textures, textures not changing, looking different to yourself from how you look to others, etc. Prim attachment problems are not included. Fixes can be found on our wiki pages, for Phoenix and for Firestorm.

Heard That One Before, Part 1

Since the last time I posted anything to this blog, a lot has changed in both my Second Life and my real life. The two most significant changes are that I finished the work for my Ph.D. (graduation is this coming Sunday) and that I've been on the Phoenix/Firestorm Support Team since February of 2011 and on its management team since last September. I still host and play lots and lots of trivia in SL, but I don't hunt much anymore. My goal is to make my living as a freelance proofreader/editor, or possibly voiceover artist, and hopefully move someplace new. I'm a fan of big cities.

It was inevitable that I would want to write about some aspects of support eventually. Although we help hundreds of people a day through our inworld groups, our web-based JIRA issue tracker, and our classes, in addition to one-on-one help in IMs and any number of casual encounters that turn into support, there are still a lot of people who don't know what kind of help we give. Some of those end up not seeking out assistance when they need it (and either complain about the viewer to people who can't help them or hang back on aging versions because the new ones "don't work"), while others want our help to be something it's not and grow angry when we don't fit their expectations.

In fact, in my experience, unrealistic expectations -- not only concerning the role of the support team but also concerning the way a variety of things work on a technical level -- become a primary barrier to receiving support. And so I've been working on a series of posts highlighting some of the perceptions, arguments, and misunderstandings people bring to us that end up becoming barriers to troubleshooting.

Happily, most people don't approach us with any of these. I want to be clear about that from the get-go. Usually, the folks we help are postiive, open to providing whatever info they can, and willing to look into the suggestions that are offered to them. They enjoy learning more about the viewer while they work on their problems, and these are the users that I find myself learning the most from, as well.

So I hope this will be informative, or entertaining, or something. I hope it can spark discussion, but only if dissent is kept civil. I also hope that at least some of these have some use beyond the context they were written for, since that context is admittedly rather narrow.

A totally unrelated picture of folks at Flying Badger Trivia. Just because.

And with that, let's kick off the series I'm calling "Heard That One Before," on things that are not as useful as some people think they are to say to viewer support team members:

1) "I'm a programmer / I build computers / I'm a NASA engineer / I do tech support for < insert non-viewer product here > / I've had a computer stapled to my fingers since before I was old enough to read the keys."

When people inform us of this in the middle of receiving support, the implication always seems to be that we therefore need to be careful not to insult their intelligence. However, all it really communicates is, "I'm embarrassed to be talking to you in the first place so I'm going to fight every one of your suggestions if I can find a way to do so."

Knowledgeable support in any area is going to be specialized, so it matters very little what quasi-related background you have. Even members of the team come to each other for help, and we don't (I hope) feel any humility about it. By all means tell us what you know, but don't mistake titles and labels for an indication of useful knowledge. More importantly, don't expect support to know what those positions suggest you do or don't know, or what you might have already tried before you came to us. The basics need to be covered regardless of what you do for a living.

Do we know everything? Of course not, and it's pretty normal to hit a number of dead ends in the troubleshooting process before finding the right route. But attempting to pull rank on someone who's trying to help you isn't going to lead to a faster fix. It's not like we hold a set of sooper sekrit Fixes for Advanced Users Only in reserve.

In fact, we find that those who do know what they're doing (and not just know how to slap a gold star on their own noses) understand why it's important to start with basic steps and double-check even the most obvious possibilities, and also to make sure both user and team member are on the same page about terms, tasks, and meanings.

For instance, if you hear, "When you did your 'clean reinstall,' did you get all three folders?" it's your own choice if you decide to be insulted by such questions, when all we really just need to know is, "Are we talking about the same thing here?"

So check your expert ego at the door when you need us. As any responsible proofreader will tell you, even proofreaders need their work checked.

****

Watch for the next post in the "Heard That One Before" series: "A lot of my friends / people I've talked to / people in this group are having the same problem."