Tag: ui

App Marketplace Ratings

Woot!  Our recently release re-vamp of Firefox for Android is climbing the Top Free chart over on the Google Play Store (as it should, it’s frickin’ awesome).  We’ve gone from #96 to #81 in the past 3 days and I have no doubt we will continue to climb as we gain users and get a chance to impress them with the Native UI which is responsive, beautiful, and support Flash.  Our rating in the store is also slowly climbing, but that’s going to be a much harder slog because our current rating still reflects the total collected in the entire life of this product being on the store.  We can’t remove ratings from our previous Firefox for Android and so even though we’ve had 5,000 5-star reviews in the first 10 days of the re-written version being online, our average rating is a 3.7. The only way to get a fresh start would have been to put up a ‘new’ product and call it something else and I’m sure you can understand that Firefox can’t go by any other name.

I spend a lot of time thinking about the Google Play store and how it could be better because I interact with its administrative backend regularly, uploading new builds of the mobile products release after release.  I was just sitting through a presentation by Dees at ReMo Camp 2012 in Berlin and he was sharing with us the strategies behind the Mozilla Marketplace. This will be our open-source contribution to mobile/desktop app distribution and seeing the mockups started me thinking about how we could improve the rating system and not just repeat what Google and Apple do with user feedback.

I’d like to see the following:

  1. User leaves rating, gives stars + writes text feedback
  2. App developer can select reviews to flag as ‘bug report/feedback’ which requires them to write text that will be presented to the user.  The developer can write a message either letting the reporter know that a bug is on file now for the issue or provide help with the issues/questions raised by the user.
  3. User gets a notification when the review is flagged and that there is a response ready for them. They can check out the bug report that got filed as a result of their feedback and perhaps they will cc themselves to know when it gets fixed or they might get a chance to try out the suggested solutions from the dev to deal with issues or questions they raised in their original review.
  4. User, now that they have gotten feedback, gets prompted to revise their review.
  5. Repeat 1-4 as needed

This would be beneficial for many reasons:

  • Users get to be a part of helping improve the product
  • Users get support from the developer without needing a different forum or login
  • Users get visibility into software development process, awareness of upcoming features & improvements, and they become participants in open source community
  • App developers have a channel to communicate with users about upcoming dev plans, feature requests, and bug tracking
  • App developers get a collected feedback average that is more accurate and representative
  • App developers have a channel to communicate with users about upcoming dev plans, feature requests, and bug tracking

I’m used to Mozilla’s collaborative environment, the values of open source, and I’m accustomed to getting feedback in our open bug tracker, Bugzilla.  There are so many companies whose products I use who do not have public bug trackers and this causes me a lot of frustration when I find bugs with their software.  I want to tell their devs about the bugs I find.  Software has bugs!  Have a bug tracker! Let people see and understand that software is a continuous improvement process so we get less reviews like this:

firefox feedback in google play store, lamenting the lack of tablet support

I’d love to let Brian know that we are sooooo close to having our tablet support ready, that we have a few outstanding bugs but it’s on-track to ship with Firefox 15 in a mere 7 weeks. We’re a tiny team compared to the Gopplesoft mobile dev teams, give us a chance to prioritize and push each goal to the finish line. With only 20% of our Firefox mobile users on tablets, we had to focus on the 80% small device folks first and then – remember, only 8 weeks later – we got our tablet ducks in a row and ready for our fabulous tablet users.

Alex should get to see a bug filed on the pinch zoom (if there’s not already one) and as one of the admins of the Firefox product, I should get a chance to interact with the folks who leave 1 or 2 star reviews since they are often based on one or two issues that are real but fixable.  I want our rating to be reflective of the work we do as we do it, incrementally improving over time. Of course, our marketplace code is open source so I suppose I should do what Paul Rouget suggested earlier today and make up some prototypes 🙂

OccupediA – Women Contributing to Wikipedia (the first of many such events)

Last Thursday night about 8 women arrived at Noisebridge to learn how to contribute to Wikipedia.  Several things led to this gathering:

  • An article in the New York Times back in October drew attention to the lack of women contributors to the Wikipedia knowledge base and that got me thinking.
  • Having organized other spontaneous “women get together and learn stuff” events I figured I could take the same approach to Wikipedia contributing, get some women together to create accounts, generate content, learn how to stop vandalism and see what would stick.
  • Recent participation in activism around the Occupy Wall Street movement also inspired me to try and reach out to communities I am in who are not as technical, to encourage people to come first with knowledge and interest in topics Wikipedia could benefit from and let the tech come second.
  • A month ago Elsa and I were talking casually about all the the above mentioned things and we decided to just go for it and pick a date, throw it up on the Noisebridge (local SF hackerspace) calendar, and see what we could make happen.

We took over a small makeshift classroom space at the back of Noisebridge. It had one lamp as the primary source of light because the fluorescent holders above were missing their tubes.  A man was near the back working on a dress for fashion school, several other hackers were up front working on their various projects.  Noisebridge was a wonderful place to have this event. It feels like anything is possible in a space like that.

I was happy with the turn out – we had a mix of artists, educators, and tech workers. Also as a bonus one of the attendees, my coworker Boriss, was a seasoned Wikipedia contributor who was able to really detail the ins and outs of the different levels of participation.  I can’t stress enough how amazing it was to have her and her knowledge there because there are lots of misconceptions about Wikipedia (I definitely had some) and her first-hand knowledge was inspiring to me.

So the beginning of the meetup went well enough, and as you might expect.  We introduced ourselves, talked about why we had come to the event and what we were hoping to get out of it. We started in on learning how to set up an account if one didn’t already exist and we looked at discussion/history/edit and other basic navigations of Wikipedia space.  There were a lot of questions about what belongs in Wikipedia, neutral tone, citations.  The conversations were lively and I found them quite enjoyable.

Here’s what I didn’t expect: Getting folks interested and excited about Wikipedia becomes REALLY HARD in practice.  Unlike learning Python where the participants can hammer out some code on their own computers in minutes and feel accomplished, there is a lot more complexity to Wikipedia.  There is a lot of confusion about their UI, their purpose, who can do what and when. Very quickly it seemed that the women who had come to the event feared adding anything new to the knowledge base and they were also incredibly intimidated by the UI of the site. It wasn’t even clear enough how one would create a new article when none existed.

From this event I learned a lot about organizing and about the intentions of future events like this and I did a little braindumping while we were meeting so I could remember to list them later in this very post.

Things that would help newcomers:

  • Having a “new to wikipedia” moniker next to their nickname for the first N activities on the site (we have this on our Mozilla bugzilla) so that hopefully older and wiser participants would be extra nice to them
  • Find a way to make some of the simpler tasks that help Wikipedia (typos, reverting vandalism, categorizing articles) into a game that a new arrival could play that would start easy and then move more toward the real-life workflow of working on Wikipedia – as a way to warm them to the UI
  • Encourage newcomer to write a straight-up article and have a place for these things to be dumped for inpection/linkage/categorization and otherwise Wikipedia-fying the knowledge dump.  My partner is an English professor and can certainly write good content for Wikipedia but everything about the site is intimidating. There should be a page where she could copy/paste or upload a document of her article and then let people who know wiki syntax and the other requirements an article needs come along and finish it up
  • Make it way easier to find the “adopt a user” program that I hear exists but no one would know to find that from the Wikipedia home page

I will continue to organize these events, perhaps once a month. More reports as they happen.