Categories

Meta

Author: atopal

Just a short while ago it was normal for people to have very few interactions with machines throughout the day. They used them at their jobs, and they were properly instructed. If the machine had its quirks, people knew how to work around them, they adapted to the machine, no problem. Fast forward to today and the world has changed. We are interacting with machines all day long, at home, when driving, parking, getting a snack, buying groceries. You are using a machine to read this text and depending on your definition of machine, you probably have more than a hundred of them working on the machine you are reading this text with. People adapting to machines was manageable when they operated one of them every day. Today that’s not an option anymore. That’s why User Experience Design as a field is rising in importance. It’s not just the invention, making something possible that wasn’t possible before, that gives you an edge in todays world. It’s also not aesthetics on its own. It’s how much people enjoy using your product, or alternatively: don’t have to think about it while using it.

Yesterday I watched a curious interaction at the grocery store. I was packing in my groceries when the women next in line was trying to pay for hers. So, she put her card into the card reader and was ready to type in her PIN when the cashier told her that the card reader wasn’t ready yet. So, they had to remove the card, reset the reader and try again. A few seconds later she puts in her card a second time and the same thing happens. This time she protests that the card reader said it was ready. And really, that’s what the card reader displayed verbatim, even the first time: “Card reader is ready”. However there is a catch: that message only displays that the reader itself is working, not that the connection to the cash register has been made and the customer can put in her card. Indeed you have to wait a few second until the card reader displays “put in your card”, before you are allowed to put in your card. At this point we have a frustrated customer who feels like an idiot, and a cashier who has resigned since it’s probably the hundredth time the same thing has happened that day.

If the above felt tedious to read imagine how bad the experience is for the people actually involved. The shame of the customer, with everyone else waiting in line, the frustration of the cashier because of the stupid card reader and stupid customers who make the same mistake day after day.

If the cashiers get a chance to switch to another product, they will jump on it. Not because other products are technically superior, do something novel or are more beautiful, but because of the User Experience. This is why bad UX will kill your product.

If the producers of that card reader had spent (or maybe did spend) 15 minutes watching their product being used in a real world environment they would have seen this issue. The question is however: Would they have blamed it on their UX or the customer behavior? Their product was technically doing everything right. Fixing the issue is easy, the difficult thing is to realize that there is an issue in the first place. That’s a paradigm change, paradigm changes kill products. Don’t let it be your product.

Over at Rands in Response Michael Lopp makes the case that after BBSes and forums in the 1990s there has been little innovation and newer tech, like blogs, Facebook and Twitter don’t lend themselves to discussion. I particularly like his “simple rules of communication among a digital population”: Add something to the conversation. Stay on topic. Don’t be a jerk.

But more on topic: there is a reason why blog posts and comments don’t create the discourse we are used from forums: In forums the initial post is just a spark and all subsequent posts are presented as equals. After a while there is little that sets the initial post apart from following posts.

It’s very different with blog posts. The blog post itself almost always dominates the whole discussion, comments are visually set apart and often set in smaller font sizes. Following up on previous comments is awkward, so most comments are focused on the initial blog post, which means the discussion doesn’t go anywhere.

With forums the discussion itself is the product, with blog posts the initial post is the product. That’s why we go back and update blog posts after a discussion, but we rarely do that with our initial post in a forum discussion.

It’s important to keep in mind that these different communication forms don’t just exist for the fun of it. They have prevailed exactly because they serve different purposes. If you really want a a discussion, a blog post maybe not be the best way to go about it. I’d say use the right tool for the right purpose, but unfortunately there has been little research into how communication forms work, and how people use them to solve communicative problems, so we’ll continue with trial and error. Discourse looks like a particularly interesting case of such a trial.

About 3 weeks ago we made the switch to a new information architecture and new design. The goal was to improve the browsability of the site and help people find the articles that they were looking for. 3 Weeks later we can now take a look at our key performance indicators to determine whether the whole project was worth the effort

Methodology

Since this project was primarily concerned with the KB, we can focus on the helpfulness rating in this channel. Also, we know from our exit surveys that about 80% of our visitors use the KB. The KB helpfulness rating is based on the survey that accompanies each article in each language. We ask the question “Was this article helpful?”, which can be answered with yes or no. Of course this metric is not perfect, articles that describe features have higher ratings than articles explaining how to fix a problem, English articles are generally higher rated than localized articles, despite having the same content, and the rating is also influenced by the path people took to get to the page. However, in this case we are not interested in the absolute ratings, we are particularly interested in the change since we moved to the new iA and design.

So, what happened?

We knew from previous tests that making the change would be beneficial for that segment of our users who would rather browse than search for their article. People rate an article down, when it’s not the one that they were looking for. We know as much from our article surveys, and assuming we did our homework we should help more people find the right article. That being the case we expected the helpfulness of articles to rise, but it was hard to tell by how much it would rise. Considering that we have over 500,000 visitors per day and 80% use the KB, even a change by one percentage point would help an additional 1.46 million visitors per year. Without further ado, here are the results:

The results are phenomenal, we raised the helpfulness by 10 percent on average. That’s an increase by 5 percentage points and means an additional 7.3 million visitors per year stating that they found a SUMO article helpful. This is across all languages and across all incoming channels. It means that in 7.3 million cases where people might have decided to drop Firefox or be miserable because they couldn’t get Firefox to do what they wanted, they will now leave SUMO satisfied with their browser.

It’s hard to overstate the significance of this, and we are extremely happy with the results. The improvements to the site were the result of month of hard work by many people on the SUMO team, from SUMOdev, our creative team, and UX designers. We knew we were able to offer our users a better service, and the work has finally paid off. Continually thinking about how to serve our users better is what’s driving this team, and we will take these results as motivation to work even harder on improving our services.

Today, I’m very proud of what this team made possible, and I’d like to extend my thanks to each and everyone involved in the process: You made these results possible!

Today we are going to make one of the biggest changes yet to SUMO, the Mozilla Support site, and this blog post is about what changes we are making. The changes will effect you the most as a user, but there are a number of changes for contributors as well.

First, a little history, what’s the SUMO team been up to this year?

For the last 9 month the SUMO team has been working on a new way to let users access our site content. Until recently the only way to reach most of our articles was by search, or by following links in articles. This is how wikis traditionally work. Of course that way of accessing content only works for a part of our visitors, some people want to search and some people want to browse to the solution, drilling down with ever finer topics to reduce the number of article that are related to the issue.

To come up with a new information architecture that would let people drill down like that, we first researched the mental model of our site users, how they think about issues and in what categories they would look for them. Based on that we created a small number of base categories and assigned our articles to those categories.

The next step was figuring out how to make this information architecture visible. We started to lay out a number of alternatives on paper and tested with real people in a lab. This paper prototyping gave us a way to test a number of ways to lay out the information very quickly. After a number of iterations we settled on the final designs and workflows.

Now we had everything to start adapting our site, but since this would be a big redesign, and we’d soon switch to the new unified One Mozilla design anyway, the decision was made to use this opportunity to rebuild the site based on the new theme, and that’s why the changes today not only affect the KB, but every part of our site.

So, what is changing? What does it look like?

The main change is, that we now support several products from one start page and all articles can be accessed by browsing. Let’s start with the start page:

We have the main topics on top, they allow you to start browsing by selecting your issue first, and then the product you have issue with.

One step below you can see the hot topics. Those are actually articles, things that came up recently and affect a large number of people. By providing them upfront we save a large number of people the hassle of searching or browsing for their solution.

Below that we have the product picker, this is a way to navigate our content by choosing the product first and then narrowing down the topics.

No matter what way you select, topic first or product first, you’ll end up narrowing down the number of articles to a scanable few and proceed to read one of the articles.

The important thing for localizers to note is: all of this is automated, there is no need anymore to create navigation pages and all the confusion that brought with it.

So, how did the article view change? On the surface not much has changed, but because we keep track of topics, we can now offer you a way to move to related topics, which is particularly interesting for people landing on articles from external searches:

Much, much more has changed, but this is the gist for the KB part of the site.

So, what has changed for forum contributors?

While the new iA did not touch the support forum per se, we took the redesign as an opportunity to improve a number of factors in the listing of questions for our contributors.

The new design is more friendly and clean, but at the same time gives more information about the thread content at the same time. This is especially helpful when contributors scan the thread listing page deciding which thread to pick next.

We already started rolling the design out to our contributor base over the last week and will start rolling it out to 1% of the general audience today. If everything goes to plan we’ll make it available to the general audience on Monday. If you want to try it out now, just register an account, and if you have any feedback, please use the comment section below.

The new information architecture will open up our content to a whole new group of users and make it much more accessible, while our new design is more coherent, taking into account all of the features we added since our first release while also being consistent with the Mozilla sites in general. All of this makes us very excited and hopeful that we’ll get that much closer to our number one goal: Happy users!

Phishing E-Mails have become a plague, particularly because phishers are getting better and better at copying the emails of banks and other prominent websites. The other day I got one, that did indeed almost fool me. But why go to all that trouble when there are millions of people out there who don’t care for authenticity? Why indeed thought the spammer, who today sent me this Email. I was kinda floored 😉

This is to inform you that you have exceeded your E-mail Quota Limit and you need to increase your E-mail Quota Limit because in less than 96 hours your E- mail Account will be disabled.Increase your E-mail Quota Limit and continue to use your Webmail Account.

To increase your E-mail Quota Limit to 2.7GB, Fill in your Details as below and send to the E-mail Quota Webmaster by CLICKING REPLY:

Verbatim is probably one of the least known and at the same time one of the biggest L10n tools at Mozilla. If you see localized text on one of the mozilla.org sites or Mozilla campaigns, chances are it was localized with Verbatim. Hundreds of localizers are registered for the various sites and languages that are managed by Verbatim.

Registration was always open at Verbatim, but to commit any localized text, you had to file a bug, print out the committers agreement, sign it and send it back by fax or traditional mail. That’s quite a barrier, if all you want is just to help localize a mozilla campaign. Some time ago we made that easier by allowing contributors to take a picture of the contributor agreement and email the signature. But still, the agreement had to be processed by someone at Mozilla and only after closing the bug we’d be able to assign you commit rights.

Last week we went one step further and removed the necessity for the contributor agreement altogether. Now we ask you to accept our license agreement upon registration, and locale leaders can request commit access for any registered user. This will reduce the overhead for contributors and Mozilla staff significantly, and it will hopefully lead to more contributions in 2012 and happier localizers overall. Of course we are not done yet, you can see our immediate plans for Verbatim on the Verbatim planning page. One of the next steps now is to allow the management of contributors by locale leaders instead of the Verbatim admins.

Another feature we added last week is acknowledgment of contributors on Verbatim. We now have a page linked from the Verbatim footer that shows each languages with its supported projects and the contributors to each project. The next step for this is to allow individual sites to credit their localizers directly on the sites. And hopefully we can crosslink the names to Mozillians sometime soon, to make it even easier for new contributors to get in touch with our established localizers.

Implementing bureaucratic overhead is usually rather simple, but reducing it is an order of magnitude harder. Especially as organizations grow and people change, it sometimes becomes unclear why a process was put in place and sometimes the process stays even as the world changes and the need for it goes away. That makes it all the more important for each and every one in an organization to constantly re-evaluate existing processes to simplify them and to eliminate the ones that are no longer needed.

In the case of Verbatim registrations several teams at Mozilla helped to lower the bureaucratic overhead needed to contribute as a localizer. I’d like to thank Seth Bindernagel who agreed to start the discussion about that with me, and Gerv, who drove the change to allow camera-pictures as contributor agreements last year; Chris Hofmann and the L10n team, who helped to drive the main discussion on Verbatim and localizer tools forward, the legal team for reviewing our processes and giving us the green light; Mike Morgan and Laura Thompson for assigning the necessary web developer resources to make those changes happen, Peter Bengtsson for the fantastic implementation and finally Stas Malolepszy for his continued support throughout the whole process.

Isn’t it funny? 20 years ago everyone thought the hardest thing about video calls was the technology (speed of connection), today it’s clear that there is something much more difficult to solve than tech problems: Greed.

If we had an international standard, you could so easily video call everyone in the world over IP, *every* camera-equipped phone, but no, reaching every phone in the world is reserved to a technology invented in 1876. Imagine going back to your younger self and explaining: “Yeah, actually video calling is not a technical problem anymore, but hardly anyone uses it. Why? Because greed keeps companies from working together.”

Last weeks FOSDEM was my 7th FOSDEM in a row and my first as part of the SUMO team. And since it’s my favorite tech conference, I wanted to share some of my experiences at Mozilla with my fellow FOSDEM visitors.

We have around 400 million Firefox users by now, that means that offering traditional support to them is completely impossible, especially since the support team has only 5 employees. But we still want happy users, and the only way that works is when users help other users. So, after evaluating the situation, we spent most of last year designing the best possible tools for our community. Because we are facing the same challenges most free software projects will face, I wanted to share our assessment and our solutions with the broader free software community, and since I needed a catchy title, it’s called “How to support 400 Million users with 4 employees.”

Instead of boring you with the slides, that don’t makes any sense on their own, I tried a little experiment. I recorded the whole presentation with my voice on it and exported it as a video. It’s a bit rough around the edges, but hopefully still useful. Let me know if you have any questions or comments.