Mobile design/Wikipedia navigation

'''This document is a work in progress. Comments are appreciated but this is not a final draft.'''

Wikipedia Navigation UI aka Glaucus is a UX design that will be deployed on multiple mobile platforms, including mobile web browsers, WAP browsers, iOS apps, Android apps, and others. There will be differences across platforms and the most comprehensive version will be for mobile web browsers, where all functions not included in basic browser functions must be accommodated in the UI that accompanies Wikipedia.

A related design is known as Athena, which is focused on making the main Wikipedia site mobile-friendly. This design is focused on optimizing the reading experience as well as accommodating contributory functions as they are developed, leading eventually to more complex editing functions. In a sense, Athena is a sort of "destination" for the evolution of this design.

See the Glaucus mock-ups here. See the enhancement bug 32117.

Design goals
The main goals of this design are as follows:

(tablet versions can be developed later)
 * A rational, easy-to-understand framework for the placement of functions related to Wikipedia
 * Simple, obvious access to these functions in a way that conserves screen real estate
 * Flexibility to add more functions over time in different categories - i.e., extensible without becoming cluttered or non-intuitive
 * Compatibility with different mobile platforms and form factors - the minimum versions of this design should include:
 * web browser on iPhone
 * web browser on iPad
 * web browser on Android smartphone
 * web browser on Android tablet
 * WAP browser on typical Series 40 device
 * iPhone app
 * iPad app
 * Android phone app
 * Android tablet app

Initial menu
Here is a first version of the new navigation UI.

Style Choices
The sections of the menus below are organized into these sections:


 * article-specific
 * nav and general
 * user-specific

Site
Here are the functions to include initially for the mobile site: --- ---
 * Inter-wiki language links -> submenu
 * Table of Contents -> submenu
 * Contributors
 * Home
 * Random
 * Articles nearby (when ready)
 * Desktop / Mobile view (could go in footer, but currently site-specific)
 * Settings -> submenu
 * Beta opt-in/opt-out
 * Disable images
 * Font size
 * About

Apps
Here are the functions to include initially for the apps: --- ---
 * Inter-wiki language links -> submenu
 * Table of Contents -> submenu
 * Save page
 * Share page -> submenu
 * Contributors
 * Back
 * Forward
 * Save pages -> submenu
 * History
 * Home
 * Random
 * Articles nearby
 * Settings -> submenu
 * Disable images
 * App languge
 * Font size
 * About

"Articles nearby" and "Save pages" are not yet implemented on the mobile site. Also Login will not be needed initially.

If a user logs in, then other functions become available. "Disable images" could be a setting in preferences, so when "Login" is included and "Preferences" is implemented, "Disable images" can be removed.

Toolbar hide/reveal
We are considering ways to hide the top bar and calling it up easily, but the thought is to show it initially. Here are some ideas:


 * The Pinterest app hides toolbars when scrolling down a page, and reveals them when scrolling up starts.


 * The Kindle shows toolbars initially which fade away, then a tap anywhere reveals them.


 * Keep the toolbar at the top of the screen, then after scrolling down a page, a tap on top status bar of the phone scrolls quickly to the top of the page.

Axel Boldt: "My concern with the Kindle way is that you may find yourself on a page with lots of links or a big image, and there won't be a safe place to tap anywhere. The Kindle doesn't have that problem, but we do.

"I like the third option for two reasons: people will know it from Safari, and it gives them a quick way to jump to the beginning of an article, which we currently lack. The downside is that some users will never figure out the tap-on-top shortcut, so they will constantly have to scroll like crazy up through long articles just to search.

"So I wonder whether combining the Pinterest and Safari methods might be feasible? Best of all possible worlds, and all that." - via email

Icons
1. The design partly looks very "Android" (the 'dot dot dot' actions icon, 'highlighting bars' over buttons, interface style in general). This will be a problem with (some) iOS users. It's not alway best to go the 'same design on all platforms' route on cross platform apps. Especially if it's not a niche app, but will be used (hopefully) by millions of users.

2. The "W" button could be problematic. Most of the apps using this slide-in-out-navigation use a "three lines" icon on the button (Path, Facebook, Sparrow). You could even consider it standard by now.

The "W" is part of the logo and identity, the three lines are the icon connected to "show me navigation". So put the W somewhere else (Besides the app icon and the launch screen, maybe inside the search field like the search provider switcher ion in Firefox, into the slide-in navigation, etc) and use the standard one.

I can see the W as the "Home" button of the app, that goes back to a dashboard or even opens a dropdown. There I probably wouldn't feel so strong about it. But showing the slide-in navigation is different. Somehow ;)

When the W is a button that opens a dropdown this makes sense. But for the slide-in navigation this type of indication (small arrowhead) is almost never used, or may be I just never saw it. I always tell my designers that additional arrows, highlights and such stuff often are trying to fix a problem, that is there only because of some more fundamental problem. The functionality should be clear enough without the non-standard/common addition.

- Jan Piotrowski

Now I think about this some more a puzzle piece tends to mean add-ons / extensions so I don't think it would be a suitable choice of icon.

- Jon Robson

I think someone else suggested this, but what about a big down arrowhead? That would correlate with the down arrow in the section headings.

I am also thinking about symbols that imply action, or extending the reading of the article in some way. --Pchang (talk) 21:46, 18 April 2012 (UTC)

Maybe a tool icon would work. Usually if I can't find some action in an app, I look under tools. Example: http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT4088/HT4088_tools-en.PNG - Axel Boldt

View history
In order to comply with the CC-BY-SA license, there is a need to show the contributors of each article. This can be done via a link to the desktop view of "View history" or a more specific view of the contributors, which would probably be called, "View contributors."

Presentation models
There are several possible presentation models for this. One is to reveal a menu from the W icon, as the mock-ups above show.

Another is similar to the Facebook menu which is revealed as the page slides to the right, to give the impression that it lies underneath the page. In this case, the menu is a full-screen list organized into sections and the page scrolls as necessary.

A different take on the Facebook approach is to have an icon in the upper right which causes the menu to slide in from the right, which would make it seem like it appears on top of the page.

Feature phones
The design of the navigation UI must accommodate feature phones, which will lack JavaScript and any form of animation. Or put another way, any UI approach must also work without animation, overlays or other sophisticated forms of presentation.

Language use
The use of language is a complex area that is more challenging on mobile devices than on the desktop. Currently, the language conventions differ by mobile platform and app/browser, though Android and iOS will be unified shortly.

On the desktop, the language of Wikipedia changes with the article in most ways. On mobile devices, some consideration must be given to the variables available on phones.

There are four different aspects of language selection:
 * Main default language, typically defined as the app language
 * Language of the phone
 * Language of the article or content
 * Language of the keyboard

In the Android app currently, this breaks down into:
 * Default language - search language and home page language, based on app language and phone language
 * Language of the article, linked from each article
 * Keyboard language is somewhat independent

So a major consideration is whether the default language follows the app/phone language or the article language.

Language selection is a core part of the Navigation UI, though it also deserves further treatment as its own project. Here are initial designs:


 * Universal Language Selector


 * Wireframes showing sample workflows as the basis for further discussion:

Functional categories
The main categories of functions that will be included in the UI are as follows:
 * Article-specific, such as inter-wiki language versions, related images
 * General to Wikipedia, such as notifications, featured content
 * Account-related, such as login, watchlists
 * Contributory, such as photo uploads, article feedback
 * Editing, such as photo patrolling, proofreading edits, visual editor, new page triage

Examples of these categories are listed below:

Article-specific

 * History (required for copyright attribution)
 * Inter-wiki links
 * Contributors
 * Table of Contents
 * Save page
 * Share page
 * Articles near this article
 * Related pictures
 * Discussion
 * What links here

General

 * Home
 * Random
 * Contact us
 * Beta opt-in/opt-out
 * Disable images (site and app)
 * Save pages (app and site)
 * Articles nearby (app and site)
 * Recent changes

Account-related

 * Login
 * Watchlists
 * Notifications
 * Talk page
 * Contributions
 * Preferences

Contributory

 * Photo upload basic
 * Photo upload "articles nearby"
 * Article feedback

Editing

 * Photo upload patrol
 * Proofreading edits

Sample timeline
Here is a rough breakdown of what features could appear when in cumulative fashion: