Jump to navigation Jump to search
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.
Toolbar Upgrades: Icons
- 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.
Toolbar Upgrades: Button Interaction
- 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.
Toolbar Upgrades: Dialogs
- 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
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
- 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.
Table of Contents + Help
- 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
- Highlights current section.
Some early designs looking forward past the Babaco Release.
Full Screen Edit Mode
- 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