Wikimedia Apps/Android/Navigation

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
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
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
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: 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.
 * 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.

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

"Now reading" tab item
We can have an additional tab at the bottom of the main activity called "Now reading" that contains the currently-read article. Pros: Cons:
 * Everything is on the same screen, and a single tap away.
 * We can keep our current system of tabbed browsing with very little modification.
 * 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
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: Cons: 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.
 * More focused and clean interface in the discovery activity, as well as in the reading activity.
 * Reduces complexity for our code.
 * 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.

Questions

 * Will there be changes to how Search is integrated?