Hi, On Tue, Jan 26, 2010 at 9:09 AM, Vincent Massol <vincent(a)massol.net> wrote: I like them overall. Making the content and edit modes look more similar to one another sounds good to me. This could be fixed by moving the non-essential inputs (basically everything but parent & title) under the content area. 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). 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. 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 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. 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's my take on what are relatively low-danger changes that could still be introduced in and benefit XE 2.2 M2: I think this can be done easily, at least for the title. Doable too. Doable. Doable. Doable. Doable. Doable. 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? -- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

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/

On 01/27/2010 02:22 PM, Vincent Massol wrote: 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. 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? What accordion? There's no accordion since 1.9. LATFW. -- Sergiu Dumitriu http://purl.org/net/sergiu/

On 01/28/2010 12:08 AM, Marius Dumitru Florea wrote: 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. 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. Comma-separated list. I don't think that there will be many instances where there are many included documents. 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? Don't know what should happen, but right now that link is hard-coded and always the same. Adding the view panels is a second step. For the moment I'm just making room for them. -- Sergiu Dumitriu http://purl.org/net/sergiu/