15 Feb
2010
15 Feb
'10
12:12 p.m.
On 02/15/2010 12:35 AM, Josh wrote:
Sergiu Dumitriu wrote:
As I said in the wiki page, but not in the mail, for other custom fields
there will be a different edit mode for document metadata not related to
the content. So the question is: do your fields belong in the content
editor, or in a document metadata editor?
For older users, there is the misconception that document metadata
should be edited in the wiki and WYSIWYG editors, which is wrong. These
editors should be about editing the content only. One drawback of this
behavior is that for sheet-based documents, such as blog entries, these
fields are not available in the inline edit mode, and this edit mode is
the only one available to non-advanced users, so editing metadata is
really hard. Separating metadata from the content should really be a
step forward, even though it will be annoying at first for users
accustomed to the current way.
Hi XWiki Users,
Please help the dev team solve a UI design dilemma. Your feedback is
very important, we really need the point of view of all categories of users.
The context:
We wish to get rid of the editor panels and integrate their
corresponding functionality in the editor itself. There are several
reasons for doing this (having all the editor functions in one place,
without depending on the panels that might or might not be in the
database, having the possibility to integrate the editors in view mode
without functionality loss, etc).
The proposals:
A) http://dev.xwiki.org/xwiki/bin/Design/ImprovedEdit#HVariantA
All the information from the side panels is inserted in the main editor
in semantically related places
- the language/translation can be chosen from the content menu
- the user can change the parent document by editing the hierarchy
- the included documents are listed above the content
- the document syntax can be selected from a field placed near the
content textarea; a link to the syntax help page is provided in the same
place. Note that the included documents and the page syntax are only
visible in the wiki editing mode. Users editing pages in wysiwyg are not
bothered with such details.
B) http://dev.xwiki.org/xwiki/bin/Design/ImprovedEdit#HVariantB
All the information from the side panels is grouped in an "Advanced
options" zone, hidden by default and displayable on the right. This
variant is highly similar to what we currently have in edit mode, with
the additional possibility to hide it to gain more horizontal space.
I option B) the best. A large XWiki project I've been working on uses
custom fields in the edit panels for editing page data stored in page
objects. Option A would seem to make it more difficult to add these
custom fields. Here are a few more thoughts and questions: 1.) Perhaps there could be an area specifically for
custom fields. That
way users could have a way within the current templates to add their own
functionality without having to learn enough about the edit templates to
choose an insertion point themselves. Also, the fields could provide a
friendlier interface than the Objects editor, much like the Inline Form
editor except in the Wiki/WYSIWYG editors.
In the future the editing will be done in a UI like the view one: same
panels on the left/right, and the extra tabs at the bottom. The
"Information" tab will be editable, and document metadata will be there.
Would this be enough for you?
Option A) could work with this by having, say, an
additional clickable
icon at the top that would reveal these additional fields. For my
project, I simply placed the custom fields in the Document Information
panel.
2.) Are the "panels" in B) still panels located in the Panels space?
At least initially. One goal of this move was to not depend on the
panels application.
3.) Would this hidden Advanced Options sidebar be
available in the
WYSIWYG edit mode as well?
Yes.
-Joshua
>
> Please comment on these proposals, telling us which works better for
> you. New ideas are also welcome.
>
>
> Thanks in advance for your feedback, which will help us move forward.
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/