Improved edit 2

Last modified by Vincent Massol on 2024/02/26 17:53

 XWiki
 Design
 Completed

Description

Community Feedback

Discussed: [VOTE] Edit UI improvements and panelless edit: http://xwiki.markmail.org/thread/qq5zixa2qyqkppcj
JIRA: http://jira.xwiki.org/browse/XWIKI-6404

Goal

The goal is to improve the usability of the edit modes, and to give more space to the edit area by removing the edit mode panels, which don't bring real value.

Overview

Note that the images have a smaller edit area, in order to fit inside the content area of this page, so they look a bit more crowded than they will be in practice.

In all the edit modes, there are no panels on the right side anymore.

plwed.png

plged.png

ploed.png

plced.png

Individual changes

Wiki editor improvements

plwed1.png

1. Parent and title above the content in wiki/wysiwyg mode, having the same look as they do in view mode

The advantage is that they have consistency, being in the same place as the view interface, so the user knows where to look for them. A minor possible problem is that they might not look like editable fields at a first glance, since they don't have the classic size and color of normal input fields.

AjaxSuggest for the parent field

plwed2.png

2. List of included documents above the content, and a new label for the content

3. Syntax switcher and syntax help above the content area

I believe that the syntax of the content is a very important setting, and it is closely related to the content, so the syntax chooser should be as near the content as possible. The same thing for the syntax help, since a side panel can easily be overlooked.

Also note that the syntax help and switcher are not present in the WYSIWYG editor, since the wiki syntax is not relevant in such an editor. Still, this is debatable, since the WYSIWYG editor has the Source tab.

4. Better label for the version comment field

"Comment" is really not intuitive.

5. Better position and display of the "minor edit" field

The current position, right next to the Comment label, is crowded and not intuitive, since the checkbox is right between the two labels.

6. Better position for the autosave field

IMO it is closely related to the save buttons, so it should be near them.

Object editor improvements

ploed1.png

7. Quick access to adding a new object

This is AJAX-powered, meaning that the object will be added without reloading the page and loosing the changes. However, it does create a new version in the background.

A debate is whether to put it before or after the list of existing documents. I've put it on top since a user that goes to the object editor and wants to add a new object should not have to scroll past the existing objects.

8. Quick access to add a new object from the same type

Again, AJAX-powered. The new object is displayed expanded initially, since the user probably wants to edit the object that he just added.

The same debate about the position. I placed it after the existing objects, since the object will be added there (objects are always sorted by their number). Otherwise, in a list of many objects, the user could click at the top of the list, then not see the new object, which appeared bellow the window margin.

Class editor improvements

plced1.png

9. Class switcher at the top of the editor

This switcher now prompts to save the current class before leaving the page.

It would be possible to remove it completely, since now we have the JumpToPage feature for quick access to other documents, but IMO we should keep it, since:

  • it lists only classes, while GTP requires that the user knows at least part of the target classname
  • it goes to the class editor, not to the view more or the content editor
  • it separates classes by their space, to faster find the right class

10. Quick access to add a new property

AJAX-powered, the new property is added expanded at the bottom. I placed it at the top, although I think it should be at the bottom, since the property appears at the end of the list.


 

Tags:
    

Get Connected