[xwiki-devs] [Brainstorming] Applications / Skin dependence
Hi, With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc. This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2]. In this thread I want to discuss some variants related to application's presentation: http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVar... I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause. Thanks, Caty [1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
Hi, This is a very complex subject, I read the proposal but it's difficult to choose ... Some thoughts below, more than answers. I'm in now way a css expert anyway :) There could be some additional info on extensions repository, telling you what is the "favorite skin" of an existing application. Something like "Best viewed with Flamingo-style skin". For this example, you would put most efforts on the look of the app under flamingo skin, and just minimal maintenance on how it looks with colibri (ie, check that functionalities are fulfilled, even if display is not optimal). Whatever the solution (branch not branch var1 2 3 4 ...), it's always a logical branch in terms of maintenance/validation, so it's always a cost for the application owner. Sometimes the line between pure presentation and "feature" is blurred. For example creating items from a pop-up (modal), to me it's not something that should depend on the skin. It only depends on your app. And it's already possible without bootstrap or flamingo, "bundled in XE" (like, users creation form). The way you display form fields is pure presentation (grid/columns/vertical/horizontal), but it's difficult to anticipate some semantic meaning of your fields when you use vertical layout / colibri, that would affect how you display them in a grid with bootstrap. Going back to your examples in [1], (i) and (ii) screenshots, from the bootstrap version I could define that there is a "title" zone (left column), an "assignment" zone (left column, over 2 sub-columns), a "status" zone (right column), and a "description" zone (below). I would use those names as css classes, then assign them a style according to the skin (bootstrap grids and whatever I want or nothing in colibri). But this I can only define once I migrated to a grid display, from the original view with colibri (vertical layout), I think I'd never have though about such structure. But putting in place this structure with proper css classes is a good thing for my app, whatever the skin. The fact that it won't improve the display in colibri is not an issue, at least it will not destroy anything. Putting directly the bootstrap "col-*" css classes in my html, has no semantics, mixes presentation with source, and has no benefit apart realizing a strong dependency to bootstrap which is not good for the future. Another question maybe, will colibri be considered an old skin, or an alternative skin ? Usually xwiki team supports only one skin at a time (after some kind of deprecation period), but the problem is that skins like colibri have a longer life-cycle and are more customized by users than older skins used to be (at least, I think). Currently in extension repository there are not so much "full" skins (custom or standard), there are quite a few colorthemes for colibri though, maybe because it's quite easy to create and package a color theme, but it's not so easy to create and package a complete xwiki skin. If creating and packaging skins gets easier (which is an objective I suppose, and is already easier than before), logically there should be more and more custom skins available. It would become even more difficult to solve the problem of presentation of an application depending on the skin. It would be interesting to know what real use of colibri skin is made by existing applications. To explain : in my app (mail archive), I used when I could css classes described by the vertical layout standard ("xform", etc). And I started to implement using velocity variables for colors coming from the ColorTheme, to adapt to the one selected. Apart from that, for the most "customized" views (like the topics view with answers), I generated completely custom HTML and specific css classes - I do not rely at all on colibri for this, except for the colors, because there's nothing fitting my needs in colibri (or in extensions I know). For these pages I completely assume skin compatibility, but at the same time I have nothing to do, except maybe add some mappings with bootstrap classes to improve display, if needed. All this reminds me of a discussion started by Denis on the same topic [2]. I tend to share the same view as Denis about this, that having more standard ways of producing html in xwiki could help solving nicely most issues with skins compatibilities. For example $doc.display is nice, but does only a very small part of the job it could do IMHO. So I started to write some velocity macros to generate form fields from both an XClass field definition, and the translation page prefix. Don't know if it's a good way to go, but based on some naming rules for fields translations (like, prefix.fieldname.hint, prefix.fieldname.label, etc...), if a translation exist or not, I display a field with or without xHint, label, etc. I also have a macro that you can pass an array of field names and that displays the corresponding form with vertical layout. Many things are missing, and the number of arguments of those macros is a bit big (but most of them are optional), but it allowed me to removed many boilerplate html (or boilerplate (% %) sequences, alternatively) from most of my pages with forms. And I like the fact that if a translation for a hint is not available in a language, then it's just not displayed, and I don't have to code this condition everywhere. Regarding my second remark about semantics, what would be missing is some macro to create a group of fields (ie a fieldset) with a specific css class (as that one can't be generic and depends on your app always and on the meaning of the fields). The semantics of fields do not always relate with where you display them and how they are grouped, but usually, as a good practice, it should. Maybe such macros already exist (maybe in AWM), but they're not published as a public api (or I'm not aware of it). To sum up moving to a new skin should not unlock new functionalities in your app, or else I think you're relying too much on this new skin. It should just unlock new ways of presenting your app UI. I'm more in favor of var3 (relying on a standard), as the parts mostly concerned are forms, and such a standard already exists for forms. If there's a way to have it cleanly adapt for colibri and flaming, and maybe introduce only new rules that may be implemented only with flamingo, I think it could work / be enough. If the standard is materialized by some sort of xwiki api, and applications rely on the standard, and the skins rely on the api, then you lower the maintenance activities. BR, Jeremie [1] http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation [2] http://markmail.org/message/shd55qxt7w56ypy3 2014-04-16 14:08 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation:
http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVar...
I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
2014-04-30 15:24 GMT+02:00 Jeremie BOUSQUET <[email protected]>:
Hi,
This is a very complex subject, I read the proposal but it's difficult to choose ... Some thoughts below, more than answers. I'm in now way a css expert anyway :)
There could be some additional info on extensions repository, telling you what is the "favorite skin" of an existing application. Something like "Best viewed with Flamingo-style skin". For this example, you would put most efforts on the look of the app under flamingo skin, and just minimal maintenance on how it looks with colibri (ie, check that functionalities are fulfilled, even if display is not optimal). Whatever the solution (branch not branch var1 2 3 4 ...), it's always a logical branch in terms of maintenance/validation, so it's always a cost for the application owner.
Sometimes the line between pure presentation and "feature" is blurred. For example creating items from a pop-up (modal), to me it's not something that should depend on the skin. It only depends on your app. And it's already possible without bootstrap or flamingo, "bundled in XE" (like, users creation form). The way you display form fields is pure presentation (grid/columns/vertical/horizontal), but it's difficult to anticipate some semantic meaning of your fields when you use vertical layout / colibri, that would affect how you display them in a grid with bootstrap. Going back to your examples in [1], (i) and (ii) screenshots, from the bootstrap version I could define that there is a "title" zone (left column), an "assignment" zone (left column, over 2 sub-columns), a "status" zone (right column), and a "description" zone (below). I would use those names as css classes, then assign them a style according to the skin (bootstrap grids and whatever I want or nothing in colibri). But this I can only define once I migrated to a grid display, from the original view with colibri (vertical layout), I think I'd never have though about such structure. But putting in place this structure with proper css classes is a good thing for my app, whatever the skin. The fact that it won't improve the display in colibri is not an issue, at least it will not destroy anything. Putting directly the bootstrap "col-*" css classes in my html, has no semantics, mixes presentation with source, and has no benefit apart realizing a strong dependency to bootstrap which is not good for the future.
Another question maybe, will colibri be considered an old skin, or an alternative skin ? Usually xwiki team supports only one skin at a time (after some kind of deprecation period), but the problem is that skins like colibri have a longer life-cycle and are more customized by users than older skins used to be (at least, I think). Currently in extension repository there are not so much "full" skins (custom or standard), there are quite a few colorthemes for colibri though, maybe because it's quite easy to create and package a color theme, but it's not so easy to create and package a complete xwiki skin. If creating and packaging skins gets easier (which is an objective I suppose, and is already easier than before), logically there should be more and more custom skins available. It would become even more difficult to solve the problem of presentation of an application depending on the skin.
It would be interesting to know what real use of colibri skin is made by existing applications. To explain : in my app (mail archive), I used when I could css classes described by the vertical layout standard ("xform", etc). And I started to implement using velocity variables for colors coming from the ColorTheme, to adapt to the one selected. Apart from that, for the most "customized" views (like the topics view with answers), I generated completely custom HTML and specific css classes - I do not rely at all on colibri for this, except for the colors, because there's nothing fitting my needs in colibri (or in extensions I know). For these pages I completely assume skin compatibility, but at the same time I have nothing to do, except maybe add some mappings with bootstrap classes to improve display, if needed.
All this reminds me of a discussion started by Denis on the same topic [2]. I tend to share the same view as Denis about this, that having more standard ways of producing html in xwiki could help solving nicely most issues with skins compatibilities. For example $doc.display is nice, but does only a very small part of the job it could do IMHO. So I started to write some velocity macros to generate form fields from both an XClass field definition, and the translation page prefix. Don't know if it's a good way to go, but based on some naming rules for fields translations (like, prefix.fieldname.hint, prefix.fieldname.label, etc...), if a translation exist or not, I display a field with or without xHint, label, etc. I also have a macro that you can pass an array of field names and that displays the corresponding form with vertical layout. Many things are missing, and the number of arguments of those macros is a bit big (but most of them are optional), but it allowed me to removed many boilerplate html (or boilerplate (% %) sequences, alternatively) from most of my pages with forms. And I like the fact that if a translation for a hint is not available in a language, then it's just not displayed, and I don't have to code this condition everywhere.
For example, #showFieldsFromPropClassName, with some divs to group some fields that can be displayed/hidden: https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/x...
Regarding my second remark about semantics, what would be missing is some macro to create a group of fields (ie a fieldset) with a specific css class (as that one can't be generic and depends on your app always and on the meaning of the fields). The semantics of fields do not always relate with where you display them and how they are grouped, but usually, as a good practice, it should. Maybe such macros already exist (maybe in AWM), but they're not published as a public api (or I'm not aware of it).
To sum up moving to a new skin should not unlock new functionalities in your app, or else I think you're relying too much on this new skin. It should just unlock new ways of presenting your app UI. I'm more in favor of var3 (relying on a standard), as the parts mostly concerned are forms, and such a standard already exists for forms. If there's a way to have it cleanly adapt for colibri and flaming, and maybe introduce only new rules that may be implemented only with flamingo, I think it could work / be enough. If the standard is materialized by some sort of xwiki api, and applications rely on the standard, and the skins rely on the api, then you lower the maintenance activities.
BR, Jeremie
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation [2] http://markmail.org/message/shd55qxt7w56ypy3
2014-04-16 14:08 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation:
http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVar...
I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
2014-04-30 15:55 GMT+02:00 Jeremie BOUSQUET <[email protected]>:
2014-04-30 15:24 GMT+02:00 Jeremie BOUSQUET <[email protected]>:
Hi,
This is a very complex subject, I read the proposal but it's difficult to choose ... Some thoughts below, more than answers. I'm in now way a css expert anyway :)
There could be some additional info on extensions repository, telling you what is the "favorite skin" of an existing application. Something like "Best viewed with Flamingo-style skin". For this example, you would put most efforts on the look of the app under flamingo skin, and just minimal maintenance on how it looks with colibri (ie, check that functionalities are fulfilled, even if display is not optimal). Whatever the solution (branch not branch var1 2 3 4 ...), it's always a logical branch in terms of maintenance/validation, so it's always a cost for the application owner.
Sometimes the line between pure presentation and "feature" is blurred. For example creating items from a pop-up (modal), to me it's not something that should depend on the skin. It only depends on your app. And it's already possible without bootstrap or flamingo, "bundled in XE" (like, users creation form). The way you display form fields is pure presentation (grid/columns/vertical/horizontal), but it's difficult to anticipate some semantic meaning of your fields when you use vertical layout / colibri, that would affect how you display them in a grid with bootstrap. Going back to your examples in [1], (i) and (ii) screenshots, from the bootstrap version I could define that there is a "title" zone (left column), an "assignment" zone (left column, over 2 sub-columns), a "status" zone (right column), and a "description" zone (below). I would use those names as css classes, then assign them a style according to the skin (bootstrap grids and whatever I want or nothing in colibri). But this I can only define once I migrated to a grid display, from the original view with colibri (vertical layout), I think I'd never have though about such structure. But putting in place this structure with proper css classes is a good thing for my app, whatever the skin. The fact that it won't improve the display in colibri is not an issue, at least it will not destroy anything. Putting directly the bootstrap "col-*" css classes in my html, has no semantics, mixes presentation with source, and has no benefit apart realizing a strong dependency to bootstrap which is not good for the future.
Another question maybe, will colibri be considered an old skin, or an alternative skin ? Usually xwiki team supports only one skin at a time (after some kind of deprecation period), but the problem is that skins like colibri have a longer life-cycle and are more customized by users than older skins used to be (at least, I think). Currently in extension repository there are not so much "full" skins (custom or standard), there are quite a few colorthemes for colibri though, maybe because it's quite easy to create and package a color theme, but it's not so easy to create and package a complete xwiki skin. If creating and packaging skins gets easier (which is an objective I suppose, and is already easier than before), logically there should be more and more custom skins available. It would become even more difficult to solve the problem of presentation of an application depending on the skin.
It would be interesting to know what real use of colibri skin is made by existing applications. To explain : in my app (mail archive), I used when I could css classes described by the vertical layout standard ("xform", etc). And I started to implement using velocity variables for colors coming from the ColorTheme, to adapt to the one selected. Apart from that, for the most "customized" views (like the topics view with answers), I generated completely custom HTML and specific css classes - I do not rely at all on colibri for this, except for the colors, because there's nothing fitting my needs in colibri (or in extensions I know). For these pages I completely assume skin compatibility, but at the same time I have nothing to do, except maybe add some mappings with bootstrap classes to improve display, if needed.
All this reminds me of a discussion started by Denis on the same topic [2]. I tend to share the same view as Denis about this, that having more standard ways of producing html in xwiki could help solving nicely most issues with skins compatibilities. For example $doc.display is nice, but does only a very small part of the job it could do IMHO. So I started to write some velocity macros to generate form fields from both an XClass field definition, and the translation page prefix. Don't know if it's a good way to go, but based on some naming rules for fields translations (like, prefix.fieldname.hint, prefix.fieldname.label, etc...), if a translation exist or not, I display a field with or without xHint, label, etc. I also have a macro that you can pass an array of field names and that displays the corresponding form with vertical layout. Many things are missing, and the number of arguments of those macros is a bit big (but most of them are optional), but it allowed me to removed many boilerplate html (or boilerplate (% %) sequences, alternatively) from most of my pages with forms. And I like the fact that if a translation for a hint is not available in a language, then it's just not displayed, and I don't have to code this condition everywhere.
For example, #showFieldsFromPropClassName, with some divs to group some fields that can be displayed/hidden:
https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/x...
... and related translations for the whole admin page, including some error cases: https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/x...
Regarding my second remark about semantics, what would be missing is some macro to create a group of fields (ie a fieldset) with a specific css class (as that one can't be generic and depends on your app always and on the meaning of the fields). The semantics of fields do not always relate with where you display them and how they are grouped, but usually, as a good practice, it should. Maybe such macros already exist (maybe in AWM), but they're not published as a public api (or I'm not aware of it).
To sum up moving to a new skin should not unlock new functionalities in your app, or else I think you're relying too much on this new skin. It should just unlock new ways of presenting your app UI. I'm more in favor of var3 (relying on a standard), as the parts mostly concerned are forms, and such a standard already exists for forms. If there's a way to have it cleanly adapt for colibri and flaming, and maybe introduce only new rules that may be implemented only with flamingo, I think it could work / be enough. If the standard is materialized by some sort of xwiki api, and applications rely on the standard, and the skins rely on the api, then you lower the maintenance activities.
BR, Jeremie
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation [2] http://markmail.org/message/shd55qxt7w56ypy3
2014-04-16 14:08 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation:
http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVar...
I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Apr 30, 2014 at 4:24 PM, Jeremie BOUSQUET < [email protected]> wrote:
Hi,
This is a very complex subject, I read the proposal but it's difficult to choose ... Some thoughts below, more than answers. I'm in now way a css expert anyway :)
There could be some additional info on extensions repository, telling you what is the "favorite skin" of an existing application. Something like "Best viewed with Flamingo-style skin". For this example, you would put most efforts on the look of the app under flamingo skin, and just minimal maintenance on how it looks with colibri (ie, check that functionalities are fulfilled, even if display is not optimal). Whatever the solution (branch not branch var1 2 3 4 ...), it's always a logical branch in terms of maintenance/validation, so it's always a cost for the application owner.
Sometimes the line between pure presentation and "feature" is blurred. For example creating items from a pop-up (modal), to me it's not something that should depend on the skin. It only depends on your app. And it's already possible without bootstrap or flamingo, "bundled in XE" (like, users creation form). The way you display form fields is pure presentation (grid/columns/vertical/horizontal), but it's difficult to anticipate some semantic meaning of your fields when you use vertical layout / colibri, that would affect how you display them in a grid with bootstrap. Going back to your examples in [1], (i) and (ii) screenshots, from the bootstrap version I could define that there is a "title" zone (left column), an "assignment" zone (left column, over 2 sub-columns), a "status" zone (right column), and a "description" zone (below). I would use those names as css classes, then assign them a style according to the skin (bootstrap grids and whatever I want or nothing in colibri). But this I can only define once I migrated to a grid display, from the original view with colibri (vertical layout), I think I'd never have though about such structure. But putting in place this structure with proper css classes is a good thing for my app, whatever the skin. The fact that it won't improve the display in colibri is not an issue, at least it will not destroy anything. Putting directly the bootstrap "col-*" css classes in my html, has no semantics, mixes presentation with source, and has no benefit apart realizing a strong dependency to bootstrap which is not good for the future.
Another question maybe, will colibri be considered an old skin, or an alternative skin ? Usually xwiki team supports only one skin at a time (after some kind of deprecation period), but the problem is that skins like colibri have a longer life-cycle and are more customized by users than older skins used to be (at least, I think). Currently in extension repository there are not so much "full" skins (custom or standard), there are quite a few colorthemes for colibri though, maybe because it's quite easy to create and package a color theme, but it's not so easy to create and package a complete xwiki skin. If creating and packaging skins gets easier (which is an objective I suppose, and is already easier than before), logically there should be more and more custom skins available. It would become even more difficult to solve the problem of presentation of an application depending on the skin.
It would be interesting to know what real use of colibri skin is made by existing applications. To explain : in my app (mail archive), I used when I could css classes described by the vertical layout standard ("xform", etc). And I started to implement using velocity variables for colors coming from the ColorTheme, to adapt to the one selected. Apart from that, for the most "customized" views (like the topics view with answers), I generated completely custom HTML and specific css classes - I do not rely at all on colibri for this, except for the colors, because there's nothing fitting my needs in colibri (or in extensions I know). For these pages I completely assume skin compatibility, but at the same time I have nothing to do, except maybe add some mappings with bootstrap classes to improve display, if needed.
All this reminds me of a discussion started by Denis on the same topic [2]. I tend to share the same view as Denis about this, that having more standard ways of producing html in xwiki could help solving nicely most issues with skins compatibilities. For example $doc.display is nice, but does only a very small part of the job it could do IMHO. So I started to write some velocity macros to generate form fields from both an XClass field definition, and the translation page prefix. Don't know if it's a good way to go, but based on some naming rules for fields translations (like, prefix.fieldname.hint, prefix.fieldname.label, etc...), if a translation exist or not, I display a field with or without xHint, label, etc. I also have a macro that you can pass an array of field names and that displays the corresponding form with vertical layout. Many things are missing, and the number of arguments of those macros is a bit big (but most of them are optional), but it allowed me to removed many boilerplate html (or boilerplate (% %) sequences, alternatively) from most of my pages with forms. And I like the fact that if a translation for a hint is not available in a language, then it's just not displayed, and I don't have to code this condition everywhere. Regarding my second remark about semantics, what would be missing is some macro to create a group of fields (ie a fieldset) with a specific css class (as that one can't be generic and depends on your app always and on the meaning of the fields). The semantics of fields do not always relate with where you display them and how they are grouped, but usually, as a good practice, it should. Maybe such macros already exist (maybe in AWM), but they're not published as a public api (or I'm not aware of it).
To sum up moving to a new skin should not unlock new functionalities in your app, or else I think you're relying too much on this new skin. It should just unlock new ways of presenting your app UI. I'm more in favor of var3 (relying on a standard), as the parts mostly concerned are forms, and such a standard already exists for forms. If there's a way to have it cleanly adapt for colibri and flaming, and maybe introduce only new rules that may be implemented only with flamingo, I think it could work / be enough. If the standard is materialized by some sort of xwiki api, and applications rely on the standard, and the skins rely on the api, then you lower the maintenance activities.
I'm also in favor of var3. Junco Skin solves this problem by having a mapping between the 'standard' and the Bootstrap specific classes, see https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-mapping.... But the thing is that we need to have LESS in order to extend and map the classes (or duplicate the code). Regarding your comments about the form macros, I agree that this system might be helpful and we should invest some time in cleaning/creating these 'standard' structure macros. Thanks for your answer, Caty
BR, Jeremie
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation [2] http://markmail.org/message/shd55qxt7w56ypy3
2014-04-16 14:08 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation:
http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVar...
I am interested in our position regarding this topic and if we have like
a
'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, I think it won't hurt to add an outsiders pov to the discussion although I'd guess it may sound a little bit provoking ;-). Consider dropping support of all Xwiki specifc theme / color editors in favor of an as-tight-as-possible developer-level integration of twitter bootstrap. Bang ! The reasoning for this is that no matter how much efforts and brains you will put into doing skins and colors a la xwiki you will never even come close to an amount of options that is offered by 3rd party commercial and free template vendors (that build on bootstrap). There are offers like themeforest http://themeforest.net/search?utf8=%E2%9C%93&term=bootstrap where you can find hundreds of theme templates based on bootstrap. For a designer / developer who tries to build individual customized front ends with very little effort this is a buffet of possibilities and inspiration. Given a better (=deeper) integration with xwiki might break ground for new use cases outside the 'traditional' wiki world. And xwiki users would benefit from an almost-as-easy individual site customization as other well recognized platforms offer (Wordpress, Joomla, Drupal, ...) IMHO Bootstrap is pretty much a safe choice in terms of long term support for the front end as java is as the programming language for the backend. And from my personal experience using themeforest / bootstrap as a development resource in a recent project: It's been fun, it's been effective, result is good looking. Enjoy Andreas Am 16.04.2014 14:08, schrieb Ecaterina Moraru (Valica):
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation: http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVar...
I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Andreas, Yes, we completely agree that we need to be able to reuse existing bootstrap themes. AFAIK what Guillaume was proposing was either to integrate a bootstrap theme maker UI (which one, I couldn’t find a good matching one when googling quickly?) or our own one (our ColorTheme application). But this would be only a way to generate a theme from XWiki’s UI. Of course we need to ensure that using existing bootstrap themes will work fine too and offer a way to upload/use them. Thanks -Vincent On 1 May 2014 at 11:34:23, Andreas Hahn ([email protected](mailto:[email protected])) wrote:
Hi,
I think it won't hurt to add an outsiders pov to the discussion although I'd guess it may sound a little bit provoking ;-).
Consider dropping support of all Xwiki specifc theme / color editors in favor of an as-tight-as-possible developer-level integration of twitter bootstrap.
Bang !
The reasoning for this is that no matter how much efforts and brains you will put into doing skins and colors a la xwiki you will never even come close to an amount of options that is offered by 3rd party commercial and free template vendors (that build on bootstrap).
There are offers like themeforest http://themeforest.net/search?utf8=%E2%9C%93&term=bootstrap where you can find hundreds of theme templates based on bootstrap. For a designer / developer who tries to build individual customized front ends with very little effort this is a buffet of possibilities and inspiration.
Given a better (=deeper) integration with xwiki might break ground for new use cases outside the 'traditional' wiki world. And xwiki users would benefit from an almost-as-easy individual site customization as other well recognized platforms offer (Wordpress, Joomla, Drupal, ...)
IMHO Bootstrap is pretty much a safe choice in terms of long term support for the front end as java is as the programming language for the backend.
And from my personal experience using themeforest / bootstrap as a development resource in a recent project: It's been fun, it's been effective, result is good looking.
Enjoy
Andreas
Am 16.04.2014 14:08, schrieb Ecaterina Moraru (Valica):
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation: http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVar...
I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, May 2, 2014 at 9:50 AM, [email protected] <[email protected]>wrote:
Hi Andreas,
Yes, we completely agree that we need to be able to reuse existing bootstrap themes.
AFAIK what Guillaume was proposing was either to integrate a bootstrap theme maker UI (which one, I couldn’t find a good matching one when googling quickly?)
Some 'quotes' from the Junco investigation http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin#HSimpleTheme... http://bootswatch.com/ http://bootswatchr.com/ http://stylebootstrap.info/ http://www.boottheme.com/ http://www.lavishbootstrap.com/ http://paintstrap.com/ Thanks, Caty
or our own one (our ColorTheme application). But this would be only a way to generate a theme from XWiki’s UI. Of course we need to ensure that using existing bootstrap themes will work fine too and offer a way to upload/use them.
Thanks -Vincent
On 1 May 2014 at 11:34:23, Andreas Hahn ([email protected](mailto: [email protected])) wrote:
Hi,
I think it won't hurt to add an outsiders pov to the discussion although I'd guess it may sound a little bit provoking ;-).
Consider dropping support of all Xwiki specifc theme / color editors in favor of an as-tight-as-possible developer-level integration of twitter bootstrap.
Bang !
The reasoning for this is that no matter how much efforts and brains you will put into doing skins and colors a la xwiki you will never even come close to an amount of options that is offered by 3rd party commercial and free template vendors (that build on bootstrap).
There are offers like themeforest http://themeforest.net/search?utf8=%E2%9C%93&term=bootstrap where you can find hundreds of theme templates based on bootstrap. For a designer / developer who tries to build individual customized front ends with very little effort this is a buffet of possibilities and inspiration.
Given a better (=deeper) integration with xwiki might break ground for new use cases outside the 'traditional' wiki world. And xwiki users would benefit from an almost-as-easy individual site customization as other well recognized platforms offer (Wordpress, Joomla, Drupal, ...)
IMHO Bootstrap is pretty much a safe choice in terms of long term support for the front end as java is as the programming language for the backend.
And from my personal experience using themeforest / bootstrap as a development resource in a recent project: It's been fun, it's been effective, result is good looking.
Enjoy
Andreas
Am 16.04.2014 14:08, schrieb Ecaterina Moraru (Valica):
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation:
http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVar...
I am interested in our position regarding this topic and if we have
like a
'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, IMO installing a theme from themeforest means a custom UI and custom applications that integrate in that particular theme, so it's var1 or var5. The main problem we are discussing here is being able to have the same application on multiple skins and this usually happens when we have multiple skins supported by the community. If you install a custom skin and you try to create a different experience/interaction you don't rely on community applications (although I'm sure you would expect them to easily integrate with the new theme). But I agree with the importance of being able to integrate third-party themes. Thanks, Caty On Thu, May 1, 2014 at 12:34 PM, Andreas Hahn <[email protected]> wrote:
Hi,
I think it won't hurt to add an outsiders pov to the discussion although I'd guess it may sound a little bit provoking ;-).
Consider dropping support of all Xwiki specifc theme / color editors in favor of an as-tight-as-possible developer-level integration of twitter bootstrap.
Bang !
The reasoning for this is that no matter how much efforts and brains you will put into doing skins and colors a la xwiki you will never even come close to an amount of options that is offered by 3rd party commercial and free template vendors (that build on bootstrap).
There are offers like themeforest http://themeforest.net/search?utf8=%E2%9C%93&term=bootstrap where you can find hundreds of theme templates based on bootstrap. For a designer / developer who tries to build individual customized front ends with very little effort this is a buffet of possibilities and inspiration.
Given a better (=deeper) integration with xwiki might break ground for new use cases outside the 'traditional' wiki world. And xwiki users would benefit from an almost-as-easy individual site customization as other well recognized platforms offer (Wordpress, Joomla, Drupal, ...)
IMHO Bootstrap is pretty much a safe choice in terms of long term support for the front end as java is as the programming language for the backend.
And from my personal experience using themeforest / bootstrap as a development resource in a recent project: It's been fun, it's been effective, result is good looking.
Enjoy
Andreas
Am 16.04.2014 14:08, schrieb Ecaterina Moraru (Valica):
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation: http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation# HVariants
I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Andreas. I agree it would be very nice to just purchase a theme on themeforest.comand install it on XWiki. But I have never purchased a theme like that. What do you obtain? A set of CSS files + an HTML template? A file overwriting all bootstrap variables? The sources of a Boostrap fork? If is is a CSS file, then probably the path URL for images will not work with the XWiki system (I mean /xwiki/bin/resources ), so you will have to modify it manually. If the reseller only provides a bootstrap variables file and some images, in a standardized package, then we could consider an automatic integration. If not, you will always need to spend some time to adapt your purchased theme to the XWiki mechanisms. Guillaume 2014-05-01 11:34 GMT+02:00 Andreas Hahn <[email protected]>:
Hi,
I think it won't hurt to add an outsiders pov to the discussion although I'd guess it may sound a little bit provoking ;-).
Consider dropping support of all Xwiki specifc theme / color editors in favor of an as-tight-as-possible developer-level integration of twitter bootstrap.
Bang !
The reasoning for this is that no matter how much efforts and brains you will put into doing skins and colors a la xwiki you will never even come close to an amount of options that is offered by 3rd party commercial and free template vendors (that build on bootstrap).
There are offers like themeforest http://themeforest.net/search?utf8=%E2%9C%93&term=bootstrap where you can find hundreds of theme templates based on bootstrap. For a designer / developer who tries to build individual customized front ends with very little effort this is a buffet of possibilities and inspiration.
Given a better (=deeper) integration with xwiki might break ground for new use cases outside the 'traditional' wiki world. And xwiki users would benefit from an almost-as-easy individual site customization as other well recognized platforms offer (Wordpress, Joomla, Drupal, ...)
IMHO Bootstrap is pretty much a safe choice in terms of long term support for the front end as java is as the programming language for the backend.
And from my personal experience using themeforest / bootstrap as a development resource in a recent project: It's been fun, it's been effective, result is good looking.
Enjoy
Andreas
Am 16.04.2014 14:08, schrieb Ecaterina Moraru (Valica):
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation: http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation# HVariants
I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
And because we cannot rewrite every applications build on top of xwiki, we need to provide a retro-compatibility system. Caty and I have written some "mapping" classes to handle this situation, just like this: a.button{ .btn; } But again, we cannot just use an external CSS file and hope it will works. My idea was to create a Color Theme Application, that exposes a lot of Bootstrap variables, and an easy way to export it as an extension on extensions.xwiki.org. So we would be able to easily provide new color themes. Guillaume 2014-05-12 19:15 GMT+02:00 Guillaume "Louis-Marie" Delhumeau < [email protected]>:
Hi Andreas.
I agree it would be very nice to just purchase a theme on themeforest.comand install it on XWiki. But I have never purchased a theme like that. What do you obtain? A set of CSS files + an HTML template? A file overwriting all bootstrap variables? The sources of a Boostrap fork?
If is is a CSS file, then probably the path URL for images will not work with the XWiki system (I mean /xwiki/bin/resources ), so you will have to modify it manually.
If the reseller only provides a bootstrap variables file and some images, in a standardized package, then we could consider an automatic integration. If not, you will always need to spend some time to adapt your purchased theme to the XWiki mechanisms.
Guillaume
2014-05-01 11:34 GMT+02:00 Andreas Hahn <[email protected]>:
Hi,
I think it won't hurt to add an outsiders pov to the discussion although I'd guess it may sound a little bit provoking ;-).
Consider dropping support of all Xwiki specifc theme / color editors in favor of an as-tight-as-possible developer-level integration of twitter bootstrap.
Bang !
The reasoning for this is that no matter how much efforts and brains you will put into doing skins and colors a la xwiki you will never even come close to an amount of options that is offered by 3rd party commercial and free template vendors (that build on bootstrap).
There are offers like themeforest http://themeforest.net/search?utf8=%E2%9C%93&term=bootstrap where you can find hundreds of theme templates based on bootstrap. For a designer / developer who tries to build individual customized front ends with very little effort this is a buffet of possibilities and inspiration.
Given a better (=deeper) integration with xwiki might break ground for new use cases outside the 'traditional' wiki world. And xwiki users would benefit from an almost-as-easy individual site customization as other well recognized platforms offer (Wordpress, Joomla, Drupal, ...)
IMHO Bootstrap is pretty much a safe choice in terms of long term support for the front end as java is as the programming language for the backend.
And from my personal experience using themeforest / bootstrap as a development resource in a recent project: It's been fun, it's been effective, result is good looking.
Enjoy
Andreas
Am 16.04.2014 14:08, schrieb Ecaterina Moraru (Valica):
Hi,
With the new Flamingo skin and with the design investigations done on existing Applications, there are more and more questions related to: * how will the applications be displayed on the new skin, while conserving the same look on the old skin; * how much an application should preserve previous functionality and how many efforts are we putting in adapting the functionality for new layouts; * when do we create a new application vs. when do we retire one; * etc.
This question applies in general to applications and you can also read some discussions about applications like Panels [1] or ColorThemes [2].
In this thread I want to discuss some variants related to application's presentation: http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation# HVariants
I am interested in our position regarding this topic and if we have like a 'standard' solution or if the answer depends on the application in cause.
Thanks, Caty
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements [2] http://design.xwiki.org/xwiki/bin/view/Proposal/ ColorThemeforFlamingo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Andreas Hahn -
Ecaterina Moraru (Valica) -
Guillaume "Louis-Marie" Delhumeau -
Jeremie BOUSQUET -
vincent＠massol.net