Heard That One Before, Part 9: Connecting the Dot Dot Dot

This post is part of a series on common barriers in communication when it comes to getting help for problems with Firestorm Viewer in Second Life. The series starts here.

9) Can't you just get the devs to do it?

Pffft. I wish.

"You there, dev. You got nothing better to do? Well, this random user wants me to get you to drop that project you're already in the middle of and work on the issue they think is more important."

Yeah…no.

There are two main reasons people ask, "Can't you just get the devs to do it?" One is that they don't want to file the bug report or feature request on it themselves for any of a variety of reasons (lacking in self-confidence, hate the JIRA, simply lazy, etc.). The other is that they think that a support person will be more effective at "getting a dev to do it" than they would be because we have "connections."

Both reasons are based on misconceptions of the process and our team's structure.

How It Works

The two biggest misconceptions that shape these problems have to do with 1) the process and 2) its pace, and these misunderstandings feed into animosity about or reluctance to engage in reporting bugs. Just a hunch, but I suspect that those who know more probably have more realistic expectations.

So we'll start with how bugs that you find or features that you want normally get implemented. I'll refer to bug reports here, but feature requests actually follow the same process.

In almost every case, it starts with a user submission at http://jira.phoenixviewer.com/. Now… a number of people who've delivered the "Can't you just…" line seem to argue, "But there was this one time when I mentioned this thing to a dev and it happened right away. I didn't need to file a JIRA then, so why should I have to now?" That's going to be an exception, not the rule, and most likely, the dev did it either because they were already planning to do it or because someone else filed a request for the same thing. If you look through old issues, there will most likely be one there that matches yours.

http://jira.phoenixviewer.com/

And so, it starts with a bug report on the JIRA. The issue will get its first look pretty quickly. A few people on the team look at new issues daily. They'll ask for additional info if necessary. They'll link and close issues that are out of scope or duplicates of previous reports. They'll move issues to the support section (not publicly visible, but you'll be able to view your own issues there) if they aren't true bugs. After that, though, it's time to wait.

Depending on the issue, it may sit for a while. Some sit for only days, others for months and months and months. This doesn't mean the issue has been lost, that it will never get implemented, or that it isn't getting looked at on occasion. All it usually means is that there is no developer available at the moment who has the time to work on that specific issue and knows what needs to be done to implement it. That's actually pretty straightforward when you think about it, right?

After an hour, a week, a month, or a year, it may get assigned to a developer. That developer will work on fixing the bug for however long it takes, given the complexity of the code, their real life and SL schedules, and their other development workload. After another hour, week, month, or year, they'll finish the code, mark the issue as fixed or completed, and add it to the viewer repository (the big code collection that comprises the viewer).

Once the code is in the repo, it waits to get tested. Since Firestorm's releases are usually about two to three months apart, it might take even more time before that bug fix actually shows up in a publicly available version of the viewer, but the status can be tracked in the issue you filed. If it passes QA (quality assurance), then it will be included in the next release.

And voila, that's the route from issue to fix.

How long can you expect it to take? Well, over Firestorm's history, the average time from issue creation to issue resolution has been about 73 days, though specific issues have taken anywhere from one to 535 days. As far as I'm aware, that's not an unusual pace for software development, especially when the developers are doing the work in their free time. I include these numbers to provide some perspective. Some people "hate the JIRA" because they think it "doesn't work," and they base this assumption on the fact that the bug they reported last month hasn't been fixed yet. It's like refusing to use a car because it doesn't fly. Or teleport. Patience, grasshopper. 

And there's always the duh factor. Although 73 days might sound like a long time to wait for something you think you need, guess how long it will take if you don't file at all? Go ahead and hold your breath. I'll let you know when your face turns blue.

"Connections"

The more laughable reason we hear "Can't you just get the devs to do it?" is when folks think that if the request comes from someone on the team, it will hold more weight than if they do it. In some cases, they think that we have so much weight that we wouldn't even have to file a JIRA for it -- that all we need to do is ask. I even got into an argument once with someone who wanted Jessica Lyon to file a JIRA for him because her voice would have the most pull. And she should do this favor for you… why, exactly?

To address the idea that we don't have to file JIRAs: We do. Everything gets filed. If we have a feature request, we file it. If we spot a bug, we file it. Developers file JIRAs for other developers to work on. Developers file JIRAs for themselves to work on. And if a developer has already done work on something, they'll file a JIRA retroactively so that it's documented for the testers.

The JIRA is a to do list and a record of what has already been worked on. Literally no one is spared from JIRAing.

As for the "connections" perception, well… it's an odd one because it's more skewed than it is completely wrong. But it's a weird interpretation of our actual team dynamic, and the weirdness feeds into why saying, "Can't you just have a dev do it? You're the one with connections," won't get you very far.

So… yeah, I know the devs. I'm in contact with them all day in our various inworld and out-of-world chat rooms. We have a whole virtual office going on. With that frame of reference, would you say the shoe department has "connections" with the furniture department? That patents has "connections" with accounting? That obstetrics has "connections" with oncology? We're just different departments on the same team. When we work together, it's not about pulling strings, it's about collaboration, as teams do.

We don't schmooze with devs, we work with them. And when we have issues we want looked at, we file JIRAs. Indeed, if we asked the devs for "special favors" for everything we wanted, let alone all those we are asked about, our working relationship would sour very, very quickly.

Making it Work for You

Admittedly, filing a JIRA is easier said than done. I can repeat the mantra til kingdom come and some people will still avoid it like syphilis. Let's talk about the legitimate concerns and how we can help you with them.

"It's designed for people who aren't me." Would it make you feel better if I said that's how I feel about Facebook?

"I can never find anything on it." The search functions actually became easier to use lately with a platform update, but I agree it can still be confusing.

"I'm afraid of putting something in wrong and ruining my chance of getting my issue looked at." Been there myself, so I'll try to quell the fears.

Yeah. A large chunk of it feeling foreign and uncomfortable is just that it's foreign and uncomfortable. The fact that it appears jargony and techie and scary can intimidate some into thinking it's hard to get used to, but it's really no worse than any other platform when it's new to you. The biggest difference is that when it comes to the JIRA, you have a team of support people standing by to answer your questions.

There are three ways you can learn about how to use the JIRA:

• Reading and following the wiki page on how to file a JIRA;
• Attending the Reporting Bugs, Requesting Features class we hold inworld (class schedule updated progressively);
• Asking a member of the support team -- not to do it for you but to explain anything you don't fully understand.

http://wiki.phoenixviewer.com/file_a_jira/

If you're just trying to find your way around, either the wiki page or the class will work well for you. If you're specifically having trouble with the search mechanisms, come to the class -- we give some tips on that, with visual aids. If you're worried about embarrassing yourself by filling the report out wrong, either attending the class or seeking out one-on-one help is probably best.

We're used to seeing errors in the JIRA, and we can edit your ticket if the errors create ambiguity. We'd rather have a shabby JIRA from you than no JIRA at all.

I should note that on some occasions, support people will do a JIRA themselves based on your complaints or comments, but this is most often the case if it's a bug they can reproduce on their systems and that they think they can describe best. It's not as common for feature requests, and if the team member can't reproduce the bug, they're not going to be the best ones to file the report -- you are. Furthermore, it's a case-by-case matter even when we choose to do the filing. If you have a bug that takes place only in Mouselook, for instance, I'm not going to file it for you even if I can reproduce it: I don't use ML regularly, and my familiarity with its quirks is probably limited to what you've just told me in our conversation. I wouldn't be able to describe the problem as well, and if a dev asked for more info, I'd be totally useless.

Fact is, you are the expert on your own experience, and in most cases we need to hear it from you when things are not right for you. Finding and reporting bugs is a collaborative responsibility. You are entrusted to take part in this process, and we'll do our best to show you how.

Heard That One Before, Part 8: Keeping Small Talk Small

This is the latest in a series of posts concerned with unproductive approaches to getting support from members of the Firestorm Viewer Support team. Today's is about opening lines.  But it's about so much more than that (which is why it ended up kinda long). It's about learning lessons from the introverted that allow us to broaden our perspective on effective communication. If you'd like to start from the beginning of this series, episode #1 is here.

But for now, the next unproductive thing to say when you first try to contact a support person is:

8) "Hi."

Dammit, Jim, I'm a support person, not a dentist.

If you need help from support, please be forthcoming and don't make us pull teeth to try to figure out what's wrong. We don't want to play twenty questions with you, we want to hear what your problem is and give you an answer. We're not identical across the board in terms of how we respond to IMs, however, so let's talk about what you can expect when you contact us.

This is a tricky issue to discuss without coming off as unfriendly, so I'd like to frame it within two particular themes. One is respect for people's time; the other is challenging the dominance of extrovert-oriented approaches in social interactions. Eek, I just got really academic-sounding on that second one. I promise it won't be so painful when I get to it. We'll also talk about the benefits of listening.

Keeping the Small Talk Small

Support team members are Second Life residents. We could be doing anything at all when you IM us: creating content or shopping for it, slexxing with partners or leaving our avies afk. We need to set limits for ourselves in order not to feel as if we are "on call" to the entire metaverse at all times. Each of us does this in different ways.

Some support team members don't respond to unsolicited IMs at all. That's a little extreme for me, but hey, if they need to do that to stay happy doing support, then it's all cool. Others are perfectly ok with small talk and will welcome chat before, during, or after the problem-solving process. 

I fall somewhere in between. I just want to know enough about your issue to know how to approach it before I answer. That means that instead of saying just "Hi" or "Are you there?" or even "Can you help?" I want you to tell me your actual problem. "Friendly" introductions like these place the burden on the support person to try and get you to the point. We won't always have the patience or the time.

The IMs I respond to most promptly are the full-paragraph questions that include lots of information and give me a good idea of whether I'm in for a two-minute or two-hour helping session. (Though of course I still can't answer if I'm afk, in the middle of a class, or hosting a trivia event.)

The trouble here is that when people say nothing but "Hi," they're not generally trying to irritate us. Some of them genuinely believe that a warm and social introduction will be appreciated more than a cold, hard question. And others just don't think of it at all -- they're just checking to make sure we're paying attention.

I have no sympathy for that last one and will always ignore "Lette?" and "Are you there?" The wonderful thing about text conversation is that it doesn't always have to take place in real time. If you ask your (direct and highly detailed) question now, I may answer it hours later, but I'll usually answer it. If you absolutely require an answer ASAP, you're best off asking the support group anyway. There isn't always someone immediately available with an answer, but it's a better bet than asking only one.

As for the "warm and social" type, I do sympathize… but there's another side to that. And this brings me to the second point I mentioned above, the one involving lots of long words.

Social Skills 201: Sometimes Less is More

Even in SL, where perhaps the majority of people I've met consider themselves to be introverts in RL, we (introverts, extroverts, and fence-sitters alike) still run the risk of being misunderstood as unfriendly or antisocial if we're not interested in investing energy in a conversation with someone we hardly know. 

I use the word "energy" on purpose, not because I find you, person reading this right now, personally draining, but because for introverts, social interaction usually means an expenditure of energy, while alone time means recharging. This doesn't mean introverts are all hermits, but it does mean that they're likely to be economical with their social time. If you're IMing an introvert like me for viewer help and start in with pleasantries, you're gonna wear us out before you even get to the hard part.

So how do you know if someone's an introvert or an extrovert before you contact them? You don't, unless there's something in their profile to indicate it. But nor does it matter. This isn't about individual styles, this is about what we can learn from the existence of different individual styles.

Let me put it this way: I don't think I've ever heard anyone say, "I wish these users would engage in more small talk before they got to the point. I mean, is it really so much trouble to say, 'Hi,' 'How are you?' and 'Can you help?' before they ask the actual question?"

My point, to put it directly, is that a lot of our habits and what we think of as "courtesy" come out of a culture where extroversion is the norm. Sometimes those habits aren't always the most appropriate, which means it's worth learning from the introvert's perspective what some of the alternatives are and when it's best to use them.

When it comes to IMing someone out of the blue for something, whether it's viewer help or customer support for a store or looking to buy or rent land, courtesy is less likely to mean leading with a few warmup phrases and more likely to mean respecting the other person's time by being direct and to-the-point.

Finally, let's talk about when the equivalent phenomenon hits the support group. There are some key differences in what we see there.

Attention!

It happens when a user unfamiliar with the group says, "Hello?" … "Anyone there?" And there may be fourteen streams of conversation going on around them. Questions, answers, support people caught up in the rhythm of shooting out info, links, and follow-up questions. The person starts to think that because no one is going out of their way to say, "What is it, User X? What can we do for you?" that it must mean they're being ignored. Ten minutes later, after maybe saying "Hello?" a couple more times, the person finally says passive-aggressively, "Fine, guess no one wants to help me."

Soon as they do that, a few people, usually our more regular users/non-mod helpers, will inevitably point out that the passive-aggressive person still hasn't asked a question, and then it devolves into an antagonistic spat about what the person should or shouldn't have done instead of focusing on what the person's goddamn problem was.

This isn't really a pleasantries thing. It's not really small talk. I think that usually, these poor folks just don't know the norms of our group and think they need to get someone's attention first in order to get their question answered. But what happens after the unanswered hellos is the important thing here.

Some will open with the intro phrases, notice what's going on in the group, and then figure out how it works. Those people will usually realize they just need to ask their question and will do so.

But others, the "Fine, guess no one wants to help me" people, don't catch on. Mostly, it seems they don't catch on because they aren't paying attention to any of the existing discussion. They aren't interested in observing the group's flow of communication; they just want the attention to be turned toward them. Now. Because only when they have the spotlight can their Very Important Question be enunciated.

The moral of this part of the story is: Observe. When you enter any new group or location. You don't have to lurk for days, just a few minutes. Spend more time reading than speaking, and you're likely to find your interactions going a lot more smoothly. In the support context, you'll also get your problems solved more quickly.

This is actually another lesson to be learned from prototypical introversion. Being the loudest might get you what you want eventually, but there are other ways of going about it that don't alienate other people from you before you have the chance to ask the question we want to answer.

Ashes to Ashes

The prospect of the "death" of Phoenix Viewer has been vexing its ardent users for anywhere from the past week or so to two years (depending on when they first heard something about it). Our team first warned of Linden Lab's intentions to make the grid increasingly incompatible with traditional V1s in the fall of 2010 and then ramped up the volume a year later. Although LL's plans have taken much longer to develop than we expected, the end of Phoenix's viability on the grid is now concrete and fast approaching. 

Some Phoenix users see the Phoenix Firestorm team's decision not to keep the viewer up to date with the grid's impending changes as a betrayal of their loyalty or a murder of the client; they can't imagine using another viewer. I will attempt in this post, as straightforwardly as possible, to explain why it is actually neither one.

Viewer software for Second Life is open source, meaning that anyone who wants to and knows what they're doing can obtain the source code and try to improve on it, customize it, make it something closer to what they want it to be. As long as you stay within both legal parameters (a lot of the code and the supplementary software is subject to licensing terms) and Linden Lab's policies, the options are as broad as your imagination and coding abilities.

Sounds a lot like creating inworld content, right? Your world, your imagination, and your proficiency with Blender and Photoshop. Only with a lot less Blender and Photoshop and a lot more C++.

Where do developers get this code and do this fun stuff with it? Linden Lab and any Third Party Viewers on the Linden-approved TPV list keep their released code and most of their unreleased code in online spaces called repositories. It's available for anyone to view or download. Whether you can make sense of it or not is another story.

But the important thing is that some people can. And not all of them are on the Phoenix Firestorm Project. 

The important thing, in other words, is that the Phoenix Firestorm team has no ownership, no monopoly, no exclusive claim to the Phoenix code. It means that anyone with the desire and the know-how can dive right in and claim the continuation of Phoenix's development as their own ambitious project. Not just one person. Lots of people. Lots of Phoenix forks can come out of the Phoenix code.

They'd have to change the name, and if they wanted it on the TPV directory, they'd need to incorporate some original code, but there's zero reason why the Phoenix Firestorm team's decision to no longer be the ones developing Phoenix should mean the viewer dies.

All you need is the desire and the know-how, and YOU can be Phoenix's savior. YOU can be the one whom Phoenix fans adore for your passion to keep the viewer alive. YOU can do for Phoenix users what was once done for Emerald users back in 2010, pulling the "viewer from the ashes" from, well, the ashes. YOU can be -- fine, I'll just say it -- the Jessica Lyon of 2013.

But there's that one hangup: the fact that this task has two requirements, both desire and know-how. Which means there are Phoenatics saying, "I'd love to do that, but I don't know anything about coding!" and there are developers saying, "Well sure, I could do that… if I cared."

The trouble for Phoenatics is not solely that our team no longer wants to work on -- and, soon, won't be supporting -- Phoenix. The trouble is that there may be no one else with development background who wants to, either. There seems to be no overlap between those with desire and those with know-how. Why is that?

Let's crank out some theories.

Theory 1: Developers are technologically progressive, and most have moved on to V3 viewers.

This can work as a partial explanation but not a full one, since folks generally have lots of different reasons for their viewer choices. It does, however, thin the herd for potential candidates considerably. Although there are still coders, developers, and self-compilers who prefer Phoenix over Firestorm, they seem to be in the minority, and an ever-shrinking minority at that.

The most common reasons that people remain on Phoenix are less likely to apply to the people most equipped to keep it going.

• Developers are more likely to keep their systems up to date than most of us, so they are seldom the ones being held back on an old viewer because of their hardware.
• If there's something they hate about a viewer (like Firestorm), they are more likely to know how to change it themselves rather than avoid it completely or know the correct avenues (JIRA) for requesting the change.
• Many spend more use hours inworld, which means more of a chance to push themselves to get used to the V3 interface even if they can't improve on it themselves.
• If they experience poorer performance on V3s than on V1s, they're more likely to know what adjustments to make at their end to compensate.

There are certainly developers the above points don't apply to. I'm not gonna say they aren't out there. There are even devs on our team who still use Phoenix. But my general impression is that the vast pool of Phoenatics who would be passionate enough to fuel a revival simply does not include a lot of people who possess the expertise to do it, largely because most of the folks with expertise have already moved on.

Meanwhile, most of the V1-using developers around are already spoken for.

Theory 2: V1 developers are already hard at work on their own projects.

There are, in fact, two V1-based viewers under active development -- Singularity and CoolVL -- whose developers clearly challenge Theory 1. Are developers like Siana Gearz and Henri Beauchamp contenders to the savior-of-Phoenix throne? They could be if they wanted to be, knowledge-wise, but I have the feeling they're more ready to watch their own viewers' user numbers go up in the near future.

You see, what you may not know is that these viewers have had releases more recently than Phoenix and have thus advanced beyond Phoenix in some areas, such as multiple clothing layer support (the ability to wear more than one tattoo, alpha layer, or other clothing item on the same system layer -- not to be confused with multiple attachments, which Phoenix has had for two years). If existing V1s were to refashion themselves as Phoenix forks, they'd actually be moving backward. Phoenix hasn't been the most advanced V1 viewer in a long time. Anything these devs wanted to draw from Phoenix in terms of code content has been available to them for months.

In other words, the revival has long been in progress. Just not by our team. Or even by people who would associate themselves with the Phoenix name. But they're there for the V1 diehards, and I'm sure they'll be happy to see your downloads.

Those developers, in fact, have done most of the work that Phoenix pulled in during its final six months of development -- most notably, mesh rendering, built by Henri Beauchamp. Our devs did the work of merging it in, but the original coding was done by others. 

If Singularity and Cool aren't what you're looking for -- if nothing will do for you except an actual Phoenix resurrection -- then let's tabulate… now you need someone who not only has the desire to develop a V1 and the skill to develop a V1 but who isn't already busy with their own V1 project.

Theory 3: Keeping a V1 viewer compatible with a V3 world is difficult and time-consuming.

Well… it is. It's the entire reason for where we are now.

Theories 1 and 2 only explain part of the reason why no one so far has jumped in to pump new wind into Phoenix's sails. Number 3 takes care of the rest. It explains not only why our team doesn't want to do it but why we may find that no one else does, either. Or at least no one has been making a visible effort so far. The last major Phoenix release was a year ago this month, with a minor one in March 2012. Jessica Lyon warned that Phoenix 1.6.1 would be one of the last Phoenix releases 53 weeks ago. Those were 53 weeks during which someone could've gotten their butt in gear to be ready for the final end to development and support.

Didn't happen.

Of course, now that the cat is out of the bag about the team's decision to move away from Phoenix, we might see people stepping forward. If someone does end up coming to bat for Team Phoenix, then their first essential task is going to be preparing the viewer to be compatible with server-side baking. This is a fix for avatar bake issues (think clouds, ruths, blurry people, and unintended nudity) that Linden Lab will be rolling out some time in the New Year and that will considerably break the usability of any viewer that doesn't upgrade between now and then, Phoenix's included. There's no real disadvantage to using an unsupported viewer right now. But when that change comes, you'll be -- pardon my Esperanto -- up shit creek. Unless your favorite color is grey.

These hypothetical Phoenix-of-the-future devs will also probably want to work on pulling multi-layer support from the other V1 viewers to make Phoenix current. And if they're trying to get Phoenix's users before they migrate fully to another viewer, they might want to scramble some support resources together or prepare for a deluge of questions and requests for help.

It will be a significant amount of work and will take someone who has a true passion for Phoenix. If someone decides to do it, they can probably expect a moment of notoriety and a lot of grateful users at first, but that will fade as soon as those happy users start to take the viewer and its upkeep for granted. Eventually, there will be all the usual support and bug complaints, along with passive-aggressive reminiscences of how great the old Phoenix was (not because the new devs do anything wrong but for the same reason we still hear people fondly remembering Emerald and asking, "Why do none of these viewers run as well as that did?" and conveniently forgetting that its problems were not fewer but merely different), and whines about why it doesn't yet have that Awesome Feature X that all the V3s got weeks ago.

Goddess help them if they ever discover it's too much to handle, though. Take it from us… as hard as it is to jump into an endeavor like that, it's a lot harder to disengage from it.

Heard That One Before, Part 7: What the Mean Means

Welcome to the next installment of "Heard That One Before," the series in which you hear from the front lines of Phoenix Firestorm Viewer support on how not to make it more difficult to troubleshoot your issues. Today's topic got a little lengthy because there are nuances to it, and I wanted to be totally clear about what I do and don't mean by it. Hopefully, it's clear enough.

7) "I'm not a techie / Second Life professional / support person / dev and therefore can't understand a word you're saying / anything on your wiki."

As usual, there are different layers to this, so let me be specific. This is not about those who are aware that they don't know a lot about the viewer or their computer or SL. If by "I'm not a techie," you mean "I'm computer illiterate" or "I need more help understanding what's going on here," then don't worry, this is not about you.

It's about those who, if they don't understand something we tell them or that they read on the wiki, conclude that we're speaking too technically not just for them but for the "average person" and go on to tell us so in a way that suggests that we must be technological elitists who aren't interested in helping the "majority" of users.

In other words, the problem is not in whether the person knows something or not -- it's always ok not to know things -- but in where they attribute any criss-crossings of communication that occur when support is trying to help them.

If you need us to explain anything better, just ask. We work with such a wide range of people with so many different backgrounds that it takes a lot to make most of us judgmental about what you do or don't know. Ordinarily, all you really need to say is, "What does that mean?"

In this context, "What does that mean?" differs from "You're too technical for the average user" in a very important way: it's neutral. It doesn't imply that either of us ought to know more about what the other person knows than we could possibly be expected to.

It would probably surprise most people that I don't think of myself as a techie, either, and this is part of why the "You're too technical" comment is not only unproductive but sometimes startling. I know the viewer decently well, but if you want me to talk about computers, I'll be pleading the Fifth. Anything I know, I learned by lurking in the viewer group, eventually chiming in when I knew something (which, almost without exception, I had learned there in that group), and then picking up more on the "job." I entered support not knowing my operating system was out of date, never having performed a clean install, and terrified that I'd be expected to know things about Macs simply because I'm a Mac user. I wasn't invited to the team because I was a genius or an expert; I was invited because I was helpful and open to learning. There are a number of people on the team with similar beginnings.

Further, the more you know, the more you become aware of not knowing, so I really don't feel like I'm anywhere nearer to being "a techie" (whatever that means) than I was almost two years ago. The most valuable skill I've learned is not how to answer questions but how to ask them. Sometimes I'll be asking for help from others, and other times I'll be asking a user questions to figure out how best to help them. Either way, when you ask questions, you turn the helping process into a conversation where you can gain the information you need, and the helper learns how to explain it in a new way.

When you use the line, "This is too technical for the average user," a barrier comes up. Unlike "This is too technical for me," a comment that implies that the information is still accessible, the replacement of "me" with "average user" suggests the opposite: that it's closed off, that the user bears no responsibility for it and thus may not be interested in learning it. It's a subtle difference, but I've seen it make or break dozens of support sessions.

Who Speaks for the "Average" User?

This is really the question at the root of where the "You're too techie for the average user" issue comes from. Fortunately, most people have a pretty good sense of what they don't know and can admit to the gaps in their knowledge, and as a result they're good at asking questions or at least pinpointing what they don't understand. I love working with people like that because it means the issue might turn out to be a little one that just needed a better explanation.

The problem comes in when a user and a support person's perceptions of "average" don't mesh. So let's talk a bit about where these separate perceptions come from.

Our (support's) perceptions come primarily from past experience helping people, with specific explanations tweaked according to other factors, like what kind of an understanding a user has exhibited earlier in the conversation and how long they've been in SL.

When it comes to how we explain stuff, we get opposing complaints from both sides, as the very first post in this series should illustrate. We're about equally likely to get "You're talking over my head" as we are to get "You're talking down to me," and sometimes -- more often than should be logical -- we get both from the same person, in the exact same conversation. Both of these reactions are different sides of the same coin. They're defense mechanisms, the first against feeling dumb and the second against feeling like your intelligence is being insulted.

As a result, the way we explain something will be a result of weeks, months, or years of experience, of talking to users and eventually figuring out what explanation works for the greatest number of people: detailed enough that most people will understand it, but not so detailed that most people would be offended, with the recognition that there are always a few people who will still need more explanation.

We'll adjust that as needed, too. I have some regulars to whom I immediately give detailed explanations because I know they need that and others who need exactly the opposite. If I'm talking to a newbie, my answers are going to start out more precise than if I'm talking to someone with a 2004 rez date.

It could turn out that the holder of the eight-year-old account might have taken seven years off and now needs a newbie-level explanation. The person on the new account might be an experienced user on an alt. In either case, I'll adjust. I'll feel my way as I go. But in all cases, I'll be starting at a flexible middle point that I came to not by basing the "average user" on myself but by honing what kinds of explanations seem to work best with the widest range of users.

Am I wrong sometimes? Of course. But the point is that if I speak over your head, it's not for lack of doing my best not to. It's not because my explanation is "meant for" someone who knows a lot. If I fail to explain something you need explained, more likely than not it's because the majority of people I've spoken to previously were ok with the explanation I gave.

Here's where it gets tricky because there's no easy way to sugar-coat it. You might notice this means I'm suggesting that if you don't get what we (or the wiki) are saying, your level of understanding might be below average. Well… sometimes, yeah. Sorry, but yeah: on that particular subject.

This shouldn't make anyone feel defensive, though. Knowledge (including viewer, computer, and SL knowledge) isn't a greater than/less than quantity. It's pretty normal to know plenty about one subject and very little about another, so we expect to be asked for clarification sometimes.

But what if you don't feel unknowledgeable? What if you see yourself on par with the average user? In most ways you probably are. Those who are aware of the gaps in their knowledge on a particular topic won't be embarrassed by having to ask for clarification; it's only when a user thinks they're about average, but our experience with a range of users tells us otherwise, that this uncomfortable situation comes up.

What is "Too Technical"?

Here are some examples of subjects that I have been told are "too technical." To be clear, these are not all topics that the "average user" necessarily knows; in fact, the number of times I've been asked for clarification on some of them has taught me to present them differently or have an explanation at the ready. Others I've only been told are "too technical" once.

• The term "docking" (as in tabs docking into windows, or windows docking to other parts of the UI).
• The abbreviation "UI" ("user interface") and its meaning (the buttons, windows, and other graphical parts of the viewer but not the world).
• The abbreviation "OS" ("operating system"), as well as what it means (Windows, Mac, and Linux and their various flavors).
• How to find a skin or shape in one's inventory.
• Anything included in a wiki page.
• How to follow a path in the First Menu -> Next Menu -> Setting or Preferences -> Tab -> Subtab -> Setting format to locate a setting.
• A computer file path in the [USER NAME]/First Folder/Next Folder/Last Folder format.
• The use of the word "path."
• How to locate the number of items in one's inventory.

As I mentioned, the above list is not intended to imply that everything included is basic knowledge. Rather, the list is there to give a range of topics that do come up, some of which might make you say, "Yeah, that's kinda techie," and others of which probably make you go, "Seriously?" They're also not listed in any order of difficulty, and I won't be identifying which ones I'm asked for all the time and which ones I've only had to explain once to a non-newbie.

That variety is the point. You never quite know what people are going to think is "too technical," and if we err too far toward assuming people know nothing and need everything explained, then we risk irritating a lot more people than we're helping.

There are two sides to the solution, however. One half of it is for support and the other half is for users.

Our responsiblity is to keep mental note of what topics we're asked to explain over and over and over again and to adjust our approach to them if we have to. That process is continuous -- we've all been doing it since we joined the team, and we'll continue doing it while talking to you.

Users' responsibility is, if there's something you don't understand, all you have to do is ask. No attributions of techieheadness necessary. A simple "What does this mean?" will do.

The Wiki: Contestable Terrain

This applies to our wiki, too. Sometimes we'll direct a user in need to one of the wiki pages already set up for troubleshooting the particular problem they have, and they'll return after a few minutes to say, "I don't understand anything on that page; it's written for techies, not regular people." Well… the wiki doesn't have the easiest design to read when you're new to it, and sometimes it's frustrating to face a wall of text and not know where to begin (though the beginning is usually a good choice), but the instructions are meant to be straightforward.

Trouble is, although I can adjust my explanation for someone line-by-line in a real time conversation, the wiki is only changed if and when we know it needs to be.

This means that if it isn't as straightforward as we hope, then you can do us a load of good by telling us what should be straightforwardized better for you (and possibly for others). What this takes is specificity. "It's written for techies" isn't as helpful as, "When it says to go to a certain folder, I don't know what that string of words and slashes means." If you're unable to give us that specificity, then it probably won't get fixed.

In the end, let's make it about the information. About problems and solutions. If you don't understand a suggestion we make about a solution, let's focus on helping you to understand it. When there's a wrench in that system, we'll rely on you to help us just as much as we're helping you. Implications that we don't know how to speak on your level won't get us nearly as far as straightforward questions and pinpointing what you need explained.

The Phantomless Menace: Using the Firestorm AO to Replicate Phantom Mode

Up until recently, a number of Third Party Viewers have had a popular feature known as "Phantom mode" that allows the user to make his or her avatar immobile. Phantom mode was excellent for preventing one's avatar from being pushed by griefers or aimless noobs.

Unfortunately, when Linden Lab introduced their Pathfinding feature, Phantom mode was broken as collateral damage. Yes, the setting still shows up in your menus if you're on an older viewer, and yes, you won't be able to walk if you turn it on. But your avatar will be pushable. That part is gone, probably for good. Consequently, if you've upgraded your viewer since Pathfinding came out, you're probably using one that does not have Phantom mode as an option. Doesn't work anyway, so why leave it in?

So what other options do you have now?

• Option A: Just use a Force Ground Sit. In Firestorm, this is found in Avatar > Movement > Force Ground Sit, or Ctrl-Alt-S. As many of us learned as our first lesson in virtual self-protection, you can't be moved if you're sitting. And Force Ground Sit will sit you down anywhere at all, even hovering in the sky. 
• Option B: There are HUDs you can purchase that include a "movelock" feature that works similarly. No, I can't name a single one. I'm not a HUD person. Search the Marketplace if you're interested.

The drawback of Option A is that you'll be sitting down. There may be times when you'd rather be more subtle about what you're doing, and you probably don't want to sit in the middle of a club where everyone is standing or dancing. The drawback of Option B is having to use a HUD when it's really not necessary. Some people don't give that any thought, but I like to keep my screen and my attachment points free and clear, and I prefer to minimize worn scripts to only those for which there is no alternative.

So here is a nifty alternative that works well on Firestorm and any other TPVs that have incorporated the Firestorm client-side AO. It involves using the internal animation overrider to put your avatar in a ground sit while it appears to be standing. After it's set up, it's close enough that we can call it Fake Phantom. If you've already been using the Firestorm AO, then this will be very straightforward and you can mostly skim. If you're new to using the Firestorm AO, then read carefully and go one step at a time.

Replicating Phantom Mode in a Post-Phantom SL

1) Make sure you have at least one stand animation in your Inventory. You can copy one or more out of your animation overrider HUD if you need to (and if they are copiable). See "Extracting Animations" below for more info.

2) Open the client-side AO window. On all skins except the Vintage skin, do this by clicking the button marked "AO." On Firestorm's Vintage skin, click the Up arrow alongside the part that says "AO."

3) If all you see in the AO window when you open it is a dropdown, a couple of arrows, and a "Sit" box, then it's in its collapsed state. Click the Wrench icon to open it to full size.

4) Click the "+" icon in the full-size AO window and name the set you're about to create. "Standing Ground Sit" would be a logical option.

5) About a third of the way down the window, find a dropdown that most likely shows "Standing." Change that to "Sitting on Ground."

6) Drag one or more stand animations from your Inventory onto the open AO window. It will say "Reloading Config / Please Wait" while it processes. When it's done, you should see the animation(s) listed in the window.

7) To turn your new Fake Phantom mode on:

• Make sure it's selected in the upper dropdown in the AO window.
• If you have other AO sets loaded in addition to this one, click the checkmark icon to the right of the name. This tells the AO which set to use.
• Turn the AO on using the toolbar button. On all skins besides Vintage, click the box in the corner of the button so a checkmark appears in it. On Vintage skin, click the part that says "AO."
• Force a ground sit by going to Avatar > Movement > Force Ground Sit, or hit Ctrl-Alt-S.

8) Find yourself standing unmoveably in one spot. Don't forget to hit Stand before you try to go anywhere.

Additional Bits 'n' Pieces

• Extracting animations: Your AO HUD is just like a box. You can unpack the contents in the same way.
• If the animations are copiable, then you can wear the HUD, right-click it on your screen, and put it in Edit mode. Flip to the Content tab, find the animations you want to use, and left-click drag them from your AO into your Inventory. It doesn't much matter where they are in your Inventory for this particular use of the AO, but it doesn't hurt to create a folder for them so you can keep track of them.
• If they're not copiable, then you can't have them in more than one place at once. Either in the HUD or in your Inventory, but not both. You can, however, use the same animation in more than one set in the client-side AO. So instead of just unpacking the stands, you might as well unpack everything at once and create not just a faux-phantom set but a regular set as well. Take the HUD off if you're wearing it, rez it on the ground, right-click it, and choose "Open" and then "Copy to Inventory." Then go back to the above instructions to finish creating Fake Phantom.

• After you've created your Fake Phantom mode, you will have actually followed the same instructions you'd use for creating a full internal AO set using the Manual Method. To create that, as well, hit up our wiki page. Most of it will sound and look very famliar now.

• Instead of stands, you can use dances for entering Fake Phantom mode at a dance club. Just follow the above instructions, but instead of loading standing animations, load dance animations. They will allow you to appear to be dancing when you're technically ground sitting.

• If you've loaded more than one stand (or dance) animation as ground sits, you'll probably want them to cycle. In the AO window, make sure you have the ground sit set selected at the top and "Sitting on Ground" selected in the lower of the two dropdowns. Check the box marked "Cycle" and put your preferred cycle time in the space provided.

• You can always add or remove animations from this set. To add, simply drag the additional animations from your Inventory onto your AO window as you did when you first set it up. Just make sure you have both of the dropdowns in the window set properly. To remove animations, highlight them in the AO window and then click the lower of the two Trash icons.

• It doesn't matter what store you bought the animations from. It doesn't matter if they're copy or no copy once they're in your Inventory. This process works the same way regardless of those factors.

And that should do it! With just a little bit of prep work, you can get back that phantom functionality you're used to!