Design/Archive/Wikimedia User Interface

 Problems we're solving & Goals User stories Share your story Collaborate with us

=Currently working on...=

High-priority 1 - Enhance accessibility of MediaWiki UI library / OOjs UI to screen readers and color-deficient users
 * Improve color palette to comply with WCAG 2.0 and color-deficiency-friendly.
 * Update the documentation for recommended color palette
 * Gray for "inactive" elements in the toolbar is too light
 * Inactive notification badge colors not compliant with WCAG 2.0 accessibility guidelines
 * Blueprint should make use of HTML5 and element with correct ARIA roles
 * Create landmarks for screen reader
 * Wrap MediaWiki footer to HTML5 tag
 * OOjs UI Input validation should be annotated with more ARIA attributes
 * Accessibility for keyboard users and screen readers

High-priority 2 - Standardize MediaWiki components
 * Support a responsive grid system
 * Use consistent preferences icon in Echo
 * Date and time input widgets
 * mw-ui-buttons should have a max width
 * Button styles differ between OOjs UI and mediawiki UI (tracking)
 * toaster overlay for watchlisting is inconsistent between mobile and desktop
 * Buttons on login page are inconsistent
 * Button group active item should not have hover or click effects.
 * Use consistent help icon in VE, Echo, and elsewhere
 * DateInputWidget: popup shouldn't have a blue border
 * ToggleSwitchWidget shouldn't be solid blue
 * Consider consolidating progressive and constructive buttons
 * Make Special:ListFiles follow OOjs UI

High-priority 3 - Improving differences between implemented components and in pholio mock-ups
 * Re-design of drop-down menu
 * ToggleSwitchWidget's background-color and box-shadow transition is not in-sync
 * ToggleSwitchWidget's circle icon should be larger
 * ToggleSwitchWidget is pixelated
 * Getting CheckboxInputWidget to design spec
 * Getting RadioSelectInputWidget to design spec
 * Consolidate differences between ButtonWidget (icon only, framed)‎ and ButtonWidget (indicator only, framed)‎
 * Disabled icon on any ButtonWidget should be gray. Currently green.
 * Icon color does not currently change on any mouse interaction.
 * Button's background-color and box-shadow transition is not in-sync
 * Consolidate different button types into a single style

Full to-do list

We manage our project, tasks and bugs on Phabricator. View our complete to-do list.

Log in to Phabricator with your MediaWiki login credentials to be involved in this project.

= Problems & Goals =

Problems


 * A specific icon (i.e.: star icon) can have many different meanings (i.e.: featured article, watch list, watch current page, portal of the week). This happens throughout Wikimedia projects even within the same culture and language. Conversely, one meaning can be represented by a few different icons.
 * One component type (i.e.: button, menu) with the same use case is implemented in many different ways
 * Deficiency in being screen-reader and keyboard-user accessible
 * Deficiency in being color blind-friendly and photophobia-friendly
 * Lack of mobile support and components are not finger-friendly (touchscreen-friendly)

Goals


 * Standardize Wikimedia's user interface components (i.e.: button, dropdown menu, radio button, list, etc.) so that they visually look and feel the same across any templates and pages within WikiProjects, Wikipedia article pages, every language Wikipedia, MediaWiki documentation pages, Meta-wiki, and so on.
 * Strengthen the mental model of our components (i.e.: button, menu, dropdown, text field) by reusing the same component type for the same use case (example: To “delete a comment," we should always use a red button. We should never use a green button to “delete a comment.” Conversely, we also shouldn’t use a red button to “create a new topic.”)
 * Make sure that Wikimedia project sites are largely accessible for the visually-impaired using screen-readers
 * Make sure that Wikimedia project sites are largely accessible for the color blind and photophobic
 * Make sure that Wikimedia project sites are largely user-friendly at all device sizes
 * Support for bi-directional - RTL (right-to-left) and LTR (left-to-right) language text

Questions & answers how we did prioritize on those goals.

Let us know if we're missing anything else under "Goals"

= Challenges & Execution =

Challenges


 * Wikimedia projects are built and improved by a large community of both technical and non-technical contributors. With that in mind, the solution must also be accessible for all kinds of contributors.
 * Our users' and contributors' use cases are varied across languages, cultures, projects and content types. With that in mind, our solutions should be a fundament for flexible use cases while preserving consistency.

Execution

To solve our current interface challenges, we have resorted to building a library of components. This library will conform to these guidelines to achieve all listed goals above: We want to hear about your thoughts around this execution method.
 * Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA)
 * Web Content Accessibility Guidelines (WCAG 2.0)

=Team=


 * MGalloway (WMF) / violetto / IRC: violetto ([mailto:may@wikimedia.org Contact me] for design-related questions)
 * Volker E. (WMF) / Volker_E / IRC: Volker_E ([mailto:volker@wikimedia.org Contact me] for all organisational and technical questions)

=See also=
 * [ Create a new task] in this project (Tag project "UI-Standardization" under "Projects" field)
 * Work-in-progress library called OOjs UI
 * The Need for Web Design Standards by Jakob Nielsen
 * May Galloway on the need for consistency at Wikimania 2014 • Slide deck