Hello,
My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS app. I wanted to speak to a couple specific issues and misunderstandings raised by this email thread.
First, please take a look at https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service which provides some background on this decision. Jonatan linked to it, and it covers several of the concerns raised on the thread and gives our reasoning. I'd also suggest subscribing to this ticket: https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where you can track efforts and issues with replacement maps.
A few clarifying points:
1. The Places tab[1], and its use of Apple’s maps tiles, is not part of the articles or article display, it is a navigational aid to help you find articles. This doesn’t mean it’s exempt from considerations raised here, but just want to clarify that this is not about editor created maps in projects, but rather an app-specific discovery mechanism.
2. The feature doesn’t violate our privacy policy[2] and was reviewed by Wikimedia Foundation's Legal department before entering beta. The App’s access to the users’ geolocation to recommend nearby articles, with the users’ explicit consent, is already part of both apps. The new feature merely adds a different way to visually view nearby articles - the user must, as before, still provide explicit consent for the App to access their geolocation. Users can always turn on or off the provision of their geolocation via their iPhone location settings.
The feature also makes requests to Apple’s map tile servers for display on the App. These tiles may or may not be near the actual location of the user. It doesn’t involve sending Apple the articles you read or anything about your Wikipedia usage. Apple has public statements and documentation to explain[3] how their maps service preserves privacy by using a randomized and frequently changing device ID to request the maps, by not tracking users over time, and by not building map usage profiles of users. Overall, Apple’s data collection practices are governed by their privacy policy [4], which users must agree to order to use their iPhones.
We plan to further expand the explanation in the FAQ/privacy section of the https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service page in the next day or so.
3. As stated by others on this thread, the issue at hand is the feasibility and usability of a libre maps tile server, and impacts on users and how it reflects (or doesn’t) the values of Wikimedians. The rest of the work on this feature (such as the time spent on search, visually clustering items on the map, a list view of nearby landmarks, and the Wikipedia article pins) will be applicable, independent of the map provider. In fact, I’d estimate the engineer doing the work spent more time on hacking to try to make a combination of MapBox and Wikimedia tiles work, than he did/will on integrating/removing Apple maps.
4. This feature was announced on the Wikimedia Blog[5], described in an initial MediaWiki.org page[6], all work was documented and tracked on Phabricator (including an initial tech investigation, the request to remove Apple Maps during development, and the overall feature[7]) and then the decision to push into beta with Apple Maps further documented on MediaWiki.org[8].
In conclusion, I would like to thank you for the feedback and the opportunity to engage in a civil discussion about these important issues. Again, if you are interested in the next steps, I’d invite you to subscribe and comment on the phab ticket https://phabricator.wikimedia.org/T157763 or the MediaWiki.org page.
[1] Design specification: https://phabricator.wikimedia.org/T130889 [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service#Privacy [3] https://support.apple.com/en-us/HT203033, https://support.apple.com/en-us/HT207056, http://www.apple.com/privacy/approach-to-privacy/ [4] http://www.apple.com/privacy/privacy-policy/ [5] https://blog.wikimedia.org/2016/06/17/wikipedia-mobile/ [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Nearby [7] https://phabricator.wikimedia.org/tag/ios-app-feature-places/ [8] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
Good to hear about privacy being maintained. Are there efforts to move to OSM eventually?
J
On Tue, Mar 14, 2017 at 6:18 PM, Joshua Minor jminor@wikimedia.org wrote:
Hello,
My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS app. I wanted to speak to a couple specific issues and misunderstandings raised by this email thread.
First, please take a look at https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service which provides some background on this decision. Jonatan linked to it, and it covers several of the concerns raised on the thread and gives our reasoning. I'd also suggest subscribing to this ticket: https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where you can track efforts and issues with replacement maps.
A few clarifying points:
- The Places tab[1], and its use of Apple’s maps tiles, is not part of the
articles or article display, it is a navigational aid to help you find articles. This doesn’t mean it’s exempt from considerations raised here, but just want to clarify that this is not about editor created maps in projects, but rather an app-specific discovery mechanism.
- The feature doesn’t violate our privacy policy[2] and was reviewed by
Wikimedia Foundation's Legal department before entering beta. The App’s access to the users’ geolocation to recommend nearby articles, with the users’ explicit consent, is already part of both apps. The new feature merely adds a different way to visually view nearby articles - the user must, as before, still provide explicit consent for the App to access their geolocation. Users can always turn on or off the provision of their geolocation via their iPhone location settings.
The feature also makes requests to Apple’s map tile servers for display on the App. These tiles may or may not be near the actual location of the user. It doesn’t involve sending Apple the articles you read or anything about your Wikipedia usage. Apple has public statements and documentation to explain[3] how their maps service preserves privacy by using a randomized and frequently changing device ID to request the maps, by not tracking users over time, and by not building map usage profiles of users. Overall, Apple’s data collection practices are governed by their privacy policy [4], which users must agree to order to use their iPhones.
We plan to further expand the explanation in the FAQ/privacy section of the https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service page in the next day or so.
- As stated by others on this thread, the issue at hand is the feasibility
and usability of a libre maps tile server, and impacts on users and how it reflects (or doesn’t) the values of Wikimedians. The rest of the work on this feature (such as the time spent on search, visually clustering items on the map, a list view of nearby landmarks, and the Wikipedia article pins) will be applicable, independent of the map provider. In fact, I’d estimate the engineer doing the work spent more time on hacking to try to make a combination of MapBox and Wikimedia tiles work, than he did/will on integrating/removing Apple maps.
- This feature was announced on the Wikimedia Blog[5], described in an
initial MediaWiki.org page[6], all work was documented and tracked on Phabricator (including an initial tech investigation, the request to remove Apple Maps during development, and the overall feature[7]) and then the decision to push into beta with Apple Maps further documented on MediaWiki.org[8].
In conclusion, I would like to thank you for the feedback and the opportunity to engage in a civil discussion about these important issues. Again, if you are interested in the next steps, I’d invite you to subscribe and comment on the phab ticket https://phabricator.wikimedia.org/T157763 or the MediaWiki.org page.
[1] Design specification: https://phabricator.wikimedia.org/T130889 [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/ Maps_service#Privacy [3] https://support.apple.com/en-us/HT203033, https://support.apple.com/en-us/HT207056, http://www.apple.com/privacy/approach-to-privacy/ [4] http://www.apple.com/privacy/privacy-policy/ [5] https://blog.wikimedia.org/2016/06/17/wikipedia-mobile/ [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Nearby [7] https://phabricator.wikimedia.org/tag/ios-app-feature-places/ [8] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hoi, One point about OSM is that it provides a better service in situations that are sub optimal. The infra structure for Haiti is diminished and it is in OSM where people are actually working hard to provide the best map service.
We have had nearby function in Labs for a very long time, I have read the article and I find what has been decided, it does not provide me with the reasons for it. As far as I am concerned you chose to go this way. Thanks, GerardM
On 15 March 2017 at 01:18, Joshua Minor jminor@wikimedia.org wrote:
Hello,
My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS app. I wanted to speak to a couple specific issues and misunderstandings raised by this email thread.
First, please take a look at https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service which provides some background on this decision. Jonatan linked to it, and it covers several of the concerns raised on the thread and gives our reasoning. I'd also suggest subscribing to this ticket: https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where you can track efforts and issues with replacement maps.
A few clarifying points:
- The Places tab[1], and its use of Apple’s maps tiles, is not part of the
articles or article display, it is a navigational aid to help you find articles. This doesn’t mean it’s exempt from considerations raised here, but just want to clarify that this is not about editor created maps in projects, but rather an app-specific discovery mechanism.
- The feature doesn’t violate our privacy policy[2] and was reviewed by
Wikimedia Foundation's Legal department before entering beta. The App’s access to the users’ geolocation to recommend nearby articles, with the users’ explicit consent, is already part of both apps. The new feature merely adds a different way to visually view nearby articles - the user must, as before, still provide explicit consent for the App to access their geolocation. Users can always turn on or off the provision of their geolocation via their iPhone location settings.
The feature also makes requests to Apple’s map tile servers for display on the App. These tiles may or may not be near the actual location of the user. It doesn’t involve sending Apple the articles you read or anything about your Wikipedia usage. Apple has public statements and documentation to explain[3] how their maps service preserves privacy by using a randomized and frequently changing device ID to request the maps, by not tracking users over time, and by not building map usage profiles of users. Overall, Apple’s data collection practices are governed by their privacy policy [4], which users must agree to order to use their iPhones.
We plan to further expand the explanation in the FAQ/privacy section of the https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service page in the next day or so.
- As stated by others on this thread, the issue at hand is the feasibility
and usability of a libre maps tile server, and impacts on users and how it reflects (or doesn’t) the values of Wikimedians. The rest of the work on this feature (such as the time spent on search, visually clustering items on the map, a list view of nearby landmarks, and the Wikipedia article pins) will be applicable, independent of the map provider. In fact, I’d estimate the engineer doing the work spent more time on hacking to try to make a combination of MapBox and Wikimedia tiles work, than he did/will on integrating/removing Apple maps.
- This feature was announced on the Wikimedia Blog[5], described in an
initial MediaWiki.org page[6], all work was documented and tracked on Phabricator (including an initial tech investigation, the request to remove Apple Maps during development, and the overall feature[7]) and then the decision to push into beta with Apple Maps further documented on MediaWiki.org[8].
In conclusion, I would like to thank you for the feedback and the opportunity to engage in a civil discussion about these important issues. Again, if you are interested in the next steps, I’d invite you to subscribe and comment on the phab ticket https://phabricator.wikimedia.org/T157763 or the MediaWiki.org page.
[1] Design specification: https://phabricator.wikimedia.org/T130889 [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/ Maps_service#Privacy [3] https://support.apple.com/en-us/HT203033, https://support.apple.com/en-us/HT207056, http://www.apple.com/privacy/approach-to-privacy/ [4] http://www.apple.com/privacy/privacy-policy/ [5] https://blog.wikimedia.org/2016/06/17/wikipedia-mobile/ [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Nearby [7] https://phabricator.wikimedia.org/tag/ios-app-feature-places/ [8] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi Josh, all,
I am not one hell-bent on "FOSS or death"; I tend to use whatever works best.
That said, the cost-benefit analysis of using Apple Maps seems to boil down: * Apple Maps has slightly better rendering (didn't check, but I assume) * Apple Maps uses less mobile bandwidth * Apple Maps is not free (as in freedom)
Now, looking at these points:
* Somewhat better quality is not an argument. If it were, we would have stayed with Britannica, and skipped that whole Wikipedia nonsense. Wikipedia became better, in part, because people actually used it, saw the issues, and fixed them. And OSM rendering might be not quite en par with Apple Maps, it is quite usable, in my experience.
* Less bandwidth usage is not an argument either. I doubt we are talking about a significant percentage of an average users' data volume here. If Android users can afford the bandwidth, so can people who buy an iPhone (source: used to have iPhone).
* The price tag is the "non-freedom". As far as I can tell, this would be the very first Wikimedia "product" that incorporates non-free technology and data. It sets a precedence. It also has the potential to poison the otherwise great relations between the Wikipedia, Wikidata, and OSM community. It says "OSM is not good enough (at least for Apple users)" quite plainly. How would we feel if OSM started to remove Wikidata tags and replace them with Britannica links?
All in all, IMHO, the cost is too high for the (at best) flimsy benefits.
Cheers, Magnus
On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor jminor@wikimedia.org wrote:
Hello,
My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS app. I wanted to speak to a couple specific issues and misunderstandings raised by this email thread.
First, please take a look at https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service which provides some background on this decision. Jonatan linked to it, and it covers several of the concerns raised on the thread and gives our reasoning. I'd also suggest subscribing to this ticket: https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where you can track efforts and issues with replacement maps.
A few clarifying points:
- The Places tab[1], and its use of Apple’s maps tiles, is not part of the
articles or article display, it is a navigational aid to help you find articles. This doesn’t mean it’s exempt from considerations raised here, but just want to clarify that this is not about editor created maps in projects, but rather an app-specific discovery mechanism.
- The feature doesn’t violate our privacy policy[2] and was reviewed by
Wikimedia Foundation's Legal department before entering beta. The App’s access to the users’ geolocation to recommend nearby articles, with the users’ explicit consent, is already part of both apps. The new feature merely adds a different way to visually view nearby articles - the user must, as before, still provide explicit consent for the App to access their geolocation. Users can always turn on or off the provision of their geolocation via their iPhone location settings.
The feature also makes requests to Apple’s map tile servers for display on the App. These tiles may or may not be near the actual location of the user. It doesn’t involve sending Apple the articles you read or anything about your Wikipedia usage. Apple has public statements and documentation to explain[3] how their maps service preserves privacy by using a randomized and frequently changing device ID to request the maps, by not tracking users over time, and by not building map usage profiles of users. Overall, Apple’s data collection practices are governed by their privacy policy [4], which users must agree to order to use their iPhones.
We plan to further expand the explanation in the FAQ/privacy section of the https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service page in the next day or so.
- As stated by others on this thread, the issue at hand is the feasibility
and usability of a libre maps tile server, and impacts on users and how it reflects (or doesn’t) the values of Wikimedians. The rest of the work on this feature (such as the time spent on search, visually clustering items on the map, a list view of nearby landmarks, and the Wikipedia article pins) will be applicable, independent of the map provider. In fact, I’d estimate the engineer doing the work spent more time on hacking to try to make a combination of MapBox and Wikimedia tiles work, than he did/will on integrating/removing Apple maps.
- This feature was announced on the Wikimedia Blog[5], described in an
initial MediaWiki.org page[6], all work was documented and tracked on Phabricator (including an initial tech investigation, the request to remove Apple Maps during development, and the overall feature[7]) and then the decision to push into beta with Apple Maps further documented on MediaWiki.org[8].
In conclusion, I would like to thank you for the feedback and the opportunity to engage in a civil discussion about these important issues. Again, if you are interested in the next steps, I’d invite you to subscribe and comment on the phab ticket https://phabricator.wikimedia.org/T157763 or the MediaWiki.org page.
[1] Design specification: https://phabricator.wikimedia.org/T130889 [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service#Privacy [3] https://support.apple.com/en-us/HT203033, https://support.apple.com/en-us/HT207056, http://www.apple.com/privacy/approach-to-privacy/ [4] http://www.apple.com/privacy/privacy-policy/ [5] https://blog.wikimedia.org/2016/06/17/wikipedia-mobile/ [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Nearby [7] https://phabricator.wikimedia.org/tag/ios-app-feature-places/ [8] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hey Magnus,
There are a few other factors to consider in addition to those listed. For example, development cost. Our maps tile service is not compatible with the iOS app out of the box. This isn't surprising; Apple wants you to use things like Apple Maps rather than your own solution. Android is, by its nature, a more open platform, so I am not too surprised that it was easier to integrate our tile server into the Android app than the iOS app. Sadly, it's not as simple as just switching over to OSM-based tiles; on the contrary, it's a significant amount of work.
Now, using our tile service would also have required the iOS app to use the MapBox SDK. This is the size of all their other third party libraries combined, significantly increasing app download size. The size of your app can significantly reduce downloads [1]. Switch a single feature over to a different set of map tiles, and possibly decreasing downloads of the app, seems like a dangerous and counterintuitive tradeoff to me.
So the question is, given all this, is switching over the nearby feature to use OSM-based tiles instead of Apple Maps worth it? In the long run, if these problems could be solved, I'd say it absolutely is worth it. But, in the short term, the work would take significant time and effort, and could actually decrease app usage by decreasing the app download rate; that tradeoff doesn't seem worth it to me.
Thanks, Dan
Disclaimers: These are my opinions only. I worked on the apps in the past, but haven't for two years; my statements about development costs may be wrong, and the apps folks may well disagree with me about things. I work in the department responsible for Wikimedia maps, but have only worked on the team working on maps for a couple of months.
[1]: https://segment.com/blog/mobile-app-size-effect-on-downloads/
On 15 March 2017 at 09:25, Magnus Manske magnusmanske@googlemail.com wrote:
Hi Josh, all,
I am not one hell-bent on "FOSS or death"; I tend to use whatever works best.
That said, the cost-benefit analysis of using Apple Maps seems to boil down:
- Apple Maps has slightly better rendering (didn't check, but I assume)
- Apple Maps uses less mobile bandwidth
- Apple Maps is not free (as in freedom)
Now, looking at these points:
- Somewhat better quality is not an argument. If it were, we would have
stayed with Britannica, and skipped that whole Wikipedia nonsense. Wikipedia became better, in part, because people actually used it, saw the issues, and fixed them. And OSM rendering might be not quite en par with Apple Maps, it is quite usable, in my experience.
- Less bandwidth usage is not an argument either. I doubt we are talking
about a significant percentage of an average users' data volume here. If Android users can afford the bandwidth, so can people who buy an iPhone (source: used to have iPhone).
- The price tag is the "non-freedom". As far as I can tell, this would be
the very first Wikimedia "product" that incorporates non-free technology and data. It sets a precedence. It also has the potential to poison the otherwise great relations between the Wikipedia, Wikidata, and OSM community. It says "OSM is not good enough (at least for Apple users)" quite plainly. How would we feel if OSM started to remove Wikidata tags and replace them with Britannica links?
All in all, IMHO, the cost is too high for the (at best) flimsy benefits.
Cheers, Magnus
On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor jminor@wikimedia.org wrote:
Hello,
My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS app. I wanted to speak to a couple specific issues and misunderstandings raised by this email thread.
First, please take a look at https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
which
provides some background on this decision. Jonatan linked to it, and it covers several of the concerns raised on the thread and gives our reasoning. I'd also suggest subscribing to this ticket: https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where you can track efforts and issues with replacement maps.
A few clarifying points:
- The Places tab[1], and its use of Apple’s maps tiles, is not part of
the
articles or article display, it is a navigational aid to help you find articles. This doesn’t mean it’s exempt from considerations raised here, but just want to clarify that this is not about editor created maps in projects, but rather an app-specific discovery mechanism.
- The feature doesn’t violate our privacy policy[2] and was reviewed by
Wikimedia Foundation's Legal department before entering beta. The App’s access to the users’ geolocation to recommend nearby articles, with the users’ explicit consent, is already part of both apps. The new feature merely adds a different way to visually view nearby articles - the user must, as before, still provide explicit consent for the App to access
their
geolocation. Users can always turn on or off the provision of their geolocation via their iPhone location settings.
The feature also makes requests to Apple’s map tile servers for display
on
the App. These tiles may or may not be near the actual location of the user. It doesn’t involve sending Apple the articles you read or anything about your Wikipedia usage. Apple has public statements and documentation to explain[3] how their maps service preserves privacy by using a randomized and frequently changing device ID to request the maps, by not tracking users over time, and by not building map usage profiles of
users.
Overall, Apple’s data collection practices are governed by their privacy policy [4], which users must agree to order to use their iPhones.
We plan to further expand the explanation in the FAQ/privacy section of
the
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service page in the next day or so.
- As stated by others on this thread, the issue at hand is the
feasibility
and usability of a libre maps tile server, and impacts on users and how
it
reflects (or doesn’t) the values of Wikimedians. The rest of the work on this feature (such as the time spent on search, visually clustering items on the map, a list view of nearby landmarks, and the Wikipedia article pins) will be applicable, independent of the map provider. In fact, I’d estimate the engineer doing the work spent more time on hacking to try to make a combination of MapBox and Wikimedia tiles work, than he did/will
on
integrating/removing Apple maps.
- This feature was announced on the Wikimedia Blog[5], described in an
initial MediaWiki.org page[6], all work was documented and tracked on Phabricator (including an initial tech investigation, the request to
remove
Apple Maps during development, and the overall feature[7]) and then the decision to push into beta with Apple Maps further documented on MediaWiki.org[8].
In conclusion, I would like to thank you for the feedback and the opportunity to engage in a civil discussion about these important issues. Again, if you are interested in the next steps, I’d invite you to
subscribe
and comment on the phab ticket https://phabricator.wikimedia.org/T157763 or the MediaWiki.org page.
[1] Design specification: https://phabricator.wikimedia.org/T130889 [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/
Maps_service#Privacy
[3] https://support.apple.com/en-us/HT203033, https://support.apple.com/en-us/HT207056, http://www.apple.com/privacy/approach-to-privacy/ [4] http://www.apple.com/privacy/privacy-policy/ [5] https://blog.wikimedia.org/2016/06/17/wikipedia-mobile/ [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Nearby [7] https://phabricator.wikimedia.org/tag/ios-app-feature-places/ [8] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
This reminds me of en wiki's non-free policy. https://en.wikipedia.org/wiki/Wikipedia:Non-free_content_criteria#1 highlights the point fairly clearly Usage of non-free materials is often easier and higher quality than using the free equivalent . However Wikimedia's mission and goal's are to support and promote free content, yes you will need to jump thru a few more hoops and adds a little more work. But without those driving factors we will often see the free options wither and fail.
On Tue, Mar 21, 2017 at 10:22 AM, Dan Garry dgarry@wikimedia.org wrote:
Hey Magnus,
There are a few other factors to consider in addition to those listed. For example, development cost. Our maps tile service is not compatible with the iOS app out of the box. This isn't surprising; Apple wants you to use things like Apple Maps rather than your own solution. Android is, by its nature, a more open platform, so I am not too surprised that it was easier to integrate our tile server into the Android app than the iOS app. Sadly, it's not as simple as just switching over to OSM-based tiles; on the contrary, it's a significant amount of work.
Now, using our tile service would also have required the iOS app to use the MapBox SDK. This is the size of all their other third party libraries combined, significantly increasing app download size. The size of your app can significantly reduce downloads [1]. Switch a single feature over to a different set of map tiles, and possibly decreasing downloads of the app, seems like a dangerous and counterintuitive tradeoff to me.
So the question is, given all this, is switching over the nearby feature to use OSM-based tiles instead of Apple Maps worth it? In the long run, if these problems could be solved, I'd say it absolutely is worth it. But, in the short term, the work would take significant time and effort, and could actually decrease app usage by decreasing the app download rate; that tradeoff doesn't seem worth it to me.
Thanks, Dan
Disclaimers: These are my opinions only. I worked on the apps in the past, but haven't for two years; my statements about development costs may be wrong, and the apps folks may well disagree with me about things. I work in the department responsible for Wikimedia maps, but have only worked on the team working on maps for a couple of months.
On 15 March 2017 at 09:25, Magnus Manske magnusmanske@googlemail.com wrote:
Hi Josh, all,
I am not one hell-bent on "FOSS or death"; I tend to use whatever works best.
That said, the cost-benefit analysis of using Apple Maps seems to boil down:
- Apple Maps has slightly better rendering (didn't check, but I assume)
- Apple Maps uses less mobile bandwidth
- Apple Maps is not free (as in freedom)
Now, looking at these points:
- Somewhat better quality is not an argument. If it were, we would have
stayed with Britannica, and skipped that whole Wikipedia nonsense. Wikipedia became better, in part, because people actually used it, saw
the
issues, and fixed them. And OSM rendering might be not quite en par with Apple Maps, it is quite usable, in my experience.
- Less bandwidth usage is not an argument either. I doubt we are talking
about a significant percentage of an average users' data volume here. If Android users can afford the bandwidth, so can people who buy an iPhone (source: used to have iPhone).
- The price tag is the "non-freedom". As far as I can tell, this would be
the very first Wikimedia "product" that incorporates non-free technology and data. It sets a precedence. It also has the potential to poison the otherwise great relations between the Wikipedia, Wikidata, and OSM community. It says "OSM is not good enough (at least for Apple users)" quite plainly. How would we feel if OSM started to remove Wikidata tags
and
replace them with Britannica links?
All in all, IMHO, the cost is too high for the (at best) flimsy benefits.
Cheers, Magnus
On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor jminor@wikimedia.org wrote:
Hello,
My name is Josh Minor, and I am the Product Manager for the Wikipedia
iOS
app. I wanted to speak to a couple specific issues and
misunderstandings
raised by this email thread.
First, please take a look at https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
which
provides some background on this decision. Jonatan linked to it, and it covers several of the concerns raised on the thread and gives our reasoning. I'd also suggest subscribing to this ticket: https://phabricator.wikimedia.org/T157763 which Jonatan filed, and
where
you can track efforts and issues with replacement maps.
A few clarifying points:
- The Places tab[1], and its use of Apple’s maps tiles, is not part of
the
articles or article display, it is a navigational aid to help you find articles. This doesn’t mean it’s exempt from considerations raised
here,
but just want to clarify that this is not about editor created maps in projects, but rather an app-specific discovery mechanism.
- The feature doesn’t violate our privacy policy[2] and was reviewed
by
Wikimedia Foundation's Legal department before entering beta. The App’s access to the users’ geolocation to recommend nearby articles, with the users’ explicit consent, is already part of both apps. The new feature merely adds a different way to visually view nearby articles - the user must, as before, still provide explicit consent for the App to access
their
geolocation. Users can always turn on or off the provision of their geolocation via their iPhone location settings.
The feature also makes requests to Apple’s map tile servers for display
on
the App. These tiles may or may not be near the actual location of the user. It doesn’t involve sending Apple the articles you read or
anything
about your Wikipedia usage. Apple has public statements and
documentation
to explain[3] how their maps service preserves privacy by using a randomized and frequently changing device ID to request the maps, by
not
tracking users over time, and by not building map usage profiles of
users.
Overall, Apple’s data collection practices are governed by their
privacy
policy [4], which users must agree to order to use their iPhones.
We plan to further expand the explanation in the FAQ/privacy section of
the
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
page
in the next day or so.
- As stated by others on this thread, the issue at hand is the
feasibility
and usability of a libre maps tile server, and impacts on users and how
it
reflects (or doesn’t) the values of Wikimedians. The rest of the work
on
this feature (such as the time spent on search, visually clustering
items
on the map, a list view of nearby landmarks, and the Wikipedia article pins) will be applicable, independent of the map provider. In fact, I’d estimate the engineer doing the work spent more time on hacking to try
to
make a combination of MapBox and Wikimedia tiles work, than he did/will
on
integrating/removing Apple maps.
- This feature was announced on the Wikimedia Blog[5], described in an
initial MediaWiki.org page[6], all work was documented and tracked on Phabricator (including an initial tech investigation, the request to
remove
Apple Maps during development, and the overall feature[7]) and then the decision to push into beta with Apple Maps further documented on MediaWiki.org[8].
In conclusion, I would like to thank you for the feedback and the opportunity to engage in a civil discussion about these important
issues.
Again, if you are interested in the next steps, I’d invite you to
subscribe
and comment on the phab ticket https://phabricator.wikimedia.
org/T157763
or the MediaWiki.org page.
[1] Design specification: https://phabricator.wikimedia.org/T130889 [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/
Maps_service#Privacy
[3] https://support.apple.com/en-us/HT203033, https://support.apple.com/en-us/HT207056, http://www.apple.com/privacy/approach-to-privacy/ [4] http://www.apple.com/privacy/privacy-policy/ [5] https://blog.wikimedia.org/2016/06/17/wikipedia-mobile/ [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Nearby [7] https://phabricator.wikimedia.org/tag/ios-app-feature-places/ [8] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/
Maps_service
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 21 March 2017 at 14:32, John phoenixoverride@gmail.com wrote:
This reminds me of en wiki's non-free policy. https://en.wikipedia.org/wiki/Wikipedia:Non-free_content_criteria#1 highlights the point fairly clearly Usage of non-free materials is often easier and higher quality than using the free equivalent . However Wikimedia's mission and goal's are to support and promote free content, yes you will need to jump thru a few more hoops and adds a little more work. But without those driving factors we will often see the free options wither and fail.
In general I do not think attempting to apply English Wikipedia policies to product development is particularly meaningful, given that writing an online encyclopaedia is very different from developing software. Regardless, I do not think there is anyone opposed to this ideological statement, but as I have explained in my email, ideology and reality sometimes come in to conflict.
Dan
Hoi, Technical considerations are imho less relevant. What trumps it is functionality. Our maps have to be good everywhere and as far as I know OSM is superior in places where there is profit to be made from maps.
Current maps world wide and historical maps are what we need. How would you use the Apple maps for a map of the Ottoman empire? Thanks, GerardM
On 21 March 2017 at 15:22, Dan Garry dgarry@wikimedia.org wrote:
Hey Magnus,
There are a few other factors to consider in addition to those listed. For example, development cost. Our maps tile service is not compatible with the iOS app out of the box. This isn't surprising; Apple wants you to use things like Apple Maps rather than your own solution. Android is, by its nature, a more open platform, so I am not too surprised that it was easier to integrate our tile server into the Android app than the iOS app. Sadly, it's not as simple as just switching over to OSM-based tiles; on the contrary, it's a significant amount of work.
Now, using our tile service would also have required the iOS app to use the MapBox SDK. This is the size of all their other third party libraries combined, significantly increasing app download size. The size of your app can significantly reduce downloads [1]. Switch a single feature over to a different set of map tiles, and possibly decreasing downloads of the app, seems like a dangerous and counterintuitive tradeoff to me.
So the question is, given all this, is switching over the nearby feature to use OSM-based tiles instead of Apple Maps worth it? In the long run, if these problems could be solved, I'd say it absolutely is worth it. But, in the short term, the work would take significant time and effort, and could actually decrease app usage by decreasing the app download rate; that tradeoff doesn't seem worth it to me.
Thanks, Dan
Disclaimers: These are my opinions only. I worked on the apps in the past, but haven't for two years; my statements about development costs may be wrong, and the apps folks may well disagree with me about things. I work in the department responsible for Wikimedia maps, but have only worked on the team working on maps for a couple of months.
On 15 March 2017 at 09:25, Magnus Manske magnusmanske@googlemail.com wrote:
Hi Josh, all,
I am not one hell-bent on "FOSS or death"; I tend to use whatever works best.
That said, the cost-benefit analysis of using Apple Maps seems to boil down:
- Apple Maps has slightly better rendering (didn't check, but I assume)
- Apple Maps uses less mobile bandwidth
- Apple Maps is not free (as in freedom)
Now, looking at these points:
- Somewhat better quality is not an argument. If it were, we would have
stayed with Britannica, and skipped that whole Wikipedia nonsense. Wikipedia became better, in part, because people actually used it, saw
the
issues, and fixed them. And OSM rendering might be not quite en par with Apple Maps, it is quite usable, in my experience.
- Less bandwidth usage is not an argument either. I doubt we are talking
about a significant percentage of an average users' data volume here. If Android users can afford the bandwidth, so can people who buy an iPhone (source: used to have iPhone).
- The price tag is the "non-freedom". As far as I can tell, this would be
the very first Wikimedia "product" that incorporates non-free technology and data. It sets a precedence. It also has the potential to poison the otherwise great relations between the Wikipedia, Wikidata, and OSM community. It says "OSM is not good enough (at least for Apple users)" quite plainly. How would we feel if OSM started to remove Wikidata tags
and
replace them with Britannica links?
All in all, IMHO, the cost is too high for the (at best) flimsy benefits.
Cheers, Magnus
On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor jminor@wikimedia.org wrote:
Hello,
My name is Josh Minor, and I am the Product Manager for the Wikipedia
iOS
app. I wanted to speak to a couple specific issues and
misunderstandings
raised by this email thread.
First, please take a look at https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
which
provides some background on this decision. Jonatan linked to it, and it covers several of the concerns raised on the thread and gives our reasoning. I'd also suggest subscribing to this ticket: https://phabricator.wikimedia.org/T157763 which Jonatan filed, and
where
you can track efforts and issues with replacement maps.
A few clarifying points:
- The Places tab[1], and its use of Apple’s maps tiles, is not part of
the
articles or article display, it is a navigational aid to help you find articles. This doesn’t mean it’s exempt from considerations raised
here,
but just want to clarify that this is not about editor created maps in projects, but rather an app-specific discovery mechanism.
- The feature doesn’t violate our privacy policy[2] and was reviewed
by
Wikimedia Foundation's Legal department before entering beta. The App’s access to the users’ geolocation to recommend nearby articles, with the users’ explicit consent, is already part of both apps. The new feature merely adds a different way to visually view nearby articles - the user must, as before, still provide explicit consent for the App to access
their
geolocation. Users can always turn on or off the provision of their geolocation via their iPhone location settings.
The feature also makes requests to Apple’s map tile servers for display
on
the App. These tiles may or may not be near the actual location of the user. It doesn’t involve sending Apple the articles you read or
anything
about your Wikipedia usage. Apple has public statements and
documentation
to explain[3] how their maps service preserves privacy by using a randomized and frequently changing device ID to request the maps, by
not
tracking users over time, and by not building map usage profiles of
users.
Overall, Apple’s data collection practices are governed by their
privacy
policy [4], which users must agree to order to use their iPhones.
We plan to further expand the explanation in the FAQ/privacy section of
the
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
page
in the next day or so.
- As stated by others on this thread, the issue at hand is the
feasibility
and usability of a libre maps tile server, and impacts on users and how
it
reflects (or doesn’t) the values of Wikimedians. The rest of the work
on
this feature (such as the time spent on search, visually clustering
items
on the map, a list view of nearby landmarks, and the Wikipedia article pins) will be applicable, independent of the map provider. In fact, I’d estimate the engineer doing the work spent more time on hacking to try
to
make a combination of MapBox and Wikimedia tiles work, than he did/will
on
integrating/removing Apple maps.
- This feature was announced on the Wikimedia Blog[5], described in an
initial MediaWiki.org page[6], all work was documented and tracked on Phabricator (including an initial tech investigation, the request to
remove
Apple Maps during development, and the overall feature[7]) and then the decision to push into beta with Apple Maps further documented on MediaWiki.org[8].
In conclusion, I would like to thank you for the feedback and the opportunity to engage in a civil discussion about these important
issues.
Again, if you are interested in the next steps, I’d invite you to
subscribe
and comment on the phab ticket https://phabricator.wikimedia.
org/T157763
or the MediaWiki.org page.
[1] Design specification: https://phabricator.wikimedia.org/T130889 [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/
Maps_service#Privacy
[3] https://support.apple.com/en-us/HT203033, https://support.apple.com/en-us/HT207056, http://www.apple.com/privacy/approach-to-privacy/ [4] http://www.apple.com/privacy/privacy-policy/ [5] https://blog.wikimedia.org/2016/06/17/wikipedia-mobile/ [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Nearby [7] https://phabricator.wikimedia.org/tag/ios-app-feature-places/ [8] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/
Maps_service
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 21 March 2017 at 14:34, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Technical considerations are imho less relevant. What trumps it is functionality.
Technical considerations are very relevant if one is doing something technical, for example developing an iOS app or a maps tile service.
Our maps have to be good everywhere and as far as I know OSM is superior in places where there is profit to be made from maps.
If you choose to ignore the technical difficulties and half of my earlier email, then yes, that may be true.
Current maps world wide and historical maps are what we need. How would you use the Apple maps for a map of the Ottoman empire?
Given that our maps service does not support this, and will not any time soon, this is very off-topic.
Dan
As a programmer myself I understand that free vs non-free causes more work for you. However you cannot ignore one of the foundations of the wikimedia movement because it makes a little more work for you. I honestly don't understand why you thought that Apple maps would be acceptable at all. You have both a breach of our privacy policy and a violation of our free software enforcement policy. Yes using OSM adds work and increases the download size, but is a valid option. If OSM or other free software wasn't possible then we might consider non-free alternatives but that's not the case.
On Tue, Mar 21, 2017 at 12:18 PM Dan Garry dgarry@wikimedia.org wrote:
On 21 March 2017 at 14:34, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Technical considerations are imho less relevant. What trumps it is functionality.
Technical considerations are very relevant if one is doing something technical, for example developing an iOS app or a maps tile service.
Our maps have to be good everywhere and as far as I know OSM is superior in places where there is profit to be made from maps.
If you choose to ignore the technical difficulties and half of my earlier email, then yes, that may be true.
Current maps world wide and historical maps are what we need. How would
you
use the Apple maps for a map of the Ottoman empire?
Given that our maps service does not support this, and will not any time soon, this is very off-topic.
Dan
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hoi, Apple maps do not provide the same maps (not as up to date) as OSM does for a country like Haiti. That has nothing to do with "ignoring technical difficulties" but has everything to do with the quality of the service provided.
When you consider that work IS done on historic maps in an OSM context it is again you ignoring functionality that you do no offer. The excuse that "it is not on the cards" is one from your perspective; one where functional expectations apparently do not have value. Thanks, GerardM
On 21 March 2017 at 17:17, Dan Garry dgarry@wikimedia.org wrote:
On 21 March 2017 at 14:34, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Technical considerations are imho less relevant. What trumps it is functionality.
Technical considerations are very relevant if one is doing something technical, for example developing an iOS app or a maps tile service.
Our maps have to be good everywhere and as far as I know OSM is superior in places where there is profit to be made from maps.
If you choose to ignore the technical difficulties and half of my earlier email, then yes, that may be true.
Current maps world wide and historical maps are what we need. How would
you
use the Apple maps for a map of the Ottoman empire?
Given that our maps service does not support this, and will not any time soon, this is very off-topic.
Dan
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
2017-03-21 18:17 GMT+02:00 Dan Garry dgarry@wikimedia.org:
On 21 March 2017 at 14:34, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Technical considerations are imho less relevant. What trumps it is functionality.
Technical considerations are very relevant if one is doing something technical, for example developing an iOS app or a maps tile service.
I wholeheartedly disagree. OSS projects often forget that the customer should come first, mostly because of lack of funding. But since WMF's software development is a secondary activity (and a very well funded one IMO), it should not make the same mistake. Spreading free knowledge must come first, technical considerations second.
Strainu
On 21 March 2017 at 18:02, Strainu strainu10@gmail.com wrote:
2017-03-21 18:17 GMT+02:00 Dan Garry dgarry@wikimedia.org:
On 21 March 2017 at 14:34, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Technical considerations are imho less relevant. What trumps it is functionality.
Technical considerations are very relevant if one is doing something technical, for example developing an iOS app or a maps tile service.
I wholeheartedly disagree. OSS projects often forget that the customer should come first, mostly because of lack of funding. But since WMF's software development is a secondary activity (and a very well funded one IMO), it should not make the same mistake. Spreading free knowledge must come first, technical considerations second.
Please do not twist my words. I said technical considerations are relevant, not that customer needs do not come first. If something is incredibly difficult to do, that is factored in to prioritisation, alongside the size of the audience and expected impact. That is very basic product management.
Sadly, as is typical with this mailing list, we've now delved into a world of hypotheticals, idealisms, and misrepresentations. It would not be a productive use of time (and, indeed, donor money) for me to participate further in this thread.
Dan
On Tue, Mar 21, 2017 at 11:24 AM, Dan Garry dgarry@wikimedia.org wrote:
Sadly, as is typical with this mailing list, we've now delved into a world of hypotheticals, idealisms, and misrepresentations. It would not be a productive use of time (and, indeed, donor money) for me to participate further in this thread.
Without manually labeling all the comments made on this thread and by quickly going over it again: What I see is that most of the comments on this thread are not hypothetical. They are idealistic, but that's the nature of the work we do (Building Wikimedia projects is idealistic at its core.). If one conversation doesn't go where you want it to go, please don't give up on the whole thread. There are many good points raised across this thread. What's being discussed here is very important.
And of course, I respect how you want to spend your staff time and what you think is the best use of your time. :)
Best, Leila
Dan
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
În 21 martie 2017 20:24:49 EET, Dan Garry dgarry@wikimedia.org a scris:
On 21 March 2017 at 18:02, Strainu strainu10@gmail.com wrote:
2017-03-21 18:17 GMT+02:00 Dan Garry dgarry@wikimedia.org:
On 21 March 2017 at 14:34, Gerard Meijssen
wrote:
Technical considerations are imho less relevant. What trumps it is functionality.
Technical considerations are very relevant if one is doing
something
technical, for example developing an iOS app or a maps tile
service.
I wholeheartedly disagree. OSS projects often forget that the
customer
should come first, mostly because of lack of funding. But since WMF's software development is a secondary activity (and a very well funded one IMO), it should not make the same mistake. Spreading free knowledge must come first, technical considerations second.
Please do not twist my words.
I don't see how is that twisting your words. Gerard said that technical considerations should be secondary to functionality and you implied that was not possible without explaining why.
I said technical considerations are relevant, not that customer needs do not come first. If something is incredibly difficult to do, that is factored in to prioritisation, alongside the size of the audience and expected impact. That is very basic product management.
The wording in the wiki page does not suggest an "incredibly difficult" technological issue, but more of a political issue (WMF's mapping efforts are in maintenance) and the possibility of minor extra costs for the users (with the possibility of improvement over Apple maps clearly listed). That makes this list the best place to discuss such issues due to the large and diverse audience.
Strainu
Sadly, as is typical with this mailing list, we've now delved into a world of hypotheticals, idealisms, and misrepresentations. It would not be a productive use of time (and, indeed, donor money) for me to participate further in this thread.
Dan
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Dan,
On Tue, Mar 21, 2017 at 6:24 PM, you wrote:
Please do not twist my words. I said technical considerations are relevant, not that customer needs do not come first. If something is incredibly difficult to do, that is factored in to prioritisation, alongside the size of the audience and expected impact. That is very basic product management.
Sadly, as is typical with this mailing list, we've now delved into a world of hypotheticals, idealisms, and misrepresentations. It would not be a productive use of time (and, indeed, donor money) for me to participate further in this thread.
That is unfortunate. I had been hoping to hear an answer to the very concrete question of why this issue is being raised with the community only after so much work has been done, rather than before. I would have thought that very basic product management would have involved engaging with the user community at the planning stage, and determining the customer needs of which you write. Indeed, I raised that point here ten days ago. But it seems that it will have to go unanswered.
"Rogol"
Hoi, Today it is announced that for maps in Commons, maps that are known in Wikidata we have now support for "geoshapes". Dan, you indicated nine days agao that this is not on your road map. But it is there. Could you please inform us how this can be used in Apple maps? Thanks, GerardM
https://lists.wikimedia.org/pipermail/wikidata-tech/2017-March/001106.html
On 21 March 2017 at 17:17, Dan Garry dgarry@wikimedia.org wrote:
On 21 March 2017 at 14:34, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Technical considerations are imho less relevant. What trumps it is functionality.
Technical considerations are very relevant if one is doing something technical, for example developing an iOS app or a maps tile service.
Our maps have to be good everywhere and as far as I know OSM is superior in places where there is profit to be made from maps.
If you choose to ignore the technical difficulties and half of my earlier email, then yes, that may be true.
Current maps world wide and historical maps are what we need. How would
you
use the Apple maps for a map of the Ottoman empire?
Given that our maps service does not support this, and will not any time soon, this is very off-topic.
Dan
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Mar 21, 2017 at 7:22 AM, Dan Garry dgarry@wikimedia.org wrote:
The size of your app can significantly reduce downloads [1]. [1]: https://segment.com/blog/mobile-app-size-effect-on-downloads/
That article seems super sketchy. They took a 3MB app, increased it to 100MB+, and interpolated the retention changes linearly. They even point out that the drop in installs was mostly due to negative reviews (since they reverted the app size and the installs didn't climb back up) and the reviews were mostly along the line of "WTF is this simple calculator app a hundred megabytes?".
The Wikipedia app is 39MB and the SDK seems to add one MB per [2] which does not sound like a big deal.
Agreed, the reference does not look reliable for the claim made. Cheers, Peter
-----Original Message----- From: Wikimedia-l [mailto:wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of Gergo Tisza Sent: Wednesday, 22 March 2017 5:54 AM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)
On Tue, Mar 21, 2017 at 7:22 AM, Dan Garry dgarry@wikimedia.org wrote:
The size of your app can significantly reduce downloads [1]. [1]: https://segment.com/blog/mobile-app-size-effect-on-downloads/
That article seems super sketchy. They took a 3MB app, increased it to 100MB+, and interpolated the retention changes linearly. They even point out that the drop in installs was mostly due to negative reviews (since they reverted the app size and the installs didn't climb back up) and the reviews were mostly along the line of "WTF is this simple calculator app a hundred megabytes?".
The Wikipedia app is 39MB and the SDK seems to add one MB per [2] which does not sound like a big deal.
[2] https://www.mapbox.com/blog/mapbox-mobile-polylines/ _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.8007 / Virus Database: 4767/14161 - Release Date: 03/21/17
wikimedia-l@lists.wikimedia.org