Description

Other WYSIWYG Inteface Proposals

Proposal Number 1

This first proposal would keep the familiar buttons & dialog boxes interface. Buttons would be available in one long toolbar and provide access to all features, using inline dialog boxes (instead of the current popup dialog boxes) as needed to provide further options to the user.

For instance, an user wants to add a macro that places a given location on a Google Map plan and displays it in the wiki page :

• He clicks on the "Macro" button
• A dialog box opens, asking him to choose the macro he wants to use
• He selects the macro he wants by double-clicking on it
• A 2nd dialog box opens, letting the user input the macro's parameters
• The user clicks on "Save", the result of the macro is displayed on the page
  The look of the current implementation of the WYSIWYG editor :
  
• Pros :
  • Easy to implement as the foundations are already there
  • Does not require extensive maintenance
  • Every feature is available one click away
  • Can be made to keep only a subset of all buttons in smaller textareas
  • Works fine up to 20 toolbar buttons
• Cons :
  • Can quickly become cluttered, especially with a lot of buttons -> harder for users to find what they're looking for
  • Does not make a distinction between commonly used features and others, less used features
  • Might lead to a dialog box overload (lot of dialog boxes to perform any kind of advanced action) Could be addressed using modal dialog boxes in combination with wizards.
  • Additional, less-often used features still need to be catered for.

Proposal Number 2

This second proposal is closer to common Desktop Implementations (such as OpenOffice or Word 2003) of a rich text editor. It features a toolbar that provides access to basic, commonly used features and a top bar with drop-down menus to give access to other features. This solution should be complemented with modal dialog boxes.

The look of the Google Sites editor :

• Pros :
  • Easy to use for users familiar with usual Desktop interfaces
  • Easy to extend as new features can be added in submenus as required
  • Makes it easy to display a lot of items, usual text features are always one click away
  • The lighter toolbar can be used on its own in smaller textareas
• Cons :
  • Might lead to a nasty game of "do not hover over the wrong part of the menu" if poorly implemented
  • Would not include all tha advanced features (only the toolbar) when used in degraded mode for smaller textareas
  • Would require extensive cross-browser testing to make sure everything works fine, things might break more easily Marius, the WYSIWYG lead developer, doesn't think it's gonna be specifically harder.
  • Some submenus will include a lot of items (the insert menu already does)

Proposal Number 3

In this proposal, the editor menu would be divided in tabs that would provide quick access to the various features offered by the WYSIWYG editor. An inspector would be made available in option to manage settings for macros or links (instead of dialog boxes)

The look of the suggested editor :

An artist view of the tabbed editor (those are definitely not the real colors that would be used) :

Second artist view of the suggested tabbed editor :

• Pros :
  • Provides quick and intuitive access to many features
  • Limits the number of dialog boxes & drop down menus, makes efficient use of space
  • This kind of interface is purportedly more intuitive for users (at least from Microsoft usability testing labs PoW)
• Cons :
  • Potentially makes the toolbar one click away at any given time (see below for discussion)
  • Lacks flexibility
  • Issues may arise if the space allocated to dialog boxes isn't enough to display all the necessary information
  • The suggested dialog boxes will cover textareas without allowing users to move them to look at the underlying content.
  • Will the editor really scale ? What if some tabs do not need to include some sub-features ?
  • Many people are annoyed with the new MS Office "ribbon" layout
  • Right now content types (text, links, macros) are mixed with actions (insert, import, create) which does not make sense
  • The actions might not be visible enough on the first screenshot (save, undo...)

One way to make this option work without making the toolbar go away everytime would be to switch back to the toolbar once any given action has been completed :

• An user wants to copy/paste content from a Word document into a wiki page
• She clicks on the "Import" tab
• She then clicks on the "Word" button
• The dialog appears
• She pastes her Word content into the relevant textarea
• She clicks on "Save"
• The content is displayed on the page -> this means that the Word Copy/Paste action is finished
• The WYSIWYG menu displays the toolbar (the "text" tab is active) again without the user having to click on it

This way, the toolbar is always the default available choice but we still benefit from the tabbed layout.