[xwiki-devs] [Discussion] Providing Default Template Providers in default XE
Hi, I think we should provide default template providers in default XE. This thread is about deciding which ones to have by default. Candidates: ========== 1- Wiki Macro 2- Blog Post 3- Scheduler Job 4- Class (same result as creating a class from the class wizard) 5- Color Theme 6- Panel 7- Skin For some of these we have home pages to create them (For example: Blog, Scheduler, Class, Color Theme, Panel) so we need to decide if it's ok to provide 2 locations from where to create them. In addition some of the candidates above are technical things and they shouldn't be displayed to simple users IMO: Wiki Macro, Scheduler Job, Class, Color Theme, Panel, Skin. Thus I'd also like to discuss having a mechanism for a Template Provider to say to whom it's addressed. Could be done by adding an "Audience" field to the Template Provider class. WDYT? Thanks -Vincent
Hi, On Tue, Nov 30, 2010 at 17:12, Vincent Massol <[email protected]> wrote:
Hi,
I think we should provide default template providers in default XE. This thread is about deciding which ones to have by default.
+1 for the concept. See my comments below.
Candidates: ==========
1- Wiki Macro 2- Blog Post 3- Scheduler Job 4- Class (same result as creating a class from the class wizard) 5- Color Theme 6- Panel 7- Skin
We might also want to have a "user" template, if that's doable with the current mechanism.
For some of these we have home pages to create them (For example: Blog, Scheduler, Class, Color Theme, Panel) so we need to decide if it's ok to provide 2 locations from where to create them.
Yes, I think it's ok to have 2 locations, the same way we have more than one way to create new pages (links to non-existent pages, "create" button...). In addition some of the candidates above are technical things and they
shouldn't be displayed to simple users IMO: Wiki Macro, Scheduler Job, Class, Color Theme, Panel, Skin.
Thus I'd also like to discuss having a mechanism for a Template Provider to say to whom it's addressed. Could be done by adding an "Audience" field to the Template Provider class.
That's not necessarily needed. There are already 2 mechanisms that can be leveraged in order to handle this use case: - The ability to restrict a template to a given space -> the ColorTheme template could be provided only in the ColorThemes space for instance - The $blacklistedSpaces variable -> it's already used to hide technical spaces. Coupled with the above mechanism, it could be sufficient Thus I'm not sure that we need an additional field. Let's first use (and if needed improve) the existing mechanisms. Guillaume
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 30, 2010, at 5:24 PM, Guillaume Lerouge wrote:
Hi,
On Tue, Nov 30, 2010 at 17:12, Vincent Massol <[email protected]> wrote:
Hi,
I think we should provide default template providers in default XE. This thread is about deciding which ones to have by default.
+1 for the concept. See my comments below.
Candidates: ==========
1- Wiki Macro 2- Blog Post 3- Scheduler Job 4- Class (same result as creating a class from the class wizard) 5- Color Theme 6- Panel 7- Skin
We might also want to have a "user" template, if that's doable with the current mechanism.
I hesitated adding it to the list since I don't think it' a good thing to have. I think that when we have specialized UI it's better to not have a template provider, or maybe better to redirect to the specialized UI.
For some of these we have home pages to create them (For example: Blog, Scheduler, Class, Color Theme, Panel) so we need to decide if it's ok to provide 2 locations from where to create them.
Yes, I think it's ok to have 2 locations, the same way we have more than one way to create new pages (links to non-existent pages, "create" button...).
In addition some of the candidates above are technical things and they
shouldn't be displayed to simple users IMO: Wiki Macro, Scheduler Job, Class, Color Theme, Panel, Skin.
Thus I'd also like to discuss having a mechanism for a Template Provider to say to whom it's addressed. Could be done by adding an "Audience" field to the Template Provider class.
That's not necessarily needed. There are already 2 mechanisms that can be leveraged in order to handle this use case:
- The ability to restrict a template to a given space -> the ColorTheme template could be provided only in the ColorThemes space for instance
That makes a colortheme template provider quite useless since there's already a way to create color themes from the color theme space... ok it allows a user to create a new theme when viewing another theme, sure, but that use case is not the main one IMO and it's covered by the create color theme feature of the color them webhome.
- The $blacklistedSpaces variable -> it's already used to hide technical spaces. Coupled with the above mechanism, it could be sufficient
See previous comment. Template providers are not really useful when restricted to a space IMO. Thanks -Vincent
Thus I'm not sure that we need an additional field. Let's first use (and if needed improve) the existing mechanisms.
Guillaume
WDYT?
Thanks -Vincent
On Tue, Nov 30, 2010 at 5:34 PM, Vincent Massol <[email protected]> wrote:
On Nov 30, 2010, at 5:24 PM, Guillaume Lerouge wrote:
That's not necessarily needed. There are already 2 mechanisms that can be leveraged in order to handle this use case:
- The ability to restrict a template to a given space -> the ColorTheme template could be provided only in the ColorThemes space for instance
That makes a colortheme template provider quite useless since there's already a way to create color themes from the color theme space... ok it allows a user to create a new theme when viewing another theme, sure, but that use case is not the main one IMO and it's covered by the create color theme feature of the color them webhome.
- The $blacklistedSpaces variable -> it's already used to hide technical spaces. Coupled with the above mechanism, it could be sufficient
See previous comment. Template providers are not really useful when restricted to a space IMO.
I think we need to be careful with our choice here, having too much entries in the global list of available templates can make the page creation look complex. IMHO some applications would deserve it. The blog for example, but IIRC it's made to allow to have 1 space / 1 blog (at least it's been asked several times). Other applications like a meeting manager or a todo manager would definitely get my +1 to be suggested everywhere in the wiki, provided those apps handles objects coming from the entire wiki of course. Thanks, JV.
Hi, On Tue, Nov 30, 2010 at 17:47, Jean-Vincent Drean <[email protected]>wrote:
On Tue, Nov 30, 2010 at 5:34 PM, Vincent Massol <[email protected]> wrote:
On Nov 30, 2010, at 5:24 PM, Guillaume Lerouge wrote:
That's not necessarily needed. There are already 2 mechanisms that can
be
leveraged in order to handle this use case:
- The ability to restrict a template to a given space -> the ColorTheme template could be provided only in the ColorThemes space for instance
That makes a colortheme template provider quite useless since there's already a way to create color themes from the color theme space... ok it allows a user to create a new theme when viewing another theme, sure, but that use case is not the main one IMO and it's covered by the create color theme feature of the color them webhome.
- The $blacklistedSpaces variable -> it's already used to hide technical spaces. Coupled with the above mechanism, it could be sufficient
See previous comment. Template providers are not really useful when restricted to a space IMO.
I think we need to be careful with our choice here, having too much entries in the global list of available templates can make the page creation look complex.
I agree as well. Maybe we could solve that by hiding some template providers for simple users? Guillaume
IMHO some applications would deserve it. The blog for example, but IIRC it's made to allow to have 1 space / 1 blog (at least it's been asked several times). Other applications like a meeting manager or a todo manager would definitely get my +1 to be suggested everywhere in the wiki, provided those apps handles objects coming from the entire wiki of course.
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 30, 2010, at 5:53 PM, Guillaume Lerouge wrote:
Hi,
On Tue, Nov 30, 2010 at 17:47, Jean-Vincent Drean <[email protected]>wrote:
On Tue, Nov 30, 2010 at 5:34 PM, Vincent Massol <[email protected]> wrote:
On Nov 30, 2010, at 5:24 PM, Guillaume Lerouge wrote:
That's not necessarily needed. There are already 2 mechanisms that can
be
leveraged in order to handle this use case:
- The ability to restrict a template to a given space -> the ColorTheme template could be provided only in the ColorThemes space for instance
That makes a colortheme template provider quite useless since there's already a way to create color themes from the color theme space... ok it allows a user to create a new theme when viewing another theme, sure, but that use case is not the main one IMO and it's covered by the create color theme feature of the color them webhome.
- The $blacklistedSpaces variable -> it's already used to hide technical spaces. Coupled with the above mechanism, it could be sufficient
See previous comment. Template providers are not really useful when restricted to a space IMO.
I think we need to be careful with our choice here, having too much entries in the global list of available templates can make the page creation look complex.
I agree as well. Maybe we could solve that by hiding some template providers for simple users?
Guillaume this is exactly what I was proposing... I was probably not clear enough :) Thanks -Vincent
Guillaume
IMHO some applications would deserve it. The blog for example, but IIRC it's made to allow to have 1 space / 1 blog (at least it's been asked several times). Other applications like a meeting manager or a todo manager would definitely get my +1 to be suggested everywhere in the wiki, provided those apps handles objects coming from the entire wiki of course.
Thanks, JV.
On Nov 30, 2010, at 5:47 PM, Jean-Vincent Drean wrote:
On Tue, Nov 30, 2010 at 5:34 PM, Vincent Massol <[email protected]> wrote:
On Nov 30, 2010, at 5:24 PM, Guillaume Lerouge wrote:
That's not necessarily needed. There are already 2 mechanisms that can be leveraged in order to handle this use case:
- The ability to restrict a template to a given space -> the ColorTheme template could be provided only in the ColorThemes space for instance
That makes a colortheme template provider quite useless since there's already a way to create color themes from the color theme space... ok it allows a user to create a new theme when viewing another theme, sure, but that use case is not the main one IMO and it's covered by the create color theme feature of the color them webhome.
- The $blacklistedSpaces variable -> it's already used to hide technical spaces. Coupled with the above mechanism, it could be sufficient
See previous comment. Template providers are not really useful when restricted to a space IMO.
I think we need to be careful with our choice here, having too much entries in the global list of available templates can make the page creation look complex.
I don't think have 1 or 50 templates makes it harder to create a page (the empty page should always be the default and it could be a button "Advanced..." that opens a dialog a la Macro editor in the WYSIWYG where you have categories for template providers and you can search for specific providers). Actually category is probably a better idea than the "audience" field I was hinting at in my previous mail. Thanks -Vincent
IMHO some applications would deserve it. The blog for example, but IIRC it's made to allow to have 1 space / 1 blog (at least it's been asked several times). Other applications like a meeting manager or a todo manager would definitely get my +1 to be suggested everywhere in the wiki, provided those apps handles objects coming from the entire wiki of course.
Thanks, JV.
On Tue, Nov 30, 2010 at 5:53 PM, Vincent Massol <[email protected]> wrote:
On Nov 30, 2010, at 5:47 PM, Jean-Vincent Drean wrote:
I think we need to be careful with our choice here, having too much entries in the global list of available templates can make the page creation look complex.
I don't think have 1 or 50 templates makes it harder to create a page (the empty page should always be the default and it could be a button "Advanced..." that opens a dialog a la Macro editor in the WYSIWYG where you have categories for template providers and you can search for specific providers).
1/ We list all the templates without "advanced" dialog - People will read - With 50 templates 2/ We put all the templates except "default" in a "advanced" dialog - More clicks - Some users won't click
Actually category is probably a better idea than the "audience" field I was hinting at in my previous mail.
I prefer category as well but I think we're quite far from needing them. Thanks, JV.
On Tue, Nov 30, 2010 at 5:12 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think we should provide default template providers in default XE. This thread is about deciding which ones to have by default.
I agree, however we need to find a way to translate the name of the provided templates, for the moment this name is stored in a simple string property. I haven't commited templates by default since I was reluctant to put velocity in those fields.
Candidates: ==========
I think all those candidates should be present only in specific spaces, this way most of them would be (almost) invisible to simple users.
1- Wiki Macro
XWiki.
2- Blog Post
Blog.
3- Scheduler Job
Scheduler.
4- Class (same result as creating a class from the class wizard)
XWiki.
5- Color Theme
ColorThemes.
6- Panel
Panels.
7- Skin
XWiki.
For some of these we have home pages to create them (For example: Blog, Scheduler, Class, Color Theme, Panel) so we need to decide if it's ok to provide 2 locations from where to create them.
I think it's ok to have multiple locations allowing to create them, a macro would be cool.
In addition some of the candidates above are technical things and they shouldn't be displayed to simple users IMO: Wiki Macro, Scheduler Job, Class, Color Theme, Panel, Skin.
Thus I'd also like to discuss having a mechanism for a Template Provider to say to whom it's addressed. Could be done by adding an "Audience" field to the Template Provider class.
I'm 0 on this, I'm not a fan of relying on this prop but space restriction might not be enough. Thanks, JV.
On Nov 30, 2010, at 5:38 PM, Jean-Vincent Drean wrote:
On Tue, Nov 30, 2010 at 5:12 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think we should provide default template providers in default XE. This thread is about deciding which ones to have by default.
I agree, however we need to find a way to translate the name of the provided templates, for the moment this name is stored in a simple string property. I haven't commited templates by default since I was reluctant to put velocity in those fields.
Candidates: ==========
I think all those candidates should be present only in specific spaces, this way most of them would be (almost) invisible to simple users.
I don't like it. The point of this Add menu is to make it extra *simple* to create new pages. If I have to navigate first to the right space, we fail this goal and we don't need template providers at all since we can offer buttons to create objects from the space's webhomes. IMO we really need a way to create new pages with objects from anywhere else in the wiki. Thanks -Vincent
1- Wiki Macro
XWiki.
2- Blog Post
Blog.
3- Scheduler Job
Scheduler.
4- Class (same result as creating a class from the class wizard)
XWiki.
5- Color Theme
ColorThemes.
6- Panel
Panels.
7- Skin
XWiki.
For some of these we have home pages to create them (For example: Blog, Scheduler, Class, Color Theme, Panel) so we need to decide if it's ok to provide 2 locations from where to create them.
I think it's ok to have multiple locations allowing to create them, a macro would be cool.
In addition some of the candidates above are technical things and they shouldn't be displayed to simple users IMO: Wiki Macro, Scheduler Job, Class, Color Theme, Panel, Skin.
Thus I'd also like to discuss having a mechanism for a Template Provider to say to whom it's addressed. Could be done by adding an "Audience" field to the Template Provider class.
I'm 0 on this, I'm not a fan of relying on this prop but space restriction might not be enough.
Thanks, JV.
On Tue, Nov 30, 2010 at 5:43 PM, Vincent Massol <[email protected]> wrote:
I don't like it. The point of this Add menu is to make it extra *simple* to create new pages. If I have to navigate first to the right space, we fail this goal and we don't need template providers at all since we can offer buttons to create objects from the space's webhomes.
Yes, but I don't think being able to create a ColorTheme or a Wiki Macro from any page is improving the user experience. Or in this case we'd need a new "User type" imho: developer. I think the majority of the people using the advanced mode doesn't frequently create color themes or macros.
IMO we really need a way to create new pages with objects from anywhere else in the wiki.
We do need one, and we have one, but IMHO we don't have any app in XE that deserves to appear everywhere except the Blog. Thanks, JV.
Hi, On Tue, Nov 30, 2010 at 17:57, Jean-Vincent Drean <[email protected]>wrote:
On Tue, Nov 30, 2010 at 5:43 PM, Vincent Massol <[email protected]> wrote:
I don't like it. The point of this Add menu is to make it extra *simple*
to create new pages. If I have to navigate first to the right space, we fail this goal and we don't need template providers at all since we can offer buttons to create objects from the space's webhomes.
Yes, but I don't think being able to create a ColorTheme or a Wiki Macro from any page is improving the user experience. Or in this case we'd need a new "User type" imho: developer. I think the majority of the people using the advanced mode doesn't frequently create color themes or macros.
We're switching to a debate about turning "simple users / advanced users" into "user / admin / developer" here :-) Could be the topic of a new thread (it's an interesting idea). Once we have this, is would be much easier to target specific features towards specific users in the wiki and it's a natural extension to what we already have. Guillaume
IMO we really need a way to create new pages with objects from anywhere else in the wiki.
We do need one, and we have one, but IMHO we don't have any app in XE that deserves to appear everywhere except the Blog.
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Sales - XWiki SAS Skype: wikibc Office: +33 1 45 42 40 90 Mobile: +33 6 10 79 76 70
I might be wrong, may be only developers use the Advanced mode, but I'm not sure about that. JV. On Tue, Nov 30, 2010 at 6:01 PM, Guillaume Lerouge <[email protected]> wrote:
Hi,
On Tue, Nov 30, 2010 at 17:57, Jean-Vincent Drean <[email protected]>wrote:
On Tue, Nov 30, 2010 at 5:43 PM, Vincent Massol <[email protected]> wrote:
I don't like it. The point of this Add menu is to make it extra *simple*
to create new pages. If I have to navigate first to the right space, we fail this goal and we don't need template providers at all since we can offer buttons to create objects from the space's webhomes.
Yes, but I don't think being able to create a ColorTheme or a Wiki Macro from any page is improving the user experience. Or in this case we'd need a new "User type" imho: developer. I think the majority of the people using the advanced mode doesn't frequently create color themes or macros.
We're switching to a debate about turning "simple users / advanced users" into "user / admin / developer" here :-)
Could be the topic of a new thread (it's an interesting idea). Once we have this, is would be much easier to target specific features towards specific users in the wiki and it's a natural extension to what we already have.
Guillaume
IMO we really need a way to create new pages with objects from anywhere else in the wiki.
We do need one, and we have one, but IMHO we don't have any app in XE that deserves to appear everywhere except the Blog.
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Sales - XWiki SAS Skype: wikibc Office: +33 1 45 42 40 90 Mobile: +33 6 10 79 76 70 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Guillaume Lerouge -
Jean-Vincent Drean -
Vincent Massol