[xwiki-devs] [Discussion] Problematic ColorTheme extensibility
Hi, Since we introduces ColorThemes in XE 2.0 we've used them constantly, being a great improvement for the cases when we wanted to rapidly change the color variables used. The problem with the ColorThemes is that they contain a limited number of variables. There are places in Colibri where we've recycled and used variables that were not intended to be used there, for example: - Administration's vertical-menu is using $theme.panelCollapsedBackgroundColor (which was intended for the collapsed state of the panels); - Suggest search results is using for it's .resultContainer also $theme.panelCollapsedBackgroundColor; - etc. Also there are some variables in the ColorThemes like $theme.textPrimaryColor and $theme.textSecondaryColor or even $theme.backgroundSecondaryColor that are used quite randomly in the code (all being shades of gray in the default theme). Not knowing exactly what is the purpose and usage of a color is very easy when you create a ColorTheme to chose colors that in practice will not provide enough contrast or that will not look very nice together. Since their release, we've added just 6 new variables (2 for the "Add" menu and 4 for the notifications colors: warning, error, success and info). One of the reason behind not adding new colors was not to confuse the user with a wide range of color variations. The colortheme wizard was great at making it easy for the user to change the 36 variables, but having 50+ variables to set could be a difficult/complex task even when using a Wizard. Although when we created ColorThemes we had in mind that they will be skin independent I don't know if in practice this will be still valid. When we're going to create a new skin for XE it will have a different layout, a different semantic of the variables names and a different color pool need. These needs are not mappable on what we currently have. So I think the ColorThemes should be skin dependent and also version dependent in order to assure that is gonna look the way it was originally intended to look. For example I want to add some CSS3 gradients for the 3.4 Colibri skin, but I don't have enough variables to specify the gradient shades. To solve that I've used non semantically variables combinations like: background-image: -moz-linear-gradient(top, $theme.linkColor 0%, $theme.buttonPrimaryBackgroundColor 100%); background-image: -moz-linear-gradient(top, $theme.pageContentBackgroundColor 0%, $theme.buttonSecondaryBackgroundColor 100%); Even though the combination will work for the ColorTheme defined specially for XE 3.4, this means the other existing ColorThemes will be used in a way they were not designed for (like ColorThemes.Bordo theme, etc.) thus not being as good looking as before when applied on the new skin. The same use case will be for any other skin that we will create for the XE 4.x. IMO you can't assume that any defined colortheme will work "graciously" independent of the skin applied and version used. (they will work but the color mix will be random). So another solution would be add more colors to the ColorTheme. For variation of Colibri this will work, but for a new skin (that maybe will not have 2 sets of menus, or will not have 2 separate colors for the background and the content) all the semantic behind the variables naming will fail. We will end up with variables inside the colortheme that may never be used inside the new skin code and I don't even imagine how the ColorTheme Wizard would look like (a nice idea would be to adjust itself dynamically dependent of the enabled skin). Also I want to know what is your opinion regarding adding new variables. What is the backward compatibility strategy for that? Right now, we have a fallback ColorTheme that provides fallback colors in case the ColorTheme doesn't have those colors set. But this does not assure that installing an "old" red colortheme will look nice with the fallback blue colors. We are not telling the user anywhere that there are missing colors in the installed colortheme and also in the wizard is hard to know what colors are defined and what are the fallback ones (if you know what colors are missing than you can manual define them and you don't need to cover all wizard dialogs in order to find the inconsistencies). So IMO the only solution is to have ColorThemes designed dependent of a skin and a version, with the possibility to let the user manually enhance and reuse old colortheme to work on the new versions. Maybe you have other solutions. Thanks, Caty
Hi Caty On Fri, Dec 16, 2011 at 8:21 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Since we introduces ColorThemes in XE 2.0 we've used them constantly, being a great improvement for the cases when we wanted to rapidly change the color variables used. The problem with the ColorThemes is that they contain a limited number of variables. There are places in Colibri where we've recycled and used variables that were not intended to be used there, for example: - Administration's vertical-menu is using $theme.panelCollapsedBackgroundColor (which was intended for the collapsed state of the panels); - Suggest search results is using for it's .resultContainer also $theme.panelCollapsedBackgroundColor; - etc.
Also there are some variables in the ColorThemes like $theme.textPrimaryColor and $theme.textSecondaryColor or even $theme.backgroundSecondaryColor that are used quite randomly in the code (all being shades of gray in the default theme). Not knowing exactly what is the purpose and usage of a color is very easy when you create a ColorTheme to chose colors that in practice will not provide enough contrast or that will not look very nice together.
Since their release, we've added just 6 new variables (2 for the "Add" menu and 4 for the notifications colors: warning, error, success and info). One of the reason behind not adding new colors was not to confuse the user with a wide range of color variations. The colortheme wizard was great at making it easy for the user to change the 36 variables, but having 50+ variables to set could be a difficult/complex task even when using a Wizard.
Although when we created ColorThemes we had in mind that they will be skin independent I don't know if in practice this will be still valid.
Indeed, it's not, right now it's very colibri specific. I've started integrating support for color themes in Lyrebird, a skin I'm working on (https://github.com/jvelo/Lyrebird), and I could barey use a couple of properties, all the other made no sense.
When we're going to create a new skin for XE it will have a different layout, a different semantic of the variables names and a different color pool need. These needs are not mappable on what we currently have.
So I think the ColorThemes should be skin dependent and also version dependent in order to assure that is gonna look the way it was originally intended to look.
Maybe there could be a middle path where your color theme is composed of a an object common for all skins (with couple of properties you can expect to find in any skin, like button color, link color, background color, etc.) and an object specific per skin. (Each color theme would be able to implement from one to all skins available for example). This is an idea, I don't know if in practice this would be handy or not. But it sounds already better to me.
For example I want to add some CSS3 gradients for the 3.4 Colibri skin, but I don't have enough variables to specify the gradient shades. To solve that I've used non semantically variables combinations like: background-image: -moz-linear-gradient(top, $theme.linkColor 0%, $theme.buttonPrimaryBackgroundColor 100%); background-image: -moz-linear-gradient(top, $theme.pageContentBackgroundColor 0%, $theme.buttonSecondaryBackgroundColor 100%);
One thing we could do is to push for server-side support of a preprocessor like LESS (http://lesscss.org/). Then for this particular problem you can use color functions like "lighten 10%, or "desaturate 5%", etc. (See http://lesscss.org/#-color-functions). And I think there is plenty other reason why we would want to adopt such a preprocessor. I've been using LESS for couple of weeks now, and it makes a big difference in expressiveness, conciseness, productivity, and more. I've started to work on a branch of platform in my fork to add support for pre-processors on skin extensions : https://github.com/jvelo/xwiki-platform/tree/sx-preprocessors - more work is required though.
Even though the combination will work for the ColorTheme defined specially for XE 3.4, this means the other existing ColorThemes will be used in a way they were not designed for (like ColorThemes.Bordo theme, etc.) thus not being as good looking as before when applied on the new skin. The same use case will be for any other skin that we will create for the XE 4.x. IMO you can't assume that any defined colortheme will work "graciously" independent of the skin applied and version used. (they will work but the color mix will be random).
So another solution would be add more colors to the ColorTheme. For variation of Colibri this will work, but for a new skin (that maybe will not have 2 sets of menus, or will not have 2 separate colors for the background and the content) all the semantic behind the variables naming will fail. We will end up with variables inside the colortheme that may never be used inside the new skin code and I don't even imagine how the ColorTheme Wizard would look like (a nice idea would be to adjust itself dynamically dependent of the enabled skin).
Also I want to know what is your opinion regarding adding new variables. What is the backward compatibility strategy for that? Right now, we have a fallback ColorTheme that provides fallback colors in case the ColorTheme doesn't have those colors set. But this does not assure that installing an "old" red colortheme will look nice with the fallback blue colors. We are not telling the user anywhere that there are missing colors in the installed colortheme and also in the wizard is hard to know what colors are defined and what are the fallback ones (if you know what colors are missing than you can manual define them and you don't need to cover all wizard dialogs in order to find the inconsistencies).
So IMO the only solution is to have ColorThemes designed dependent of a skin and a version, with the possibility to let the user manually enhance and reuse old colortheme to work on the new versions. Maybe you have other solutions.
The per-version idea is hard to implement/support in reality I believe. Maybe we could have a small message in the administration UI next to the selected color theme, like "Your color theme is missing 5 parameters, fix it here", and more explicitly show in the color theme editor what parameters are missing ? WDYT ?
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
On Sat, Dec 17, 2011 at 12:47, Jerome Velociter <[email protected]>wrote:
Hi Caty
On Fri, Dec 16, 2011 at 8:21 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Since we introduces ColorThemes in XE 2.0 we've used them constantly, being a great improvement for the cases when we wanted to rapidly change the color variables used. The problem with the ColorThemes is that they contain a limited number of variables. There are places in Colibri where we've recycled and used variables that were not intended to be used there, for example: - Administration's vertical-menu is using $theme.panelCollapsedBackgroundColor (which was intended for the collapsed state of the panels); - Suggest search results is using for it's .resultContainer also $theme.panelCollapsedBackgroundColor; - etc.
Also there are some variables in the ColorThemes like $theme.textPrimaryColor and $theme.textSecondaryColor or even $theme.backgroundSecondaryColor that are used quite randomly in the code (all being shades of gray in the default theme). Not knowing exactly what is the purpose and usage of a color is very easy when you create a ColorTheme to chose colors that in practice will not provide enough contrast or that will not look very nice together.
Since their release, we've added just 6 new variables (2 for the "Add" menu and 4 for the notifications colors: warning, error, success and info). One of the reason behind not adding new colors was not to confuse the user with a wide range of color variations. The colortheme wizard was great at making it easy for the user to change the 36 variables, but having 50+ variables to set could be a difficult/complex task even when using a Wizard.
Although when we created ColorThemes we had in mind that they will be skin independent I don't know if in practice this will be still valid.
Indeed, it's not, right now it's very colibri specific. I've started integrating support for color themes in Lyrebird, a skin I'm working on (https://github.com/jvelo/Lyrebird), and I could barey use a couple of properties, all the other made no sense.
When we're going to create a new skin for XE it will have a different layout, a different semantic of the variables names and a different color pool need. These needs are not mappable on what we currently have.
So I think the ColorThemes should be skin dependent and also version dependent in order to assure that is gonna look the way it was originally intended to look.
Maybe there could be a middle path where your color theme is composed of a an object common for all skins (with couple of properties you can expect to find in any skin, like button color, link color, background color, etc.) and an object specific per skin. (Each color theme would be able to implement from one to all skins available for example). This is an idea, I don't know if in practice this would be handy or not. But it sounds already better to me.
For example I want to add some CSS3 gradients for the 3.4 Colibri skin, but I don't have enough variables to specify the gradient shades. To solve that I've used non semantically variables combinations like: background-image: -moz-linear-gradient(top, $theme.linkColor 0%, $theme.buttonPrimaryBackgroundColor 100%); background-image: -moz-linear-gradient(top, $theme.pageContentBackgroundColor 0%, $theme.buttonSecondaryBackgroundColor 100%);
One thing we could do is to push for server-side support of a preprocessor like LESS (http://lesscss.org/). Then for this particular problem you can use color functions like "lighten 10%, or "desaturate 5%", etc. (See http://lesscss.org/#-color-functions). And I think there is plenty other reason why we would want to adopt such a preprocessor. I've been using LESS for couple of weeks now, and it makes a big difference in expressiveness, conciseness, productivity, and more. I've started to work on a branch of platform in my fork to add support for pre-processors on skin extensions : https://github.com/jvelo/xwiki-platform/tree/sx-preprocessors - more work is required though.
Haven't worked with it - I need to test it to see what it does.
Even though the combination will work for the ColorTheme defined
specially
for XE 3.4, this means the other existing ColorThemes will be used in a way they were not designed for (like ColorThemes.Bordo theme, etc.) thus not being as good looking as before when applied on the new skin. The same use case will be for any other skin that we will create for the XE 4.x. IMO you can't assume that any defined colortheme will work "graciously" independent of the skin applied and version used. (they will work but the color mix will be random).
So another solution would be add more colors to the ColorTheme. For variation of Colibri this will work, but for a new skin (that maybe will not have 2 sets of menus, or will not have 2 separate colors for the background and the content) all the semantic behind the variables naming will fail. We will end up with variables inside the colortheme that may never be used inside the new skin code and I don't even imagine how the ColorTheme Wizard would look like (a nice idea would be to adjust itself dynamically dependent of the enabled skin).
Also I want to know what is your opinion regarding adding new variables. What is the backward compatibility strategy for that? Right now, we have a fallback ColorTheme that provides fallback colors in case the ColorTheme doesn't have those colors set. But this does not assure that installing an "old" red colortheme will look nice with the fallback blue colors. We are not telling the user anywhere that there are missing colors in the installed colortheme and also in the wizard is hard to know what colors are defined and what are the fallback ones (if you know what colors are missing than you can manual define them and you don't need to cover all wizard dialogs in order to find the inconsistencies).
So IMO the only solution is to have ColorThemes designed dependent of a skin and a version, with the possibility to let the user manually enhance and reuse old colortheme to work on the new versions. Maybe you have other solutions.
The per-version idea is hard to implement/support in reality I believe.
Maybe we could have a small message in the administration UI next to the selected color theme, like "Your color theme is missing 5 parameters, fix it here", and more explicitly show in the color theme editor what parameters are missing ?
Not sure in the administration, but like I've said in the Wizard itself (just like we do on the Class Editor when we have properties missing). Thanks Jerome for your answer. Caty
WDYT ?
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Ecaterina Moraru (Valica) -
Jerome Velociter