On 01/26/2010 03:14 PM, Guillaume Lerouge wrote:
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).
Yes, this too is a good reason for discarding the edit panels. Several
users have asked about changing the edit panels in the past.
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.
I agree.
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 ;-)
Exactly.
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?
Well, a first step would be to have something like this:
- keep the SVN repo as the main repo
- add a git central repo that devs and users can push to
- this git repo is configured as a SVN clone
- the master branch automatically pushes to the SVN trunk any new commit
- we can do the same for the equivalent of SVN branches
- git automatically fetches updates from the SVN repo
- configure rights so that developers can push changes to any branch
- configure rights so that any user can have his own branch where only
he and the developers can commit
This means that devs can work both with the SVN and the git repo, as
they wish, giving us the freedom to test git instead of suddenly
switching to it.
This also makes it easier for users to contribute and feel more involved.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/