Hi.
I've been having difficulty wrapping my head around Wikimedia's (relatively) recent efforts in mobile application development. I understand that reaching users on mobile platforms is important to the Wikimedia Foundation and I've read https://meta.wikimedia.org/wiki/Mobile_Projects/strategy and related pages.
Mobile seems to have two branches these days: (1) the mobile versions of the sites; and more recently (2) specific mobile applications. Branch 1 is fairly understandable. What I'm having difficulty understanding is branch 2.
The idea behind free and open content is that the content can be taken and reused and redistributed by others without issue. That's part of the great beauty of Wikimedia wikis. With a vibrant app market for both Androids and iPhones, why is Wikimedia getting involved in mobile application development? Isn't this something best left to third parties (which, as I understand it, have already filled the "Wikipedia app" niche with a variety of options for both platforms) or interested volunteers?
MZMcBride
On Mon, Apr 9, 2012 at 9:37 PM, MZMcBride z@mzmcbride.com wrote:
Hi.
I've been having difficulty wrapping my head around Wikimedia's (relatively) recent efforts in mobile application development. I understand that reaching users on mobile platforms is important to the Wikimedia Foundation and I've read https://meta.wikimedia.org/wiki/Mobile_Projects/strategy and related pages.
Great to see these pages getting used
Mobile seems to have two branches these days: (1) the mobile versions of the sites; and more recently (2) specific mobile applications. Branch 1 is fairly understandable. What I'm having difficulty understanding is branch 2.
While mobile has two branches, I wouldn't slice it that way. The way that we look at it is either
* Smart phone development - editing, image uploads, mobile web, apps, mobile frontend, etc * Alternate access methods - S40 (J2ME), SMS/USSD, & Zero
The idea behind free and open content is that the content can be taken and reused and redistributed by others without issue. That's part of the great beauty of Wikimedia wikis. With a vibrant app market for both Androids and iPhones, why is Wikimedia getting involved in mobile application development? Isn't this something best left to third parties (which, as I understand it, have already filled the "Wikipedia app" niche with a variety of options for both platforms) or interested volunteers?
No, its really not and we've heard from countless people that it wasn't working. There are a number of reasons that my team was asked to do mobile apps and i'll list some of them below
* Whenever we talk with carriers about partnering with us they want to see a suite of products they can provide on our behalf. These can range from a basic bookmarks on the mobile web, sms access, to a listing our app within their own markets. Any one thing missing ends the conversation pretty quickly. I suggest reading the original blog post from January http://bit.ly/IFoti4 to gain more insite. Kul & Amit can elaborate more on this.
* Were constantly getting asked about why "insert new Wikipedia app name" in "new app store" has ads, is not free, and in general doesn't provide a polished experience. Users are confused why the foundation would provide so many bad offerings in each of the apps stores because they associate most apps in the market with something that the foundation has done. I've had users approach me and ask why the foundation puts ads inside their apps and even after explaining that we have no affiliation they insist that its a poor reflection of our projects. No matter how we look at it ... were being judged on behalf of any app that is showing people data from Wikipedia. Rather then having to explain why there are so many bad ones we decided to provide a better solution then the rest to raise awareness that you a) dont have to see ads b) don't have to pay for basic features like saving pages and c) have control in the future direction of the project.
* It's a great way to eat our own dog food. Apps should always be decoupled and with the next release of both of our apps we'll have learned a ton about how our API's are deficient. By better understanding these use cases we've extended functionality for such things as loading articles into small chunks and our mobile web projects will soon be receiving the same benefits. Re-using code like this is key to making both our projects better and third party apps faster.
* People use them. No matter if your a fan of apps or not they've replaced the function of bookmarks for most mobile users. They provide a faster and easier way of accessing content and our stats are starting to show it. In just under a month of metrics we've already seen 20+ million page views from the official android app and growth is continuing.
* Code re-use. Whenever companies build native apps they have to create separate code bases. We chose not to do that. Through the use of PhoneGap were re-using more and more code with each release. It work bi-directionally and allows us move quickly without a significant investment on either end.
* Community outreach. We've run three hackathons that focused on mobile and nothing was as popular as working for Android. The barrier to entry for working on the mobile projects has been dropped significantly and now its one of the easiest Wikimedia projects to join. Since their decoupled and work with standard web tech ... its been really easy to get volunteers engaged and involved.
I could go on but i'll end here for now.
--tomasz
Thank you very much for the detailed and insightful reply.
Tomasz Finc wrote:
On Mon, Apr 9, 2012 at 9:37 PM, MZMcBride z@mzmcbride.com wrote:
Mobile seems to have two branches these days: (1) the mobile versions of the sites; and more recently (2) specific mobile applications. Branch 1 is fairly understandable. What I'm having difficulty understanding is branch 2.
While mobile has two branches, I wouldn't slice it that way. The way that we look at it is either
- Smart phone development - editing, image uploads, mobile web, apps,
mobile frontend, etc
- Alternate access methods - S40 (J2ME), SMS/USSD, & Zero
Okay, I think that's sensible. In my opinion, initiatives such as Wikipedia Zero are exactly the type of work that can only really be done at the Wikimedia Foundation-level and great progress has been made there that I don't think would have been possible with volunteers. And in a lot of ways, being able to host and maintain the mobile sites is something that only the Wikimedia Foundation is capable of doing. The mobile application development was the part that I saw as possibly being ripe for outside organizations, but as you explain below, that may not be the case for a variety of reasons.
The idea behind free and open content is that the content can be taken and reused and redistributed by others without issue. That's part of the great beauty of Wikimedia wikis. With a vibrant app market for both Androids and iPhones, why is Wikimedia getting involved in mobile application development? Isn't this something best left to third parties (which, as I understand it, have already filled the "Wikipedia app" niche with a variety of options for both platforms) or interested volunteers?
No, its really not and we've heard from countless people that it wasn't working. There are a number of reasons that my team was asked to do mobile apps and i'll list some of them below
- Whenever we talk with carriers about partnering with us they want to
see a suite of products they can provide on our behalf. These can range from a basic bookmarks on the mobile web, sms access, to a listing our app within their own markets. Any one thing missing ends the conversation pretty quickly. I suggest reading the original blog post from January http://bit.ly/IFoti4 to gain more insite. Kul & Amit can elaborate more on this.
I'm a bit confused about the relationship between mobile applications and carriers. As I understand it, carriers in this context refers to cell phone service providers (Verizon, AT&T, et al.). The mobile applications are generally at a different layer (Apple's iTunes Store, Google's Android Market, etc.), aren't they? Is this strictly about pre-installed applications on devices sold through these carriers?
I'd encourage anyone interested to read both the blog post _and_ the comments below it, where some of these same questions are asked (and answered!).
- Were constantly getting asked about why "insert new Wikipedia app
name" in "new app store" has ads, is not free, and in general doesn't provide a polished experience. Users are confused why the foundation would provide so many bad offerings in each of the apps stores because they associate most apps in the market with something that the foundation has done. I've had users approach me and ask why the foundation puts ads inside their apps and even after explaining that we have no affiliation they insist that its a poor reflection of our projects. No matter how we look at it ... were being judged on behalf of any app that is showing people data from Wikipedia. Rather then having to explain why there are so many bad ones we decided to provide a better solution then the rest to raise awareness that you a) dont have to see ads b) don't have to pay for basic features like saving pages and c) have control in the future direction of the project.
Aha! This is a very interesting point. I hadn't realized that this was an issue. Ad blindness seems to have not affected mobile device users as much as it has desktop users (yet).
- It's a great way to eat our own dog food. Apps should always be
decoupled and with the next release of both of our apps we'll have learned a ton about how our API's are deficient. By better understanding these use cases we've extended functionality for such things as loading articles into small chunks and our mobile web projects will soon be receiving the same benefits. Re-using code like this is key to making both our projects better and third party apps faster.
- People use them. No matter if your a fan of apps or not they've
replaced the function of bookmarks for most mobile users. They provide a faster and easier way of accessing content and our stats are starting to show it. In just under a month of metrics we've already seen 20+ million page views from the official android app and growth is continuing.
- Code re-use. Whenever companies build native apps they have to
create separate code bases. We chose not to do that. Through the use of PhoneGap were re-using more and more code with each release. It work bi-directionally and allows us move quickly without a significant investment on either end.
- Community outreach. We've run three hackathons that focused on
mobile and nothing was as popular as working for Android. The barrier to entry for working on the mobile projects has been dropped significantly and now its one of the easiest Wikimedia projects to join. Since their decoupled and work with standard web tech ... its been really easy to get volunteers engaged and involved.
All of these are great. :-) I need to figure out a way to incorporate some of this content (or at least a link to it) in the pages at Meta-Wiki. This info is all very helpful to understanding the larger mobile efforts.
When I discussed the mobile apps with others a few days ago, one of the benefits quickly mentioned was the ability to add editing functionality to the apps. The idea being that third-party groups wouldn't have as much of an interest in developing features of this nature.
Can you discuss (or point to a page, if this has been previously discussed) the plans for users being able to manipulate content, rather than simply read it? I can't imagine it's an easy task, as even editing through a full Web browser on a desktop right now is difficult and tedious (posting to a talk page, editing any article that uses references, etc.).
The mobile sites began as read-only portals. What level of interactivity is expected from mobile devices? Simple typo-fixing? Content additions (paragraphs of new text)? I know that mobile uploads (from cell phone cameras in particular) has been a long-term goal. If you could elaborate on some of this, I'd really appreciate it. :-)
Thanks again for your very thorough reply. It's given me (and I imagine others) a much better understanding of what your team has been working on.
MZMcBride
Hi MZ,
I'm going to further address one of your questions below to shed a little more light on the relationship of mobile applications and carriers, and another reason why we need to have Wikipedia mobile apps.
<snip>
Okay, I think that's sensible. In my opinion, initiatives such as Wikipedia Zero are exactly the type of work that can only really be done at the Wikimedia Foundation-level and great progress has been made there that I don't think would have been possible with volunteers. And in a lot of ways, being able to host and maintain the mobile sites is something that only the Wikimedia Foundation is capable of doing. The mobile application development was the part that I saw as possibly being ripe for outside organizations, but as you explain below, that may not be the case for a variety of reasons.
The idea behind free and open content is that the content can be taken and reused and redistributed by others without issue. That's part of the great beauty of Wikimedia wikis. With a vibrant app market for both Androids and iPhones, why is Wikimedia getting involved in mobile application development? Isn't this something best left to third parties (which, as I understand it, have already filled the "Wikipedia app" niche with a variety of options for both platforms) or interested volunteers?
No, its really not and we've heard from countless people that it wasn't working. There are a number of reasons that my team was asked to do mobile apps and i'll list some of them below
- Whenever we talk with carriers about partnering with us they want to
see a suite of products they can provide on our behalf. These can range from a basic bookmarks on the mobile web, sms access, to a listing our app within their own markets. Any one thing missing ends the conversation pretty quickly. I suggest reading the original blog post from January http://bit.ly/IFoti4 to gain more insite. Kul & Amit can elaborate more on this.
I'm a bit confused about the relationship between mobile applications and carriers. As I understand it, carriers in this context refers to cell phone service providers (Verizon, AT&T, et al.). The mobile applications are generally at a different layer (Apple's iTunes Store, Google's Android Market, etc.), aren't they? Is this strictly about pre-installed applications on devices sold through these carriers?
I'd encourage anyone interested to read both the blog post _and_ the comments below it, where some of these same questions are asked (and answered!).
In regards to carriers, it's consistently been a requirement from them to provide Wikipedia mobile apps for the following reasons: 1) marketing/awareness; 2) better user experience; and, 3) to provide a presence in their own app stores.
1) As you pointed out, many of these carriers would like to pre-install Wikipedia apps on their phones and they require us to have these apps available for them. They have a lot of control to determine what goes on the deck of Android phones so that's better exposure for us. Furthermore, they have told us that their data shows it's the preferred way their customers access applications. I know it makes less sense for iOS because Apple exclusively controls what's on the iPhone deck but, from a marketing perspective, it's easier for them to message "access to Wikipedia" if they just identify an app in their marketing campaigns. I was in discussions with another carrier this morning and they also emphasized the importance of having an app in order to market Wikipedia Zero because they believe their customers may be hesitant to access Wikipedia directly via the mobile web. They think their average customer may be wary that it's not actually free, which may deter them from using the site if they feel that there is some chance they may be charged for data usage. Some carriers claim that it's easier to message the Wikipedia Zero experience if the app is the clear gateway to it. We're obviously relying on the insight we're getting from our partners on this but we've been hearing the same thing from many carriers on this.
2) In regards to user experience, there are some benefits to users in having native functionality in a smart phone app but it's a more compelling argument for feature phones. Especially for low-end feature phones such as those that run on J2ME, the in-browser experience is significantly worse than a native app experience. This was a common request made by carriers in developing countries where, in some territories, feature phone usage is still 50% to upwards of 80% of their user base.
3) Almost every carrier we've talked to have their own app stores: Android, J2ME, Bada, etc.. And although I'm not convinced it makes as much sense to promote the Wikipedia app in their Android store when most people go to Google's Play Marketplace, it's not an either/or proposition (we can do both) and carriers are willing to put more marketing dollars/power behind our apps if it's also available in their stores. It's what they want and if it help us reach more people that's an additional benefit (not a compelling enough reason on it's own though). However, some app marketplaces run by carriers like those for J2ME (and Bada, although we're not developing for that) have significant downloads from their customers that rival the main app stores (managed by Nokia and Samsung respectively) so we're definitely getting more exposure to their customers by providing apps for feature phones as well.
Let me know if you have any other questions.
--Kul
wikimedia-l@lists.wikimedia.org