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/