Jump to content

Design/Archive/Athena

From mediawiki.org
(Redirected from Athena)

This document was a work in progress.

Athena as shown at Wikimania 2012
Athena as shown at Wikimania 2012, showing the Echo notifications system
Athena as shown at Wikimania 2012, showing GlobalProfile
Athena in mobile mode
Athena showing page expanders in mobile mode
The mobile login screen
The mobile version, showing an expanded user menu
The Athena skin, in tablet and browser mode (w/filled gutter)
The Athena skin, in tablet/browser mode, showing a user page with Global Profile enabled
The Athena skin, in tablet/browser mode, with gutter showing Interwiki links
The footer in tablet/browser mode, fully expressed
An alternative, minimal banner


Munaf Assaf's work-in-progress on an Athena-like skin
In Greek mythology, Athena, Athenê, or Athene, also referred to as Pallas Athena/Athene, is the goddess of wisdom, courage, inspiration, civilization, warfare, strength, strategy, female arts, crafts, justice, and skill.

This document describes the design of a MediaWiki skin, codenamed Athena. The Athena skin is designed to operate in multiple modes:

  • Mobile smart phones
  • Tablet devices
  • Desktop browsers

Athena aims to solve many usability problems within all modes of operation. It is designed to "gracefully enable" (rather than "gracefully degrade"): As the viewing device expresses additional capabilities (such as screen resolution or GPS functionality), the skin will automatically adjust and accommodate.

This document is a work in progress. Feedback is welcome on the talk page.

Notes on Nomenclature

[edit]

This document contains the following nomenclature which may be of use to readers:

  • Chrome - elements of the user interface which are not directly applicable to the action the user is taking and are "outside" of the main viewing pane (e.g., a sidebar, header, or footer). These elements are common across all pages.
  • Site Action - actions or links which affect the user's interaction with the site as a whole (such as "go to main page" or "browse recent changes").
  • Content Object - the content that is being viewed (e.g., an article or a talk page).
  • Content Action - actions or links which directly affect the content that is being viewed (e.g., "view history", "view what links here", "add to watchlist")

Rationale

[edit]
  • The future of all Wikimedia properties is mobile (Data courtesy of Luke Wroblewski):
    • From the second quarter of 2010 to the second quarter of 2011, mobile data traffic more than doubled.
    • Research suggests that the industry will go from six billion connections today to more than 12 billion by 2020.
    • In North America, high-end smartphones generate twice the traffic of comparable smartphones in Asia and Europe.
    • Almost half of UK internet users are going online via mobile phone data connections in UK.
    • While 71% of 16 to 24-year-old who went online in the UK said they used mobile broadband, just 8% of UK internet users aged over 65 made use of mobile broadband.
    • The mobile media user population in the US (those who browse the mobile web, access applications, or download content) grew 19 percent in the past year to more than 116 million people at the end of August 2011.
    • 72.2 million Americans accessed social networking sites or blogs on their mobile device in August 2011, an increase of 37 percent in the past year.


  • There is currently great confusion regarding the "context" that the user is in when viewing a page on Wikipedia and other projects. This is a result of the way the tab metaphor is used.
    • While the "tab" metaphor has some merit with regards to viewing content, nearly every Article or Page has multiple contexts. Generally, these are the page itself and the discussion. However, both the page and the discussion have histories and other "sub-views". Normally, this might be solved with sub-tabs but this results in excessive interface clutter and is not acceptable in a mobile format.
    • In nearly all current skins, the tabs are located outside of the "content pane". As a result, they bleed into the site "chrome", which users are trained to ignore.
    • The "edit" button is not called out in any special way. This results in fewer editors.
  • Content Actions are spread out in multiple areas. Some actions are tabs ("view history") while others are located in the sidebar (the "toolbox"), such as "view what links here".
    • Further compounding the problem is that there are often Site Actions mixed with Content Actions within the toolbox (such as "upload file" or "view special pages"). This significantly increases user confusion.
    • Even further compounding this problem is the fact that, in the default deployment of the Vector skin, the toolbox is automatically collapsed.

Goals

[edit]
  • To become significantly friendlier to mobile and tablet environments
  • To provide a consistent user experience between all formats (mobile, tablet, browser)
  • To radically call out the Edit functionality of the system.
  • To create an obvious distinction between the Content Object and the site Chrome
  • To establish a metaphor of View and Sub-View in a way that is logical
  • To reduce interface clutter by either removing less-common elements or moving them to positions of non-prominence.
  • To increase overall joy within the confines of using the interface

Feature Map

[edit]

Mobile smartphone

[edit]
[edit]

It is important to remember that knowing more than one language is extremely common except in the United States. Effort should be spent to reflect the potpourri of our readership rather than assuming a Western bias. Surfacing inter-wiki language on the mobile device is a priority because:

  • The ability to read articles in additional languages was one of the most requested features when the new mobile gateway was launched.
  • Around 70% of our world-wide reader base is bilingual and a significant percentage of those individuals are tri-lingual.

Since it is not an easy manner to express the existence of inter-wiki links in a mobile format, access to inter-wiki links must be collapsed to a single icon. Since access to inter-wiki links is a "Content Actions", the control is placed in the "sliders".

Regrettably, the label for the icon cannot be more than a single word, so the bulk of the heavy lifting must be done by the iconography itself. A "globe" has been chosen as the best solution for this.

Clicking on the button will bring up a device-standard "select" pulldown, with languages.

Tablet and Browser

[edit]

These features are not available at the "mobile" display resolution.

User-configurable master menu

[edit]

The top menu (of Site Actions) is to be user-configurable. Registered users will have the ability to add or remove links to various Site Actions (such as "Upload File", "View Help", or "View Recent Changes."

There will be a "stock" version which will be minimal. Non-stock Site Actions will be located in the interface footer.

(Note that the "master menu" may not be desired and could be cut completely. However, there are design considerations, especially revolving around the use of the Wikipedia mark and logo).

"Slider" Behavior

[edit]

In all formats, Athena replaces context "tabs" with "sliders." These sliders are located at the bottom of the screen and are absolutely positioned (in all modes, though they will normally be hidden during mobile viewing).

Primary Mode vs. Secondary Mode

[edit]

The sliders effectively transmit information about the user's "viewing mode". In most pages, there are two "primary modes:"

  • Page Text
  • Page Discussion

(An exception lies with most Special pages; these have only a single primary mode.)

Additionally, each primary mode likely has multiple "secondary modes":

  • History
  • What Links Here
  • Permanent Link
  • Related Changes
  • Print/Export Functions
  • Atom (some special pages)

Further, there are additional actions special to users, which may be primary modes:

  • Contributions
  • Logs
  • WikiLove
  • Email User

Chrome Behavior

[edit]

This section describes the behavior of the site "chrome".

Mobile

[edit]

Upon page load, both the top bar and the bottom sliders will be visible. After a short time (say, 1 second), these elements disappear from the screen.

Tapping on the screen (anywhere) will cause both the top bar and bottom sliders to re-appear and be usable for manipulation.

When the user reaches the bottom of the page, the sliders will "lock" against the footer and move upwards until the limit of the footer has been reached.

Tablet and Browser

[edit]

Upon page load, the top bar and the bottom sliders will be visible. As the user scrolls down, the top bar will scroll out of the viewing pane. The sliders will remain in view at all times, absolutely positioned at the bottom of the viewing screen.

When the user reaches the bottom of the page, the sliders will "lock" against the footer and move upwards until the limit of the footer has been reached.

Gadget Gutter (Tablet and browser only)

[edit]

The layout of pages in tablet and browser mode include a "gutter" on the right side (a column that is approximately 150 pixels in width). This space is intended for tools, functions, and extensions that may require additional space (such as inter-wiki links, Global Profile actions, Moodbar triggers, etc.).

When not needed, the gutter "disappears" and the content expands to the full size.

(This entire feature is a work in progress.)

Visual Style

[edit]

Color Scheme

[edit]

Athena's color scheme is both minimal and bold. The use of a primarily monochromatic theme creates a strong distinction between the site's "chrome" and the content areas; there is little chance for confusion.

Further, it is designed so that strong colors "pop" better and call attention to available actions (such as the "Edit Page" button).

Iconography

[edit]

Wikimedia brands are top-tier websites. The style of its iconography should be minimalist, user-friendly, powerful, and distinct. Accordingly, the use of externally-made "open source" icon libraries is strongly deprecated because:

  1. Icons within these sets are rarely designed specifically for the function that they are being used for (e.g., they get overloaded with meanings) because different organizations use the same icons for different functions;
  2. We're Wikimedia. We have our own voice; we don't have to use someone else's as second-hand;
  3. Most of the public domain icon sets look like they'd be right at home in Windows XP or any other 10 year old operating system

Other

[edit]

"Your" versus "My"

[edit]

Accelerator terminology for user-owned content pages (talk, preferences, watchlist, etc.) has changed from using "My" to "Your" (e.g., a move from "My Watchlist" to "Your Watchlist"). The reason for this change is that referring to "user owned" content as "my" is an asocial pattern. Users are having "conversations" with the website (in this case, Wikipedia). In many cases, "my foobar" is read by the user as the website saying "this is mine". We're going to switch to a different pattern.

Known issues/In progress

[edit]
  • Interwiki language links are a difficult problem in the tablet and browser modes.
  • Non-Javascript browsers - the design, as currently conceived, does not pay great heed to browsers that do not have Javascript enabled.

Functionality

[edit]

These are WIP pieces that we think might be useful functionality carried by the new redesign.

  • Try to show more relevant vitality data under the header so that a user understands how current the article is and how many images are associated with this article.
  • Consider how we might enable some light previewing that is available in Navigation Popups.
  • Ability To browse Images from commons and Filter by different categories.

Video Q&A

[edit]

Session recorded 2011-11-04 at Wikimedia offices in San Francisco:

Prototype Code

[edit]

Subpages

[edit]

Additional subpages to this page.