27 Jun
2011
27 Jun
'11
8:38 a.m.
Hi Marius,
2011/6/24 Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
Hi guys (especially Ludovic and Thibaut),
I read [1] and [2] and I have a few questions. I would like to know very
clear what UI/UX platform changes are you proposing independent of the
Application Within Minutes.
(A) Page creation
1. Unique page name
Currently if you specify the name of an existing page in the default
create page form you get an error message saying that the specified page
already exists. Do you propose any change to this? Should we instead
create a page with a similar name based on a specified strategy (e.g.
MyPage1, MyPage2, with a simple counter strategy).
Yes we have a getUniquePageName function but it needs to be improved
2. Skip page name
Do you propose to remove the page name field from the default create
page form (triggered from the Add > Page menu) and to automatically
generate it from the title (using the default naming strategy)?
Yes the idea is to be able to get directly to the form will all the
information to fill.
Create in one less step.
3. Implicit location
Do you propose to remove the wiki/space fields from the default create
page form and instead always create the page in the current wiki/space?
i.e. Add > Page menu will add the page to the current wiki/space.
Well I've not thought about this from using the "Add" button, but
more when
we are using the application itself.
The Application has an Add button itself, from this button the space should
be implicit.
So the request would be to be able to pass a parameter to the Add action to
make the space implicit.
Also we could include the "Space" selection in the screen that shows the
full create form, removing the space selection step.
4. Implicit template
Currently template providers can be limited to a list of spaces. Do you
propose to automatically use a template provider if it is the only one
defined for the current/selected space?
Same thing. I've not thought about this as used from the "Add" button, but
from a button in the content area.
We should be able to go directly to the create form for a specific class
which uses a specific template.
5. Create sheet/template
Are you proposing to have a (slightly) different form even for plain
wiki pages? e.g. replace the "Save & Continue" and "Save" buttons
with a
"Create" button. What other differences do you propose?
I'm not sure if we need "create". Maybe we can use "save". The
only issue
here is that you won't have the page name at this point.
-----
I talked with Caty about this and she is against 3. and 4. She would
improve the current create page form by:
* displaying all the templates independent of the current space
(currently we display only the templates that can be applied to the
current space although we can create the page in a different space)
* when a template is selected, limit the list of spaces from the space
selector so that the user can choose only a space where the selected
template can be applied.
I'm open for discussion on this. In the App Within Minutes project this is
a
bit less important to me.
For me, in the AppWithinMinutes screen where the livetable is listing pages,
it should be possible to go directly to create in one click from there
That's the main priority to me. The behavior of the general Add button is
less important to me.
Maybe what we could imagine if we want to ONLY use this ADD button is to be
able to specify a "default" action for the Add button which is proposed
first to the user and still give him the possibility to propose an alternate
action.
I'm a bit against the ADD button to propose all templates and then propose
the Space. This reduce the contextuality of the Add button. I don't think
it's good especially for non experienced users which could be confused by
all the possibilities.
(B) Display Resolution
(1) Remove the "inline" editing mechanism
What do you propose to do with the "Edit > Inline form" menu seen by the
advanced users? Should we keep it and just replace the URL? What about
simple users, will they be noticing any difference (since we already
have just one Edit button that points to the proper edit mode)?
We won't need the inline mode anymore once we switch to the new method.
What we might need is a way to choose an "ALTERNATE" view or edit mode which
would propose a list of available views or edits.
I don't think we need that for now.
We still need to keep the inline mode as deprecated.
(2) Sheet parameters
Do you mean velocity variables defined in the sheet code? This will work
only if the variables are used after the sheet code is evaluated.
No what I mean about parameters is settings that would be stored in the
Sheet (in
the XWiki.SheetClass probably) that would give use some rules on
how to display certain things.
For example which tabs to display, wether to display the standard wiki or
wysiwyg editor in the edit screen. This would also be keeping this or that
option from the editors, which buttons to show for saving.
Think that we want to CONTROL as much as we can from what is displayed to
the user without having to HACK the skin. Think that you need to be able to
at least have the way the "inline" mode currently displays (so that the user
does not necessarly feel he is in a special edit mode). In the "inline" mode
we started pretty empty so most of the work was done by the developer.
(3) Display Resolution Rules
I could find fields for specifying display sheets (defaultViewSheet and
defaultEditSheet) only in BaseClass (old core). XWikiDocument doesn't
have any. This makes sense because sheets are in fact *class* sheets.
That is, you write a sheet for a specific class, you don't write it for
a specific document. Have I understood correctly that you want to be
able to create a sheet for a document (not a class)? This could be
useful for documents that have multiple objects and you need a sheet
that displays data from all the objects (using the class sheet of one of
the object types is not enough).
Yes we could need to write a view or edit sheet for a documents either with
multiple classes but also a sheet for a class but that would be used for
only ONE specific document.
So it's more about "selecting" the sheet for a specific document (as
opposed
to selecting it for all documents using a class), than to make different
types of sheets for more complex cases.
But we could even have a sheet for a standard wiki document, which could
include plenty of options on how to display the edit form or on which tabs
to display at the bottom of the page.
Ludovic
Thanks,
Marius
[1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesPageCrea…
[2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost