Author Archives: Kensie

It was a very good year

I’ve very much enjoyed this past year and my role as the Live Chat community lead. It’s been a very cool experience helping establish a new project with a new team, especially one that so directly impacts users. We saw incredible turn out and some really great feedback when we launched last December. Since then we’ve made several changes to improve the process. The software that we’re using which was partially open source when we chose it has no been fully opened and now the possibilities for making the improvements we’ve wanted to are very exciting. We’ve also been through a release and a major update and it was really great working with other contributors to help so many people experience Firefox 3 properly.

I can’t wait to see what will happen with Live Chat in the coming year!

Working on Live Chat has also given me a chance to develop my skills and get a feel for what types of tasks I really love. I really love helping people and interacting with them. Being able to help someone do what they’re trying to do is always a great feeling. I think my favorite project though was organizing the June Support Firefox Day. All in all I think my favorite parts have all been the ones that involved working with other people to do some awesome things. Working with Jason, Chris and David has been a great experience.

While support is very dear to my heart, that’s been my major role in the Mozilla community to date. I have some opportunities to pursue projects that involve doing some other things that I love and hone some skills that I’ve had fewer chances to use in my current role. I’m definitely going to stay as involved with support as I can, but I’m also going to enjoy letting someone else take the leadership role with Live Chat and seeing what they can do with it.

Look for an announcement soon on who’s taking over!


Wo ist die Bibliothek?

If my IRC hostname hasn’t already tipped you off, I’m in Europe! This is my first trip beyond North America and it’s very exciting. One side of my family is Danish and everyone older than me has been to at least Denmark and Germany. I have to help that I was watching Enchanted on the plane, which happens to be a very good movie, btw).

With two kids, five cats, and a S.O. very focused on the release cycle I realized I needed a vacation to not only retain my sanity, but to actually get some of my own work done. The fact that I’m actually in Europe is happy serendipity borne from access to Aeroplan points and having a free place to stay complete with internet.

A very happy side effect of the time difference is that I can be around to help out all our European volunteers who have wanted to learn the Live Chat ropes but haven’t been able to make their hours fit with ours. If that describes you and you’d like to take advantage, please find me on irc.mozilla.org in #livechat or send me a message in Spark including the time that works out for you. I’ll be around this evening around 8pm CEST and will play it by ear from there.


Avoiding helper burnout

Any new project seems to take a very large time commitment from a small group of people to get it off the ground and Live Chat has been no different. We’ve had some unique challenges in that we’ve been in demand since we opened, rather than seeing our user base grow as we do. This has left us trying to grow our community of helpers as fast as possible while still trying to support as many users as possible. Finding a balance between making things comfortable for helpers while still being accessible to users has been an interesting process.

At first we focused very hard on the user, taking as many chats as possible, being open a wide range of hours so that everyone had a chance to get chat support. This worked when we first opened, when we were new, and everyone was home for the holidays with some time to lend a hand. As people went back to school, or realized real time support wasn’t for them, we were left with a handful of brave souls trying to help just as many users in just as many hours.

People stopped having fun.

This is obviously a problem. For a volunteer community to thrive, helping has to feel good. Not only that, but the quality of support the user receives declines incredibly when they’re being helped by someone who’s worried about developing a RSI. As counter-intuitive as it was at first, I realized we needed to improve the support we give our users by scaling back.

The first change we instituted was the change in hours. We focused less on trying to be accessible at different times, and focused on simply being accessible. Later shifts make it easier for students and people with day jobs to turn up. Shorter shifts make it easier for one or two people, like our room monitors, to stick around for the whole thing. It also makes it easier to remember when our official hours are as they are consistent rather than alternating based on the day.

A big change that’s made a world of difference though, has been playing around with the max number of chats any helper can have at once. At first we agreed to set it high so that people could decide for themselves how many chats they could handle. This proved to be overwhelming to new helpers. Even for veterans it was hard to ignore new chat requests and we ended up spreading ourselves too thin. We tried setting the limit to 5 chats as that would let us take most of the chats in queue, but even I found that impossible to keep up with. Finally, after a fair bit of argument that it’s better for the user if we take fewer chats at once and let some people wait a little longer in the queue, we’ve set the max to 4.

What a difference that one chat makes! Now, with only 2 or 3 helpers on a full shift is easy to do, and our wait times have hardly been affected (which are still 30 seconds or less, I might add. Quite ridiculous for a volunteer community so small, way to go guys!). It’s also easy to limit yourself to fewer chats. Currently the software counts a chat as open as long as the helper still has it open, so if you can only handle 2 at once, leave 2 finished chats open. People have stopped saying they’ll come on only if we really need them.

We’re having fun again.

Coming up we’re looking for a good way to sign up for shifts so our helpers can tell when they’re most needed and when they don’t have to feel guilty for having drinks with friends, or sleeping (*cough*Cww*cough*). Calendaring software seems like the right answer but actually has many drawbacks for our use. Ideally I can specify the shifts, as well as how many helpers and room monitors we want to have during that time, and then helpers can highlight chunks of time and sign up. It should all be web based, and hopefully free! If you know of something that sounds like it would work, please let me know!


Live Chat helper approvals – take 2

I posted earlier about our system for doing Live Chat approvals for new helpers. Unfortunately this fell apart for two reasons. First being, I’m the only one who can flip the switch on accounts. Second being, most new helpers were coming around after hours, which is great, that’s when we need more helpers, but that also meant I wasn’t around. We quickly realized this wasn’t going to work.

The ideal solution needed to take several things into account:

  1. New helpers shouldn’t be able to open help without a Room Monitor to supervise
  2. They need to be able to get to users without waiting for me to approve them
  3. They need to see the same UI as they would in a regular help chat

We stuck our heads together, and came up with what we think will be a working solution. So with many apologies to those who signed up and were never approved, here’s how it works now.

  1. Sign up for an account though the Spark client as always. Instead of being automatically added to the support group, or having to wait for approval, you’ll now be added to a “trainees” group.
  2. Join the Contributors conference. Let people know that you’re new and would like to be invited to help chats. You can also let us know in #livechat on irc.mozilla.org
  3. Watch for invitations to join help chats. When we’re open and taking requests, the trainees group will be invited to shadow these chats using the same alerts and UI that you’ll see when taking requests yourself.
  4. Help out a few requests to learn the ropes. Once you’ve followed and helped with enough chats to pick up how things work, the helpers you’ve been working with will let me know that you’re ready to help users on your own. I’ll add people to the support team when I’m around. This will usually be within 24 hours of being told you’re ready.

If you’ve already signed up for an account but were never approved, please let me know here, send me or someone else a message on Spark, or let someone know on IRC. I’ll make sure to take care of these accounts ASAP. Again, I apologize whole heartedly for the process fail. Please let us know if there are still issues with the new process.

If this is new to you and you’d like to help out, get started here.


Live Chat helper tools

In my last post I talked about the need for our volunteers share their knowledge with each other, and learn the ropes of providing user support. Since our medium is very much one to one and real time, it’s harder to learn from others than it is on a support forum, or even on IRC. We’ve put some tools in place that we hope will give new helpers a jump start on giving support, and help everyone stay on top of new answers and new ideas for being a better helper.

Bookmarks menu item in the Spark client

The first place to look for tools is the Bookmarks menu in the Spark client. These bookmarks are set on the server, so everyone always has the same links to important resources. I’ve included links to the other tools mentioned here, SUMO’s homepage, as well as to the Live Chat category of this blog. Let us know if we’re missing a link that you think should be included.

Live Chat introduction to Spark

We’ve put together an introduction to Spark’s interface. It covers all of the functions you’ll use when providing support via Live Chat.

Live Chat basic support handbook

Our basic support handbook details the basics of getting a user a good answer as fast as possible. It’s especially meant for new helpers who aren’t sure where to start, but it’s also good for experienced volunteers. Give it a read. Don’t feel compelled to stick to it if you think it doesn’t apply to the case you’re helping with, though some of the sections are “must follow” and that will be noted in them. Suggestions are always welcome, and this article will be updated when we hit common issues that need a guide.

Live Chat tips and tricks

As an experiment, I’ve set up a copy of the chirpy! quote database software. Submit any tips or tricks you have for giving users good support. Some things you might want to contribute are answers you couldn’t find on the knowledge base, shortcuts to diagnose a specific issue, or maybe even a good way to explain something that makes it easier for users to understand.

Make sure to read the latest submissions and vote up ones you find useful or insightful. Top submissions will be reviewed and added to our articles or other resources as appropriate. This is especially important for answers to new problems. This way we can share possible solutions for each other to test out before they could be added to a knowledge base article as a definitive answer.

Submissions aren’t expected to be in quote form, ignore that it’s a “quote” database. Depending on the tip you’re submitting, summarizing it in your own words is usually best, though it’s okay to just copy/paste how you said it in a chat with a user. All submissions are moderated, to make sure dangerous or incorrect suggestions aren’t promoted.

Have a good idea we’ve missed?

We’re constantly re-evaluating the best ways to support our helpers. Currently we’re looking for good free software to track who can help when, something that works more like a sign up sheet rather than a traditional calendar. If you know of anything please drop a link! Any other ideas that you think will help are also welcome.


How I got involved with user support

I don’t remember the exact details of how I first got involved with supporting Firefox. I know I started in #firefox (that’s an IRC channel, for those of you not familiar with the syntax) but I don’t remember if I’d just been hanging out in the channel, or if I’d actually had an issue myself that I got help with there. In either case, whether it started with a specific solution or not, I found myself able to answer some common questions that I’d seen answered before. That’s all it took.

When I answered the easy questions, it left the more experienced helpers – who were usually developers or extension authors pulling double duty to make sure users got support – free to take the harder questions or to spend more time working directly on projects. As myself and some other community members were around more often to help, some even took the opportunity to stop giving support regularly and quite wisely spent their time on tasks they were better suited for, like writing patches and creating new features.

The great thing about supporting Firefox is that if nothing else, either a new profile or a fresh install will solve the problem, or it’s caused by a third party app (there may be a few uncommon exceptions I’m forgetting here). A new install leaves all the user information intact, and settings can easily be moved between profiles. Eventually you start to get a feeling for which symptoms are going to be caused by a bad install and which are caused a broken profile simply by troubleshooting issues yourself. A while after that you’ll start to get a feel for which files specifically can cause which symptoms. So even though the old helpers were still around and available to help us if we got stuck, we were pretty well able to handle most issues and only ping them when we thought we’d found a bug that they’d want to check out.

For the most part, helping out on SUMO is going to be quite similar to my experience, users will learn from each other, and from reading the knowledge base, and some will even move on to contributing code and developing. However, Live Chat is one to one by nature. While users can always invite other helpers into a chat, or ask in the workgroup for help on issues they don’t know about, it’s harder for more experienced users to cut in if they know the answer to a problem. Because helpers aren’t watching each other help as much, it’s harder for them to get a head of the learning curve by learning from others’ experiences.

How to replicate this accelerated learning is going to be an interesting and very important problem for me to solve. I’ve already put some tools in place which I will blog about separately. This week I’m going to focus on monitoring chats and being around for helpers to ask me questions. I’ll take what I learn and figure out what areas our helpers could use the most help with, then work with our room monitors to figure out the best ways to give our helpers what they need. Of course we’ll constantly re-evaluate what we can do to help our helpers, and any suggestions are always welcome.


Live Chat helper approvals

For those of you not yet familiar with the new Live Chat software, we have it set that while everyone can sign up for an account to help, only people who have been approved can actually take questions from users. Last week we didn’t do any new approvals, and we apologize for the delay to those of you who have been signed up and waiting patiently. The software is new to us as well and we took the time to familiarize ourselves with the user control options that are available (and which ones aren’t). This helps give us an idea of how many approvals we can do at once, while still making sure we’re providing a quality service to our users.

We’ll be doing new approvals this week, starting today after the SUMO conference call, so that’s around 11am PST (GMT -8). We’ll only be doing a few at a time so that we can monitor new helpers, and guide them. If you have any questions you can find us either via the conference feature in the product, or drop by #sumo on irc.mozilla.org


5 o’clock world

I’ve finally sat down to process the emails I asked for in regards to times people can commit to help. With the responses I’ve received so far, we can extend our hours during weekday afternoons. However, I didn’t receive many emails committing to the later hours, though I know we have plenty of helpers on during the evenings.

If you haven’t already, please email majken at gmail dot com with the hours you are willing to commit to being around. If you’re available 12 hours of the day, that’s great, but unless you’re saying you will be on and helping 12 hours a day, that’s not what I’m after. Also, if the time you can be around is less than an hour at a time, don’t worry about mentioning it.

Again, you’re free to help whenever you feel like it, but this is for the purposes of making sure we have the coverage to advertise being open. Also, if your times change, don’t sweat it, just drop me another email.

As it stands I’ll be extending the hours to:

Monday, Wednesday, Friday: 9am – 3pm PST (GMT-8)
Tuesday, Thursday: 12pm – 4pm PST (GMT-8)

Please email me ASAP if you can help extend the hours further!


There is no try…

As many people who know me might already know, I’ve been leading the effort to bring real time text support to Firefox users. We’re live now, it’s going really well, and I’m doing some really cool things with some really cool people. I’ve been remiss about blogging things as they’ve been happening, though probably in large part to the fact that I haven’t done something like this before. I’ve found myself doing a lot of assessing in the moment, and then dealing with whatever that assessment meant should happen next. I think I’m ahead of that curve now, in no small part thanks to the community that sprouted up over night to help share the load!

It’s been really interesting for me, finding myself on the other side of contributing to Mozilla. While I understood how rapidly things move, and how busy it can keep you, I didn’t quite understand how much effort it really took to make sure other, less attention demanding, tasks got done. I’ve never been one to decide something shouldn’t be done just because it’s hard. In fact I’m a firm believer that some of the things most worth doing take a fair amount of thought and effort.

I was reading planet a few weeks ago and noticing how a few users and projects would simply put what they’d done in the week in simple bullet form. I found myself finding posts like these incredibly helpful and informative. In some cases, more helpful than the detailed posts about one particular task.

Again, now on the other side, I’m realizing how many people don’t know what I’m up to even though I think I’m mentioning everything I do somewhere where people can see. Of course, if I talk about it in IRC and someone isn’t there, they don’t know about it. Then figure that not everyone will see what I post on the newsgroups, or the bugs I file in bugzilla and I’ve realized that to keep people (including myself – especially myself?) informed of the tasks I’m working on and have completed I should really be blogging.

So, here’s my commitment to try and blog at least once a week what I’m doing, what I’ve accomplished, what I’m trying to accomplish and anything else interesting that comes up. Maybe I’ll even manage to blog about things that have already happened. I’ve even picked out a shiny new WordPress theme! Actually I’m going back and forth between two, I may or may not switch periodically.


Firefox 3beta1 Memory spike

The issue

There have been a number of reports of Firefox 3 beta 1 consuming high amounts of memory shortly after being run (anywhere from 1 to 10 minutes) and needing to be killed in the task manager, only to happen again next time.

The workaround


The bug has been filed
, and the culprit seems to be the safe browsing list. The first link contains the workaround, which is to simply leave Firefox alone for a while – seems to be 9 minutes according to the two people I’ve heard from – and it will go back to normal, and stay that way.

What’s going on

In a new profile, which is what we recommend you use when testing a beta, Firefox needs to download the safe browsing blacklist. This list is supposed to be downloaded in increments, not all at once. Something’s going wrong and triggering the list to be downloaded all at once. See the second link to follow along (the first link is a dupe of the second link, but contains the workaround).