Internal document This is an internal document

While making small fixes to this page like fixing typos and dead-links is encouraged, any changes which significantly modify the information of this page should be suggested on the discussion page instead, as this is an internal document.

We welcome your constructive feedback. Please use the Discussion page for all of your comments.

Tabbed Navigation

Motivation

  • Introducing tabs that can be used within content generation dialogues and a right column.
  • The active tab should be a part of the page.
  • Emphasizing special functionality of tabs --> For example: The Edit link is unique and very important. It's different from a link in the left nav (like "Help" or "Mainpage") so it should look different.
  • Achieve consistent design

Approach

  • Real tabs (not open at the top).
  • Rounded corners
  • Gentle gradient background
  • Blue background indicates a link
  • Gray background (="empty tab") and red link indicates a not existing page

Layout

Motivation

  • Take advantage of horizontal screen real estate without sacrificing readability page/article contents
  • Create space for contextual editing tools on edit pages only
  • Design layout of right navigation bar for possible inclusion in all Wiki pages.
  • Achieve a more predictable layout
  • Improve readability of article content without alienating any particular browser/screen configuration of our users

Approach

  • Fixed width left and right columns
  • Elastic content column
  • Accommodates users with smaller (800X600) screens and is ideal for our users average screen size
  • Right column only exists on edit pages.


Color Scheme

Motivation

  • Add more visual cues for page navigation, points of interaction, action, selection, etc.
  • Carefully use color for emphasis of page, tabular, and organizational structure.

Approach

  • Maintain historical consistency with wiki colors - blue for links, red for yet-to-be-started pages, yellow for selection - in a unified color palette.
  • Maintain sitewide consistency with colors across different pages.
  • Use more readable and differentiable colors. I.e. the dk. gray tested by many online newspaper sites. Use highlight, selected, dynamic, or static cue colors when appropriate.
  • Introduce color only as needed to solve specific navigation issues.

Toolbar Upgrades: Icons

GNOME icons

Motivation

  • Improve comprehensibility
  • Achieve consistent design

Approach

  • Adapting Gnome-Icons
  • Monochrome and simple in color treatment
  • Gentle shiny "button" style

Resources

  • Learn how to make a "Bold" or "Italics" icon for your language here.

Toolbar Upgrades: Button Interaction

Motivation

  • The current toolbar has a singular mode of interaction
  • We want the buttons to reinforce selection: This reinforces the user's sense of it being "click able" and their mouse selection.
  • We want it to reflect state: If my cursor is in a section that is already bold, it would be beneficial to have the toolbar/buttons convey this.

Approach

  • Add mouse over behavior to toolbar buttons to improve interaction and experience.
  • Explore the possibilities of the syntax highlighting/development necessary to enable the toolbar with 2-way interaction.
  • If possible, add "selected" look and behavior to toolbar buttons.

Toolbar Upgrades: Dialogs

Motivation

  • Make it as easy to add links, images, references as it is to add and format text.
  • Allow users to create and insert these without needing to know wiki syntax
  • Create an intermediate between rich-text and wiki syntax for special insertions: links, references, media, tables

Approach 1

  • Create dialogs that can be used for insertion, but that can also be used for editing those links, references, etc.
  • Be as smart and give as much feedback to the user when creating/inserting these elements
  • Achieve consistency of interaction across all dialogs.

Approach 2

  • Unified UI for internal and external links using software to guess the intention of the user, but still allow the user to force the link to be internal or external
  • Give feedback for internal links as to whether the link is to an existing page or not
  • Greatly simplify the options for tables
  • Provide a preview of what the table will look like

Insert table dialog

Please visit Sandbox3 to test the dialogs.

We are not sure about the preview

  • Because it does not reflect the table dimensions
  • It reflects tableborder, sortable table amd header row only
  • People might want to edit this preview-table, which is not possible. Therefor the preview should be named "Example" and should look not editable. (See mockup #1 - #2)
  • Maybe it is a wiser decision not to show this preview/example at all. (See mockup #4)

Editing Interface Improvements

Motivation

  • Users got lost while previewing
  • Users did not consistently locate and make use of the terms of contribution, edit summary, minor edit and watch controls
  • Users with different sized screens may wish to adjust the size of the table of contents or even hide it completely
  • Many users were not fully aware of the effects of clicking save (you've now changed Wikipedia!)

Approach

  • Make preview a mode of the editing interface activated with a set of tabs
  • Only show terms of contribution, edit summary, minor edit and watch controls when a user clicks the publish button using a modal dialog.
  • Add hide and show control for the table of contents as well as drag-and-resize grips on the left side of the table of contents and a grip icon at the bottom.

Table of Contents + Help

Motivation

  • Allow users to navigate the editing of the article as they do the article itself.
  • Give users a sense of where they are (or rather, their cursor is) in the structure of the article.
  • Possibly provide help in this right column real estate as well.

Approach

  • Dynamically laid out table of contents.
  • Jumps to section on click
  • Scrollable.
  • Highlights current section.

Beyond Babaco

Some early designs looking forward past the Babaco Release.

Left Navigation

Full Screen Edit Mode

 

Motivations

  • More screen real estate for editing tools and help
  • A more "defined" editing process and space
  • Simplifying the editing experience by removing less useful links and navigation.

Approach

  • Use left and right columns for non-toolbar editing tools
  • Keep main sitewide navigation
  • Remove less relevant sitewide links

Messages

 

Motivation

  • Prevent messages on discussion pages (as well as article pages) from overwhelming users and distracting from the content.
  • Prevent messages from taking a full screen of real estate - obscuring content.
  • Give users control for how they view, show, hide messages.

Approach

  • Make messages collapsible
  • Provide toggle to show and hide messages
  • User right column for messages on article pages?
  • Ranking system for message type?

Discussion

Motivation

  • Users were not able to easily identify the timeline of discussions
  • Users had trouble knowing where to contribute to the discussion
  • Users often did not know how to, that they should, or simply forgot to add a signature
  • Processes like Featured content and deletion candidates must have complex templates and be managed manually

Approach 1

 

Approach 2

 
  • Integration of reply and internal link views into the post they are in relation to
  • Avoid obscuring information with the toolbar