Wikimedia Apps/Wikipedia App/Reader Experience

From MediaWiki.org
Jump to: navigation, search
Wikipedia ❤ Readers


Table of Contents
[edit | edit source]


Intent[edit | edit source]


Design an efficient way of navigating and surfacing a variety of content types within an article.


Related User Stories[edit | edit source]


Importing from Trello soon!


Q&A[edit | edit source]


Q: How to give readers a better idea of what they can expect from the article / does it contain what they're looking for?
A: Summary of each section; pictures from each section.

Q: A better way of navigating through a long article?
A: ToC can be accessed at any time from the Action Menu instead of having to scroll to the top of the article.

Q: How to better surface variety of content type within the article?
A: Including References, Related articles, External links within the ToC list. Also, providing an alternative view to navigate the content within the ToC with all media types like images and videos.


Design rationale[edit | edit source]


  • Users access the Table of Contents (ToC) through the Action Menu. (1.0)
  • The article minimizes and slides to the right of the screen and remain as a perspective to where the user is currently within the article. This is the default view of ToC -- viewing by sections (1.1)
  • On the left of the screen is a list of all root section titles and subtitles only. This includes References, Related articles, External links at the end of the list.

This makes it easy for users to:

See if the article has what they were looking for and
Find what they are looking for and/or
Keep looking for the right article / explore similar content within Related articles

And surfaces:

Deeper content beyond infobox (mobile web users hardly ever scroll pass infobox).
We should enrich readers' knowledge with all the content curated by our hardworking editors.
References that's typically hidden at the bottom of the page on desktop and is collapsed by default on mobile web.
We need to better show that content on Wikipedia is backed by reliable sources and make it easy for users to be aware of them and locate them.

  • Image to the left of the section titles are only shown partially to lure users to reveal the alternative viewing method by swiping to the right. The first image within the root-level section is chosen to represent the section. If that's unavailable, we would use the first image available within any sub-section of the root-level section (that's a lot of section talk!). When there is absolutely no images within the section, we will use a placeholder image as a call to action to search or submit an image!
  • The reason why images are only available on each root-section title and not every single section and sub-section is to preserve the structure of the ToC in times when only a several sub-section has an accompanying image and others don't. The availability of an accompanying image also supports the idea that the particular item on the list is a root-level section. A clear content structure not only helps users with understanding content but to also reduce the cognitive load by organizing the content for them. This will especially help in a dense article.
  • With this alternative view of TOC -- viewing by media. a user gets to navigate the article with images, videos, or sound recordings. In this view, users will be navigating through media, hence, sub-sections titles aren't listed, however, all media within sub-sections are presented under the root-level section. (1.2)
  • Swipe left to return to the section view. To return to the article, either tap on any media/section title or on the article on the right side of the screen. You may also keep swiping left to return the article.


Current Progress on comps[edit | edit source]







Reading experience customization
[edit | edit source]


Intent[edit | edit source]


Wikipedia readers consist of just about any kind of person. Make it available for users to read the way they want!


Related User Stories[edit | edit source]


Importing from Trello soon!


Q&A[edit | edit source]


Q: What would make it more comfortable for users to consume content at any time of day, vision condition, etc, etc?!
A: Night mode, day mode, smaller text, bigger text, more space, less space, more contrast, less contrast!


Design rationale[edit | edit source]


  • Users should be able to opt in to automatically switch to night/day mode according to the time of day/lighting conditions.
  • If that's not favorable, they are able to find the setting within the Action Menu (2.0)
  • Users are able to view in real time the changes to settings they make onto the article.


Current Progress on comps[edit | edit source]


More coming soon ...










Quick facts vs In-depth article
[edit | edit source]


Intent[edit | edit source]


Letting users choose the way they read about the subject. More reading flexibility!


Related User Stories[edit | edit source]


Importing from Trello soon!


Q&A[edit | edit source]


Q: How to allow equally easy access (or as equal as possible) to both infobox and article?
A: Using familiar gesture to access but at different target points.



Issues / To Fix[edit | edit source]


  • Currently on mobile web, users must scroll pass infobox (quick facts) to get to the in-depth article. This is inconvenient for users who want to jump straight into the article.
  • Infoboxes can be very long and at the same time shouldn't be collapsed to make it inconvenient for users who want to access infobox.


Design rationale[edit | edit source]


  • Infobox contains short and quick facts of the particular subject while the article provides a more in-depth view of the subject.
  • Those two ways of understanding a subject have two different use cases that depends on intention, interest, time constraint, surrounding environment, etc, etc. Users should be able to access quick facts as convenient as accessing in-depth info (article) and vice versa. Not one is more superior than the other.
  • A typical gesture to read content is to swipe up. Hence:

Letting users swipe up from the lead image reveals infobox (quick facts)
Letting users swipe up from the text area reveals more article (in-depth info)

  • The lead image of an article are typically within an infobox, hence, the access point to an infobox at the same time illustrating the article. Where there isn't any lead image or any images in the infobox, we will provide a placeholder as a call to action to search for one on Commons or submit one.
  • The lead image will take up ~60% of the vertical screen space, hence, users can easily swipe up and discover the infobox. 3.0
  • When in infobox, the main article (in-depth info) will "dock" at the bottom of the screen for easy access at any point of viewing the infobox. When users scroll pass the end of the infobox, the main article automatically follows the infobox for a smooth reading transition. This means that there is no difference from the current reading pattern (Infobox → Article), except, users chose to view infobox first. 3.1
  • For users who wants to go straight into the article, they swipe up from the lower portion of the screen where the article starts, without having to scroll pass infobox. 3.2


Current Progress on comps[edit | edit source]


Coming soon ...




Wikipedia is credible
[edit | edit source]


Intent[edit | edit source]


Make it obvious that our content is backed by reliable sources.


Related User Stories[edit | edit source]


Importing from Trello soon!


Q&A[edit | edit source]


  • Some users don't seek out for the source of the fact when reading an article, but because we are Wikipedia and haven't gotten much support from, say, school professors, how can we make it obvious that our content is reliable?
  • When do users typically look for sources when reading an article and how?
  • What kind of source info are they interested in knowing when seeking out for sources within the context of the article?
  • What kind of source info can we display minimally to show the reliability of the source (Author name / Publication name / Date / Year / etc?)
  • Also, on a small mobile phone screen, the superscript reference number is a small area of target to tap on, how can we increase this target size?
  • Is it possible that user taps on any part of the article to surface references, is this necessary?


Design rationale[edit | edit source]


  • When user is reading an article and taps on any superscript reference number, he will see a minimal source info--Author or Publication name and Year. (4.0)
  • When there is more than one reference for that paragraph or sentence, users will be able to swipe left / right to view more / previous sources. In this area, they will also be able to share, add more source or copy the formal full citation.
  • Tapping on the source will bring users down to the reference section where the fully cited source is available


Current Progress on comps[edit | edit source]


Coming soon ...