Wikimedia Apps/Android/Navigation

From MediaWiki.org
Jump to navigation Jump to search

In Q1 of 2016, the Android team plans to re-imagine the navigation experience in the app. Specifically, we'd like to move away from using the "hamburger" menu, and instead surface the most-used features in the app in a more simple and straightforward way.

Goals[edit]

The ultimate goal is to improve user retention in the app, as well as user engagement while using the app (i.e. more time spent per session). Our hypothesis is that a smoother and more integrated experience will lead to better engagement by facilitating discovery of features and a greater diversity of content.

The case against the Hamburger menu[edit]

Until recently, the Hamburger menu was the accepted paradigm for navigation in Android apps, as well as in many websites. However, designers have been increasingly critical of this method, for the following reasons:

  • Because the hamburger menu is hidden by default (it requires a click to be revealed), any feature placed in that menu is no longer as discoverable as it can be. The more important the feature, the less it makes sense to place it in the hamburger menu.
  • The hamburger menu encourages a "kitchen sink" mentality. It encourages developers to create features without being mindful of how the features interrelate with each other, which leads to a disjointed experience. It's easy to pile a new feature into the hamburger menu, but it's much better to truly integrate the feature into the experience of the app.

Product decisions made[edit]

The app's main screen (the main activity) will become more of a "discovery" activity, where the user can switch between different tabs that provide the following content:

  • Explore Feed: the feed functionality that is currently part of the app.
  • Nearby: the current "Nearby" fragment in the app.
  • Reading lists: the current "Reading lists" fragment in the app.
  • History: the current "History" fragment in the app.

Since the above items are already implemented as "fragments" in our app, it will be relatively simple to combine and integrate them into a single tabbed activity.

Product decisions in progress[edit]

As for the actual reading of articles, there are two possible paths we can take:

"Now reading" tab item[edit]

We can have an additional tab at the bottom of the main activity called "Now reading" that contains the currently-read article. Pros:

  • Everything is on the same screen, and a single tap away.
  • We can keep our current system of tabbed browsing with very little modification.

Cons:

  • The bottom tab bar might start to become cluttered, since this means that we would have five items in it.
  • If we want to have a button bar at the bottom of the reading screen, it would clash with the bottom tab bar.

Modal reading activity[edit]

We can also make reading become a separate modal activity, invoked from any of the links in the main activity, or from external links in other apps. Pros:

  • More focused and clean interface in the discovery activity, as well as in the reading activity.
  • Reduces complexity for our code.

Cons:

  • No longer intuitive how to quickly switch between multiple articles currently being read.
  • Conveys the message that reading articles is a secondary function of the app.

Question: If we proceed with this method, what will replace tabbed browsing? We will not be able to have multiple instances of the reading activity.

User Testing 2018[edit]

As part of improving the navigation in the app and within articles, the Android team created 2 prototypes to test with users in Aug-Sep 2018.

Existing daily users of the Android app were invited to participate in a User Testing study. The following PDF documents the release form and privacy statement for Android My Recruit UserTesting.com studies.

Android app My Recruit UserTesting study privacy statement and release
Android app My Recruit UserTesting study privacy statement and release form