Wikimedia Apps/Wikipedia App/Navigation

How users navigate the Wikipedia mobile native application and access page actions.

Intent

 * Designing a minimal interface for an immersive experience by surfacing only necessary actions for any given context. To achieve this, we seek to understand user's behavior, intent, and need in their activities

Questions

 * How can we give users the best experience while consuming content?
 * How can we help users contribute to the WP content they're consuming?
 * How can we make actions that appear on the top nav inviting and friendly to use?
 * How many actions on the top nav before it gets scary and slow to make decision and choose to use?
 * If readers do not typically take edit actions, how can we feed their potential compulsion to improve WP articles while reading an article?
 * How can we reduce the number of edit buttons on the page?
 * When consuming content, are users more likely to search or click on links to surf Wikipedia?

Issues / To Fix

 * ❑ We should humanize and give life to Wikipedia articles. Our content has a neutral point of view but humans tend to not be like that. :) We don't need to show how humans aren't always neutral, but show that humans wrote this article. "Look at the hard work to achieve neutrality!" Surface the team behind the scenes of every single article. This could be access to talk pages as well as small information like when the article was updated.
 * ✓ Currently there is an edit action next to every single section, subsections, and etc on mobile web. When sections are short, it looks like an overload of actions on the screen. When sections are long, users have to scroll back up to the title of the section to edit. They risk losing track of the area they want to edit.
 * ✓ Currently when users are scrolling through the article content and want to access search on mobile web. We should make search more accessible since that's one big way to explore Wikipedia content.
 * ✓ Currently on mobile web, when a user lands on an article, they have 5+1 actions to choose from (+3-7 more from browser chrome) taking up quite a bit of space on the screen real estate. Those 5 WP actions are to access left drawer, search, edit, add image, add to watchlist, and talk (still in beta). They're all important, we should provide a balance of immersive experience and amount of actions by carefully examining questions above.

Design rationale

 * When users arrive at an article, they might assess if they've come to the right article. Actions to surface at this screen, if it turns out to not be the right article, is disambiguations, search, nearby articles, and access to left drawer. In the current comp (1.1), I've only shown access to search and access to left drawer. Still thinking how to incorporate disambiguation, nearby articles, and when the article was updated without crowding the top nav. They might not end up being in the top nav. I'll keep exploring and suggestions appreciated.
 * If it's the right article, they scroll the content. When users are scrolling through the article, they are consuming the article content. It makes sense to include actions to do onto the content whenever they find areas that need correction or more information. So I'm swapping search function with editing actions. (1.2)
 * We originally looked at scrolling off the top nav when user is scrolling through the content, but we've found a way to keep the top nav minimal while giving persistent access to essential actions relevant to their browsing activities.
 * Now, instead of scrolling off the entire top nav, user scroll off the ability to search to reveal actions for editing while they consume article content. :)


 * When users scroll back up on the article, they are most likely searching for previously read content. While they are already in the "search" mind mode, we surface the search action again. (1.3, 1.6)
 * As user continues to scroll the content, the top nav actions become quiet. They take the back seat and let the content shine by becoming even lighter in visual weight and emphasis. (1.5)
 * Also, as a section title scrolls off the screen, the context is preserved next to the edit action to further associate edit action and section title. (1.5)
 * With one tap gesture on the search icon, we'd bring up the keyboard for user to start typing. (1.7)
 * When there is an image behind the top nav, the nav does not have a background color. Instead, we will be using a subtle black to transparent gradient vs a white solid background. This is to decrease the amount of space preserved for just two actions and providing a more immersive image experience. However, when the top nav has text behind it, we will use a solid white background to avoid unnecessary visual tension and text illegibility. (1.4-1.6)

Current Progress on comps
[http://invis.io/Q2OMYMU4  Play with the prototype! ] <font color="#AAA"> (You can access this link on your mobile device)

<font color="#347BFF">Intent

 * <font color="#347BFF">Article actions are important to surface in context to the current article. While we already have a top navigation and is clearly higher in the hierarchy, we want to make these actions just as easily accessible while keeping the navigation extremely minimal. Remember, we want users to feel invited to consume the content, not to feel overboard with the actions that they can take around the content.

<font color="#347BFF">Questions

 * How can we make these actions accessible FAST! discreet but obvious?
 * Besides editing, what kind of actions would users want to take in the midst of consuming content?
 * Could this be a good place to access table of contents (ToC)?
 * Possible article actions are ToC, reading experience customization (REC), share article, save to "To Read" list. Which could be the most frequently used to provide within one-tap access?

<font color="#FF5D00">Issues / To Fix

 * <font color="#00AF89">✓ Currently the table of contents (ToC) is stacked above the article on desktop. On mobile web, instead of a ToC, all root-level sections are minimized by default. It would be great if we could decrease the amount of work to skip from section to section without having to scroll all the way up to collapse a section and expand another.

<font color="#347BFF">Design rationale

 * While we do not want another block of navigation at the bottom, we can still provide access to article actions with as little as one tap gesture.
 * Currently, we're assuming that ToC would be the most used action. Second would be Sharing article and saving to "To Read" list. Third would be reading experience customization (REC).
 * The reason why reading experience customization is at the bottom of the hierarchy is because it's an important feature, yes, but users would most likely change these settings less often than they share, save to "To Read" list or access ToC. In terms of urgency to access REC, we're assuming that the slightly slower speed of accessing REC would be less frustrating.
 * Once user taps on the •••   icon at the bottom right of the screen, the button expands to 4 actions. <font color="#00AF89">(2.1→ 2.2)
 * The idea here is that user tap & hold their finger and move their finger to either side of the screen and release the hold to choose an article action. For example, a user wants to share the article. She would:
 * Tap & hold •••   icon> move finger to the right over the "Share" icon > release finger to make the selection. <font color="#00AF89">(2.1→ 2.3) (Watch 2.0)


 * The way we've made ToC accessible via one-tap is by making ToC the first selection when user tap & hold •••
 * Tap & hold •••   > release hold