On Jun 12, 2014, at 10:32 AM, Mike Connor <[email protected]> wrote:
> I’ll note that, at least on my Samsung phone, the reporting bit is opt-in > (i.e. if you turn on wifi-aided geolocation you agree to contribute back). > Of course, GPS is slow, so most people take the trade. > Good to know, I didn't remember being asked on my device. > Do we have a model of how many opt-ins (absolute number) we’d need to have in > a given area to deliver solid results? Saying “we need way more” isn’t > really enough to define/target success. It’s also worth noting that purely > percentage-based opt-ins won’t be as relevant (i.e. a lot of Toronto and the > Bay Area is well-mapped already). No, I could try to pass that question further up the Geolocation chain. But, I can tell you from my involvement up to now, there is no answer to that question. It is actively discussed, as we need to establish success metrics. I do know that we will be looking to come up with numbers as soon as the feature is in (opt-in numbers, collection volume, collection quality), and extrapolating from there. MLS services is working heavily on success metrics of the service, based on number of collection points, geolocation accuracy, and comparing our database in various ways to commercial telecoms that are internally sharing data with us. There are various experiments going on ATM, taxi wardriving, focused stumbling groups in India. None of these are providing the answer to your question though. > If we want to get more data from less-covered areas, it’s potentially a very > different call to action: publish a set of bounding boxes where we need more > coverage, when we fulfil a location request, check to see if the user is in a > less-covered area. If they are, the ask can then be framed “Mozilla is > building a privacy-respecting location service, and we need your help to make > it awesome in your area!” It’s a more specific ask, and I’d suspect the more > personal contribution aspect would help opt-in rates. Absolutely. We need the bounds of heavily stumbled areas because we are wasting resources (cpu/battery/network) having people stumble the same areas (work and home) 300 days a year. We can auto-geofence using these bounds, so that when a user is inside the fence, we stumble very little. MozStumbler would also use this not just for auto-geofencing, but to provide more feedback on the map view. This *was* planned for future, but your idea of tying that in to make people's contribution feel more valuable, is really compelling. > Semi-related: have we considered enabling a similar feature in desktop > builds? It obviously wouldn’t be as good for the “in-between” spaces, but > it’d still get us more data than we have now. It is relatively easy to hook up on the desktop, to do an occasional wifi scan when someone visits a web page that uses geolocation. I don't recall this being discussed, but it is a good idea. Also, we want to scan for bluetooth locators, something desktops can help with. Those are all tasks for future Garvan to worry about. _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
