[xwiki-devs] [VOTE] Is it OK to edit a standard color theme
Hi xwikiers, Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.). 1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one). 2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo) 3) Same as 2 but delete is bad (same as home page) WDYT ? I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2). Thanks, -- Thomas Mortagne
The major problem is that some users reused the Color Themes as they were, but they have "customized" them by adding their own logo. On Mon, Apr 23, 2018 at 1:29 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
Yes that's why I sent this mail. But as I suggested there is always ways to make them not do that if we want those theme to stay standard. For example the UI could automate a bit the creation of a copy of the standard theme you want to customize (ask you the new name, etc.). On Mon, Apr 23, 2018 at 12:47 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
The major problem is that some users reused the Color Themes as they were, but they have "customized" them by adding their own logo.
On Mon, Apr 23, 2018 at 1:29 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
I don't know why I don't like this "copy" solution. Maybe because everything will feel less "wiki" like. Everything will become like a template, including color themes. Lot's of duplication instead of relying on the history. Another solution (that applies only for the use case of Color Themes and Skins) would be to externalize the Logo property. On Mon, Apr 23, 2018 at 2:38 PM, Thomas Mortagne <[email protected]> wrote:
Yes that's why I sent this mail.
But as I suggested there is always ways to make them not do that if we want those theme to stay standard. For example the UI could automate a bit the creation of a copy of the standard theme you want to customize (ask you the new name, etc.).
On Mon, Apr 23, 2018 at 12:47 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
The major problem is that some users reused the Color Themes as they were, but they have "customized" them by adding their own logo.
On Mon, Apr 23, 2018 at 1:29 PM, Thomas Mortagne < [email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
2018-04-23 13:46 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
I don't know why I don't like this "copy" solution. Maybe because everything will feel less "wiki" like. Everything will become like a template, including color themes. Lot's of duplication instead of relying on the history.
Another solution (that applies only for the use case of Color Themes and Skins) would be to externalize the Logo property.
+10000
On Mon, Apr 23, 2018 at 2:38 PM, Thomas Mortagne < [email protected]> wrote:
Yes that's why I sent this mail.
But as I suggested there is always ways to make them not do that if we want those theme to stay standard. For example the UI could automate a bit the creation of a copy of the standard theme you want to customize (ask you the new name, etc.).
On Mon, Apr 23, 2018 at 12:47 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
The major problem is that some users reused the Color Themes as they were, but they have "customized" them by adding their own logo.
On Mon, Apr 23, 2018 at 1:29 PM, Thomas Mortagne < [email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
For the specific use case of the logo yes having it in the color theme never been a good idea IMO. But people will probably still want to customize a bit existing color themes to feet they internal colors and stuff like these. On Mon, Apr 23, 2018 at 1:48 PM, Guillaume Delhumeau <[email protected]> wrote:
2018-04-23 13:46 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
I don't know why I don't like this "copy" solution. Maybe because everything will feel less "wiki" like. Everything will become like a template, including color themes. Lot's of duplication instead of relying on the history.
Another solution (that applies only for the use case of Color Themes and Skins) would be to externalize the Logo property.
+10000
On Mon, Apr 23, 2018 at 2:38 PM, Thomas Mortagne < [email protected]> wrote:
Yes that's why I sent this mail.
But as I suggested there is always ways to make them not do that if we want those theme to stay standard. For example the UI could automate a bit the creation of a copy of the standard theme you want to customize (ask you the new name, etc.).
On Mon, Apr 23, 2018 at 12:47 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
The major problem is that some users reused the Color Themes as they were, but they have "customized" them by adding their own logo.
On Mon, Apr 23, 2018 at 1:29 PM, Thomas Mortagne < [email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
-- Thomas Mortagne
Some of the users may see the default color theme as a set of configuration properties, same as wiki preferences, that they can modify without the need to create a copy first. So maybe we should separate the "default color theme" from the rest of the color themes. I mean, if Iceberg is the default color theme, we could provide 2 pages: "Iceberg" (the preset, with edit protection) and "DefaultColorTheme" (which is a copy of Iceberg that is editable). On Mon, Apr 23, 2018 at 1:29 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
Indeed that would probably be a good idea. On Mon, Apr 23, 2018 at 3:54 PM, Marius Dumitru Florea <[email protected]> wrote:
Some of the users may see the default color theme as a set of configuration properties, same as wiki preferences, that they can modify without the need to create a copy first. So maybe we should separate the "default color theme" from the rest of the color themes. I mean, if Iceberg is the default color theme, we could provide 2 pages: "Iceberg" (the preset, with edit protection) and "DefaultColorTheme" (which is a copy of Iceberg that is editable).
On Mon, Apr 23, 2018 at 1:29 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)). From the answer it seems we might need a new VOTE since several new points have been added to the discussion. I’m not able to VOTE right now. Thanks -Vincent
On 23 Apr 2018, at 12:29, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
To give my opinion, I’m hesitating about 2 approaches: Approach 1: “standard" ================== * We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc. * Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user should copy the page to customize it instead of editing it. * The Color Theme UI should also be improved a bit to have a “Customize” button on color theme pages that would perform a copy to let the user customize a theme. Approach 2: “demo" ================ * Consider all color themes to be demo content and once the user starts modifying them don’t merge them anymore * When we want to provide modified color themes, introduce new theme pages * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT. Analysis ======= Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions. I think I’m leaning more towards 2 ATM. Thanks -Vincent
On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote:
Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)).
From the answer it seems we might need a new VOTE since several new points have been added to the discussion. I’m not able to VOTE right now.
Thanks -Vincent
On 23 Apr 2018, at 12:29, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]> wrote:
To give my opinion, I’m hesitating about 2 approaches:
Approach 1: “standard" ==================
* We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc.
* Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user should copy the page to customize it instead of editing it.
* The Color Theme UI should also be improved a bit to have a “Customize” button on color theme pages that would perform a copy to let the user customize a theme.
Approach 2: “demo" ================
* Consider all color themes to be demo content and once the user starts modifying them don’t merge them anymore * When we want to provide modified color themes, introduce new theme pages * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT.
Analysis =======
Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions.
I think I’m leaning more towards 2 ATM.
So you think delete is OK too, right ?
Thanks -Vincent
On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote:
Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)).
From the answer it seems we might need a new VOTE since several new points have been added to the discussion. I’m not able to VOTE right now.
Thanks -Vincent
On 23 Apr 2018, at 12:29, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]> wrote:
To give my opinion, I’m hesitating about 2 approaches:
Approach 1: “standard" ==================
* We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc.
* Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user should copy the page to customize it instead of editing it.
* The Color Theme UI should also be improved a bit to have a “Customize” button on color theme pages that would perform a copy to let the user customize a theme.
Approach 2: “demo" ================
* Consider all color themes to be demo content and once the user starts modifying them don’t merge them anymore * When we want to provide modified color themes, introduce new theme pages * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT.
Analysis =======
Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions.
I think I’m leaning more towards 2 ATM.
So you think delete is OK too, right ?
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live). I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback. Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially. Thanks, Caty
Thanks -Vincent
On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote:
Is this a VOTE or a proposal or a brainstorming? I’m asking since
nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)).
From the answer it seems we might need a new VOTE since several new
points have been added to the discussion. I’m not able to VOTE right now.
Thanks -Vincent
On 23 Apr 2018, at 12:29, Thomas Mortagne <[email protected]>
wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
So it seems that 2) is currently leading with Ecaterina and Vincent. Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?). Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ? Any other point of view input ? On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]> wrote:
To give my opinion, I’m hesitating about 2 approaches:
Approach 1: “standard" ==================
* We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc.
* Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user should copy the page to customize it instead of editing it.
* The Color Theme UI should also be improved a bit to have a “Customize” button on color theme pages that would perform a copy to let the user customize a theme.
Approach 2: “demo" ================
* Consider all color themes to be demo content and once the user starts modifying them don’t merge them anymore * When we want to provide modified color themes, introduce new theme pages * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT.
Analysis =======
Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions.
I think I’m leaning more towards 2 ATM.
So you think delete is OK too, right ?
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live).
I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback.
Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially.
Thanks, Caty
Thanks -Vincent
On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote:
Is this a VOTE or a proposal or a brainstorming? I’m asking since
nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)).
From the answer it seems we might need a new VOTE since several new
points have been added to the discussion. I’m not able to VOTE right now.
Thanks -Vincent
On 23 Apr 2018, at 12:29, Thomas Mortagne <[email protected]>
wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color changed a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <[email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> wrote:
On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]> wrote:
To give my opinion, I’m hesitating about 2 approaches:
Approach 1: “standard" ==================
* We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc.
* Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user should copy the page to customize it instead of editing it.
* The Color Theme UI should also be improved a bit to have a “Customize” button on color theme pages that would perform a copy to let the user customize a theme.
Approach 2: “demo" ================
* Consider all color themes to be demo content and once the user starts modifying them don’t merge them anymore * When we want to provide modified color themes, introduce new theme pages * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT.
Analysis =======
Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions.
I think I’m leaning more towards 2 ATM.
So you think delete is OK too, right ?
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live).
I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback.
Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially.
Thanks, Caty
Thanks -Vincent
On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote:
Is this a VOTE or a proposal or a brainstorming? I’m asking since
nobody has voted yet, not even Thomas (except if we consider that
“prefer”
means +1 and “OK” means +0 ;)).
From the answer it seems we might need a new VOTE since several new
points have been added to the discussion. I’m not able to VOTE right now.
Thanks -Vincent
On 23 Apr 2018, at 12:29, Thomas Mortagne <
[email protected]> wrote:
Hi xwikiers,
Following new XAR entry type mail here is a question about color themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
1) Standard stuff, if you want a custom color theme create a new one (would be nice to be able to copy a standard one and propose it when you try to edit a standard one).
2) Demo content, edit and delete it all you want and upgrade won't touch a customized theme to avoid surprises (background color
changed
a bit in the standard version which now collide with your logo)
3) Same as 2 but delete is bad (same as home page)
WDYT ?
I'm think I prefer 1) but I'm OK with 3) if other think it's more example than standard material. Let's say -0 for 2).
Thanks, -- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
Hi, I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me. We're not talking about content pages here, but rather about a preset/pack of preferences (I would actually call them more code than configuration, to be honest, since we're talking about CSS and LESS) which have an identity. Once you start changing their values, they lose their identity and you can't call them "Iceberg" or "Charcoal" (etc.) anymore. Once you customize them, they are "CustomIceberg" or "MyIceberg" (etc.), if you really want to preserve a hint of the base of your customizations. IMO, we should have a distinction between the default color themes and the user contributed ones (this also includes customized copies of default ones). I believe this would actually help the user in getting a better understanding of what is going on instead of asking them to digg through the document history, look at diffs, etc. Nobody wants to do that. I don't like (-0) the idea of DefaultColorTheme being a useless copy of Iceberg. If we want, we could store in an unexposed property of the FlamingoThemes application what is the default color theme, so that the user can have a "default" option or a "Reset to default" when choosing what theme to use. Also, new versions of XWiki could update that property's value (as part of the code), for when we will want to introduce a new "default" theme for future versions of XWiki. I believe users need to be able to see and easily experience new features, without asking them to drop their customizations or write code (i.e. compared to what they would get if they intall a new/clean XWiki instance with the latest version). I do like (+1) the other 2 bullet points of Approach 1 ("standard"). Hitting "Customize" when using a standard theme should generate you a copy for your customization which you can then select from the list and apply. Heck, we could even make a nice distinction in the UI (or at least in the Select input) between the standard themes and the custom(-ized) ones. IMO, the important part to distinguish the fact that the configuration part (for a regular, non-dev) is choosing *which* color theme to use, while the customization (i.e. coding, done by someone that understands CSS/LESS, in this case) part is editing/customizing your own version of a color theme. Should be easy to make the choice if we look at it this way, since it would be similar to what we do for other parts of XWiki that need either configuration (i.e. choosing *what* to use) and that might need also some customization (i.e. modifying or defining *how* that choice will perform its job). General note/rant/reiteration: I am very much in favor of resisting the urge to "edit everything" (that's what actually got us to the current "problem"), even if it is a wiki at heart, since no software maintainers can provide you any time of support or upgrade paths that can factor in the fact that you are just barging in and making a beautiful mess of the code they developed. IMO, we just need to draw the line where the software ends and the wiki begins, otherwise users will be trapped/stuck with outdated and un-upgradable XWiki versions and will be regretting their choice. We need to think of the admins as well, and not only from the POV of the dev that wants to make everything possible. You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :) Thanks, Eduard On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> wrote:
On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]> wrote:
To give my opinion, I’m hesitating about 2 approaches:
Approach 1: “standard" ==================
* We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc.
* Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user
should
copy the page to customize it instead of editing it.
* The Color Theme UI should also be improved a bit to have a
“Customize” button on color theme pages that would perform a copy to let the user customize a theme.
Approach 2: “demo" ================
* Consider all color themes to be demo content and once the user
starts modifying them don’t merge them anymore
* When we want to provide modified color themes, introduce new theme pages * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT.
Analysis =======
Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions.
I think I’m leaning more towards 2 ATM.
So you think delete is OK too, right ?
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live).
I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback.
Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially.
Thanks, Caty
Thanks -Vincent
On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]>
wrote:
Is this a VOTE or a proposal or a brainstorming? I’m asking since
nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)).
From the answer it seems we might need a new VOTE since several new
points have been added to the discussion. I’m not able to VOTE right now.
Thanks -Vincent
> On 23 Apr 2018, at 12:29, Thomas Mortagne <
[email protected]> wrote:
> > Hi xwikiers, > > Following new XAR entry type mail here is a question about color > themes we provide in standard XWiki (Cerulean, Charcoal, etc.). > > 1) Standard stuff, if you want a custom color theme create a new one > (would be nice to be able to copy a standard one and propose it when > you try to edit a standard one). > > 2) Demo content, edit and delete it all you want and upgrade won't > touch a customized theme to avoid surprises (background color changed > a bit in the standard version which now collide with your logo) > > 3) Same as 2 but delete is bad (same as home page) > > WDYT ? > > I'm think I prefer 1) but I'm OK with 3) if other think it's more > example than standard material. Let's say -0 for 2). > > Thanks, > -- > Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
Hi Edy, Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :) For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now. It would be the first time we copy something before allowing changing it and that’s not logical and not consistent. In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages… The more I think about it, the more I’m convinced that approach 2 is both the simplest (and I agree that “less is more” :)) and the most logical. You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here). Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> wrote:
On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]> wrote:
To give my opinion, I’m hesitating about 2 approaches:
Approach 1: “standard" ==================
* We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc.
* Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user
should
copy the page to customize it instead of editing it.
* The Color Theme UI should also be improved a bit to have a
“Customize” button on color theme pages that would perform a copy to let the user customize a theme.
Approach 2: “demo" ================
* Consider all color themes to be demo content and once the user
starts modifying them don’t merge them anymore
* When we want to provide modified color themes, introduce new theme pages * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT.
Analysis =======
Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions.
I think I’m leaning more towards 2 ATM.
So you think delete is OK too, right ?
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live).
I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback.
Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially.
Thanks, Caty
Thanks -Vincent
> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]>
wrote:
> > Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)). > > From the answer it seems we might need a new VOTE since several new points have been added to the discussion. I’m not able to VOTE right now. > > Thanks > -Vincent > >> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> wrote: >> >> Hi xwikiers, >> >> Following new XAR entry type mail here is a question about color >> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >> >> 1) Standard stuff, if you want a custom color theme create a new one >> (would be nice to be able to copy a standard one and propose it when >> you try to edit a standard one). >> >> 2) Demo content, edit and delete it all you want and upgrade won't >> touch a customized theme to avoid surprises (background color changed >> a bit in the standard version which now collide with your logo) >> >> 3) Same as 2 but delete is bad (same as home page) >> >> WDYT ? >> >> I'm think I prefer 1) but I'm OK with 3) if other think it's more >> example than standard material. Let's say -0 for 2). >> >> Thanks, >> -- >> Thomas Mortagne >
-- Thomas Mortagne
-- Thomas Mortagne
I vote for option 2 (but I'm fine with option 3 too) 2018-04-26 11:54 GMT+02:00 Vincent Massol <[email protected]>:
Hi Edy,
Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :)
For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now.
It would be the first time we copy something before allowing changing it and that’s not logical and not consistent.
In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages…
The more I think about it, the more I’m convinced that approach 2 is both the simplest (and I agree that “less is more” :)) and the most logical.
You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here).
Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> wrote:
On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]
wrote: > To give my opinion, I’m hesitating about 2 approaches: > > Approach 1: “standard" > ================== > > * We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc. > > * Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user should copy the page to customize it instead of editing it. > > * The Color Theme UI should also be improved a bit to have a “Customize” button on color theme pages that would perform a copy to let the user customize a theme. > > Approach 2: “demo" > ================ > > * Consider all color themes to be demo content and once the user starts modifying them don’t merge them anymore > * When we want to provide modified color themes, introduce new theme pages > * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT. > > Analysis > ======= > > Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions. > > I think I’m leaning more towards 2 ATM.
So you think delete is OK too, right ?
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live).
I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback.
Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially.
Thanks, Caty
> > Thanks > -Vincent > >> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]>
wrote:
>> >> Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)). >> >> From the answer it seems we might need a new VOTE since several new points have been added to the discussion. I’m not able to VOTE right now. >> >> Thanks >> -Vincent >> >>> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> wrote: >>> >>> Hi xwikiers, >>> >>> Following new XAR entry type mail here is a question about color >>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >>> >>> 1) Standard stuff, if you want a custom color theme create a new one >>> (would be nice to be able to copy a standard one and propose it when >>> you try to edit a standard one). >>> >>> 2) Demo content, edit and delete it all you want and upgrade won't >>> touch a customized theme to avoid surprises (background color changed >>> a bit in the standard version which now collide with your logo) >>> >>> 3) Same as 2 but delete is bad (same as home page) >>> >>> WDYT ? >>> >>> I'm think I prefer 1) but I'm OK with 3) if other think it's more >>> example than standard material. Let's say -0 for 2). >>> >>> Thanks, >>> -- >>> Thomas Mortagne >> >
-- Thomas Mortagne
-- Thomas Mortagne
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
Hi, Vincent, On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :)
For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now.
You missed something from those snips where I explained the way I saw this and what might cause some confusion: "IMO, the important part to distinguish the fact that the configuration part (for a regular, non-dev) is choosing *which* color theme to use, while the customization (i.e. coding, done by someone that understands CSS/LESS, in this case) part is editing/customizing your own version of a color theme." i.e. Themes are not configuration, but actual code.
It would be the first time we copy something before allowing changing it and that’s not logical and not consistent.
The whole discussion is about not allowing to edit something, which is a first indeed, but we are moving in that direction, so of course there will be some changes to the way XWiki works.
In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages…
The more I think about it, the more I’m convinced that approach 2 is both the simplest (and I agree that “less is more” :)) and the most logical.
You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here).
Going again through the page types (specifically the "demo" one) and through the options, I agree that, at least of the Color Themes case, approach 2 should do the job. Of course, all of this being possible with the contract that we don't update color themes and we always publish new ones, of which I'm a bit skeptical. So +0.5 for approach 2. Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> wrote:
On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]
wrote: > To give my opinion, I’m hesitating about 2 approaches: > > Approach 1: “standard" > ================== > > * We should have “Default Color Theme” be a copy from the Iceberg color theme page. I think I’d prefer the copy to be done at runtime; for example if the currently defined color theme page doesn’t exist when going to the L&F > Themes admin page, create it by copying Iceberg. This provides a self healing feature if the color theme page has been removed/doesn’t exist/etc. > > * Predefined color theme pages should be considered “standard” and a warning message displayed if a user wants to edit them. BTW would be nice to have a feature to have a customized message per “type”. For example for color theme pages we would display a message saying that the user should copy the page to customize it instead of editing it. > > * The Color Theme UI should also be improved a bit to have a “Customize” button on color theme pages that would perform a copy to let the user customize a theme. > > Approach 2: “demo" > ================ > > * Consider all color themes to be demo content and once the user starts modifying them don’t merge them anymore > * When we want to provide modified color themes, introduce new theme pages > * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the default CT. > > Analysis > ======= > > Approach 2 is more wiki style and simpler for sure. Users can use the diff feature and the rollback feature if they want to go back to the original versions. > > I think I’m leaning more towards 2 ATM.
So you think delete is OK too, right ?
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live).
I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback.
Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially.
Thanks, Caty
> > Thanks > -Vincent > >> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]>
wrote:
>> >> Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has voted yet, not even Thomas (except if we consider that “prefer” means +1 and “OK” means +0 ;)). >> >> From the answer it seems we might need a new VOTE since several new points have been added to the discussion. I’m not able to VOTE right now. >> >> Thanks >> -Vincent >> >>> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> wrote: >>> >>> Hi xwikiers, >>> >>> Following new XAR entry type mail here is a question about color >>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >>> >>> 1) Standard stuff, if you want a custom color theme create a new one >>> (would be nice to be able to copy a standard one and propose it when >>> you try to edit a standard one). >>> >>> 2) Demo content, edit and delete it all you want and upgrade won't >>> touch a customized theme to avoid surprises (background color changed >>> a bit in the standard version which now collide with your logo) >>> >>> 3) Same as 2 but delete is bad (same as home page) >>> >>> WDYT ? >>> >>> I'm think I prefer 1) but I'm OK with 3) if other think it's more >>> example than standard material. Let's say -0 for 2). >>> >>> Thanks, >>> -- >>> Thomas Mortagne >> >
-- Thomas Mortagne
-- Thomas Mortagne
2018-04-26 14:13 GMT+02:00 Eduard Moraru <[email protected]>:
Hi, Vincent,
On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :)
For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now.
You missed something from those snips where I explained the way I saw this and what might cause some confusion:
"IMO, the important part to distinguish the fact that the configuration part (for a regular, non-dev) is choosing *which* color theme to use, while the customization (i.e. coding, done by someone that understands CSS/LESS, in this case) part is editing/customizing your own version of a color theme."
i.e. Themes are not configuration, but actual code.
That is actually sad. We already have the "Skin" concept as the "complex stuff people are not supposed to touch". As opposed to this, I have always seen the "Theme" as the "little stuff you can change easily to change some color of the big skin". I agree that themes can now contain a bit of "less" code. But if both Skin and Themes are seens as "complex stuff regular users should not change (because it's code)", it's very sad for the user-friendlyness, and it's probably time to make things better. Copying a theme when someone wants to edit is indeed breaking the wiki workflow and it's again something complex. I would prefer a simple button in the theme to "revert colors to factory default".
It would be the first time we copy something before allowing changing it and that’s not logical and not consistent.
The whole discussion is about not allowing to edit something, which is a first indeed, but we are moving in that direction, so of course there will be some changes to the way XWiki works.
In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages…
The more I think about it, the more I’m convinced that approach 2 is both the simplest (and I agree that “less is more” :)) and the most logical.
You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here).
Going again through the page types (specifically the "demo" one) and through the options, I agree that, at least of the Color Themes case, approach 2 should do the job. Of course, all of this being possible with the contract that we don't update color themes and we always publish new ones, of which I'm a bit skeptical.
So +0.5 for approach 2.
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> wrote:
> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
> wrote: >> To give my opinion, I’m hesitating about 2 approaches: >> >> Approach 1: “standard" >> ================== >> >> * We should have “Default Color Theme” be a copy from the Iceberg color > theme page. I think I’d prefer the copy to be done at runtime; for example > if the currently defined color theme page doesn’t exist when going
to
the
> L&F > Themes admin page, create it by copying Iceberg. This provides a self > healing feature if the color theme page has been removed/doesn’t exist/etc. >> >> * Predefined color theme pages should be considered “standard” and a > warning message displayed if a user wants to edit them. BTW would be nice > to have a feature to have a customized message per “type”. For example for > color theme pages we would display a message saying that the user should > copy the page to customize it instead of editing it. >> >> * The Color Theme UI should also be improved a bit to have a “Customize” > button on color theme pages that would perform a copy to let the user > customize a theme. >> >> Approach 2: “demo" >> ================ >> >> * Consider all color themes to be demo content and once the user starts > modifying them don’t merge them anymore >> * When we want to provide modified color themes, introduce new theme > pages >> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to > be the default CT. >> >> Analysis >> ======= >> >> Approach 2 is more wiki style and simpler for sure. Users can use the > diff feature and the rollback feature if they want to go back to the > original versions. >> >> I think I’m leaning more towards 2 ATM. > > So you think delete is OK too, right ? >
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live).
I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback.
Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially.
Thanks, Caty
> >> >> Thanks >> -Vincent >> >>> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote: >>> >>> Is this a VOTE or a proposal or a brainstorming? I’m asking since > nobody has voted yet, not even Thomas (except if we consider that “prefer” > means +1 and “OK” means +0 ;)). >>> >>> From the answer it seems we might need a new VOTE since several new > points have been added to the discussion. I’m not able to VOTE right now. >>> >>> Thanks >>> -Vincent >>> >>>> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> > wrote: >>>> >>>> Hi xwikiers, >>>> >>>> Following new XAR entry type mail here is a question about color >>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >>>> >>>> 1) Standard stuff, if you want a custom color theme create a new one >>>> (would be nice to be able to copy a standard one and propose it when >>>> you try to edit a standard one). >>>> >>>> 2) Demo content, edit and delete it all you want and upgrade won't >>>> touch a customized theme to avoid surprises (background color changed >>>> a bit in the standard version which now collide with your logo) >>>> >>>> 3) Same as 2 but delete is bad (same as home page) >>>> >>>> WDYT ? >>>> >>>> I'm think I prefer 1) but I'm OK with 3) if other think it's more >>>> example than standard material. Let's say -0 for 2). >>>> >>>> Thanks, >>>> -- >>>> Thomas Mortagne >>> >> > > > > -- > Thomas Mortagne >
-- Thomas Mortagne
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
So looks like 2) is the one getting the best upvote/downvote ratio so "demo" it is then. Thanks for your participation in this debate, if you enjoyed it there is many more to comes I'm sure :) On Thu, Apr 26, 2018 at 2:40 PM, Guillaume Delhumeau <[email protected]> wrote:
2018-04-26 14:13 GMT+02:00 Eduard Moraru <[email protected]>:
Hi, Vincent,
On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :)
For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now.
You missed something from those snips where I explained the way I saw this and what might cause some confusion:
"IMO, the important part to distinguish the fact that the configuration part (for a regular, non-dev) is choosing *which* color theme to use, while the customization (i.e. coding, done by someone that understands CSS/LESS, in this case) part is editing/customizing your own version of a color theme."
i.e. Themes are not configuration, but actual code.
That is actually sad. We already have the "Skin" concept as the "complex stuff people are not supposed to touch". As opposed to this, I have always seen the "Theme" as the "little stuff you can change easily to change some color of the big skin". I agree that themes can now contain a bit of "less" code. But if both Skin and Themes are seens as "complex stuff regular users should not change (because it's code)", it's very sad for the user-friendlyness, and it's probably time to make things better.
Copying a theme when someone wants to edit is indeed breaking the wiki workflow and it's again something complex. I would prefer a simple button in the theme to "revert colors to factory default".
It would be the first time we copy something before allowing changing it and that’s not logical and not consistent.
The whole discussion is about not allowing to edit something, which is a first indeed, but we are moving in that direction, so of course there will be some changes to the way XWiki works.
In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages…
The more I think about it, the more I’m convinced that approach 2 is both the simplest (and I agree that “less is more” :)) and the most logical.
You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here).
Going again through the page types (specifically the "demo" one) and through the options, I agree that, at least of the Color Themes case, approach 2 should do the job. Of course, all of this being possible with the contract that we don't update color themes and we always publish new ones, of which I'm a bit skeptical.
So +0.5 for approach 2.
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote: > On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> > wrote: > >> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
>> wrote: >>> To give my opinion, I’m hesitating about 2 approaches: >>> >>> Approach 1: “standard" >>> ================== >>> >>> * We should have “Default Color Theme” be a copy from the Iceberg color >> theme page. I think I’d prefer the copy to be done at runtime; for example >> if the currently defined color theme page doesn’t exist when going
to
the >> L&F > Themes admin page, create it by copying Iceberg. This provides a self >> healing feature if the color theme page has been removed/doesn’t exist/etc. >>> >>> * Predefined color theme pages should be considered “standard” and a >> warning message displayed if a user wants to edit them. BTW would be nice >> to have a feature to have a customized message per “type”. For example for >> color theme pages we would display a message saying that the user should >> copy the page to customize it instead of editing it. >>> >>> * The Color Theme UI should also be improved a bit to have a “Customize” >> button on color theme pages that would perform a copy to let the user >> customize a theme. >>> >>> Approach 2: “demo" >>> ================ >>> >>> * Consider all color themes to be demo content and once the user starts >> modifying them don’t merge them anymore >>> * When we want to provide modified color themes, introduce new theme >> pages >>> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to >> be the default CT. >>> >>> Analysis >>> ======= >>> >>> Approach 2 is more wiki style and simpler for sure. Users can use the >> diff feature and the rollback feature if they want to go back to the >> original versions. >>> >>> I think I’m leaning more towards 2 ATM. >> >> So you think delete is OK too, right ? >> > > For me delete is ok too. IMO we should provide just a few themes by > default, and the user should be able to uninstall and install what themes > he wants (ideally he would be able to preview them live). > > I don't like the copying part very much. Users like to have a base to start > from, but they also have history as a fallback. > > Also we rarely make changes to ColorThemes, especially since they are not > very complex since they should contain only variables. Still it all depends > on how well the Default Theme is tested initially. > > Thanks, > Caty > > >> >>> >>> Thanks >>> -Vincent >>> >>>> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote: >>>> >>>> Is this a VOTE or a proposal or a brainstorming? I’m asking since >> nobody has voted yet, not even Thomas (except if we consider that “prefer” >> means +1 and “OK” means +0 ;)). >>>> >>>> From the answer it seems we might need a new VOTE since several new >> points have been added to the discussion. I’m not able to VOTE right now. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> >> wrote: >>>>> >>>>> Hi xwikiers, >>>>> >>>>> Following new XAR entry type mail here is a question about color >>>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >>>>> >>>>> 1) Standard stuff, if you want a custom color theme create a new one >>>>> (would be nice to be able to copy a standard one and propose it when >>>>> you try to edit a standard one). >>>>> >>>>> 2) Demo content, edit and delete it all you want and upgrade won't >>>>> touch a customized theme to avoid surprises (background color changed >>>>> a bit in the standard version which now collide with your logo) >>>>> >>>>> 3) Same as 2 but delete is bad (same as home page) >>>>> >>>>> WDYT ? >>>>> >>>>> I'm think I prefer 1) but I'm OK with 3) if other think it's more >>>>> example than standard material. Let's say -0 for 2). >>>>> >>>>> Thanks, >>>>> -- >>>>> Thomas Mortagne >>>> >>> >> >> >> >> -- >> Thomas Mortagne >>
-- Thomas Mortagne
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
-- Thomas Mortagne
On Thu, Apr 26, 2018 at 3:40 PM, Guillaume Delhumeau < [email protected]> wrote:
2018-04-26 14:13 GMT+02:00 Eduard Moraru <[email protected]>:
Hi, Vincent,
On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :)
For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now.
You missed something from those snips where I explained the way I saw this and what might cause some confusion:
"IMO, the important part to distinguish the fact that the configuration part (for a regular, non-dev) is choosing *which* color theme to use, while the customization (i.e. coding, done by someone that understands CSS/LESS, in this case) part is editing/customizing your own version of a color theme."
i.e. Themes are not configuration, but actual code.
That is actually sad. We already have the "Skin" concept as the "complex stuff people are not supposed to touch". As opposed to this, I have always seen the "Theme" as the "little stuff you can change easily to change some color of the big skin". I agree that themes can now contain a bit of "less" code. But if both Skin and Themes are seens as "complex stuff regular users should not change (because it's code)", it's very sad for the user-friendlyness, and it's probably time to make things better.
Copying a theme when someone wants to edit is indeed breaking the wiki workflow and it's again something complex. I would prefer a simple button in the theme to "revert colors to factory default".
Yeah, you're right. Themes do go almost entirely into a configuration domain rather than a code domain, specifically since they have dedicated UI for each configurable variable. The LESS part is more for advanced stuff that a regular user would normally ignore. So it would more about configuring which "demo" configurations you want to use. Thanks, Eduard
It would be the first time we copy something before allowing changing
it
and that’s not logical and not consistent.
The whole discussion is about not allowing to edit something, which is a first indeed, but we are moving in that direction, so of course there will be some changes to the way XWiki works.
In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages…
The more I think about it, the more I’m convinced that approach 2 is both the simplest (and I agree that “less is more” :)) and the most logical.
You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here).
Going again through the page types (specifically the "demo" one) and through the options, I agree that, at least of the Color Themes case, approach 2 should do the job. Of course, all of this being possible with the contract that we don't update color themes and we always publish new ones, of which I'm a bit skeptical.
So +0.5 for approach 2.
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and
Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you
think
about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote: > On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> > wrote: > >> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
>> wrote: >>> To give my opinion, I’m hesitating about 2 approaches: >>> >>> Approach 1: “standard" >>> ================== >>> >>> * We should have “Default Color Theme” be a copy from the Iceberg color >> theme page. I think I’d prefer the copy to be done at runtime; for example >> if the currently defined color theme page doesn’t exist when going to the >> L&F > Themes admin page, create it by copying Iceberg. This provides a self >> healing feature if the color theme page has been removed/doesn’t exist/etc. >>> >>> * Predefined color theme pages should be considered “standard” and a >> warning message displayed if a user wants to edit them. BTW would be nice >> to have a feature to have a customized message per “type”. For example for >> color theme pages we would display a message saying that the user should >> copy the page to customize it instead of editing it. >>> >>> * The Color Theme UI should also be improved a bit to have a “Customize” >> button on color theme pages that would perform a copy to let the user >> customize a theme. >>> >>> Approach 2: “demo" >>> ================ >>> >>> * Consider all color themes to be demo content and once the user starts >> modifying them don’t merge them anymore >>> * When we want to provide modified color themes, introduce new theme >> pages >>> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to >> be the default CT. >>> >>> Analysis >>> ======= >>> >>> Approach 2 is more wiki style and simpler for sure. Users can use the >> diff feature and the rollback feature if they want to go back to the >> original versions. >>> >>> I think I’m leaning more towards 2 ATM. >> >> So you think delete is OK too, right ? >> > > For me delete is ok too. IMO we should provide just a few themes by > default, and the user should be able to uninstall and install what themes > he wants (ideally he would be able to preview them live). > > I don't like the copying part very much. Users like to have a base to start > from, but they also have history as a fallback. > > Also we rarely make changes to ColorThemes, especially since they are not > very complex since they should contain only variables. Still it all depends > on how well the Default Theme is tested initially. > > Thanks, > Caty > > >> >>> >>> Thanks >>> -Vincent >>> >>>> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote: >>>> >>>> Is this a VOTE or a proposal or a brainstorming? I’m asking since >> nobody has voted yet, not even Thomas (except if we consider that “prefer” >> means +1 and “OK” means +0 ;)). >>>> >>>> From the answer it seems we might need a new VOTE since several new >> points have been added to the discussion. I’m not able to VOTE right now. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> >> wrote: >>>>> >>>>> Hi xwikiers, >>>>> >>>>> Following new XAR entry type mail here is a question about color >>>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >>>>> >>>>> 1) Standard stuff, if you want a custom color theme create a new one >>>>> (would be nice to be able to copy a standard one and propose it when >>>>> you try to edit a standard one). >>>>> >>>>> 2) Demo content, edit and delete it all you want and upgrade won't >>>>> touch a customized theme to avoid surprises (background color changed >>>>> a bit in the standard version which now collide with your logo) >>>>> >>>>> 3) Same as 2 but delete is bad (same as home page) >>>>> >>>>> WDYT ? >>>>> >>>>> I'm think I prefer 1) but I'm OK with 3) if other think it's more >>>>> example than standard material. Let's say -0 for 2). >>>>> >>>>> Thanks, >>>>> -- >>>>> Thomas Mortagne >>>> >>> >> >> >> >> -- >> Thomas Mortagne >>
-- Thomas Mortagne
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
Hi Edy,
On 26 Apr 2018, at 14:13, Eduard Moraru <[email protected]> wrote:
Hi, Vincent,
On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :)
For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now.
You missed something from those snips where I explained the way I saw this and what might cause some confusion:
"IMO, the important part to distinguish the fact that the configuration part (for a regular, non-dev) is choosing *which* color theme to use, while the customization (i.e. coding, done by someone that understands CSS/LESS, in this case) part is editing/customizing your own version of a color theme."
i.e. Themes are not configuration, but actual code.
It would be the first time we copy something before allowing changing it and that’s not logical and not consistent.
The whole discussion is about not allowing to edit something, which is a first indeed, but we are moving in that direction, so of course there will be some changes to the way XWiki works.
For me XWiki has a huge advantage over any other software we know: it’s the ability to track changes to configuration and code. Not a lot of software do this. For ex, imagine I change a setting in JIRA or in Jenkins. There’s no way you’ll know about it, nor be able to see the diff of what was changed, nor be able to roll it back. That’s an enormous advantage and we shouldn’t remove it.
In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages…
The more I think about it, the more I’m convinced that approach 2 is both the simplest (and I agree that “less is more” :)) and the most logical.
You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here).
Going again through the page types (specifically the "demo" one) and through the options, I agree that, at least of the Color Themes case, approach 2 should do the job. Of course, all of this being possible with the contract that we don't update color themes and we always publish new ones, of which I'm a bit skeptical.
It’ll work, even if we update existing color themes. It’s just that users won’t get the changes by default as soon as they start customizing a theme. If we want, it would be not too hard to add a button in the Color Theme sheet to revert to the factory default (I think it was proposed by Guillaume too), to make it more user-friendly than having to go to the history view to do that. Thanks -Vincent
So +0.5 for approach 2.
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> wrote:
> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]
> wrote: >> To give my opinion, I’m hesitating about 2 approaches: >> >> Approach 1: “standard" >> ================== >> >> * We should have “Default Color Theme” be a copy from the Iceberg color > theme page. I think I’d prefer the copy to be done at runtime; for example > if the currently defined color theme page doesn’t exist when going to the > L&F > Themes admin page, create it by copying Iceberg. This provides a self > healing feature if the color theme page has been removed/doesn’t exist/etc. >> >> * Predefined color theme pages should be considered “standard” and a > warning message displayed if a user wants to edit them. BTW would be nice > to have a feature to have a customized message per “type”. For example for > color theme pages we would display a message saying that the user should > copy the page to customize it instead of editing it. >> >> * The Color Theme UI should also be improved a bit to have a “Customize” > button on color theme pages that would perform a copy to let the user > customize a theme. >> >> Approach 2: “demo" >> ================ >> >> * Consider all color themes to be demo content and once the user starts > modifying them don’t merge them anymore >> * When we want to provide modified color themes, introduce new theme > pages >> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to > be the default CT. >> >> Analysis >> ======= >> >> Approach 2 is more wiki style and simpler for sure. Users can use the > diff feature and the rollback feature if they want to go back to the > original versions. >> >> I think I’m leaning more towards 2 ATM. > > So you think delete is OK too, right ? >
For me delete is ok too. IMO we should provide just a few themes by default, and the user should be able to uninstall and install what themes he wants (ideally he would be able to preview them live).
I don't like the copying part very much. Users like to have a base to start from, but they also have history as a fallback.
Also we rarely make changes to ColorThemes, especially since they are not very complex since they should contain only variables. Still it all depends on how well the Default Theme is tested initially.
Thanks, Caty
> >> >> Thanks >> -Vincent >> >>> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote: >>> >>> Is this a VOTE or a proposal or a brainstorming? I’m asking since > nobody has voted yet, not even Thomas (except if we consider that “prefer” > means +1 and “OK” means +0 ;)). >>> >>> From the answer it seems we might need a new VOTE since several new > points have been added to the discussion. I’m not able to VOTE right now. >>> >>> Thanks >>> -Vincent >>> >>>> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> > wrote: >>>> >>>> Hi xwikiers, >>>> >>>> Following new XAR entry type mail here is a question about color >>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >>>> >>>> 1) Standard stuff, if you want a custom color theme create a new one >>>> (would be nice to be able to copy a standard one and propose it when >>>> you try to edit a standard one). >>>> >>>> 2) Demo content, edit and delete it all you want and upgrade won't >>>> touch a customized theme to avoid surprises (background color changed >>>> a bit in the standard version which now collide with your logo) >>>> >>>> 3) Same as 2 but delete is bad (same as home page) >>>> >>>> WDYT ? >>>> >>>> I'm think I prefer 1) but I'm OK with 3) if other think it's more >>>> example than standard material. Let's say -0 for 2). >>>> >>>> Thanks, >>>> -- >>>> Thomas Mortagne >>> >> > > > > -- > Thomas Mortagne >
-- Thomas Mortagne
On Fri, Apr 27, 2018 at 11:05 AM, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 26 Apr 2018, at 14:13, Eduard Moraru <[email protected]> wrote:
Hi, Vincent,
On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :)
For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now.
You missed something from those snips where I explained the way I saw this and what might cause some confusion:
"IMO, the important part to distinguish the fact that the configuration part (for a regular, non-dev) is choosing *which* color theme to use, while the customization (i.e. coding, done by someone that understands CSS/LESS, in this case) part is editing/customizing your own version of a color theme."
i.e. Themes are not configuration, but actual code.
It would be the first time we copy something before allowing changing it and that’s not logical and not consistent.
The whole discussion is about not allowing to edit something, which is a first indeed, but we are moving in that direction, so of course there will be some changes to the way XWiki works.
For me XWiki has a huge advantage over any other software we know: it’s the ability to track changes to configuration and code. Not a lot of software do this. For ex, imagine I change a setting in JIRA or in Jenkins. There’s no way you’ll know about it, nor be able to see the diff of what was changed, nor be able to roll it back. That’s an enormous advantage and we shouldn’t remove it.
Yes we need to show more of these reset button is use cases like theses (default themes, default configuration, etc.).
In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages…
The more I think about it, the more I’m convinced that approach 2 is both the simplest (and I agree that “less is more” :)) and the most logical.
You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here).
Going again through the page types (specifically the "demo" one) and through the options, I agree that, at least of the Color Themes case, approach 2 should do the job. Of course, all of this being possible with the contract that we don't update color themes and we always publish new ones, of which I'm a bit skeptical.
It’ll work, even if we update existing color themes. It’s just that users won’t get the changes by default as soon as they start customizing a theme.
If we want, it would be not too hard to add a button in the Color Theme sheet to revert to the factory default (I think it was proposed by Guillaume too), to make it more user-friendly than having to go to the history view to do that.
Thanks -Vincent
So +0.5 for approach 2.
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote: > On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> > wrote: > >> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[email protected]
>> wrote: >>> To give my opinion, I’m hesitating about 2 approaches: >>> >>> Approach 1: “standard" >>> ================== >>> >>> * We should have “Default Color Theme” be a copy from the Iceberg color >> theme page. I think I’d prefer the copy to be done at runtime; for example >> if the currently defined color theme page doesn’t exist when going to the >> L&F > Themes admin page, create it by copying Iceberg. This provides a self >> healing feature if the color theme page has been removed/doesn’t exist/etc. >>> >>> * Predefined color theme pages should be considered “standard” and a >> warning message displayed if a user wants to edit them. BTW would be nice >> to have a feature to have a customized message per “type”. For example for >> color theme pages we would display a message saying that the user should >> copy the page to customize it instead of editing it. >>> >>> * The Color Theme UI should also be improved a bit to have a “Customize” >> button on color theme pages that would perform a copy to let the user >> customize a theme. >>> >>> Approach 2: “demo" >>> ================ >>> >>> * Consider all color themes to be demo content and once the user starts >> modifying them don’t merge them anymore >>> * When we want to provide modified color themes, introduce new theme >> pages >>> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to >> be the default CT. >>> >>> Analysis >>> ======= >>> >>> Approach 2 is more wiki style and simpler for sure. Users can use the >> diff feature and the rollback feature if they want to go back to the >> original versions. >>> >>> I think I’m leaning more towards 2 ATM. >> >> So you think delete is OK too, right ? >> > > For me delete is ok too. IMO we should provide just a few themes by > default, and the user should be able to uninstall and install what themes > he wants (ideally he would be able to preview them live). > > I don't like the copying part very much. Users like to have a base to start > from, but they also have history as a fallback. > > Also we rarely make changes to ColorThemes, especially since they are not > very complex since they should contain only variables. Still it all depends > on how well the Default Theme is tested initially. > > Thanks, > Caty > > >> >>> >>> Thanks >>> -Vincent >>> >>>> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote: >>>> >>>> Is this a VOTE or a proposal or a brainstorming? I’m asking since >> nobody has voted yet, not even Thomas (except if we consider that “prefer” >> means +1 and “OK” means +0 ;)). >>>> >>>> From the answer it seems we might need a new VOTE since several new >> points have been added to the discussion. I’m not able to VOTE right now. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> >> wrote: >>>>> >>>>> Hi xwikiers, >>>>> >>>>> Following new XAR entry type mail here is a question about color >>>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >>>>> >>>>> 1) Standard stuff, if you want a custom color theme create a new one >>>>> (would be nice to be able to copy a standard one and propose it when >>>>> you try to edit a standard one). >>>>> >>>>> 2) Demo content, edit and delete it all you want and upgrade won't >>>>> touch a customized theme to avoid surprises (background color changed >>>>> a bit in the standard version which now collide with your logo) >>>>> >>>>> 3) Same as 2 but delete is bad (same as home page) >>>>> >>>>> WDYT ? >>>>> >>>>> I'm think I prefer 1) but I'm OK with 3) if other think it's more >>>>> example than standard material. Let's say -0 for 2). >>>>> >>>>> Thanks, >>>>> -- >>>>> Thomas Mortagne >>>> >>> >> >> >> >> -- >> Thomas Mortagne >>
-- Thomas Mortagne
-- Thomas Mortagne
On Fri, Apr 27, 2018 at 12:05 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 26 Apr 2018, at 14:13, Eduard Moraru <[email protected]> wrote:
Hi, Vincent,
On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
Thanks for your input, see below.
On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> wrote:
Hi,
I'm sorry, but nothing related to configuration inside pages looks very "wiki-like" to me.
[snip]
You should not need a developer (possibly the original developer of the project/customizations) in order to make a really basic operation such as an upgrade. Maybe I'm saying "sometimes less is more"? :)
I’m just reacting to this part, hence the snipping :)
For me approach 1 is both the complex approach by far and completely unwiki-like. The wiki way is to be able to make easy edits and be able to rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great and this is what we do everywhere in XWiki, including configurations since all configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And we’re not going to change that now.
You missed something from those snips where I explained the way I saw this and what might cause some confusion:
"IMO, the important part to distinguish the fact that the configuration part (for a regular, non-dev) is choosing *which* color theme to use, while the customization (i.e. coding, done by someone that understands CSS/LESS, in this case) part is editing/customizing your own version of a color theme."
i.e. Themes are not configuration, but actual code.
It would be the first time we copy something before allowing changing it and that’s not logical and not consistent.
The whole discussion is about not allowing to edit something, which is a first indeed, but we are moving in that direction, so of course there will be some changes to the way XWiki works.
For me XWiki has a huge advantage over any other software we know: it’s the ability to track changes to configuration and code. Not a lot of software do this. For ex, imagine I change a setting in JIRA or in Jenkins. There’s no way you’ll know about it, nor be able to see the diff of what was changed, nor be able to roll it back. That’s an enormous advantage and we shouldn’t remove it.
Of course, but I'm not sure how is that related to what I said. Configuration is and still will be editable and traceable in history. My concern is only about *code*, specifically code that is written, maintained and periodically released by someone other than the person currently editing it, thus introducing a high potential for conflicts. I share your grief for software not keeping a history of changes done in the configs.
In addition we would make a bigger mess since not only users would be directed to making copies of color themes pages but they would still be able to make modifications to current color theme pages…
The more I think about it, the more I’m convinced that approach 2 is
both
the simplest (and I agree that “less is more” :)) and the most logical.
You mentioned upgrade being a problem but I don’t think this is correct since approach 2 means that the color theme pages are “demo” pages meaning that there will never be any upgrade conflict. When we do new XWiki cycle versions, we will still be able to provide new color themes and since those are new (like Iceberg this year) users will be able to switch to them easily (there’s no upgrade issue either here).
Going again through the page types (specifically the "demo" one) and through the options, I agree that, at least of the Color Themes case, approach 2 should do the job. Of course, all of this being possible with the contract that we don't update color themes and we always publish new ones, of which I'm a bit skeptical.
It’ll work, even if we update existing color themes. It’s just that users won’t get the changes by default as soon as they start customizing a theme.
Thinking about this, how would they reset to the latest version? If they delete the page (hoping it will be re-added on the upgrade), I'm not sure if they will get it or if EM will consider that if it is deleted, then the user wants to keep it deleted.
If we want, it would be not too hard to add a button in the Color Theme sheet to revert to the factory default (I think it was proposed by Guillaume too), to make it more user-friendly than having to go to the history view to do that.
Indeed, a reset to defaults that would actually reset to the latest extension version of that document (suggested by Caty offline) would be indeed a nice feature for configuration docs. This should also cover the above case of restoring an edited and deleted page. Thanks, Eduard
Thanks -Vincent
So +0.5 for approach 2.
Thanks, Eduard
Thanks -Vincent
Thanks, Eduard
On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
So it seems that 2) is currently leading with Ecaterina and Vincent.
Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think about delete ?).
Marius, does your proposal means you are more for 1) but with the difference that the default color theme would be allowed for edit ?
Yes, but I'm ok with 2)
Any other point of view input ?
On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica) <[email protected]> wrote: > On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < [email protected]> > wrote: > >> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
>> wrote: >>> To give my opinion, I’m hesitating about 2 approaches: >>> >>> Approach 1: “standard" >>> ================== >>> >>> * We should have “Default Color Theme” be a copy from the Iceberg color >> theme page. I think I’d prefer the copy to be done at runtime; for example >> if the currently defined color theme page doesn’t exist when going
to
the >> L&F > Themes admin page, create it by copying Iceberg. This provides a self >> healing feature if the color theme page has been removed/doesn’t exist/etc. >>> >>> * Predefined color theme pages should be considered “standard” and a >> warning message displayed if a user wants to edit them. BTW would be nice >> to have a feature to have a customized message per “type”. For example for >> color theme pages we would display a message saying that the user should >> copy the page to customize it instead of editing it. >>> >>> * The Color Theme UI should also be improved a bit to have a “Customize” >> button on color theme pages that would perform a copy to let the user >> customize a theme. >>> >>> Approach 2: “demo" >>> ================ >>> >>> * Consider all color themes to be demo content and once the user starts >> modifying them don’t merge them anymore >>> * When we want to provide modified color themes, introduce new theme >> pages >>> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to >> be the default CT. >>> >>> Analysis >>> ======= >>> >>> Approach 2 is more wiki style and simpler for sure. Users can use the >> diff feature and the rollback feature if they want to go back to the >> original versions. >>> >>> I think I’m leaning more towards 2 ATM. >> >> So you think delete is OK too, right ? >> > > For me delete is ok too. IMO we should provide just a few themes by > default, and the user should be able to uninstall and install what themes > he wants (ideally he would be able to preview them live). > > I don't like the copying part very much. Users like to have a base to start > from, but they also have history as a fallback. > > Also we rarely make changes to ColorThemes, especially since they are not > very complex since they should contain only variables. Still it all depends > on how well the Default Theme is tested initially. > > Thanks, > Caty > > >> >>> >>> Thanks >>> -Vincent >>> >>>> On 25 Apr 2018, at 11:35, Vincent Massol <[email protected]> wrote: >>>> >>>> Is this a VOTE or a proposal or a brainstorming? I’m asking since >> nobody has voted yet, not even Thomas (except if we consider that “prefer” >> means +1 and “OK” means +0 ;)). >>>> >>>> From the answer it seems we might need a new VOTE since several new >> points have been added to the discussion. I’m not able to VOTE right now. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> On 23 Apr 2018, at 12:29, Thomas Mortagne < [email protected]> >> wrote: >>>>> >>>>> Hi xwikiers, >>>>> >>>>> Following new XAR entry type mail here is a question about color >>>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.). >>>>> >>>>> 1) Standard stuff, if you want a custom color theme create a new one >>>>> (would be nice to be able to copy a standard one and propose it when >>>>> you try to edit a standard one). >>>>> >>>>> 2) Demo content, edit and delete it all you want and upgrade won't >>>>> touch a customized theme to avoid surprises (background color changed >>>>> a bit in the standard version which now collide with your logo) >>>>> >>>>> 3) Same as 2 but delete is bad (same as home page) >>>>> >>>>> WDYT ? >>>>> >>>>> I'm think I prefer 1) but I'm OK with 3) if other think it's more >>>>> example than standard material. Let's say -0 for 2). >>>>> >>>>> Thanks, >>>>> -- >>>>> Thomas Mortagne >>>> >>> >> >> >> >> -- >> Thomas Mortagne >>
-- Thomas Mortagne
participants (6)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol