Thank you very much for the detailed and insightful reply.
Tomasz Finc wrote:
On Mon, Apr 9, 2012 at 9:37 PM, MZMcBride
<z(a)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