Skip to Content

Changes for page Improved edit mode

Last modified by Ecaterina Moraru on 2018/09/26 16:02
From version 7.4
edited by Ecaterina Valica
on 2010/01/22 17:23
Change comment: Added comment
To version 19.3
edited by Ecaterina Valica
on 2011/06/15 23:19
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +Improved edit mode
Content
... ... @@ -1,9 +1,88 @@
1 -= Improved edit mode =
1 +== Community Feedback ==
2 2  
3 -[[image:EditingWikiforDummy.png]]
3 +{{info}}Discussed: [VOTE] Edit UI improvements and panelless edit: http://xwiki.markmail.org/thread/qq5zixa2qyqkppcj{{/info}}
4 4  
5 +== Goal ==
5 5  
6 -[[image:objed.png]]
7 +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.
7 7  
9 +== Overview ==
8 8  
9 -[[image:clsed.png]]
11 +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.
12 +
13 +In all the edit modes, there are no panels on the right side anymore.
14 +
15 +[[image:plwed.png]]
16 +
17 +[[image:plged.png]]
18 +
19 +[[image:ploed.png]]
20 +
21 +[[image:plced.png]]
22 +
23 +== Individual changes ==
24 +
25 +=== Wiki editor improvements ===
26 +[[image:plwed1.png]]
27 +
28 +==== 1. Parent and title above the content in wiki/wysiwyg mode, having the same look as they do in view mode ====
29 +
30 +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.
31 +
32 +==== AjaxSuggest for the parent field ====
33 +
34 +image:plwed2.png
35 +
36 +==== 2. List of included documents above the content, and a new label for the content ====
37 +
38 +==== 3. Syntax switcher and syntax help above the content area ====
39 +
40 +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.
41 +
42 +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.
43 +
44 +==== 4. Better label for the version comment field ====
45 +
46 +"Comment" is really not intuitive.
47 +
48 +==== 5. Better position and display of the "minor edit" field ====
49 +
50 +The current position, right next to the Comment label, is crowded and not intuitive, since the checkbox is right between the two labels.
51 +
52 +==== 6. Better position for the autosave field ====
53 +
54 +IMO it is closely related to the save buttons, so it should be near them.
55 +
56 +=== Object editor improvements ===
57 +
58 +image:ploed1.png
59 +
60 +==== 7. Quick access to adding a new object ====
61 +
62 +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.
63 +
64 +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.
65 +
66 +==== 8. Quick access to add a new object from the same type ====
67 +
68 +Again, AJAX-powered. The new object is displayed expanded initially, since the user probably wants to edit the object that he just added.
69 +
70 +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.
71 +
72 +=== Class editor improvements ===
73 +
74 +image:plced1.png
75 +
76 +==== 9. Class switcher at the top of the editor ====
77 +
78 +This switcher now prompts to save the current class before leaving the page.
79 +
80 +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:
81 +
82 +* it lists only classes, while GTP requires that the user knows at least part of the target classname
83 +* it goes to the class editor, not to the view more or the content editor
84 +* it separates classes by their space, to faster find the right class
85 +
86 +==== 10. Quick access to add a new property ====
87 +
88 +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.
AdvEditMode.pdf
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Size
... ... @@ -1,0 +1,1 @@
1 +242.8 KB
Content
AdvEditMode.svg
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Size
... ... @@ -1,0 +1,1 @@
1 +455.6 KB
Content
cExpanded.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Size
... ... @@ -1,0 +1,1 @@
1 +46.3 KB
Content
plced.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Sergiu
Size
... ... @@ -1,0 +1,1 @@
1 +47.0 KB
Content
plced1.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Sergiu
Size
... ... @@ -1,0 +1,1 @@
1 +51.4 KB
Content
plged.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Sergiu
Size
... ... @@ -1,0 +1,1 @@
1 +37.2 KB
Content
ploed.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Sergiu
Size
... ... @@ -1,0 +1,1 @@
1 +55.1 KB
Content
ploed1.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Sergiu
Size
... ... @@ -1,0 +1,1 @@
1 +60.3 KB
Content
plwed.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Sergiu
Size
... ... @@ -1,0 +1,1 @@
1 +53.5 KB
Content
plwed1.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Sergiu
Size
... ... @@ -1,0 +1,1 @@
1 +59.7 KB
Content
plwed2.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Sergiu
Size
... ... @@ -1,0 +1,1 @@
1 +23.5 KB
Content
propE1.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Size
... ... @@ -1,0 +1,1 @@
1 +71.8 KB
Content
XWiki.XWikiComments[3]
Date
... ... @@ -1,1 +1,1 @@
1 -2010-01-22 15:52:34.642
1 +2010-01-22 15:52:34.0
XWiki.XWikiComments[4]
Date
... ... @@ -1,1 +1,1 @@
1 -2010-01-22 15:55:33.416
1 +2010-01-22 15:55:33.0
XWiki.XWikiComments[5]
Date
... ... @@ -1,1 +1,1 @@
1 -2010-01-22 16:09:35.402
1 +2010-01-22 16:09:35.0
XWiki.XWikiComments[6]
Comment
... ... @@ -3,5 +3,5 @@
3 3  Three minor comments:
4 4  
5 5  * I'd make the title field larger than the parent field, because you usually need to write more in the title field. Of course, then they might look a bit unbalanced, so if this turns out to be an issue they can be left with equal sizes.
6 -* Re "All languages will be in the menu, but will be shown active just the versions that exists for this page" -- indeed there must be a difference between the appearance of entries for existing translations and non-existing translation, but I wouldn't say non-existing translation should look/be inactive, because the user should be able to create a new translation, and be aware of this possibility.
6 +* Re "All languages will be in the menu, but will be shown active just the versions that exists for this page" - indeed there must be a difference between the appearance of entries for existing translations and non-existing translation, but I wouldn't say non-existing translation should look/be inactive, because the user should be able to create a new translation, and be aware of this possibility.
7 7  * I'm not sure about listing the included documents before the text area, but I can't come up with a much better place either. One option is to list them under the text area, because they are not that important. However, this position would really decrease their visibility.
Date
... ... @@ -1,1 +1,1 @@
1 -2010-01-22 16:19:14.509
1 +2010-01-22 16:19:14.0
XWiki.XWikiComments[7]
Date
... ... @@ -1,1 +1,1 @@
1 -2010-01-22 16:22:03.135
1 +2010-01-22 16:22:03.0
XWiki.XWikiComments[8]
Date
... ... @@ -1,1 +1,1 @@
1 -2010-01-22 16:23:52.874
1 +2010-01-22 16:23:52.0
XWiki.XWikiComments[9]
Date
... ... @@ -1,1 +1,1 @@
1 -2010-01-22 16:23:59.262
1 +2010-01-22 16:23:59.0
XWiki.XWikiComments[10]
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Comment
... ... @@ -1,0 +1,1 @@
1 +:)
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 16:24:11.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +8
XWiki.XWikiComments[11]
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Comment
... ... @@ -1,0 +1,1 @@
1 +[[image:propE1.png||width="900px"]]
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 16:43:16.0
XWiki.XWikiComments[12]
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Comment
... ... @@ -1,0 +1,1 @@
1 +I've put the included documents before the text for cases like Blog.BlogCode, when you have pages that contain just included doc and you don't need to scroll to be able to access them.
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 16:45:54.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +6
XWiki.XWikiComments[13]
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Marta
Comment
... ... @@ -1,0 +1,1 @@
1 +For included documents: the brackets should either be around "Includes" as well, or should disappear completely. Otherwise, this looks great.
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 16:50:07.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +11
XWiki.XWikiComments[14]
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Comment
... ... @@ -1,0 +1,1 @@
1 +done - thanks for all the feedback
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 16:52:40.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +13
XWiki.XWikiComments[15]
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Marta
Comment
... ... @@ -1,0 +1,1 @@
1 +Just a thought: would the "autosave" part go better on the same line with the form buttons? IMO, semantically, it is more related to the buttons than to the change comment.
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 16:54:51.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +11
XWiki.XWikiComments[16]
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Comment
... ... @@ -1,0 +1,1 @@
1 +I didn't test autosave, but every 5 minutes the page saves with the comment described and as minor change if selected?
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 17:11:56.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +15
XWiki.XWikiComments[17]
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Comment
... ... @@ -1,0 +1,3 @@
1 +so autosave acts like a minor change with the current comment - the position is ok if we thing autosave apply those fields.
2 +
3 +Being on the line with buttons would describe the save action better. Would fit so well though.
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 17:24:25.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +16
XWiki.XWikiComments[18]
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Marta
Comment
... ... @@ -1,0 +1,1 @@
1 +I just realized the tags are missing from all the proposals. Was that on purpose? If not, would it be OK to put them under the content?
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-22 21:03:11.0
XWiki.XWikiComments[19]
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.evalica
Comment
... ... @@ -1,0 +1,3 @@
1 +If we put them under the content we really need the separator helping text "Comma separated tags" and this separator shouldn't change to "|" when editing back the page.
2 +
3 +Are we sure we want tags in the edit mode? We already have a interface for them in the view.
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-23 01:02:16.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +18
XWiki.XWikiComments[20]
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.lucaa
Comment
... ... @@ -1,0 +1,8 @@
1 +The source tab shouldn't be there, transforms the Wysiwyg editor in a wiki editor and makes things sort of inconsistent. For example,
2 +* we cannot remove this help on wiki syntax, although it's completely irrelevant for users seeing the wysiwyg editor (I think pretty few of them move to Source)
3 +* we cannot remove the syntax selector all together, which doesn't make sense at all in a wysiwyg editor (actually, the syntax selector would be useful for the source tab which disappears anyway when you change syntax, it's doesn't make too much sense),
4 +* it doesn't look good together with the Content label (having Content, Wysiwyg, Source), all there looks bad.
5 +* and, last but definitely not least, we already have the wiki editor to edit wiki, that's just duplicated functionality, we should set for only one of them and my vote goes for wiki editor
6 +* oh, and also it's not displayed when editing wysiwyg an inline form (blog for example).
7 +
8 +WDYT?
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-23 20:42:34.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +5
XWiki.XWikiComments[21]
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.Marta
Comment
... ... @@ -1,0 +1,1 @@
1 +Re "The source tab shouldn't be there, transforms the Wysiwyg editor in a wiki editor and makes things sort of inconsistent": BIG +1, the tabs on top of the wysiwyg really shouldn't be there.
Date
... ... @@ -1,0 +1,1 @@
1 +2010-01-24 23:06:42.0
Reply To
... ... @@ -1,0 +1,1 @@
1 +20