Hi, On Tue, Jan 26, 2010 at 9:09 AM, Vincent Massol <vincent@massol.net> wrote:

Hi Sergiu,

On Jan 25, 2010, at 9:37 PM, Sergiu Dumitriu wrote:

...

Hi devs,

We've been working on improving the editors (content, class, object), and now I have some pretty important UI changes to commit, but not everybody seems to agree with them, so I bring up a vote.

The whole improvements can be seen on http://incubator.myxwiki.org/xwiki/bin/Improvements/ImprovedEdit

I like them overall. Making the content and edit modes look more similar to one another sounds good to me.

I cannot check right now since incubator is down but Jean-Vincent has shown it to me 2 days ago. I'm assuming it's still roughly the same.

What I don't like:

* We're freeing horizontal space to increase vertical space (or cramping it). This is not logical since screens all have more width than height. * It adds a LOT of visual clutter. Now when I read a page (from top to bottom) I have to see the extra fields (parent, syntax, translations, included docs, help, etc). That makes me think about them before even reaching the important part which is the content part.

This could be fixed by moving the non-essential inputs (basically everything but parent & title) under the content area.

* Panels were meant exactly for this use case: to move stuff that are less important out of the main viewport to remove distraction. We're now suggesting to remove the primary benefit of panels.

The fact that currently panels are not the same in edit & view mode and the fact that users can configure view panels as they see fit but not edit panels is a usability problem too. Panels can be useful but it doesn't mean they're used to the best effect right now. Additionally, some panels are plain obnoxious (especially the translation & tags ones).

* It doesn't scale. Right now we have about 3 parameters: parent, syntax, translations. When we add more tomorrow (and we will since we'll allow other metadata to be edited for sure, we can imagine: hidden or not hidden doc, etc) we'll cramp even more the vertical space

Assuming adding metadata wouldn't scale with a vertical display while it would with a horizontal one sounds fallacious to me. Panels (or the lack thereof) are not directly related with how well the interface scales. Hiding less important metadata "under the fold" or in a hidden DIV that would be opened with a click could work fine too.

* The advantage of either being able to have view panels or more edit space is not compelling enough to me in view of all the disadvantages

For me this is a huge regression in term of making XWiki usable.

I disagree. If done well, I think this could make XWiki much easier to use. Having inputs located at the same place, with the same style that where content is displayed in view mode would be a big plus. There are some good ideas though but they can be implemented with panels on

the right: * AJAX suggest for parent field (even better if it's a dialog box in the future - same one as the one for creating a link in the wysiwyg editor would be great) * AJAX add object/property

So right now I'm a strong -1 for adding any clutter to the main viewport (unless I am convinced of course).

Since this is going to take time and since we should already have release XE 2.2 (and since any visual stuff takes at least 1 to 2 weeks to stabilize, fix introduced XHTML violations, WCAG violations, CSS issues breaking other places, etc), I'd also propose to postpone any change to XE 2.3M1.

Although I like the way Sergiu's suggestions are going, I agree with Vincent that this is major work that we can't possibly try making fit in XE 2.2 now without postponing the release & introducing a lot of instability. We have already introduced risk with Vincent's refactoring. I'm aware that some community members are looking forward to the WCAG / accessibility improvements we brought in XE 2.2 and I think it would be safer to provide a version that introduces them without re-hauling the whole XWiki Edit interface. Last but not least, these proposals have been discussed very little on the list so far and could benefit from additional refinements. Waiting for XE 2.3 would give us more time to make it work just right.

Thanks -Vincent

PS: It's really cool to look for new ideas. I just hope you haven't started coding it too much. It would have been better to propose it earlier so that we could have discussed it, not causing extra work for Marta and you. PPS: In your mail you haven't explained why you wanted to have panelless edits. Could you explain?

My personal take on this is that panelless edit would open the way to make inline edition a reality in XWiki. In practice this would mean that the content area (contentview.vm) could be replaced with the edit area while everything else would remain the same on the page (header, footer, panels). We could also load the edit part dynamically via AJAX, improving the speed and thus the perceived performance for the user. Last but not least, this would also bring us closer to unifying the edit & inline mode, which I believe would make XWiki more appealing for application developers. I've been developing applications lastly by adding metadata right above and under the content area in contentview.vm and being able to use the native XE content area & edit mode without mixing edit & inline is great and makes for a smoother user experience. I see Sergiu's proposal as a first and significant step in that direction and I think it's maybe actually not ambitious enough rather than the other way round ;-)

...

Here are the individual voted points:

Here's my take on what are relatively low-danger changes that could still be introduced in and benefit XE 2.2 M2:

0 Remove all panels in edit mode

...

1a Parent and title above the content in wiki/wysiwyg mode

1b The same style in edit mode as in view mode for the parent/title

fields

I think this can be done easily, at least for the title.

1c AJAX Suggest for the parent field

Doable too.

...

2a New label for the content textarea ("Content")

Doable.

2b List of included documents after the Content label

...

3a Syntax switcher in the top right corner of the content

3b Syntax help in the top right corner of the content

3c Syntax help and switcher only in the wiki editor

4 Better label for the version comment

Doable.

5a Right float the Minor edit field

Doable.

5b Put the Minor edit label after the checkbox

Doable.

6 Move autosave in line with the submit buttons

Doable.

...

7 Introduce new AJAX-powered Add Object i) above the objects ii) bellow the objects

8 Introduce new AJAX-powered Add Object from this class i) at the top of the list of existing objects ii) at the end of the list

9 Move the class switcher in the top right corner

9b Remove the class switcher

10 Introduce new AJAX-powered Add Property i) at the top of the list of properties ii) at the end of the list

Those might be done since I think Sergiu already has a working prototype. However it would be better to introduce them at the same time as panelless content edition mode since they're in the same spirit. Guillaume PS: Sergiu, I know all this would be much nicer if we were using Git and you could implement it in your own branch and share it whith whomever developer pleased you. Maybe this could be the right time to explore once again how XWiki development could take place using Git?

...

I vote +1 for all of the above, except 9b (-0), and with options 7i), 8ii), and 10ii)

-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

On 01/26/2010 09:09 AM, Vincent Massol wrote:

Hi Sergiu,

On Jan 25, 2010, at 9:37 PM, Sergiu Dumitriu wrote:

...

Hi devs,

We've been working on improving the editors (content, class, object), and now I have some pretty important UI changes to commit, but not everybody seems to agree with them, so I bring up a vote.

The whole improvements can be seen on http://incubator.myxwiki.org/xwiki/bin/Improvements/ImprovedEdit

I cannot check right now since incubator is down but Jean-Vincent has shown it to me 2 days ago. I'm assuming it's still roughly the same.

You should look, since it probably has changed since JV showed it to you.

What I don't like:

* We're freeing horizontal space to increase vertical space (or cramping it). This is not logical since screens all have more width than height.

That is not true, I measured it locally, and for the wiki editor the height from the end of the content menu to the bottom border of the content area increased from 642px to 650 px. Is 8px really such a huge price to pay for better consistency, faster access to fields, and better overall aspect (IMO)? As for cramping, I disagree again. Several of the items bellow actually make the UI clearer and easier to access, like moving the Minor edit field to the right, moving the Autosave in line with the buttons. The height does increase for the object editor, since we add new rows with links for adding objects, but this is acceptable, since it is faster to add a new object from the same type by clicking on the link at the end of the list of existing objects. We do the same in the WYSIWYG link dialog, and nobody complained about all the New Page entries all over the tree. Which one do you prefer: - I'm happily editing my objects (let's say it's a Presentation with many slides), and I want to add a new slide. I'm way down the page, so I have to scroll all the way up, find the panel with the select box, expand the select box, try to find the class in that list, then push Add, then scroll back down. I'm finally editing my new slide. - I'm happily editing my objects, and I want to add a new slide. I'm way down the page, so I click the link right there. I'm already editing my new slide.

* It adds a LOT of visual clutter. Now when I read a page (from top to bottom) I have to see the extra fields (parent, syntax, translations, included docs, help, etc). That makes me think about them before even reaching the important part which is the content part.

You also have to skip past the global menu, the logo, the search box, the content menu, the toolbar, the menu for the WYSIWYG, the two tabs of the WYSIWYG, and let's not count the browser's menu, location bar, tabbar, bookmarks, etc. But nobody complained about this. And there's the full screen edit. So, IMO it is logical, better, more consistent and easier to understand if the parent is above the title, exactly where it is in view mode. I believe that beginners won't know to look for it on the right, in a panel. To find it you actually have to scan the whole interface. And, since we're putting so much into having a parent for documents (why would we have an Orphaned Pages and why would we automatically set a parent for pages created from links otherwise), isn't it normal to show the parent field to the user in the most visible and accessible way? Are you saying now that the parent is not really important? And the content area is really hard to miss, it's that big thing in the middle of the page. Nobody really reads the page from top to bottom while looking for the content area. As I said on the Incubator (which right now is up): "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." The translations will be in the view menu as well in the future, so it will be in the same place in view and edit mode. And it is just an entry in the menu, which is already there, so it doesn't take up useful space.

* Panels were meant exactly for this use case: to move stuff that are less important out of the main viewport to remove distraction. We're now suggesting to remove the primary benefit of panels.

You say distraction, I say easier access and a more logical and easy to find position.

* It doesn't scale. Right now we have about 3 parameters: parent, syntax, translations. When we add more tomorrow (and we will since we'll allow other metadata to be edited for sure, we can imagine: hidden or not hidden doc, etc) we'll cramp even more the vertical space

Agile practice: Don't think about future use cases, write the minimal code that solves today's problems. Still, I don't think that we'll come up with so many new fields. But I have a solution for this, too. My goal is to have in-place edit in the future, which means that in edit mode (for the content at least) the bottom tabs will be present, and the Information tab could become editable, like it was for the tags, and we can add extra information in there. Another solution: the hidden setting can be placed in view mode somewhere in the More Actions menu. Another solution: like for the blog, the hidden setting can be an icon near the title in view mode. Of course, this works if there are more action icons. And I'm sure that when needed we'll find more and better solutions for our problems.

* The advantage of either being able to have view panels or more edit space is not compelling enough to me in view of all the disadvantages

For me this is a huge regression in term of making XWiki usable.

For me this is a huge improvement in terms of making XWiki usable.

There are some good ideas though but they can be implemented with panels on the right: * AJAX suggest for parent field (even better if it's a dialog box in the future - same one as the one for creating a link in the wysiwyg editor would be great)

Even better, as with the withTip class that triggers a JS behavior, there's the suggestDocuments class that enables ajax suggest for any input, not something custom for the title. About dialogs, I agree, and another future goal is to have most of the WYSIWYG tools work for the wiki editor too: link, macro, table, etc.

* AJAX add object/property

So right now I'm a strong -1 for adding any clutter to the main viewport (unless I am convinced of course).

Since this is going to take time and since we should already have release XE 2.2 (and since any visual stuff takes at least 1 to 2 weeks to stabilize, fix introduced XHTML violations, WCAG violations, CSS issues breaking other places, etc), I'd also propose to postpone any change to XE 2.3M1.

K.

Thanks -Vincent

PS: It's really cool to look for new ideas. I just hope you haven't started coding it too much. It would have been better to propose it earlier so that we could have discussed it, not causing extra work for Marta and you.

The work is already done (95%). Anyway, there wasn't that much work. The object and class editor improvements were actually done a long time ago (during 1.9), but were left uncommitted, and luckily survived the disk crash. And the wiki editor was progressively designed and implemented (JV started it), and there have been lots of discussions between the UI people, there are earlier drafts in the attachments of the page on the incubator.

PPS: In your mail you haven't explained why you wanted to have panelless edits. Could you explain?

Well, it seems that both JV and me reached the same conclusion independently. My reasons are: 1. I want to move towards in-place editing, where the page is really WYSIWYG. The inline editor does this right. The WYSIWYG editor should do the same. 2. In some edit modes the panels don't provide any real value. For example the rights editor really does not need the Welcome message, the help is very deprecated (speaks about inputs), and the tips are not that useful, and again deprecated. For the class editor, the only thing that brings value and is essential is the form for adding a new property, and IMO it belongs in the list of properties, not near it. Without it, all the panels for the class editor become useless, too. For the object editor again, the only thing that brings value is the Add Object form, and I strongly believe that the proposed solution is much better, and again, there are no panels left for the object editor. So, most edit modes don't really need panels, and a few edit modes have useful things in the panels. For consistency, I think that it's better if they all have or don't have panels. And since I don't like having useless stuff in the UI for the sake of consistency, it's better if we move the little useful things that are in the panels somewhere else. Now, I'd really appreciate if I get other votes, and if you took the time to look at the incubator page and comment on each point, since there are lots of items in this list that make sense individually, even if the consensus is not to eliminate panels.

...

Here are the individual voted points:

0 Remove all panels in edit mode

1a Parent and title above the content in wiki/wysiwyg mode

1b The same style in edit mode as in view mode for the parent/title fields

1c AJAX Suggest for the parent field

2a New label for the content textarea ("Content")

2b List of included documents after the Content label

3a Syntax switcher in the top right corner of the content

3b Syntax help in the top right corner of the content

3c Syntax help and switcher only in the wiki editor

4 Better label for the version comment

5a Right float the Minor edit field

5b Put the Minor edit label after the checkbox

6 Move autosave in line with the submit buttons

7 Introduce new AJAX-powered Add Object i) above the objects ii) bellow the objects

8 Introduce new AJAX-powered Add Object from this class i) at the top of the list of existing objects ii) at the end of the list

9 Move the class switcher in the top right corner

9b Remove the class switcher

10 Introduce new AJAX-powered Add Property i) at the top of the list of properties ii) at the end of the list

I vote +1 for all of the above, except 9b (-0), and with options 7i), 8ii), and 10ii)

-- Sergiu Dumitriu http://purl.org/net/sergiu/

On 01/27/2010 02:22 PM, Vincent Massol wrote:

I've discussed it a bit with Guillaume and here are some ideas:

* In the same manner that we have simple/advanced mode for view mode (user type) we could also have the same for the edit mode. * The simple edit mode would be an inplace editing mode where the page doesn't reload and the user is shown with an edit box for title/content (still to be decided for the parent). There would be a button to switch to advanced edit mode. * The advanced edit mode would be similar to the current edit mode, i.e panels on the left removed and panels on the right replaced by advanced edit panels, ie: included docs, syntax change, language translations, other metadata changes, etc. There would be a button to swtich to simple edit mode. * Basically the idea is to do what all tools do when there's not mandatory options to display, ie create an inspector/panel/dialog box to move non mandatory stuff out of the main view.

WDYT?

I don't really like it. All of the fields are important and should be displayed by default (except maybe the syntax switch, which really is an advanced field). Having access to translations is important, and hiding them in a different interface is not good. Changing the parent should be easy. And in general, people rarely go to the alternative edit mode, unless they really want something and they're courageous and they're willing to search for it everywhere. From my experience with users, people are not courageous, they don't just push buttons to see what they do.

Others:

* I don't really have a pb with the other editors (object/class).

So, you think that the class/object editors can be panelless, but the content editors should still have panels? What about consistency and the skin complexity? Did you read my previous email?

* For the class editor, I'd put the class properties as vertical tabs instead so that opening a property doesn't hide the others from the view (ie no accordion).

What accordion? There's no accordion since 1.9. LATFW.

Thanks -Vincent

On Jan 25, 2010, at 9:37 PM, Sergiu Dumitriu wrote:

...

Hi devs,

We've been working on improving the editors (content, class, object), and now I have some pretty important UI changes to commit, but not everybody seems to agree with them, so I bring up a vote.

The whole improvements can be seen on http://incubator.myxwiki.org/xwiki/bin/Improvements/ImprovedEdit

Here are the individual voted points:

0 Remove all panels in edit mode

1a Parent and title above the content in wiki/wysiwyg mode

1b The same style in edit mode as in view mode for the parent/title fields

1c AJAX Suggest for the parent field

2a New label for the content textarea ("Content")

2b List of included documents after the Content label

3a Syntax switcher in the top right corner of the content

3b Syntax help in the top right corner of the content

3c Syntax help and switcher only in the wiki editor

4 Better label for the version comment

5a Right float the Minor edit field

5b Put the Minor edit label after the checkbox

6 Move autosave in line with the submit buttons

7 Introduce new AJAX-powered Add Object i) above the objects ii) bellow the objects

8 Introduce new AJAX-powered Add Object from this class i) at the top of the list of existing objects ii) at the end of the list

9 Move the class switcher in the top right corner

9b Remove the class switcher

10 Introduce new AJAX-powered Add Property i) at the top of the list of properties ii) at the end of the list

I vote +1 for all of the above, except 9b (-0), and with options 7i), 8ii), and 10ii)

-- Sergiu Dumitriu http://purl.org/net/sergiu/

On 01/28/2010 12:08 AM, Marius Dumitru Florea wrote:

Hi Sergiu,

The design is good overall. Here are some comments:

* the information is overcrowded; I would add more space between the elements and make the labels less striking

As I said in the wiki page, too, the images are done around a much smaller content. Normally the content would never get this small, since there's a min-width. I'll try to see how it looks with larger margins.

* uppercase is fine for one word but otherwise makes the text hard to read; (why are the labels shouting at me?)

I don't know why the labels are upper case, they were already so in the skin. But I agree, I don't like them shouting either.

* it's not clear how multiple includes are displayed

Comma-separated list. I don't think that there will be many instances where there are many included documents.

* any reason (other than "there's no room for it") for not showing the list of included documents in WYSIWYG mode?

Since it's WYSIWYG, you can see the included document inline. But you still can't access it easily, so maybe this list should be in WYSIWYG also. What do others think?

* what happens with the syntax help if I don't select an XWiki syntax?

Don't know what should happen, but right now that link is hard-coded and always the same.

Sergiu Dumitriu wrote:

...

Hi devs,

We've been working on improving the editors (content, class, object), and now I have some pretty important UI changes to commit, but not everybody seems to agree with them, so I bring up a vote.

The whole improvements can be seen on http://incubator.myxwiki.org/xwiki/bin/Improvements/ImprovedEdit

Here are the individual voted points:

0 Remove all panels in edit mode

If your goal is in-line/in-place editing why removing the view panels?

Adding the view panels is a second step. For the moment I'm just making room for them.

...

1a Parent and title above the content in wiki/wysiwyg mode

+1

...

1b The same style in edit mode as in view mode for the parent/title fields

-0

...

1c AJAX Suggest for the parent field

+1

...

2a New label for the content textarea ("Content")

+0

...

2b List of included documents after the Content label

I'm not convinced it scales. I'd like to see the list in WYSIWYG mode also.

...

3a Syntax switcher in the top right corner of the content

+1

...

3b Syntax help in the top right corner of the content

+0

...

3c Syntax help and switcher only in the wiki editor

-0

...

4 Better label for the version comment

+1 but please don't display it all in uppercase

...

5a Right float the Minor edit field

+0

...

5b Put the Minor edit label after the checkbox

+1

...

6 Move autosave in line with the submit buttons

+1

...

7 Introduce new AJAX-powered Add Object i) above the objects ii) bellow the objects

+1 for any of them

...

8 Introduce new AJAX-powered Add Object from this class i) at the top of the list of existing objects ii) at the end of the list

+1 for any of them

...

9 Move the class switcher in the top right corner

+0

...

9b Remove the class switcher

+0 it doesn't belong there but at the same it can be very useful

...

10 Introduce new AJAX-powered Add Property i) at the top of the list of properties ii) at the end of the list

+1 for any of them

-- Sergiu Dumitriu http://purl.org/net/sergiu/