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

• 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

• 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

• 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

• 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.

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

• 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.

• Improve comprehensibility
• Achieve consistent design

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

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

• 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.

• 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.

• 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

• 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.

• 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

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)

• 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!)

• 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.

• 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.

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

Some early designs looking forward past the Babaco Release.

• 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.

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

• 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.

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

• 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

• Made posting isolated, as opposed to editing entire discussion
• Enforced structure of discussion to represent threading and order
• Posts are always signed automatically
• Enable users to watch only their discussion
• Set default parameters and structure automatically
• See also strategy:Proposal:Stop using wikis for tasks for which wikis are not suitable

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

Retrieved from "https://usability.wikimedia.org/w/index.php?title=Babaco_Designs&oldid=6681"

Category:

• Internal documents