Over on the mobile team we've been chatting for a while about the various trade-offs in native vs HTML-based (PhoneGap/Cordova) development.
Currently our main Wikipedia apps are all HTML-based: * Android - HTML + Cordova + plugins * iOS - HTML + Cordova + plugins * BlackBerry PlayBook (and later BB 10) - HTML + WebWorks * Firefox OS - HTML * Windows 8 - HTML + WinRT (mostly separate UI code)
We also used Cordova and HTML for the Wiki Loves Monuments app. While it worked and was good for quick prototyping, we've run into a number of problems doing HTML-based development in both apps:
* performance -- especially when combining large scrolling text areas with static controls * compatibility -- making something that worked on Android 2.x and 4+, and on iOS 4.x and 5+, is sometimes.... fun. Since we're stuck running in the native web view control on each platform, we're stuck with old bugs and sometimes have to make huge workarounds. * platform limitations -- for WLM we had to modify the Cordova platform so we could do a progress bar on upload. Ouch! * platform integration -- to use system sharing features and other things well we often need plugins for Cordova, which means either relying on third-party code (which may not be as well maintained as Cordova core) or writing our own (and keeping them up to date as Cordova evolves). Either way we have to fiddle with native code to handle things like saved pages already, so we're not playing pure HTML+JS. * crash reports are often useless, not giving us JavaScript stack traces
For instance we recently ran into a problem where HTTPS stopped working in release builds on Android 2.2... we got no backtraces from the system, just knew that *something* somewhere in the WebView's infrastructure stopped working. It was.... not fun to track down. If we'd been doing the page loads in native Java, we probably would have gotten stack traces automatically.
We've started a couple experimental projects as fully-native Android apps: a Signpost app that uses native notifications to alert you to new issues, and a Commons uploader which lets you take photos or videos and upload them direct to Commons.
Going native on these means: * good access to notifications, multimedia, etc * faster startup times * native use of Android accounts management system when doing editing features * more native look & feel * no damn tricks for scrolling areas :P * crash reports are more likely to point at something relevant
So we've been thinking about splitting up the HTML-based Wikipedia app as well. There'll still be a big WebView in the middle of the app -- it shows web content after all! -- but most of the UI chrome, retrieval of data, and all the system integration will go into the native-side code.
Essentially we may reorg to: * HTML core for the WebView -- handle section collapsing, references, table collapse/expand, etc. Probably share much of this code with MobileFrontend. * native iOS UI (Obj-C) * native Android UI (Java) * separate HTML UI for Firefox OS, BlackBerry PlayBook & BB 10 * separate HTML UI for Windows 8/RT
Firefox OS, BlackBerry 10, and Windows 8 all give us fairly good system integration within the HTML+JS environment so we probably won't have to do truly 'native' code on these, which is good since we'll have less time to devote to them.
iOS and Android remain our top-tier mobile platforms, and we know we can do better on them than we do so far...
Any thoughts? Wildly in favor or against?
-- brion
Brion Vibber wrote:
Over on the mobile team we've been chatting for a while about the various trade-offs in native vs HTML-based (PhoneGap/Cordova) development.
[...]
iOS and Android remain our top-tier mobile platforms, and we know we can do better on them than we do so far...
Any thoughts? Wildly in favor or against?
It's unclear from your e-mail what the goal of mobile interaction (for lack of a better term) is. Are you trying to build editing features? File upload features? Or do you want to just have a decent reader? This seems like a key component to any discussion of the future of mobile development.
Looking at the big picture, I don't think we'll ever see widespread editing from mobile devices. The user experience is simply too awful. The best I think most people are hoping for is the ability to easily fix a typo, maybe, but even then you have to assess costs vs. benefit. That is, is it really worth paying two or three full-time employees so that someone can easily change "Barrack" to "Barack" from his or her iPhone? Probably not.
Perhaps mobile uploading could use better native support, but again, is the cost worth it? Does Commons need more low-quality photos? And even as phone cameras get better, do those photos need to be _instantly_ uploaded to the site? There's something to be said for waiting until you get home to upload photos, especially given how cumbersome the photo upload process is (copyright, permissions, categorization, etc.). And this all side-steps the question of whether there are better organizations equipped at handling photos (such as Flickr or whatever).
That leaves reading. If a relatively recent browser can't read Wikimedia wikis without performance issues, I think that indicates a problem with Wikimedia wikis (way too much JavaScript, images are too large, etc.). Mobile browsers are fairly robust (vastly more robust compared to what they used to be), so I'm not sure why having a Wikipedia reader is valuable or why it's worth investing finite resources in. Occasionally I'll hear "but I want to have a favorite pages feature or I want to support offline reading," but the phone's OS should be able to handle most of this from the built-in Web browser. Or not, but I think if a phone is incapable of a feature such as "e-mail this Web page (article) to a friend," it's not an important enough feature to devote resources to.
Wikimedia wikis have a lot of bugs and the Wikimedia Foundation has finite resources. I personally only use the "Messages" and "Music" apps on my phone, so I'm not the best person to make the argument for additional mobile development, but when I look at how terrible the user experience continues to be for desktop users, it becomes difficult for me to understand why the Wikimedia Foundation would delve into the world of mobile (apart from initiatives such as Wikipedia Zero). What benefit to the creation or dissemination of free educational content are we seeing (or hoping to see) from native apps?
MZMcBride
On 12 December 2012 00:04, MZMcBride z@mzmcbride.com wrote:
Looking at the big picture, I don't think we'll ever see widespread editing from mobile devices. The user experience is simply too awful. The best I think most people are hoping for is the ability to easily fix a typo, maybe, but even then you have to assess costs vs. benefit. That is, is it really worth paying two or three full-time employees so that someone can easily change "Barrack" to "Barack" from his or her iPhone? Probably not.
OTOH, see recent coverage of Wikipedia in Africa, where it's basically going to be on phones. Cheap shitty smartphones. That the kids are *desperate* to get Wikipedia on. Do we want to make those readers into editors? It'd be nice.
Perhaps mobile uploading could use better native support, but again, is the cost worth it? Does Commons need more low-quality photos? And even as phone cameras get better, do those photos need to be _instantly_ uploaded to the site? There's something to be said for waiting until you get home to upload photos, especially given how cumbersome the photo upload process is (copyright, permissions, categorization, etc.). And this all side-steps the question of whether there are better organizations equipped at handling photos (such as Flickr or whatever).
This is a version of the general argument against participation. There are reasons it's not favoured.
- d.
On 12/12/12 01:04, MZMcBride wrote:
Looking at the big picture, I don't think we'll ever see widespread editing from mobile devices. The user experience is simply too awful. The best I think most people are hoping for is the ability to easily fix a typo, maybe, but even then you have to assess costs vs. benefit. That is, is it really worth paying two or three full-time employees so that someone can easily change "Barrack" to "Barack" from his or her iPhone? Probably not.
Then maybe the only feature needed by the mobile apps is a "highlight article content" and "email me a bookmark to this when I'm on desktop".
David Gerard wrote:
OTOH, see recent coverage of Wikipedia in Africa, where it's basically going to be on phones. Cheap shitty smartphones. That the kids are *desperate* to get Wikipedia on. Do we want to make those readers into editors? It'd be nice.
Have a link? 'Cheap smartphone' seems a contradiction.
I think there is a field for mobiles and one for desktop. You could do one tasks from the other? Probably, but not as well as if you used the right tool*. The proper optimization should be done, it's ok to make things *possible*, but trying to force everything to work one way (eg. Windows 8) is the wrong path imho.
* Note that there are valid cases in which you have to use a suboptimal tool.
On 12 December 2012 00:22, Platonides Platonides@gmail.com wrote:
David Gerard wrote:
OTOH, see recent coverage of Wikipedia in Africa, where it's basically going to be on phones. Cheap shitty smartphones. That the kids are *desperate* to get Wikipedia on. Do we want to make those readers into editors? It'd be nice.
Have a link? 'Cheap smartphone' seems a contradiction.
$50 Huawei phones running an ancient Android and only getting cheaper. Jimbo's all about them. http://techcrunch.com/2012/12/10/50-android-smartphones-are-disrupting-afric...
I think there is a field for mobiles and one for desktop. You could do one tasks from the other? Probably, but not as well as if you used the right tool*.
You're assuming from the position of someone who can assume a general-purpose computer with a good Internet connection.
- d.
Have a link? 'Cheap smartphone' seems a contradiction.
$50 Huawei phones running an ancient Android and only getting cheaper. Jimbo's all about them.
http://techcrunch.com/2012/12/10/50-android-smartphones-are-disrupting-afric...
This is a big deal at Mozilla also: http://arstechnica.com/information-technology/2012/07/mozillas-b2g-to-be-cal...
Platonides wrote:
On 12/12/12 01:04, MZMcBride wrote:
Looking at the big picture, I don't think we'll ever see widespread editing from mobile devices. The user experience is simply too awful. The best I think most people are hoping for is the ability to easily fix a typo, maybe, but even then you have to assess costs vs. benefit. That is, is it really worth paying two or three full-time employees so that someone can easily change "Barrack" to "Barack" from his or her iPhone? Probably not.
Then maybe the only feature needed by the mobile apps is a "highlight article content" and "email me a bookmark to this when I'm on desktop".
Maybe. But if you have an entire mobile team, they're going to quickly run out of things to do.
David Gerard wrote:
OTOH, see recent coverage of Wikipedia in Africa, where it's basically going to be on phones. Cheap shitty smartphones. That the kids are *desperate* to get Wikipedia on. Do we want to make those readers into editors? It'd be nice.
Sure, it's difficult to argue against turning readers into editors. I'm asking if the described mobile-related efforts (i.e., going native) will get us any closer to our broader goals (creating and disseminating free educational content). And if so, how?
As I hinted in my previous post, I make a distinction between mobile app/site development work and initiatives such as Wikipedia Zero (which is probably what the kids in Africa are reading Wikipedia via). I think it makes sense to focus effort and energy on making Wikimedia wikis (not just Wikipedia!) available in more places. I'm not sure it makes a lot of sense to support editing and other interaction components on mobile devices. But, again, there's a lot of vagueness and ambiguity in this discussion, particularly with regard to what the _goals_ of mobile interaction actually are. Without having defined, measurable goals, it's almost impossible to make an informed decision here, in my opinion.
David Gerard wrote:
MZMcBride wrote:
Perhaps mobile uploading could use better native support, but again, is the cost worth it? Does Commons need more low-quality photos? And even as phone cameras get better, do those photos need to be _instantly_ uploaded to the site? There's something to be said for waiting until you get home to upload photos, especially given how cumbersome the photo upload process is (copyright, permissions, categorization, etc.). And this all side-steps the question of whether there are better organizations equipped at handling photos (such as Flickr or whatever).
This is a version of the general argument against participation. There are reasons it's not favoured.
Oh come on now, that's not really fair. I'm not arguing against participation, I'm arguing against shitty photos. I was almost completely uninvolved, but I seem to remember much ado earlier this year about Wiki Loves Monuments and mobile support (it even had its own mobile app, I guess?). But looking at all of the WLM winners (https://commons.wikimedia.org/wiki/Wiki_Loves_Monuments_2012_winners), were any of them taken on mobile devices? A quick sampling seems to suggest that all of the good photos came from Nikon or Sony cameras. That isn't to say that mobile uploads ("muploads") aren't ever going to be valuable to Wikimedia wikis, but it does raise the legitimate question of whether it's a good use of finite resources to support such projects. What is the value?
MZMcBride
On Tue, 11 Dec 2012 16:57:26 -0800, MZMcBride z@mzmcbride.com wrote:
David Gerard wrote:
MZMcBride wrote:
Perhaps mobile uploading could use better native support, but again, is the cost worth it? Does Commons need more low-quality photos? And even as phone cameras get better, do those photos need to be _instantly_ uploaded to the site? There's something to be said for waiting until you get home to upload photos, especially given how cumbersome the photo upload process is (copyright, permissions, categorization, etc.). And this all side-steps the question of whether there are better organizations equipped at handling photos (such as Flickr or whatever).
This is a version of the general argument against participation. There are reasons it's not favoured.
Oh come on now, that's not really fair. I'm not arguing against participation, I'm arguing against shitty photos. I was almost completely uninvolved, but I seem to remember much ado earlier this year about Wiki Loves Monuments and mobile support (it even had its own mobile app, I guess?). But looking at all of the WLM winners (https://commons.wikimedia.org/wiki/Wiki_Loves_Monuments_2012_winners), were any of them taken on mobile devices? A quick sampling seems to suggest that all of the good photos came from Nikon or Sony cameras. That isn't to say that mobile uploads ("muploads") aren't ever going to be valuable to Wikimedia wikis, but it does raise the legitimate question of whether it's a good use of finite resources to support such projects. What is the value? MZMcBride
Sorry but that smells like a red herring. First of all given a photography contest of course pro quality photos with pro cameras are going to dominate the list of winners. The winners of WLM are irrelevant to the topic of improving the quality and coverage of photos when ALL of the photos taken for WLM are available for use. A photo doesn't need to win WLM to be valuable to us.
More importantly while quality is nice, that's not what's really important. More important than quality is coverage. Getting photos of those things that we don't have photos for. That is where mobile devices will always be superior than said Nikon or Sony cameras. Images of things taken spur of the moment no-one has taken an image of yet. Especially in remote areas, sudden events, etc...
On 13 December 2012 10:44, Daniel Friesen daniel@nadir-seen-fire.com wrote:
More importantly while quality is nice, that's not what's really important. More important than quality is coverage. Getting photos of those things that we don't have photos for. That is where mobile devices will always be superior than said Nikon or Sony cameras. Images of things taken spur of the moment no-one has taken an image of yet. Especially in remote areas, sudden events, etc...
Every article on a place needs a video, for example. (That's why we need to be able to ingest absolutely any rubbish a phone can produce and upload.)
- d.
Small (native) apps can do Wikimedia work quite effectively using the api
Upload image File categorisation New page patrol Flagged revs/Pending changes OTRS
John Vandenberg. sent from Galaxy Note On Dec 12, 2012 7:04 AM, "MZMcBride" z@mzmcbride.com wrote:
Brion Vibber wrote:
Over on the mobile team we've been chatting for a while about the various trade-offs in native vs HTML-based (PhoneGap/Cordova) development.
[...]
iOS and Android remain our top-tier mobile platforms, and we know we can
do
better on them than we do so far...
Any thoughts? Wildly in favor or against?
It's unclear from your e-mail what the goal of mobile interaction (for lack of a better term) is. Are you trying to build editing features? File upload features? Or do you want to just have a decent reader? This seems like a key component to any discussion of the future of mobile development.
Looking at the big picture, I don't think we'll ever see widespread editing from mobile devices. The user experience is simply too awful. The best I think most people are hoping for is the ability to easily fix a typo, maybe, but even then you have to assess costs vs. benefit. That is, is it really worth paying two or three full-time employees so that someone can easily change "Barrack" to "Barack" from his or her iPhone? Probably not.
Perhaps mobile uploading could use better native support, but again, is the cost worth it? Does Commons need more low-quality photos? And even as phone cameras get better, do those photos need to be _instantly_ uploaded to the site? There's something to be said for waiting until you get home to upload photos, especially given how cumbersome the photo upload process is (copyright, permissions, categorization, etc.). And this all side-steps the question of whether there are better organizations equipped at handling photos (such as Flickr or whatever).
That leaves reading. If a relatively recent browser can't read Wikimedia wikis without performance issues, I think that indicates a problem with Wikimedia wikis (way too much JavaScript, images are too large, etc.). Mobile browsers are fairly robust (vastly more robust compared to what they used to be), so I'm not sure why having a Wikipedia reader is valuable or why it's worth investing finite resources in. Occasionally I'll hear "but I want to have a favorite pages feature or I want to support offline reading," but the phone's OS should be able to handle most of this from the built-in Web browser. Or not, but I think if a phone is incapable of a feature such as "e-mail this Web page (article) to a friend," it's not an important enough feature to devote resources to.
Wikimedia wikis have a lot of bugs and the Wikimedia Foundation has finite resources. I personally only use the "Messages" and "Music" apps on my phone, so I'm not the best person to make the argument for additional mobile development, but when I look at how terrible the user experience continues to be for desktop users, it becomes difficult for me to understand why the Wikimedia Foundation would delve into the world of mobile (apart from initiatives such as Wikipedia Zero). What benefit to the creation or dissemination of free educational content are we seeing (or hoping to see) from native apps?
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
John Vandenberg wrote:
Small (native) apps can do Wikimedia work quite effectively using the api
Upload image File categorisation New page patrol Flagged revs/Pending changes OTRS
I think I fundamentally agree with your point, but when I consider that there is (for example) no API for adding or removing a category from a page (file or otherwise), it seems like a much better investment of finite resources to create such an API and let others build mobile apps that use that API. Or fix other long-standing categorization issues such as the ability to move/rename categories (https://bugzilla.wikimedia.org/3311). The lack of infinite developer resources really can't be overlooked or overstated here, in my view.
MZMcBride
We've gone a bit off topic into the question of whether we should spend any time on mobile at all, it seems. :)
On Dec 11, 2012 5:11 PM, "MZMcBride" z@mzmcbride.com wrote:
I think I fundamentally agree with your point, but when I consider that there is (for example) no API for adding or removing a category from a
page
(file or otherwise), it seems like a much better investment of finite resources to create such an API and let others build mobile apps that use that API.
Where are these others who will build the apps for us? I'd like to hire them.
Or fix other long-standing categorization issues such as the ability to move/rename categories (https://bugzilla.wikimedia.org/3311). The lack of infinite developer resources really can't be overlooked or overstated here, in my view.
Finite developer resources exist in other areas than API development. I'll be honest; I think a good mobile app will pull in more users and do more good than just making a few API tweaks and hoping something happens.
Note also that the mobile dept is making API improvements as we go along... these things are not exclusive. Rather, our needs drive the API development we do.
One in progress is the GeoData extension which is now collecting coordinates on en.wikipedia.org and once the search back end is deployed will make location-based search a first class citizen instead of relying on tool server hacks and third party services.
-- brion
Brion Vibber wrote:
We've gone a bit off topic into the question of whether we should spend any time on mobile at all, it seems. :)
Well, I think that's expected when the question was (broadly) where do we go from here? I think native or non-native support is a false dichotomy: there's a broader question of what we want the mobile experience to be. I don't think the answer to this question really exists currently.
Finite developer resources exist in other areas than API development. I'll be honest; I think a good mobile app will pull in more users and do more good than just making a few API tweaks and hoping something happens.
Fair enough. But I really would strongly urge you (and/or the mobile team) to better define what the goals are for mobile interaction, maybe in an RFC. What do you want people to be able to do from mobile devices? What's realistic now? What's realistic in five years from now? What's realistic on 4G and what's realistic on whatever slow connection users have elsewhere?
One in progress is the GeoData extension which is now collecting coordinates on en.wikipedia.org and once the search back end is deployed will make location-based search a first class citizen instead of relying on tool server hacks and third party services.
Hmmm, I actually see this as more of a counter-example: Max was able to devote some time to creating a GeoData extension that has broad applicable use to Wikimedia wikis and to the free content movement. Just imagine what he could be doing if he weren't battling (for example) the article editing interface on a Samsung Nexus. I see your point about mobile development feeding APIs and vice versa, I'm just not sure where the value comes from the _Wikimedia Foundation_ working on mobile development instead of devoting more energy and resources to tools exactly like the GeoData extension.
MZMcBride
On Tue, Dec 11, 2012 at 8:11 PM, MZMcBride z@mzmcbride.com wrote:
I think I fundamentally agree with your point, but when I consider that there is (for example) no API for adding or removing a category from a page (file or otherwise),
Sure there is, action=edit. Although the client does need to do some minimal manipulation of the wikitext.
Στις 11-12-2012, ημέρα Τρι, και ώρα 19:04 -0500, ο/η MZMcBride έγραψε:
Brion Vibber wrote:
Over on the mobile team we've been chatting for a while about the various trade-offs in native vs HTML-based (PhoneGap/Cordova) development.
[...]
iOS and Android remain our top-tier mobile platforms, and we know we can do better on them than we do so far...
Any thoughts? Wildly in favor or against?
<snip>
Looking at the big picture, I don't think we'll ever see widespread editing from mobile devices. The user experience is simply too awful. The best I think most people are hoping for is the ability to easily fix a typo, maybe, but even then you have to assess costs vs. benefit. That is, is it really worth paying two or three full-time employees so that someone can easily change "Barrack" to "Barack" from his or her iPhone? Probably not.
Actually I think this one of the very things we really want to target. How many readers become editors after sitting down and writing a full article with references from scratch? How many make a small change, fix a typo or a date or a grammatical error, tweak a sentence or two? Making this work well on mobile devices seems to me like time and resources well spent; I'm less convinced that folks need to be able to add complex infoboxes but that discussion can be put off until more modest goals are achieved. By then the landscape will have shifted again and we can re-evaluate.
I don't know if that is best achieved via a native platform or not. There were a couple of previous projects that were all about making small edits (e.g. [1]). How well can such an approach be adapted for mobile use?
Ariel
On Tue, Dec 11, 2012 at 4:35 PM, Brion Vibber bvibber@wikimedia.org wrote:
Any thoughts? Wildly in favor or against?
From Brion's original email as well as my perspective from being involved
in these projects, I am in favor of shifting to native code for iOS and Android. Considering the goals of the mobile team for 2012/2013 [1] include building contributory features (beyond basic editing and even beyond just uploading photos [and while certainly some mobile devices have terrible cameras, many have exceptional cameras]), the fact that we've been thinking about contributory pipelines that involve multiple devices, and the fact that we've had headaches building contributory features using Cordova, shifting to a native codebase for the most used mobile platforms makes a LOT of sense.
One argument that could be made against shifting to a native codebase for the android/iOS apps is that of accessibility to our engineering community. The great thing about Cordova is the fact that 99% of what you need to know to dive in is HTML and JS. However, we do have Java devs and Objective C devs in the community - and creating more things in those language could also help attract other engineers who like to focus on that kind of stuff into our community. Overall, I think the benefits far outweigh the potential drawbacks.
[1] http://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals#Mobile
wikitech-l@lists.wikimedia.org