Mobile design/Wikipedia navigation/Back behavior

This page is a whiteboard for discussion of the back/forward behavior in the new navigation UI. It is also intended to outline all of the expected behavior to aid in implementation.

General principles

At its core, back needs to achieve some basic objectives, which can be summarized as:

• providing a quick and simple method of going back to an article from any context, such as a menu or submenu
• providing a simple way to re-trace steps in a detailed way, as in a breadcrumb trail
• providing a way to cancel some actions, such as typing or navigating to a place that was not desired (such as a language version)

These objectives can be at odds, since the first objective includes a focus on speed and convenience.

From an implementation perspective, this boils down to defining what are the steps in a navigation path. To achieve the above objectives, there needs to be a balance between defining many elements as steps, and defining too few.

Defining an article as a step is not enough, since there are potential states of the page, based on the following variables:

• Action bar showing or not showing
• section(s) closed or not closed
• position on the page
• language

In general, the principle is to navigate back to the last state of the article page when possible.

There is also an issue of user expectations, which differ between browser and apps, in particular regarding submenus. These differences will be noted in the sections below. And there are differences based on platform. The focus here is on Android and iOS, and specific differences will be noted. In general, Android uses back on the phone not only to go back, but also to close an app once the all back steps are achieved. iOS has no built-in back function but in the native browser, back and forward are built into the toolbar, which is not accessible except in the article view. The Home button can function as back in some cases, while most menus and submenus have a back function included.

All of the details below are subject to change based on feasibility.

Articles and sections

The main path of back/forward navigation is article to article. There are some issues to consider with article sections in particular, because in the mobile version of WIkipedia, there is a need to maximize navigation through articles in terms of speed and convenience, and sections can be collapsed and accessed via Contents to aid with this.

Here are the variations with the intended back behavior:

• After opening a section, back should close the section and go to the top of the page.

• If multiple sections are open, close all of them and go to the top of the page. (Another version of this: each back closes the current section and goes to the last open section, until all sections are closed and the top of the page is reached.)

• Subsequent back will go to the previous page, to the top of that page, with all sections closed. (Another version of this: back goes to the previous page at the same position and in the same state from which it was left.)

• The final design of dynamic sections can affect the above behavior - see Dynamic Sections

• A variation on this behavior is when navigating from the Contents list to a section, back should go back to the Contents list. See Table of Contents below.

Search

• Before typing has started, back should close the full-screen search window and go back to the last article at the top of the page. This mimics the function of the back arrow at the top left of the screen.

• After typing has started, back should close the keyboard and preserve the search term typed to that point (as well as type-ahead results).
  • This operates differently on IOS, where "Done" on the keyboard causes the keyboard to close.

• After a search result is selected, back should go back to the full-screen search window with the search term preserved, and if possible the keyboard activated.

Menus and submenus

• From any menu, back should go back to the article at the top of the page.

• From any submenu, meaning the Main Menu and Action Bar, back should go back to the article at the top of the page with the Main Menu and Action Bar closed.

• The back path should include submenus where possible. So going from Settings to an article, back should go back to Settings. A further back should go to the article from which Settings was invoked.

• One option to consider is to keep the Action Bar open whenever it was left open. This is not so useful now with just two functions in the Action Bar, but later when more functions appear it could be considered.

• In apps, it is not customary to include submenus in back behavior, and it may not be possible.

Languages

• The points above for menus and submenus apply to Languages.

• In particular, when going from a Language selection to a new page, back should go back to the Languages submenu, in the context of the language version from which Languages was invoked (meaning the top of the submenu will be in that original language).

• An important case of back behavior with languages is the ability to navigate back to a language version that is readable, in case the wrong one is selected by accident. The point above should address this.

• Please note the comment about apps under Menus and submenus, above.

Table of Contents

• The points above for menus and submenus apply to Contents.

• In particular, when going from a section selection to a section, back should go back to the Contents submenu.

• Based on the variation above regarding going back through each section in sequence, the following can be considered: If another section was open after the navigation from Contents to a section, back should close the current section and go back to the previous section first, and then a subsequent back will go the Contents submenu.

• Please note the comment about apps under Menus and submenus, above.

Random problem

• The Random function currently has a bug related to back behavior, which is evident on the desktop site as well: bugzilla:37224

---

---

The following sections are for capturing design issues and will be refined as we get closer to implementation.