Hi Marius, 2011/6/24 Marius Dumitru Florea <[email protected]>
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/ApplicationWithinMinutesPageCreat... [2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChang... _______________________________________________ devs mailing list [email protected] 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