Re: [xwiki-devs] [VOTE] Edit UI improvements and panelless edit

On 01/26/2010 09:09 AM, Vincent Massol wrote: You should look, since it probably has changed since JV showed it to you. 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. 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. You say distraction, I say easier access and a more logical and easy to find position. 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. For me this is a huge improvement in terms of making XWiki usable. 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. K. 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. 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. -- Sergiu Dumitriu http://purl.org/net/sergiu/