Wikimedia Apps/Team/Why 5: Difference between revisions
JMinor (WMF) (talk | contribs) Overview of the 5.0 version of Wikipedia for iOS |
JMinor (WMF) (talk | contribs) |
||
| Line 1: | Line 1: | ||
== Introduction == |
== Introduction == |
||
Major content platforms on the internet have largely seen a shift from desktop web traffic to a mix of mobile web, desktop web and app traffic<ref><nowiki>http://venturebeat.com/2015/09/25/wait-what-mobile-browser-traffic-is-2x-bigger-than-app-traffic-and-growing-faster/</nowiki></ref><ref><nowiki>http://www.smartinsights.com/marketplace-analysis/customer-analysis/consumer-media-device-use/</nowiki></ref>. Wikipedia (or Wikimedia as a whole) has not seen this same migration to apps, despite releasing well reviewed official apps in recent years. |
|||
Additionally, when we have had influxes of new users to the app, for example from being featured in the App Store or through PR efforts, we have not ben able to retain those uses and grow the daily overall audience for the app. |
|||
Our goal is not to "move" traffic from desktop browser to the iOS app, but to create a compelling and engaging app that encourages re-use and regular engagement with Wikipedia. |
|||
== Goals == |
== Goals == |
||
Given our current app's good reviews and positive press, but inability to build and retain a meaningfully large audience, the team decided to effectively reset the app, and invest . The goal was to rethink how people access content (especially medium or long form written content) via apps, and pilot new user experiences and look-and-feel, while preserving the functionality of the current release. |
|||
== Target Audience == |
|||
| ⚫ | |||
=== Retention === |
|||
Our main goal is to create experiences that encourage users to open the app more than once. We're using an industry standard "7-day" metric for user retention. This means our goal is to get more people who download the app to re-open the app 7 days later. |
|||
=== Aspirations === |
|||
Our team has a few guiding aspirations we're using as we developed these ideas and weigh trade offs. We asipre for the next version of the app to be: |
|||
* Sticky - Our app will engage users and keep them engaged with Wikipedia not just once, but as a habit. |
|||
* Mobile-y App-ish - We will focus on features and user experiences specific to native apps and iOS devices. We won't re-create the browser. |
|||
* Responsive - The app will respond quickly and smoothly to user interactions and load content as quickly as possible. |
|||
* Polished and On Brand - The app will look visually consistent and use standard Wikimedia branding, such as icon forms and terminology. |
|||
* Privacy Friendly - We will advance our mission value of privacy by being transparent and "opt-in" oriented about data collection. |
|||
* Feature-able - Our app will be good enough to be featured by Apple in the App Store. |
|||
* Well Engineered - Users will have an experience which is crash-free, and volunteers and staff will be able to easily contribute patches to the project |
|||
* Accessible - We will further our mission values by making an app that is easy to use for the disabled and non-English speakers. |
|||
=== Design Thinking === |
|||
NIRZAR'S deck/link to document to go here |
|||
| ⚫ | |||
In order to focus our "reset" we've prioritized 2 specific user stories. We focused on these because we believe they are uniquely suited to native apps and will keep users coming back to the app. |
|||
=== Full Article Reading === |
=== Full Article Reading === |
||
=== Explore Feed === |
=== Explore Feed === |
||
== Navigation |
== Navigation == |
||
One global change, not specific to these stories is to the overall app navigation. In this version of the app we're using the Tab bar paradigm common across iOS apps. |
|||
== Reader Experience == |
|||
== Introduction and Context == |
|||
This type of navigation has a number of advantages over the existing "W" menu approach. Specifically: |
|||
* One touch access to lists of personally relevant articles: exploration feed, saved articles and recent article history |
|||
* Entry points for key stories: visual reminder of articles you may want to continue to read and explore |
|||
* iOS standard paradigm across many app types (everything from Cydia to Facebook to the built in Contacts to the Pokedex) |
|||
* Phone form factor friendly as main navigation is near thumb |
|||
* An app specific pattern, which makes app feel “appy”, and less like a browser. |
|||
Revision as of 00:18, 3 December 2015
Introduction
Major content platforms on the internet have largely seen a shift from desktop web traffic to a mix of mobile web, desktop web and app traffic[1][2]. Wikipedia (or Wikimedia as a whole) has not seen this same migration to apps, despite releasing well reviewed official apps in recent years.
Additionally, when we have had influxes of new users to the app, for example from being featured in the App Store or through PR efforts, we have not ben able to retain those uses and grow the daily overall audience for the app.
Our goal is not to "move" traffic from desktop browser to the iOS app, but to create a compelling and engaging app that encourages re-use and regular engagement with Wikipedia.
Goals
Given our current app's good reviews and positive press, but inability to build and retain a meaningfully large audience, the team decided to effectively reset the app, and invest . The goal was to rethink how people access content (especially medium or long form written content) via apps, and pilot new user experiences and look-and-feel, while preserving the functionality of the current release.
Retention
Our main goal is to create experiences that encourage users to open the app more than once. We're using an industry standard "7-day" metric for user retention. This means our goal is to get more people who download the app to re-open the app 7 days later.
Aspirations
Our team has a few guiding aspirations we're using as we developed these ideas and weigh trade offs. We asipre for the next version of the app to be:
- Sticky - Our app will engage users and keep them engaged with Wikipedia not just once, but as a habit.
- Mobile-y App-ish - We will focus on features and user experiences specific to native apps and iOS devices. We won't re-create the browser.
- Responsive - The app will respond quickly and smoothly to user interactions and load content as quickly as possible.
- Polished and On Brand - The app will look visually consistent and use standard Wikimedia branding, such as icon forms and terminology.
- Privacy Friendly - We will advance our mission value of privacy by being transparent and "opt-in" oriented about data collection.
- Feature-able - Our app will be good enough to be featured by Apple in the App Store.
- Well Engineered - Users will have an experience which is crash-free, and volunteers and staff will be able to easily contribute patches to the project
- Accessible - We will further our mission values by making an app that is easy to use for the disabled and non-English speakers.
Design Thinking
NIRZAR'S deck/link to document to go here
Our Stories
In order to focus our "reset" we've prioritized 2 specific user stories. We focused on these because we believe they are uniquely suited to native apps and will keep users coming back to the app.
Full Article Reading
Explore Feed
Navigation
One global change, not specific to these stories is to the overall app navigation. In this version of the app we're using the Tab bar paradigm common across iOS apps.
This type of navigation has a number of advantages over the existing "W" menu approach. Specifically:
- One touch access to lists of personally relevant articles: exploration feed, saved articles and recent article history
* Entry points for key stories: visual reminder of articles you may want to continue to read and explore * iOS standard paradigm across many app types (everything from Cydia to Facebook to the built in Contacts to the Pokedex) * Phone form factor friendly as main navigation is near thumb * An app specific pattern, which makes app feel “appy”, and less like a browser.