The Input team ( i.e. the people behind input.mozilla.com ) definitely feel like we’re not getting the most bang for our buck in terms of the messages we have in our database. It’s pretty much the only publicly accessible database of user feedback on a major piece of software out there and we’re only processing the data through one form of text clustering. So, we’d like to break the bank here and get a slew of questions people would like to have answered (that makes our software/product better) with this data.
How can you offer us your questions? You can comment on this blogpost with the following format:
- Question you’d like answered:
- Why you’d like an answer to that question:
- How that answer would help make Firefox/Mobile Firefox better:
- BONUS – Suggested algorithms you’d like to see implemented to answer that question:
Some Inspiration:
- How do users commonly name features of Firefox?
- How happy/sad are messages submitted within the happy/sad forms?
- Is there a distinction in sentiment between messages sent with or without URLs across the happy/sad forms?
- How many users offer Input a message in another language, but on an en-US build, when there are no other locales available?
Is users’ happiness/sadness associated with phases of the moon or other periodic phenomena?
I’ll admit this is just a lark, but it should be easy to figure out. It might help determine when we should show off new features (when users are happy), and when we should show off bug fixes (when users are sad).
I suspect this would be a minimal effect, so you’d probably need to do a DFT on the %happy and look for a signal at ~1/30 days.
I’d like to see how often people run into situations where, for whatever reason, a URL entered does not result in a web page loaded.
I’ve never been able to pin down which extension or combination of extensions does it, but it’s VERY frustrating to click a link in Thunderbird (or middle-click one in Firefox) and then, when I get around to looking at my tabs, find several which are empty and have no URL in the address bar.
I know it’s my Firefox discarding the URL because I’ve seen it happen with only one tab, but with only one tab, the URL stays so I can click “Go” a second time and have the URL actually load.
It’s the data loss bug that really gets to me. Yes, it’s annoying to sometimes have to left-click links twice for it to actually take, but having to rely on Thunderbird’s Undo or Unclose Tab to figure out what the tab was supposed to be really worries me (I’m just lucky it hasn’t yet gobbled up a link sent by a family member via StumbleUpon) and this strikes me as the kind of thing users would probably feel too ill-defined and make users feel too intimidated to report via Bugzilla.
I’ll need to think on how to effectively identify this kind of problem from input.moz feedback though. It seems more suited to a test pilot approach. (Maybe in November once my exams are over)
How much data are there? I’d really like you to make the data available, or an interface to them, so that anybody can start exploring them and pulling out signals in all that noise.
How about it?! :D
Hey Stephen,
You’re right that the input feedback data wouldn’t be too much help there. Test Pilot is your best bet and getting something like that into Thunderbird would be super helpful.
Hey jz,
It’s like you’re reading my mind! We’re thinking up ways of making the data available in sane ways with readable formats, but we’d also like to get some real churn on people sifting through it. If you have some ideas on how to post this data up, I’d be more than happy to hear about it.
OK I’d like to see:
1. An interactive Praise/Issues ratio plotter.
2. P/I plottable as a function of
(a) time (check the whole process is working! does P/I settle to some stable value eventually?)
(b) release (encourage the coders)
(c) locale (let’s have a competition between locales to get their P/I down – a prize for the winner; do some locales complain more than others?!)
(d) website (to pressurize websites if they are slow to catch up; how do we attribute bugs to Firefox or the host?)
(e) OS etc (highlight platform difficulties)
(f) bug fixed (show when key bugs are fixed)
(g) feature area
3. Can we use input.mozilla as an early warning mechanism e.g. with a new release to see if any particular issues are suddenly cropping up that need to be fixed? How about plotting some quantities e.g. P/I for all of the above against a running mean? cf Ganglia.
Could you make a sample of a few million lines of data available for us to play with? I can use an excellent plotting package to look at most of these in a few minutes if you would put some data up :)
Do email me if you think I can help..
Thanks!
Wow, those are some great suggestions actually.
For #1-2, we’re actually going to be adding a time-based line graph that will do pretty much everything you ask for.
For #3, I think this is something we’re already bringing to light in the Firefox Planning meetings: https://wiki.mozilla.org/Firefox/Planning/2010-10-20#Highlights_.2F_Notices (hint: take a look at the table).
Lastly, we’re looking into making the data available in a sane way, but haven’t hashed out what we want to do yet completely. When we do make it available, it’ll be part of a larger program to get others to siphon through it and develop their own insights!
Thanks a lot !
I am doing research for my university paper, thanks for your brilliant points, now I am acting on a sudden impulse.
- Kris
[WORDPRESS HASHCASH] The poster sent us ’0 which is not a hashcash value.