[xwiki-devs] Application Within Minutes - Platform Changes
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). 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)? 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. 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? 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 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. (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)? (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. (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). Thanks, Marius [1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesPageCreat... [2] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChang...
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
On 06/27/2011 08:38 AM, Ludovic Dubost wrote:
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.
I think we need to make it clear that this affects only to applications and documents created by applications, not to the default way documents are handled in XWiki.
(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
Yes, this makes sense for documents belonging to an application which still uses document names, such as the blog.
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.
I don't agree that this should affect all "create a new document" forms, for example when creating a new simple document in the Main space. But for spaces dedicated to an application, such as the Holiday Request, I'd be OK with skipping the document name and instead generating one automatically. But I still think that not all types of applications must follow this behavior, since the document name and how it appears in the URL is important. One of the good points of XWiki (that I like very much) is semantic URLs, where one can see what a document is about. If we move to meaningless URLs like /xwiki/Blog/X18733198 then I'd be sad :'( This said, the application wizard should have a setting for this: [ ] Generate unique names automatically using this pattern: [%u-%i__________________________] [Hint] Any free text entered will be used as-is. The following tokens can be used: %a - current user's username %d - current date, in the yyyyMMdd format %i - unique counter %t - current time, in the HHmm format %u - current user's full name
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.
It would be confusing to have the big Add button in the menu do something different than the big Add button in the application homepage. It would also be bad UX to have the Add button only on the application homepage, forcing users to perform an extra step: go to the app homepage to click Add. So, the Add menu should have two distinct entries for adding documents: Add - Space --- - Holiday Request [this is the name of the current application] - Wiki document - Document from Office --- - comment, attachment, etc. I think that using a friendly name, like "Event", "Holiday Request", "Meeting" is a big usability boost. If there's no application in the current space, then only the "Wiki document" entry is displayed.
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.
See above for a reasoning. For the implementation, it's not enough to say "if it is the only one defined for the current/selected space", since templates can target all the wiki as well. A different approach would be "if a template and only one targets explicitly the current space". Another approach would be to somehow mark the space as a space destined to the XYZ application. This would allow applications to be used in several spaces. But I'm not sure if this is needed for the scope of this project, which is to create simple applications.
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 think the list of templates was supposed to be updated depending on the space selected; isn't it like this right now? You're proposing to reverse the order: first select the template, then the space. I agree, this is better, since the user knows what kind of thing he wants to create more than where the thing should be. But this means that the user might be surprised if the new document isn't created in the current space, where he was located initially. I don't yet agree that the Add menu should list all the templates, even if they don't apply to the current space. This will make things complicated if lots of targeted templates are used. They should be listed on the advanced create form. It's true that the fact that the Add menu changes its contents is confusing, so I'm not 100% against listing all the templates, I'd like to see real user feedback about this.
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.
While this wasn't the problem, I'd like to get rid of the special /inline/ action and replace it with /edit/ and the ?editor=inline URL parameter, for consistency. The internals should be the same, though, with the different editors generated by the different .vm files, keeping the option for advanced users to choose a different editor. What changes is the way inline mode is detected. Instead of looking for an {{include}}, look at the attached objects.
(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.
I think this is a bit too complex for the current phase and goals. AppWithinMinutes can progress enough before we find the need for custom document sheets.
Thanks, Marius
[1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesPageCreat... [2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChang...
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mon, Jun 27, 2011 at 15:13, Sergiu Dumitriu <[email protected]> wrote:
On 06/27/2011 08:38 AM, Ludovic Dubost wrote:
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.
I think we need to make it clear that this affects only to applications and documents created by applications, not to the default way documents are handled in XWiki.
+1
(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
Yes, this makes sense for documents belonging to an application which still uses document names, such as the blog.
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.
I don't agree that this should affect all "create a new document" forms, for example when creating a new simple document in the Main space. But for spaces dedicated to an application, such as the Holiday Request, I'd be OK with skipping the document name and instead generating one automatically.
But I still think that not all types of applications must follow this behavior, since the document name and how it appears in the URL is important. One of the good points of XWiki (that I like very much) is semantic URLs, where one can see what a document is about. If we move to meaningless URLs like /xwiki/Blog/X18733198 then I'd be sad :'(
This said, the application wizard should have a setting for this:
[ ] Generate unique names automatically using this pattern: [%u-%i__________________________] [Hint] Any free text entered will be used as-is. The following tokens can be used: %a - current user's username %d - current date, in the yyyyMMdd format %i - unique counter %t - current time, in the HHmm format %u - current user's full name
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.
It would be confusing to have the big Add button in the menu do something different than the big Add button in the application homepage.
It would also be bad UX to have the Add button only on the application homepage, forcing users to perform an extra step: go to the app homepage to click Add.
So, the Add menu should have two distinct entries for adding documents:
Add - Space --- - Holiday Request [this is the name of the current application] - Wiki document - Document from Office --- - comment, attachment, etc.
I think that using a friendly name, like "Event", "Holiday Request", "Meeting" is a big usability boost.
If there's no application in the current space, then only the "Wiki document" entry is displayed.
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.
See above for a reasoning.
For the implementation, it's not enough to say "if it is the only one defined for the current/selected space", since templates can target all the wiki as well. A different approach would be "if a template and only one targets explicitly the current space".
Another approach would be to somehow mark the space as a space destined to the XYZ application. This would allow applications to be used in several spaces. But I'm not sure if this is needed for the scope of this project, which is to create simple applications.
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 think the list of templates was supposed to be updated depending on the space selected; isn't it like this right now?
You're proposing to reverse the order: first select the template, then the space. I agree, this is better, since the user knows what kind of thing he wants to create more than where the thing should be.
But this means that the user might be surprised if the new document isn't created in the current space, where he was located initially.
I don't yet agree that the Add menu should list all the templates, even if they don't apply to the current space. This will make things complicated if lots of targeted templates are used. They should be listed on the advanced create form. It's true that the fact that the Add menu changes its contents is confusing, so I'm not 100% against listing all the templates, I'd like to see real user feedback about this.
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.
While this wasn't the problem, I'd like to get rid of the special /inline/ action and replace it with /edit/ and the ?editor=inline URL parameter, for consistency.
The internals should be the same, though, with the different editors generated by the different .vm files, keeping the option for advanced users to choose a different editor.
What changes is the way inline mode is detected. Instead of looking for an {{include}}, look at the attached objects.
Isn't this already the case with the new EditModeClass ?
(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.
I think this is a bit too complex for the current phase and goals. AppWithinMinutes can progress enough before we find the need for custom document sheets.
Thanks, Marius
[1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesPageCreat... [2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChang...
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 06/27/2011 07:19 PM, Thomas Mortagne wrote:
On Mon, Jun 27, 2011 at 15:13, Sergiu Dumitriu<[email protected]> wrote:
On 06/27/2011 08:38 AM, Ludovic Dubost wrote:
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.
I think we need to make it clear that this affects only to applications and documents created by applications, not to the default way documents are handled in XWiki.
+1
(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
Yes, this makes sense for documents belonging to an application which still uses document names, such as the blog.
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.
I don't agree that this should affect all "create a new document" forms, for example when creating a new simple document in the Main space. But for spaces dedicated to an application, such as the Holiday Request, I'd be OK with skipping the document name and instead generating one automatically.
But I still think that not all types of applications must follow this behavior, since the document name and how it appears in the URL is important. One of the good points of XWiki (that I like very much) is semantic URLs, where one can see what a document is about. If we move to meaningless URLs like /xwiki/Blog/X18733198 then I'd be sad :'(
This said, the application wizard should have a setting for this:
[ ] Generate unique names automatically using this pattern: [%u-%i__________________________] [Hint] Any free text entered will be used as-is. The following tokens can be used: %a - current user's username %d - current date, in the yyyyMMdd format %i - unique counter %t - current time, in the HHmm format %u - current user's full name
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.
It would be confusing to have the big Add button in the menu do something different than the big Add button in the application homepage.
It would also be bad UX to have the Add button only on the application homepage, forcing users to perform an extra step: go to the app homepage to click Add.
So, the Add menu should have two distinct entries for adding documents:
Add - Space --- - Holiday Request [this is the name of the current application] - Wiki document - Document from Office --- - comment, attachment, etc.
I think that using a friendly name, like "Event", "Holiday Request", "Meeting" is a big usability boost.
If there's no application in the current space, then only the "Wiki document" entry is displayed.
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.
See above for a reasoning.
For the implementation, it's not enough to say "if it is the only one defined for the current/selected space", since templates can target all the wiki as well. A different approach would be "if a template and only one targets explicitly the current space".
Another approach would be to somehow mark the space as a space destined to the XYZ application. This would allow applications to be used in several spaces. But I'm not sure if this is needed for the scope of this project, which is to create simple applications.
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 think the list of templates was supposed to be updated depending on the space selected; isn't it like this right now?
You're proposing to reverse the order: first select the template, then the space. I agree, this is better, since the user knows what kind of thing he wants to create more than where the thing should be.
But this means that the user might be surprised if the new document isn't created in the current space, where he was located initially.
I don't yet agree that the Add menu should list all the templates, even if they don't apply to the current space. This will make things complicated if lots of targeted templates are used. They should be listed on the advanced create form. It's true that the fact that the Add menu changes its contents is confusing, so I'm not 100% against listing all the templates, I'd like to see real user feedback about this.
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.
While this wasn't the problem, I'd like to get rid of the special /inline/ action and replace it with /edit/ and the ?editor=inline URL parameter, for consistency.
The internals should be the same, though, with the different editors generated by the different .vm files, keeping the option for advanced users to choose a different editor.
What changes is the way inline mode is detected. Instead of looking for an {{include}}, look at the attached objects.
Isn't this already the case with the new EditModeClass ?
EditModeClass is too limited. We need a generic way to specify the sheet for any action, not just edit. Thanks, Marius
(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.
I think this is a bit too complex for the current phase and goals. AppWithinMinutes can progress enough before we find the need for custom document sheets.
Thanks, Marius
[1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesPageCreat... [2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChang...
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jun 27, 2011 at 18:26, Marius Dumitru Florea <[email protected]> wrote:
On 06/27/2011 07:19 PM, Thomas Mortagne wrote:
On Mon, Jun 27, 2011 at 15:13, Sergiu Dumitriu<[email protected]> wrote:
On 06/27/2011 08:38 AM, Ludovic Dubost wrote:
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.
I think we need to make it clear that this affects only to applications and documents created by applications, not to the default way documents are handled in XWiki.
+1
(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
Yes, this makes sense for documents belonging to an application which still uses document names, such as the blog.
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.
I don't agree that this should affect all "create a new document" forms, for example when creating a new simple document in the Main space. But for spaces dedicated to an application, such as the Holiday Request, I'd be OK with skipping the document name and instead generating one automatically.
But I still think that not all types of applications must follow this behavior, since the document name and how it appears in the URL is important. One of the good points of XWiki (that I like very much) is semantic URLs, where one can see what a document is about. If we move to meaningless URLs like /xwiki/Blog/X18733198 then I'd be sad :'(
This said, the application wizard should have a setting for this:
[ ] Generate unique names automatically using this pattern: [%u-%i__________________________] [Hint] Any free text entered will be used as-is. The following tokens can be used: %a - current user's username %d - current date, in the yyyyMMdd format %i - unique counter %t - current time, in the HHmm format %u - current user's full name
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.
It would be confusing to have the big Add button in the menu do something different than the big Add button in the application homepage.
It would also be bad UX to have the Add button only on the application homepage, forcing users to perform an extra step: go to the app homepage to click Add.
So, the Add menu should have two distinct entries for adding documents:
Add - Space --- - Holiday Request [this is the name of the current application] - Wiki document - Document from Office --- - comment, attachment, etc.
I think that using a friendly name, like "Event", "Holiday Request", "Meeting" is a big usability boost.
If there's no application in the current space, then only the "Wiki document" entry is displayed.
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.
See above for a reasoning.
For the implementation, it's not enough to say "if it is the only one defined for the current/selected space", since templates can target all the wiki as well. A different approach would be "if a template and only one targets explicitly the current space".
Another approach would be to somehow mark the space as a space destined to the XYZ application. This would allow applications to be used in several spaces. But I'm not sure if this is needed for the scope of this project, which is to create simple applications.
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 think the list of templates was supposed to be updated depending on the space selected; isn't it like this right now?
You're proposing to reverse the order: first select the template, then the space. I agree, this is better, since the user knows what kind of thing he wants to create more than where the thing should be.
But this means that the user might be surprised if the new document isn't created in the current space, where he was located initially.
I don't yet agree that the Add menu should list all the templates, even if they don't apply to the current space. This will make things complicated if lots of targeted templates are used. They should be listed on the advanced create form. It's true that the fact that the Add menu changes its contents is confusing, so I'm not 100% against listing all the templates, I'd like to see real user feedback about this.
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.
While this wasn't the problem, I'd like to get rid of the special /inline/ action and replace it with /edit/ and the ?editor=inline URL parameter, for consistency.
The internals should be the same, though, with the different editors generated by the different .vm files, keeping the option for advanced users to choose a different editor.
What changes is the way inline mode is detected. Instead of looking for an {{include}}, look at the attached objects.
Isn't this already the case with the new EditModeClass ?
EditModeClass is too limited. We need a generic way to specify the sheet for any action, not just edit.
Was just saying that being base on an object instead of include is not really new concept.
Thanks, Marius
(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.
I think this is a bit too complex for the current phase and goals. AppWithinMinutes can progress enough before we find the need for custom document sheets.
Thanks, Marius
[1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesPageCreat... [2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChang...
-- 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
-- Thomas Mortagne
participants (4)
-
Ludovic Dubost -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne