Hi, On Tue, Jan 26, 2010 at 9:09 AM, Vincent Massol <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/