aakashd

I’ve been asked by a number of people about why the submission pages were formulated. Instead of tackling the entire process in one blogpost, I’ve broken it up into two parts. The first is how the requirements were gathered in the perspective of if the submission methods are currently being constructed. Here goes!

Figure out the history of the problem at hand.

You see, Mozilla’s primary general feedback mechanism has been Hendrix since 2005. This was a simple webform that allowed users to post to a product-related newsgroup with their thoughts without any restrictions or direction on how to formulate those thoughts into something usable for Mozilla. It was initially designed to funnel users away from filing non-actionable bugs in Bugzilla. It fulfilled its intention at the time, but proved to not be as useful over time as most comments were just rants. Rants aren’t actionable; rants take too long to read; there’s too much emotion tied to them. So, I got my first set of requirements: feedback submission should be directed, concise and something that alluded to the past, but felt different.

Ok, so what about the various needs within Mozilla right now?

Namely, everyone knew or felt there was a need for a feedback application. There just wasn’t an understanding of what that meant to each group within Mozilla. So, after some requirements gathering, this is what I got.

Product Drivers

• Fennec: help users and make our products better (feature requests, bug reports, undiscoverable features)
• Release Management: For betas, we want different type of feedback vs normal releases. Generally, we care if a problem happened in the previously released update. That is, regressions are most important.
• Firefox: a better way (than bugzilla, hendrix and even reporter) for all users to express a problem; a way for us to communicate to beta users what specific things we’re looking for feedback on; and better tools for them to provide it; a way for us to pivot and search through that feedback in a more structured way based on OS, arch, etc; a way for us to get performance metrics and system configuration data from the field

Evangelism

• Find issues, find broken websites

Marketing

• behavior, demographics, feature feedback, grow user base
• ex. “What addons do you use more often?”, “What are your most used features in firefox?”, “Want to follow us more? Join one of our mailinglists”

Labs

• user usage data to analyze and offer to proposees (usually labs and ux)

QA

• learn identifiable issues, collect problems and triage them into bug reports on bugzilla, educate community into becoming more useful testers

Support

• Learn identifiable issues, link people to already defined issues, grow *involved* user base

In there were a lot of correlations of needs between the groups such as issue identification and some form of user information. So, there’s my second set of requirements. How about the people that are going to give Mozilla feedback? I needed to find out what they were about too.

Who’s the Audience?

Using a Marketing-perspective, our betatesters are thought of as “early adopters”. These are folks who are the first people in line to get a new product. They want to set trends. They’re more likely to adopt new services on the web such as Twitter and are more likely to voice their opinion about a product. Ok, so there’s another requirement. We knew that they’re likely to give feedback, the system just needs to be available and highly visible.

Now that I had a set of requirements around the context of the problem at hand, I needed inspiration on how to implement the solution. So, I took notes from other Desktop App feedback systems.

What sources of inspiration can I rely on?

The most useful were:

• Microsoft Office Live 2007 with happy/sad smilies on the system task bar.
• Amarok implemented LikeBack which is uses the same happy/sad smilies on the top right of its main window.
• Uservoice collects ideas/suggestions from users in a very humane way.
• GetSatisfaction has gained a lot of popularity for its ability to quickly scale focus group level feedback on websites

There were some good ideas in each system. Namely, there was consistency across feedback systems for happy/sad/ideas as a primary channels. There were also some issues: after the initial instancing of the feedback form, there were a number of visual obstacles in the way to stop a user from giving feedback. All of these systems went from high-touch (i.e. use of smilies) to low-touch (i.e. tons of information on the forms). I mean, there were large text boxes for feedback, an e-mail address field, checkboxes for screenshots and profile information, paragraphs of text, submit/cancel buttons all spaced together in a thin and gray pop-up dialog. On top of that, none of them felt like they were alluding to a one-on-one relationship with the application as if it was a person. When asking someone for something subjective like an opinion, you can’t dis-orient them mid-submission with a robotic submission form. It’s not humane.  Ok, so my fourth set of requirements was to use happy/sad/idea and keep the submission process high-touch. I still felt like something was missing though. What about the process of directing a user towards giving useful and actionable feedback? How was that possible?

How can I direct users to give an ‘actionable’ piece of user feedback?

I started reading about effective and clear communication. The results were always related to being concise, showing empathy, asking questions in probing manner, using the first person in speech and being respectful. So, what was “concise” and “actionable” in the context of written text? I broke it down as such:

1. Sentences have three units of measure: words, syllables and characters.
2. For Words, the recommended number per sentence is proposed to be about 15-20 by Martin Cutts in the Oxford Guide To Plain English. In his words, “More people fear snakes than full stops, so they recoil when a long sentence comes hissing across the page.”
3. For syllables, the general rule-of-thumb is 1.7.
4. For characters, the general rule-of-thumb in Plain English has been 5. A good number of analysis on a quick search of google, have proven that’s a good starting point.

So, I figured the right approach was to offer a sentence’s worth of characters (i.e. 100 characters) plus a little bit of slack to take into account technical words that end up being very long. Therefore, 140 characters felt right. Also, our already defined “early adopter” Beta Testing crowd has experience dealing with this restriction on Twitter as well as SMS text messaging.

In conclusion…

1. Feedback submission should be directed and alludes to the past, but feels different.
2. Feedback needs to relate to issue identification and carry some form of user information.
3. It need to be available and highly visible.
4. Happy/sad/ideas are good ideas and keep the submission process high-touch.
5. Be concise, show empathy, ask questions in probing manner, use the first person in speech and make sure the feedback is respectful.
6. Use a 140 characters max limit.

The next blog post will detail a good part of the translation of requirements to concept. Stay tuned!

Firefox’s favorite feedback web application in Firefox 4 Beta now supports Releases! Once Firefox 4 goes out, release users will see the following set of options after clicking the “Submit Feedback” option under the Help menu.

That’s not all either! This release includes the ability to download our database of feedback via tsv files [1] and a new option within the opinion toolbox to copy the user agent of an individual piece of feedback. Of course, this wouldn’t be possible without the efforts of Frederic Wenzel, Ryan Snyder, Dave Dash, Chris Howse, Michael Kurze, Stephen Donner, Rebecca Billings, Vishal Kamdar and Dave Hunt and Corey Shields.

List of Major Features

• Submission methods for releases of Firefox 4 and later
• Input’s database is available via .tsv files[1]
• Copy User Agent feature in the opinion toolboxes
• Searching by infinite time period
• Time periods for searches on previous betas are more intuitive

Finally, here’s a list of bugs fixed in this release.

[1] To handle the potential large amount of load, the link to download the files can retrieved by going through the following instructions.

This has been a long-time coming, but here’s a handy screencast briefly outlining the features on input.mozilla.com.

If you want to learn more about how the feedback is triaged and funneled back into our community, there’s two things you can do this week:

1. Take part in Mozilla QA’s Testday on learning how to triage issues from various locales over into bugs
2. Listen in on Air Mozilla for a Brown Bag on “Getting to Know input.mozilla.com” on Thursday, 1/20, at 12pm PST.

There are a few more screencasts in the future on some planned additions to the dashboard as well as some advanced uses of it. If you have suggestions on possible uses of the dashboard, I’m more than happy to take requests!

It’s been two years into my candidacy as an MBA over at Santa Clara University and, over that time, I’ve been asked by several people how I balance a full-time job, a part-time education and a mid-20′s social life. The usual answer is “poorly” or “terribly”, but that doesn’t help those who are trying to figure out if it’s the right path for them.

First things first though, here’s a brief moment of “fud” (i.e. fear, uncertainty and doubt) for those would-be-MBA’ers:

• You’re going to lose track of one or more friends.
• Over the course of the candidacy, you’re going to let down your family in some way.
• Over the course of the candidacy, you’re going to let down your friends in some way.
• Over the course of the candidacy, you’re going to let down your co-workers in some way.
• You’ll have less patience with people and it’ll show.
• You’ll have to either forego a healthy sleep schedule, social life or both.

I’m not trying to scare you away from it; its just important to know what to expect after making the decision to dedicate a big part of your life for the next 3 or so years. Now with that out of the way, let’s get to the real meat and potatoes. I think its pretty manageable if you take the extra onus to schedule and plan your time accordingly and stick to it. The problem is that most, including myself, don’t really understand how to do it until about a year or so of being in the program. So, here’s a little advice that’ll help avoid any or all of those “fud” points from the start:

Before the Quarter Starts:

1. Open up a calendar and notebook.
2. In the calendar, write down the dates for every homework assignment and project due as well as test dates across every class you’re taking.
3. With your notebook, write down a list of things you’re looking to accomplish at work AND life over the next 3-6 months, prioritize them and offer a very general time period as to when you think they’ll get accomplish.
4. Cross-reference with the list back to your calendar and see how that’ll look.
5. Take out half or more of the things you’d like to get accomplished at work and life. Put it in a backlog. You’re going to go crazy if you try to get everything accomplished.
6. Inform your manager of time periods of when school work is going to be hectic over the next quarter. This’ll help manage expectations in terms of work.

During the Quarter

1. Treat free time as an opportunity to actually get a head-start on school work due 2 weeks to a month ahead of time. This’ll help make those expected hectic periods a whole lot more manageable.
2. Try to do a small portion of reading or homework for 1/2 – 1 hour everyday.
3. Take every opportunity to exercise even if it means not hanging out with friends. This’ll really help keep your mind fresh.
4. Be strict in allocating at least 7 hours of sleep a day.
5. A week before any hectic period, inform your family, friends and manager that you’re not going to be available through a simple e-mail or two.
6. Make plans to go out for a fully weekend day with friends or a significant other after each hectic period.

After Each Quarter

1. Go on a small vacation (i.e. a long weekend trip) with the people closest to you.

Do this every quarter. I know this may sound crazy, but its tried and true. If you do even half of these things, it’s going to go a long way to make your life a whole lot easier to handle over your time at the institution. Oh, and one other thing: always remind yourself why you’re in the program (i.e. what you’re trying to get out of it). It’s a lot of money, work and time out of your life and doing it without a rhyme and reason is a recipe for disaster. Personally, I got caught in that that recipe and I wasted a year to trying to really figure it out. So, make sure you know!

I was reading through the suggestions users were submitting for Mobile Firefox Beta 3 this past week and found these two little nuggets:

“Add a home page button. Add the ability to delete the history.”

and

“the mobile app for iphone and android devices should have a home button… that will come in really handy when setting a start page”

So, I took an idea from a sample test extension that Dietrich had written for a bug and decided to make an add-on to fulfill those suggestions. The result is an add-on which puts in a home button on the right sidebar and allows you to go back to your start page in one click. Get it here:

http://addons.mozilla.org/en-US/mobile/addon/269533/

Note: If anyone has a better icon I could use for the home button on the sidebar, please feel free to comment back with a link or an e-mail. Otherwise, enjoy!