Description

Appendix - Additional Considerations

This page will list additional design guidelines related to the new WYSIWYG editor.

All the prototype screenshots in this document are created using a Firefox with altered font sizes (smaller), that is why it might seem like too much white space is used for too little text. For comparison, see a screenshot of the webpage dialog in default font size at dialog-defaultsize.png..

{toc:initlevel=2|maxlevel=5}

Modal box titles

A) (current implementation direction)

There are 2 titles in all dialogs: the actual dialog title and the step title displayed in the dialog top.

The idea is to have the dialog title express the action being performed (insert a macro, insert a link to a wikipage, etc), consistent with the menu path chosen to get to this dialog, and the wizard step illustrate the current subaction, describe the current step towards the action to perform (select a macro, select a wikipage to link to, select the image to insert, etc). Also, the step title should be aligned to the left, consistent with the left alignment of the vertical forms used in the dialogs and highlight the main action (placed to the left as the general wiki rule says it).

Overall, these two titles should be enough to point to the user where he is going (what is the action he's performing) and what he should do at the current step to achieve that goal.

B) another proposal is, as described at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog , to have the dialog title always identical with the clicked menu (e.g. "Link" or "Image") and an additional description below the step title for the current step. 

I discussed pros and cons for these approaches and variations at http://xwiki.markmail.org/message/a7kxn46mvbkr2kjg?q=default+look+of+dialog+list:org.xwiki.devs+from:%22Anca+Paula+Luca%22 .

Buttons

The "Previous", "Next" and "Finish" (in the screenshots, "Create Link") buttons shall be displayed at all times and shown as disabled when needed. See http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog for images.

See next images for prototypes:

with the following enable / disable variations depending on what are the possible steps from that point on:

.

Button names

Instead of using generic terms in modal box form buttons, I suggest we use the actual action words instead. For instance, instead of "Finish" or "Apply", we could use "Create" or "Insert". The button naming should be consistent with the modal box top line if it's not the last screen of the modal box, or with the modal box' title if it's the last screen of the modal box.

For instance, in macro insertion, the modal box form button should read "Select" since the top line would read "Select a macro". On the second screen, it should read "Insert" (even though the top line would read "Edit macro properties") as the second screen is the last screen in the process and should thus have the same action name as the one of the modal box' title as it logically concludes the action sequence.

The following ASCII are provided for reference / example.

Macros - Step 1:

\

\ \

Macros - Step 2:

\

\ \

Marker for mandatory form fields in modal boxes

Right now, mandatory form fields are identified thanks to their color (their name is in green instead of grey), see the following print screen for an illustration: 

A

One proposal is to change this to using an asterisk ("*"), as a most usual way to mark mandatory fields across web forms. For this option, we have the following possibilities:

B  

C  

D  

E  

F  

G  

H

I

Error reporting

Whenever a dialog form is to be submitted and one of its fields contains invalid values, an error message for that field should be reported with a message above the input box for that field, printed in red. This should also be joined by a red field border for the concerned field. Another proposal is to have the error message under. See the following print screens for an illustration of these proposals.

A  

B  

C 1  

C 2

E

A is the version currently implemented.

For the case of an selection error in a list of pages, we have the following options:

A  

B 1  

B 2  

B 3  

C  

D

However, we generally (in wysiwyg dialog) use the error reporting illustrated at D to signal an error in manipulating or saving data (like something going wrong on the server during an asynchronous call) which does not depend on the user inserting correct data, something related to the whole dialog, and not a specific field, so for consistency reasons, we decided to avoid it in this case.

TODO: Convention for the error message style (description of the actual problem, description of the validation rule, description of how to fix it, advice for the user on how to fix it).

Field descriptions

All the forms in the WYSIWYG dialog boxes for inserting various objects should contain descriptions for their fields, aside from the field titles. These descriptions are to be expressed as advices for the user, to guide him in what he should do and to explain the result (instead of a longer description of the field). These descriptions are to be printed in a lighter color and smaller font, as less important than the actual field name. They should be displayed by default and not in tooltip or some other type of user action (for example click on a button to get this help text), because we shouldn't "make the user think" on how to get help.

For example, the input field to add the address of a webpage to link to would look something like this:

TODO: we need to make sure this kind of messages is consistent with the overall conventions for help messages in XWiki.