How to grow communities is a hot topic these days. Francesco Lodolo recently blogged about how the Mozilla Italia community mainly consists of veterans who have been participants for several years, and how hard it is for them to find new contributors.

Illustration: Grow by Amy.Ng

Abdulkadir Topal from the German community also blogged about getting help for localization work on the European Mozilla Community Blog and reached an interesting conclusion about how to turn new and casual contributors into long-time community members: the key is to distribute ownership.

Kadir uses Thomas from the German localization team as a good example of this theory: Thomas is a relatively new community member (”only” two years worth of contributions so far!), yet he is one of the most active members on SUMO today. The key factor for why this happened, according to Kadir, is that Thomas was given full responsibility for the SUMO component within the German localization team.

As Kadir concludes, it’s “one thing to contribute little bits and pieces to a [project], but it’s a completely different thing to own it.”

I find this theory interesting. Maybe it is not a universal law that can be applied to everyone or every type of project/responsibility, but looking back at my initial involvement with Mozilla, ownership was definitely part of what motivated me — but not all of it, as I will explain below.

Kadir mentions in his blog post that it was something as trivial as a product logo that made me discover the Mozilla project in the first place. To me, the little Gecko logo — featured in an article about the planned Netscape 6 browser based on the previously open-sourced Netscape 4.x codebase — communicated “lean and mean,” and the article went on explaining how this new Gecko HTML rendering engine would be modern, compatible, portable, and small enough to be used even in future handsets (and guess what; about nine years later it turns out that they were right!).

Just a few days later, I learned that Netscape 6.x was just a branded and slightly outdated version of something called “Mozilla,” which apparently was the open source project behind the well known Netscape browser. I immediately switched to Mozilla instead, since it was more bleeding edge and therefore more fun for a geek like me.

That’s how it started for me. However, that wasn’t the reason why I sticked. Why did I turn from just interested in Mozilla to a deeply involved contributor? I will try to explain this and get back to Kadir’s theory, but I can say right now that there is a lot more than one reason why I’m still an active Mozilla community member.

It started around year 2000 with the realization that I could actually affect the project by submitting bug reports and providing feedback. Although open source as a concept wasn’t new to me, I had never actually gotten involved myself before. This, combined with the fact that I got to know other people with similar interests, made reading the newsgroup daily a pleasure.

However, I always felt that the original Mozilla suite represented something from the past, and that the way of the future was something lean and mean (yes, that Gecko logo that got originally got my attention!). The word “monolithic” was often used to describe the Mozilla suite, and even the word itself felt big, old and unmanageable to me. When the Phoenix project was announced on MozillaZine, I immediately turned my focus to that instead, and never looked back.

Because the project was still small and new, it was also a good opportunity to get more deeply involved because the signal to noise ratio was higher. Many people in the Mozilla community were still skeptical about Phoenix and preferred the tried and true Mozilla suite. This made the feedback I provided to the Phoenix project much more visible than it had been for the suite, making it a lot more rewarding for me to contribute.

As the project started to shape up with the release of Phoenix 0.3, I found myself heavily involved with things like filing bugs and RFEs, discussing feature implementations with developers, and, most often, answering questions from the growing number of users of Phoenix. As this consumed more and more of my time, I realized that there wasn’t a centralized place for people to get help with Phoenix. I viewed this as my opportunity to finally give something meaningful back to the project, and spent a couple of afternoons creating a small site called Phoenix Help. It was also a more meaningful way to develop my HTML/CSS coding skills compared to creating a website for, say, a Brood War clan (let’s call it UU).

Phoenix Help was very small and seemingly insignificant, but it was quickly noticed and appreciated by fellow community members in the MozillaZine forums. I especially remember getting my first personal e-mail from Asa Dotzler thanking me for doing what I did and encouraging me to continue the great work. This meant a lot for my motivation, because it was a confirmation that what I was doing was appreciated.

Before I knew it, people were linking to my site from all sorts of places (starting with Phoenix 0.5, even the release notes linked to it!), which made it even more important for me to ensure that the site looked good, was easy to use, and that the content was up to date. I was, in fact, responsible for the support site of Phoenix — I “owned” that part of the Phoenix project!

To wrap up, there were several things that motivated me to stay active in the Mozilla community:

• A belief in the mission of the project — to create a web browser that supports and promotes the use of open standards
• An interest in the technology — initially with the Gecko logo as my hook
• The feeling of belonging in a community of people with similar interests
• The desire to give something back to a project that gave (and still gives) me the best browser in the world for free
• The experiences gained by managing a website — HTML, CSS, server configurations, and perhaps most importantly, the English language
• The recognition and respect from Mozilla project members for my contributions
• The pride of being responsible for an important piece of the project

When I look at this list, I realize that it’s impossible to point to one particular motivator for community members, and that everyone probably has their own unique list. More personally, I also note that my motivation model today is the exact same as it was when I got involved seven years ago.

Despite the fact that the list is based on my personal experience, I think that all of the motivators could be taken into consideration for anyone trying to build or grow a community. Depending on the project, some things might be more important than others, but they all affect your community:

Tree Climbing Cat by mokwai

• Does your project add value to people using it? Do people feel like they are making a difference by contributing?
• Is your technology cutting-edge? Is it solving a unique problem? Is your project making people feel “wow, I want to be part of that!” or “I’d love to learn more about that”?
• Is your existing community friendly, welcoming and collaborative? Are tasks and discussions communicated in the open? Do people in your community have fun together?
• What kinds of contributions are welcomed? Does your project offer different ways to get involved?
• What’s in it for the contributors? Aside from the positive feeling of making a difference, do they gain relevant experiences by contributing to your project?
• Do you reach out personally to community members and make them know that their contributions are appreciated? Do you have automated systems in place to show the impact contributors make (e.g. a karma system)?
• Is your project modularized enough to allow people to take ownership of parts of the project?

There you have it — my first attempt to unwrap the mystery of building and growing communities. Is this helpful? Do you have similar experiences? I would love to hear what you think!

Today is a special day. Some people will remember it as the day when Firefox 3.5 was released. I call it the day the web was upgraded. Stay tuned for announcements on mozilla.com soon!

How can the search engine on lenovo.com not be aware of its new Thinkpad — the T400s?

Remember back in 1984, when people were using Word to compose their e-mail messages that were sent around to colleagues and friends? We’ll chances are people will keep doing that in 2014 as well.

We’ve made the decision to continue to use Word for creating e-mail messages because we believe it’s the best e-mail authoring experience around, with rich tools that our Word customers have enjoyed for over 25 years. Our customers enjoy using a familiar and powerful tool for creating e-mail, just as they do for creating documents.

The Power of Word in Outlook

How do you want your e-mail experience to look like in the next five years? If you think Microsoft is on the right track, take no action. If you think they should switch to modern standards, send a tweet asking Microsoft to improve standards support and make sure you include fixoutlook.org in your tweet.

Or just switch to a better e-mail program.

The stone has arrived!, originally uploaded by David Tenser.

The huge project to create a beautiful garden is reaching its final stages. Early this morning, the stone tiles arrived. I’m in for a weekend with lots of non-Mozilla work…

My blog post a couple of days ago about DI.se’s poor website UX was really just one example of websites that make use of “modern” features while failing to actually make them useful. expressen.se is another example, but for other reasons.

Similar to DI.se, they have a toolbar section for each article with functions like changing the text size, printing the article, and even fancy things like sharing the article on Facebook. The problem is that they choose to have this toolbar at the bottom of the article, not at the top! Granted, some of these functions are likely very rarely used, and only meaningful once you have actually read the article (such as sending an article link through e-mail), but changing the text size is something you will want to do before you start to read the article, not after!

Their stupid design means that in order to increase the text size of an article, you have to follow this procedure:

1. Click on the article link you want to read.
2. Scroll down to the end of the article (usually somewhere in the middle of the page due to the typical display of the main site content after the article.
3. Click on the a a a toolbar buttons to select your desired text size.
4. Scroll back up to the start of the article and start reading.

To make things even worse, expressen.se, just like DI.se, doesn’t remember the text size chosen, so you have to repeat this procedure for every article you read.

Why are these things so hard for website designers to get right? Remembering the text size is as simple as storing and reading a website cookie. Even I managed to do it on the ancient Phoenix Help website back in 2002, so why are so many modern news sites still struggling with it?

It’s Midsummer Eve in Sweden and I finally got some time to reflect on the fantastic weekend I had in Geneva together with other members of the Mozilla community. I was there to lead a discussion about SUMO and community support, with a focus on sharing experiences between the five local communities represented: Denmark, France, Germany, Italy, and Spain.

The discussion started with Mozilla Italia sharing their experiences with community support, where they explained why they recently decided to switch entirely to SUMO. It was really insightful to hear their main reasons for using SUMO today. Among other things, they said that:

• Outdated content is worse than lack of content
• If your documentation isn’t easy to find or badly structured, there’s no point in having it
• Good documentation requires consistency, quality, and precision

This is absolutely true and we are constantly working on those three points on SUMO, so I was glad to see that these values were shared with Mozilla Italia. I was very impressed that they took the time and energy to share these experiences with the other communities, who are all handling community support in different ways.

After the presentation, the floor was open for questions and discussions, after which Simone, Francesco and Giuliano passed on the torch to me to hold a discussion/presentation combo about SUMO in general. Among other things, I showed the many new features in SUMO — both implemented and still in the works. In total, the SUMO discussions went on for over an hour, and many interesting ideas came out of it.

For example, we were discussing the best way to indicate in the search results that some of the content is only available in English. Should these English results be mixed together with the localized content, or should it be separated? Should we add labels specifying the language of the article? Should the behavior differ depending on locale? For example, in Germany, mixing English and German content isn’t as common as mixing Swedish and English content is in Sweden. Kadir pointed out that in Germany, the existence of English content on a German website can even lead to mistrust of the quality of the website.

After almost nine hours of discussions and presentations, it was time for us to explore Geneva and have dinner. I have to say that I fell in love with Geneva. It wasn’t just the nice weather or the beautiful buildings — there was something with the atmosphere that made walking around in the old town at night taking photos together with fellow Mozillians really, really enjoyable. I think everyone felt extra proud of being part of the Mozilla community that night.

In retrospect, I think that this inter-community meetup was one of the most successful Mozilla events I’ve attended to so far. The focus was on exchanging experiences and discussing, rather than passively watching other people’s presentations. It really worked very well to have a smaller group of people, as that made discussing various topics much easier. Also, William’s “no laptop rule” helped everyone stay focused on the purpose of the day rather than escaping into the wonderful world of bug filing, blogging, tweeting, and coding.

A huge thanks has to go to William for ensuring that the day was a true success. Big thumbs up from me, William! I would also like to thank Simone Lando, Giuliano Masseroni, and Francesco Lodolo from Mozilla Italia, for so openly sharing their experiences, pros, and cons about SUMO. It was incredibly helpful!

As I mentioned previously, user experience (UX) design is one of my specific computer interests, and as the project lead for Mozilla’s Firefox support website, I obviously care a lot about website UX in particular.

One thing that keeps annoying me is how many websites are designed to make use of some “modern” features of the web like Javascript to enhance the visitors experience while still failing utterly in the common sense department.

DI.se, a Swedish financial website, is a good illustration of this. As with many other news websites today, they have a small toolbar strip at the start of each article with buttons for things like increasing the text size (something which can be really useful since most web designs tend to think that small fonts are more pretty than big fonts, and the average physical screen size of new laptops is only getting smaller).

DI.se’s article toolbar. Looks can be deceiving.

Now, the thing that makes DI.se worth pointing out as an example of particularly poor UX design is their decision to make the toolbar about as hard to hit as a housefly.

When you hover the mouse pointer over a toolbar button, the whole toolbar suddenly changes from the button-only, horizontal layout to a vertical one with text labels. This makes all toolbar buttons change place, and your first attempt to click on a button is surely going to be a miss.

When designers make decisions like this, I wonder if they really took the time to weigh the benefits against the drawbacks, or if they just didn’t have time to think in the first place. There are of course many simple changes that could be applied to improve this. For example, they could have made the toolbar wider and show the text labels at all times. Or, they could have kept the horizontal, button-only layout and just show the label of the button being hovered over using the same CSS/Javascript technique they’re using today, without changing the location of the button.

Of course, I took the time to point this out to the DI.se webmaster over a year ago, but as with so many other popular websites, the webmaster didn’t respond, and, as is obvious by visiting their website today, didn’t think the problem was important enough to fix.

Maybe it isn’t a huge problem, but it is certainly annoying; especially since the website doesn’t even remember the text size you choose, so you have to redo the procedure every time you read an article!

Part of Mozilla’s Manifesto:

The Internet is a global public resource that must remain open and accessible.

Part of Microsoft’s “Ten Grand Is Buried Here” campaign (emphasis added):

If you’re the first to locate the buried ten grand, you keep it.

How will you know if you’ve found it? It’s a cleverly concealed webpage that only Internet Explorer 8 can view. When you find it, it’ll be obvious that the $10,000 is yours.

Microsoft is still dreaming of that world of the past where the Internet was controlled by one company and accessible only from one platform, owned by that same company. Sorry, Microsoft, but I’d rather be without your ten grands and have an open web.

(Thanks to Patrick for pointing this out.)

Tomorrow I’ll be traveling to Geneva for the first EU Inter-Community Meetup, arranged by no other than the hard-to-resist William Quiviger. I’m really looking forward to this event, which will focus on bringing together active communities from across Europe in the same city for a day of presentations, discussions and workshops. Also, I’ve never been in Geneva before (but I’m actually not sure if I’ve been in Switzerland… I have a vague memory of sitting in the back seat with my brother Manuel on the way to Spain, hearing our parents say “now we’re driving through Switzerland!” …but it could might as well have been Luxembourg, which seems like a more sensible route from Sweden to Spain)!

The communities attending are:

• Mozilla Danmark (MozDK) represented by Hansen, Henrik Gemal and Jesper Kristensen
• Mozilla France (MozFR) represented by Cedric Corazza, Goofy and Omnisilver
• Mozilla Germany represented by Kadir Topal, Thomas Schwecherl and Michael Köhler
• Mozilla Hispano represented by Nukeador, Francisco Picolini and Willyaranda
• Mozilla Italia represented by Giuliano “jooliaan” Masseroni, Francesco “flod” Lodolo and Simone “Underpass” Lando

I’ll be leading a discussion about SUMO and community support in order to figure out how support is handled today, how these local support communities look like and differ from each other, and if and how SUMO is part of their solution.

My hope is that this meetup will allow us to learn from each other and improve our communication and collaboration. I’m sure we’ll also have time to discuss specifics in SUMO itself — for example, maybe there are things in SUMO that could be improved to make support easier?

Of course, I’m also looking forward to meeting many of the fellow European Mozillians again and have a good time together.

Postcard from Luxembourg by snaiwedu.