Frequently Asked Support Questions of May 8

This week's most frequently asked support questions:

• Prims invisible until you {insert favorite workaround here}
• Lag (that is, if it's a lot worse for you on FS 4.4.0 than FS 4.3.1)
• Difficulty Clicking Continue on Terms of Service

Prims Invisible Until You…

…do the Hokey Pokey and turn yourself around or something. More effective, though, is to:

• Enter wireframe (Ctrl-Shift-R, with the Develop menu open; if you don't, Ctrl-Alt-Q will open that) and then hit the same keys to switch back. 
• Move your camera in and then pull it out, or vice versa (not as reliable but may be faster for some). 
• Right-click where the objects are supposed to be, but that could take a while if there's a lot of stuff.

Toggling in and out of wireframe can display
prims. Ctrl-Shift-R. Develop menu must be open.
(Mac users can use Cmd [shown above] or Ctrl.)

Whatever your workaround of choice, you have undoubtedly noticed an increase in how often you need to use it. The problem is the one where there are objects or pieces of them missing after you teleport.

However: it's not a problem that coincided with Firestorm 4.4.0. It has, in fact, been under discussion since "The main channel [got] the interest list project that was previously on Magnum" in the Deploys of April 1. It affects Linden Lab's viewer and all viewers based on it, including Firestorm.

Even though it was triggered by a server rollout, it's nonetheless regarded as a "viewer problem." Think of it like Dr. Linden Lab changing all our meds at the same time without giving us the chance to prepare for it, and we're all having a weird, freaky reaction. The problem isn't the pill, it's the unprepared body. Since we're talking about viewers and not human bodies, though, we'll need a viewer update from LL in order to get our viewer in sync with the server as well.

Andrew Linden addressed the progress of just such a viewer update at a user group on Tuesday (the transcript should eventually be posted on their wiki). Once the Linden code becomes public and available, the Firestorm devs will be able to pull it in. If Firestorm ends up on the cusp of another release before they make it that far, our devs have some alternative ideas in mind.

Despite the fact that it long preceded the Firestorm 4.4.0 release, we've nonetheless heard from people who associate the issue with our update. How to explain that? Jessica Lyon hit the nail on the head in her recent appearance on The Carter and Dar Show, pointing out that people tend to enter notice-new-stuff mode after they update their viewer. It's when you're most likely to be paying attention.

So the bottom line on this issue: We're all experiencing it, it's not just you. The next Firestorm release will have either the Linden fix or a homegrown workaround. Until then, I recommend getting comfy with your Ctrl-Shift-R.

Experiencing More Lag in 4.4.0 Than in 4.3.1

There are many kinds of lag. The kind this section refers to is frame rate (frames per second, or FPS). Hit Ctrl-Shift-1 to bring up the statistics bar or go to Advanced > Performance Tools > Statistics Bar. FPS will show up at the top. Higher FPS numbers correspond with better performance.

1. FastCache, new to 4.4.0, works better for some on and
better for others off. Try both ways.

Let me start by saying that we have actually received more positive comments about performance with this Firestorm release than any other I can remember. For the majority, this one has been providing improved speed in both frame rate and rez times.

Nonetheless, performance is highly individualized. Changes that improve conditions for some often end up affecting others negatively. So many factors go into performance -- many specific to your setup and various habits as a user -- that not all can be accounted for.

And so for this release, a smaller number of people have found a decline in performance, but some to a significant degree. For instance, some find that in locations where they used to see 20-30 FPS, they're now seeing 2-3, with no amount of graphics adjustment making a mark.

2. VBO improves performance for some and depletes
performance for others. Try this both ways, too.

Under normal circumstances, render quality (graphics) is the biggest and most predictable factor affecting performance. In Prefs > Graphics, the slider at the top has "Performance" at one end and "Quality" at the other. The lower the graphics quality, the faster your performance. The higher the quality, the slower your performance. It's that simple -- under normal circumstances.

But circumstances in Second Life are not always normal, and so for those times when there's something oddball going on, there are a few additional settings to look at.

Important: The results you find from the following settings are going to be specific to you. No specific option will be universally or predictably better for everyone, and your need may change from one version of the viewer to another. Experiment, experiment, experiment. And rather than telling friends what their settings "should be," recommend that they experiment, too.

3. HTTP is yet another setting that works differently
for different people. If you see no significant difference,
leave this on.

1. Fast Cache: Putting this first because it's brand new for Firestorm 4.4.0. Located in Advanced > Show Debug Settings, type or paste "FastCacheFetchEnabled," and try turning it to False. If there is no improvement, switch it back to True.
2. VBO: Located in Preferences > Graphics > Hardware Settings, "Enable OpenGL Vertex Buffer Objects." See whether you get better performance with it off or on.
3. HTTP: Located in Preferences > Graphics > Rendering, "Use HTTP Textures." Issues relating to HTTP got more complicated in the current release, though, so see our wiki page on HTTP Fetching Issues for more information beyond a simple experimental toggle. If there is no improvement with HTTP off, it is generally better to have it on.

Also try these in different combinations with each other. For more info on lag, we have informative wiki pages on general lag info and on troubleshooting lag.

Difficulty Clicking "Continue" on TOS

This hasn't been a particularly common issue, but it's timely.

The Second Life Terms of Service (TOS) got updated Tuesday. Every time there is a change to TOS, every resident needs to formally accept them (presumably after reading the new version) before being able to log in. A very small number of people inevitably have trouble doing so because the TOS loads in such a way that they cannot access the "Continue" button.

If this happens to you, just try using a different viewer to log in. TOS acceptance is per account, so you can do it on any viewer and then switch back to your preferred one. The problem is related to "webkit fail" and thus can theoretically take place on any viewer that uses webkit for web-related functions, i.e., any graphical viewer that is not based on the 1.23 code. Still, some will experience it on only one, and others will experience it on all of them, depending on why the webkit is failing.

And so you can try any other viewer you happen to have installed, but depending on the problem, your best bet might be the very old LL v1.23 (if you still have it) or Imprudence, which is still available for download. Or use a text-based client, such as Radegast.

More info on webkit fail and related topics can be found on our Media and Whitelisting wiki pages.

Other Problems? Where to Get More Help

Comments aren't open for this post. It's not because I don't want to hear from you but because I can't guarantee a response to requests for support here, and I don't want to leave the impression that such a response is likely. If you need help that isn't provided here, then please use the following means and those here:

• The wiki is a regularly updated resource with all known fixes to common problems.
• If you can't find what you need there, join our inworld group, open 24 hours with help from support team members when they're available and from your peers at all times.
• If your problems prevent you from logging in on any viewer, you can request support through the JIRA. Bug reports go to the JIRA, as well.

Fired Up,

Lette

Frequently Asked Support Questions: May 1

(a day late because we were testing a couple of the fixes included)

The three most common issues this week addressed by the Firestorm Support Team (aside from those addressed last week) have been:

• Inventory missing in Firestorm but not in other viewers
• Textures never coming in (possibly in combination with inventory, voice, and/or stream problems)
• Black rectangles in snapshots at some resolutions

Inventory

Inventory problems can have a couple of different causes. If you're only missing inventory in one viewer, then the problem relates to fetching or caching it. We haven't figured out why there has been an increase in complaints in Firestorm 4.4, so if we discover any additional information that points to new fixes to apply, we will share them.

1) In the meantime, start with the suggestions on our Missing Inventory wiki page. We've organized it step-by-step, with easier steps first and longer steps later. We strongly recommend going in order.

2) An additional fix we have just hit upon is that if you can load your inventory in the Second Life Viewer (Linden Lab's V3) and if you're comfortable working in your file system, you can copy your inventory cache file from the V3 cache into the Firestorm cache. This has worked successfully with several people so far. Here's how to do that:

Fig 1: Avatar key is in profile.
Location will vary.

• Start by finding your avatar key (UUID) while logged into Firestorm or another viewer that displays it (see Figure 1). It is a string of letters and numbers that appears in your legacy-style profile, though the exact location will vary because different skin options display it differently. If you use web profiles, you will need to switch into the legacy profile to find it (see Figure 2). You can return to the web profile style afterward if you want. When you find your key, just copy it down someplace.

  

  Fig 2: Your key will only show in legacy profiles.
  Make sure the "Use web profiles" option is unchecked.

• If you haven't yet, log into V3 and get your inventory loaded in that viewer. This might work with other viewers, as well, but V3 is the only one we've tested with. Once your inventory is loaded there, log out.
• Locate your Second Life cache folder and your Firestorm cache folder on your hard drive. Our clearing cache page will help you locate where that is (just replace "Firestorm" with "SecondLife" in the path name). Don't clear either cache! Just use the paths shown to find the folders.
• In the Second Life cache folder, find the file named with your avatar key and ending in "inv.gz" (see Figure 3). That is the inventory cache file for that specific account. Drop or copy this file into your Firestorm cache folder. Allow it to replace the one there.

  

  Fig 3: Look for the zipped file with
  your key, ending in "inv.gz."

• Log into Firestorm and check to see if your inventory is there.
• Avoid clearing cache or you may need to do this process again.

Please note: Under normal circumstances, you should not share cache between viewers because it can cause other weird problems. This suggestion should not be read as an indication that setting your cache in different viewers to the same place would be useful. It won't be.

3) We've had two reports of a Firestorm bridge recreation coinciding with an inventory loading issue suddenly getting fixed. There isn't actually any intuitive reason for that to work, but hey, it won't hurt to give it a shot. To find that, go to Avatar menu > Avatar Health > Recreate LSL Bridge (Figure 4). For more info on the bridge, we have a wiki page on the bridge and what it does.

Fig 4: How to recreate your bridge.

4) If the above suggestions don't help, then try a clean reinstall of the viewer. A few people with inventory problems this week have discovered that a clean install fixed the issue. Take note that a complete clean reinstall includes three fulls steps: uninstalling or deleting the previous Firestorm install (or installs, if you have more than one), manually deleting your settings (and not putting the files back in afterward), and manually deleting your cache.

5) Even though there may be a difference in inventory loading from one viewer to another, it does not rule out the possibility of a network/connection component, as well. Sometimes problems have a combo cause. If this problem persists, see the suggestions toward the bottom of the Missing Inventory page concerning your connection.

6) Also see the next section, especially if your inventory loss is happening in conjunction with…

Textures Not Rezzing

In preparation for Server-Side Appearance (formerly Server-Side Baking), there have been some changes at both viewer and server ends concerning the use of the HTTP texture fetching process. It's out of scope of this post to explain what that is in detail, so I'll be focusing on fixes to the problems that appear to be related to these changes.

The problems may include:

• Textures remaining grey
• Textures getting stuck in a blur-rez-blur-rez cycle
• Inventory problems
• Mesh not rezzing
• Voice, stream, or media trouble

These all have multiple possible causes, so you can find additional suggestions at our inventory, mesh, voice, and media pages.

If you're seeing them in combination with texture failure, though, or texture failure alone, then please see our HTTP Fetching Issues page. It will give you things to try and some explanation of the causes. One possible cause you're not going to be happy to hear about? Your router. See the wiki page for more info.

Very important: One of the best ways for us -- and for Linden Lab -- to figure out how to fix things so that you don't have to jump through debug hoops is to provide us viewer logs so that developers can get a better idea of where the failure is happening. We're collecting logs at FIRE-10020 for that purpose. If you're experiencing this issue, we would love to have your logs. We have a wiki page that explains how to find and attach viewer logs to our JIRA.

Black Rectangles in Snapshots

Photographers are familiar with the long-running issue where high-resolution snapshots come out with a "tiling" effect, with subtle lines crossing through the finished image. The good news is, we received a fix for that from Linden Lab and included it in the latest Firestorm release. The bad news is, the fix has a side effect that some people consider worse than the original problem: it sometimes creates black rectangles along the edge of the image in the saved version of the picture.

The bug report for this issue is at FIRE-9097. This report correlates with reports on the Linden JIRA (which, unfortunately, are not publicly visible): BUG-1094 and MAINT-2150.

The Firestorm team doesn't have any developers at present who work on the sort of code that could fix all this high resolution snapshot wonkiness once and for all, so we need to continue waiting for Linden Lab or other outside developers to address it. If you're about to say, "Well, why don't you get one?" then, uh… if you know any, send them our way and we just might! If only it were as easy as plucking one off the Developer Tree!

At best, our developers might be able to provide an option between the old and new behavior. That means you get to choose which bug you prefer to Photoshop around. Not the ideal solution, and they're not sure they'll be able to implement it at all yet, but if they can, it might do until a bug-free snapshot experience comes our way.

In the meantime, there are a couple of known workarounds, though the shortcomings will be obvious to photographers:

• Sticking with the standard resolution sizes, rather than setting a custom one, will allow you to avoid the issue.
• The problem only occurs when Advanced Lighting Model (formerly known as Lighting & Shadows) is on. In other words, you get a tradeoff between using high resolution or using shadows, depth of field, etc.

If you discover any workarounds that will be more appealing, please post them as a comment on the JIRA.

Since we'll most likely need a fix from Linden Lab for this, feel free to file reports on their JIRA under the BUG heading. Just make sure to log into and test the problem on the Linden Lab viewer first and to include the system info from their viewer, not ours. Just as we can't work with problems that aren't reproducible on Firestorm, they can't work with problems if you haven't checked for them on their viewer.

Further Help and Why No Comments?

I hope this blog post contained useful information. Last week I made the mistake of leaving comments open and unmoderated. You'll notice that's not the case this week. It's not because I don't want to hear from you but because I can't guarantee a response to requests for support here, and I don't want to leave the impression that such a response is likely. If you need help that isn't provided here, then please use the following means:

• The wiki is a regularly updated resource with all known fixes to common problems.
• If you can't find what you need there, join our inworld group, open 24 hours with help from support team members when they're available and from your peers at all times.
• If your problems prevent you from logging in on any viewer, you can request support through the JIRA. Bug reports go to the JIRA, as well.
• A one-stop list of all the ways you can get help from our support team is right here.

Frequently Asked Support Questions: April 23

Added April 25:
Please note that we are not actively monitoring the comments section to reply to requests for support. If you need help or have questions with the viewer, the following links will provide you more effective ways of accessing support that are already available:

• http://wiki.phoenixviewer.com/getting_help
• http://www.firestormviewer.org/support

In case you didn't catch it, Firestorm v4.4.0.33720 was released yesterday, April 22, at around 3:30pm SL time. Naturally, we've been busy bees in the Firestorm Support group since then.

No matter how well a release is tested before it's sent out, it won't be perfect for everyone. It can be perfect for most people and still create problems for others. Sometimes the problem is a bug, other times it's a settings change. We've got a couple of both in our FAQ for the past 24 hours.

Black Screen

Some users are experiencing a totally black screen on login. User interface, tags, and hovertips are visible, but the rest is a sea of black. This problem has so far shown up only on machines with ATI graphics cards and older graphics drivers, both Windows and Mac. Fortunately, we have a few workarounds you can use. All this info is also available on our wiki.

• The workaround that will probably be preferable to most people will be to disable Glow. Find this in Preferences > Graphics > Rendering. Just uncheck that sucker. Glow is an object property, so this will prevent some things from, well, glowing in your view. It's not the same as a light source, so don't worry, you'll still see lamps and torches and facelights.
• If you want to use Glow, and you have Advanced Lighting Model on (this used to be called Lighting & Shadows), you can also disable our new Vignette option in Phototools. How to find it. What you're missing if you disable it. This option may not work if you don't have Advanced Lighting Model enabled.
• Finally, most people will probably not want to choose this one, but it's available to you if you do: disabling Basic Shaders. This is in Prefs > Graphics > General. It'll be on the left.

Uncheck "Render glow" as a workaround to the black screen problem.

For a more permanent fix: The issue is driver-related, so installing the right graphics driver should do the trick. For Windows, we know the Catalyst 12.01 works. For Mac, it means upgrading your operating system to Mountain Lion (Lion works fine, but it isn't available from Apple anymore).

Height Offset

We anticipated that this would create a problem. In earlier versions of the viewer, we had a Height Offset option built right into our Quick Preferences. This would let you move your avatar up or down, wherever you happened to be. Feet in the floor? No problem! Hovering above your chair? No problem!

"Hover" replaces height offset

Sadly, the changes that Linden Lab are making for Server-Side Appearance (that server update that will improve avatar texture baking) are incompatible with the way Height Offset has worked up to now. Despite the fact that they never had anything equivalent in their own viewer, they've responded to our dismay at losing a popular feature by doing what they can to provide a replacement that will work with the new baking system.

The replacement to Height Offset is located in the Appearance window and is tied into your shape's parameters. Consequently, it can only be used if your shape is modifiable. Also, it can't be added back into Quick Prefs. See here for how to use it.

Dunno about you, but I give LL props for that effort. The new version may still have a couple of shortcomings compared to the old one -- perhaps with time the kinks will get worked out -- but it should be sufficient for most people.

Hidden Buttons

There are a couple of complaints/questions that we've been receiving en masse that relate to intended changes. This version of the viewer introduced the option to hide or show some user interface elements that had previously been visible but that not everyone wanted to see for one reason or another.

Specifically, this applied to chiclets (the square mini-icons that line up in the corner of your screen when you have IMs open) and media controls in the top bar.

The point of confusion is that these items are hidden by default if you log in with Phoenix Mode. This mode is intended to resemble Phoenix, so since Phoenix didn't have this stuff (the Vintage skin has the media controls at the bottom), neither does Phoenix Mode. They can be added back if you want them there. We're all about options whenever feasible.

So if you want those things back, they are both located in Preferences > User Interface > General:

• "Show media controls in top menu" is on the 7th checkbox line down from the top, to the right of "Show lag meter."
• "Hide group and IM chat chiclets" is the 2nd checkbox from the bottom.

Hide or show media controls and/or chiclets

Similarly, if you're on a different mode and you want to get rid of chiclets, you can find that option to hide them. It removes the IM and script dialog chiclets. The ones that remain there are the chat bubble that shows unread messages and the envelope that stores open notifications. Those are not removable at this time.

And there ya go. Help is also always available on our wiki and in our inworld support groups. We think our free in-person classes are pretty nifty, as well. We have many ways to get help!

Fired Up,

Lette

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.