[xwiki-devs] [Vote][Skin] Keep Colibri look or have another look for 6.x
Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin = Similarities = * Both skins have been done using the Twitter's Bootstrap framework ( http://getbootstrap.com) * Both skin are thus responsive = Differences = * Flamingo is just a proposal, while Junco is an extension. The difference is that while for Flamingo I have just a prototype, Junco is functional and installable (with some integration problems/dependencies discussed in another thread). The difference matter just from a development time perspective (if we choose Flamingo it will take longer to implement). * Flamingo provides a new look while Junco offers 'Themes', one of themes being very similar to Colibri, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin#HTheme:Colib... This vote mail is about this difference. What to consider: A. Freshness Advantages of Flamingo is that its interface is centered around Applications (it has a new left panel used for navigation). It will provide a visual difference from Colibri and looks more similar to current applications found in the wild. Advantages of Junco is that it provides Themes. Junco's Themes are very similar to our current ColorThemes, the difference is that they can change also the font used, the colors and can also add some esthetic effects (gradients, borders, shadows, etc. - CSS effects) to Bootstrap's components (buttons, navbars, alerts, tables, etc.). But except minor changes, the layout is similar to Colibri. Improvement consist in using refreshed style for font, forms, buttons, messages, etc. B. Extensions Integration One of the reasons I choose to make Junco similar to Colibri was extensions integration. The advantage of XWiki is that you can extend it how you like. The problem is that because the extensions are developed by our community (and not by a single entity) each application is providing it's own style. On extensions.xwiki.org we have applications that provide an unique style, while others are build around and for Colibri. Adding a new skin with a different style (like Flamingo) will make current extensions not look unitary. This problem is more general than just this Colibri/Junco/Flamingo discussion and it the problem of having extensions that adapt to the skin used (without creating special versions for each skin). Junco was created to look similar to Colibri (preserving layout, style, colors) while updating the 'back-end' (created on Bootstrap, it will put at developer's disposal the Bootstrap's guide style and components). One of the reasons we are having this extensions 'incompatibility' is because we are lacking visual standards and guides (maybe using the ones provided by Bootstrap can improve this area - I will send a separate mail about the CSS Framework selection). So from the style standards perspective having Junco integrated first could represent a transition step between our current Colibri and a new skin with a different look, because the developers might use Bootstrap style/structure guides in their extension development (not guaranteed). C. Parallel skin support Another advantage of Junco is that (by having the same layout) is using the same templates as Colibri. Having just a set of templates to maintain is very important from a development perspective especially if your development resources are limited. This is one of the reasons XWiki is not supporting multiple default skins. Flamingo will need some templates changed, so important from a development time and maintenance perspective. So this vote is about: 1. Keep Colibri's current look which is supported by the Junco skin, or 2. Have another look for 6.x which is proposed in the Flamingo skin Thanks, Caty
Hi, Maybe some other opinions? Thanks, Caty On Tue, Jan 28, 2014 at 12:51 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki.
Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin
= Similarities = * Both skins have been done using the Twitter's Bootstrap framework ( http://getbootstrap.com) * Both skin are thus responsive
= Differences = * Flamingo is just a proposal, while Junco is an extension. The difference is that while for Flamingo I have just a prototype, Junco is functional and installable (with some integration problems/dependencies discussed in another thread). The difference matter just from a development time perspective (if we choose Flamingo it will take longer to implement).
* Flamingo provides a new look while Junco offers 'Themes', one of themes being very similar to Colibri, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin#HTheme:Colib... This vote mail is about this difference. What to consider:
A. Freshness Advantages of Flamingo is that its interface is centered around Applications (it has a new left panel used for navigation). It will provide a visual difference from Colibri and looks more similar to current applications found in the wild. Advantages of Junco is that it provides Themes. Junco's Themes are very similar to our current ColorThemes, the difference is that they can change also the font used, the colors and can also add some esthetic effects (gradients, borders, shadows, etc. - CSS effects) to Bootstrap's components (buttons, navbars, alerts, tables, etc.). But except minor changes, the layout is similar to Colibri. Improvement consist in using refreshed style for font, forms, buttons, messages, etc.
B. Extensions Integration One of the reasons I choose to make Junco similar to Colibri was extensions integration. The advantage of XWiki is that you can extend it how you like. The problem is that because the extensions are developed by our community (and not by a single entity) each application is providing it's own style. On extensions.xwiki.org we have applications that provide an unique style, while others are build around and for Colibri. Adding a new skin with a different style (like Flamingo) will make current extensions not look unitary. This problem is more general than just this Colibri/Junco/Flamingo discussion and it the problem of having extensions that adapt to the skin used (without creating special versions for each skin). Junco was created to look similar to Colibri (preserving layout, style, colors) while updating the 'back-end' (created on Bootstrap, it will put at developer's disposal the Bootstrap's guide style and components). One of the reasons we are having this extensions 'incompatibility' is because we are lacking visual standards and guides (maybe using the ones provided by Bootstrap can improve this area - I will send a separate mail about the CSS Framework selection). So from the style standards perspective having Junco integrated first could represent a transition step between our current Colibri and a new skin with a different look, because the developers might use Bootstrap style/structure guides in their extension development (not guaranteed).
C. Parallel skin support Another advantage of Junco is that (by having the same layout) is using the same templates as Colibri. Having just a set of templates to maintain is very important from a development perspective especially if your development resources are limited. This is one of the reasons XWiki is not supporting multiple default skins. Flamingo will need some templates changed, so important from a development time and maintenance perspective.
So this vote is about: 1. Keep Colibri's current look which is supported by the Junco skin, or 2. Have another look for 6.x which is proposed in the Flamingo skin
Thanks, Caty
Hi Cathy, You have launch a couple of not so easy threads, and probably why no one have found enough time yet to follow up. I really hope this will change in the upcoming days, since the skin evolution is very important aspect that really need to be thoroughly discussed. As I see it, choosing between 1. "keeping the colibri look" using the Junco skin, and 2. using a fresh look like flamingo, based on your developed arguments, is more a question about what do we do with our current templates, and how free are we to change them ? Could we afford and impose a new improvement to our markups and templates, while providing enough backward compatibility for existing extensions. In your Bootstrap integration thread, I develop the technical aspect around these markup issues, showing, I hope, that we have the occasion to smoothly evolve our skin without getting stuck by the past. Regarding the design aspect, your Flamingo proposal is far more refreshing and appealing, providing a more responsive look that I hope could extends our user base. If we could implement it without extending bootstrap, allowing it to be restyled with any bootstrap variants, it would make it a very versatile skin. So, if we could target that new skin, while keeping an acceptable compromise for existing stuff, I see no reason not to move forward. This is not really a choice between 1) and 2), since what I propose is to use Junco to provide a backward compatibility CSS, and for a while also a modernized colibri skin using our existing templates, and to also evolve our templates, using a more bootstrap based markups to produce that more appealing Flamingo skin. So, it is more 2) than 1), since we will only target 2) for new stuffs. WDYT ?
On Sun, Feb 23, 2014 at 12:58 AM, Denis Gervalle <[email protected]> wrote:
Hi Cathy,
You have launch a couple of not so easy threads, and probably why no one have found enough time yet to follow up. I really hope this will change in the upcoming days, since the skin evolution is very important aspect that really need to be thoroughly discussed.
As I see it, choosing between 1. "keeping the colibri look" using the Junco skin, and 2. using a fresh look like flamingo, based on your developed arguments, is more a question about what do we do with our current templates, and how free are we to change them ? Could we afford and impose a new improvement to our markups and templates, while providing enough backward compatibility for existing extensions.
In your Bootstrap integration thread, I develop the technical aspect around these markup issues, showing, I hope, that we have the occasion to smoothly evolve our skin without getting stuck by the past. Regarding the design aspect, your Flamingo proposal is far more refreshing and appealing, providing a more responsive look that I hope could extends our user base. If we could implement it without extending bootstrap, allowing it to be restyled with any bootstrap variants, it would make it a very versatile skin.
So, if we could target that new skin, while keeping an acceptable compromise for existing stuff, I see no reason not to move forward. This is not really a choice between 1) and 2), since what I propose is to use Junco to provide a backward compatibility CSS, and for a while also a modernized colibri skin using our existing templates, and to also evolve our templates, using a more bootstrap based markups to produce that more appealing Flamingo skin. So, it is more 2) than 1), since we will only target 2) for new stuffs.
So what you are saying is that: - if someone wants a backwards compatible skin (with Colibri and with current extensions on e.x.o) should use Junco and - if someone wants a new skin (where we implement new functionality) should use Flamingo.
From your e-mail I understand that your preference goes towards Flamingo. I admit that Junco is more of a compromise solution for our problems and I've seen it as in intermediate step towards Flamingo, while still providing new functionality and making us advanced (in the shortest time possible).
The issue is our development resources and I think it would be hard for us to officially maintain 2 skins. So maybe some solutions would be: A. Officially: Colibri + Junco + Flamingo - Maintain support for Colibri, but not innovate. We should support this skin for 1 year at least; - Support Junco, as in intermediary solution for Colibri and Flamingo; - Support Flamingo (new stuff). B. Officially: Colibri + Flamingo - Maintain support for Colibri, but not innovate; - Support Flamingo; - Have Junco on e.x.o as a backwards compatibility solution. C. Officially: Junco + Flamingo - Stop support for Colibri since Junco will kind of duplicate it (while adding the Bootstrap functionality); - Support Junco - Support Flamingo. These are just ideas. Thanks, Caty
WDYT ?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Personally all I know is that we need a fresh look in XWiki 6.x so for me there’s no doubt that we want Flamingo. What needs to be discussed is how to get there. There are 2 paths: A) modify our templates/css heavily to use Bootstrap and base the new Flamingo on that B) keep the current templates as much as possible, with possibly some changes and move templates specific to Colibri in the Colibri skin and templates specific to Flamingo in the flamingo skin, keeping common templates in the templates directory. No bootstrap integration. Pros and Cons of solution A: ============================ + foundation for the future + allow us to perform cleanup of our templates + ability to use bootstrap themes (an issue we’ve had for a long since so far we’ve never been able to support more than 1 skin - We could do color changes but not structural changes) - more costly - will take more time to have Flamingo ready for end users - need to rethink the notion of Color Themes into a more global notion of Skin Theme which affects not only colors but also other parameters (centered or not, etc) Pros and Cons of solution B: ============================ + less costly + quicker to get in the hands of our users and thus quicker adoption of XWiki as a product - only able to support one skin as we’ve done in the past - not building for the future and not able to leverage the work done by others on bootstrap Obviously A is the best option if you have all the devs in the world and all the time in the world… :) Personally I’d like and need to see an evaluation of the work required to do A) before choosing anything. What can be done in 6.0, 6.1, etc? In which XWiki release would we be able to see Flamingo ready if we were to do A? What is important IMO is to be able to show UI improvements/progress in every release of XWiki (6.0, 6.1, etc) since we’ve been lagging a bit behind on this. Thanks! -Vincent On 24 Feb 2014 at 09:44:57, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:
On Sun, Feb 23, 2014 at 12:58 AM, Denis Gervalle wrote:
Hi Cathy,
You have launch a couple of not so easy threads, and probably why no one have found enough time yet to follow up. I really hope this will change in the upcoming days, since the skin evolution is very important aspect that really need to be thoroughly discussed.
As I see it, choosing between 1. "keeping the colibri look" using the Junco skin, and 2. using a fresh look like flamingo, based on your developed arguments, is more a question about what do we do with our current templates, and how free are we to change them ? Could we afford and impose a new improvement to our markups and templates, while providing enough backward compatibility for existing extensions.
In your Bootstrap integration thread, I develop the technical aspect around these markup issues, showing, I hope, that we have the occasion to smoothly evolve our skin without getting stuck by the past. Regarding the design aspect, your Flamingo proposal is far more refreshing and appealing, providing a more responsive look that I hope could extends our user base. If we could implement it without extending bootstrap, allowing it to be restyled with any bootstrap variants, it would make it a very versatile skin.
So, if we could target that new skin, while keeping an acceptable compromise for existing stuff, I see no reason not to move forward. This is not really a choice between 1) and 2), since what I propose is to use Junco to provide a backward compatibility CSS, and for a while also a modernized colibri skin using our existing templates, and to also evolve our templates, using a more bootstrap based markups to produce that more appealing Flamingo skin. So, it is more 2) than 1), since we will only target 2) for new stuffs.
So what you are saying is that: - if someone wants a backwards compatible skin (with Colibri and with current extensions on e.x.o) should use Junco and - if someone wants a new skin (where we implement new functionality) should use Flamingo.
From your e-mail I understand that your preference goes towards Flamingo. I admit that Junco is more of a compromise solution for our problems and I've seen it as in intermediate step towards Flamingo, while still providing new functionality and making us advanced (in the shortest time possible).
The issue is our development resources and I think it would be hard for us to officially maintain 2 skins.
So maybe some solutions would be: A. Officially: Colibri + Junco + Flamingo - Maintain support for Colibri, but not innovate. We should support this skin for 1 year at least; - Support Junco, as in intermediary solution for Colibri and Flamingo; - Support Flamingo (new stuff).
B. Officially: Colibri + Flamingo - Maintain support for Colibri, but not innovate; - Support Flamingo; - Have Junco on e.x.o as a backwards compatibility solution.
C. Officially: Junco + Flamingo - Stop support for Colibri since Junco will kind of duplicate it (while adding the Bootstrap functionality); - Support Junco - Support Flamingo.
These are just ideas. Thanks, Caty
WDYT ?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 for a fresh look, so for Flamingo. Regarding the templates, we need to take into account that Velocity is starting to become an old technology (last release is more than 3 years ago) so it may be a good time to look for alternatives. On the server side there is FreeMarker (last release in June 2013). We could also decide to use wiki syntax in the templates. On the client side there are standalone libraries, such as Handlebars used by Ember, or framework-specific implementations like in the case of Angular. Thanks, Marius On Mon, Feb 24, 2014 at 2:49 PM, [email protected] <[email protected]> wrote:
Personally all I know is that we need a fresh look in XWiki 6.x so for me there's no doubt that we want Flamingo.
What needs to be discussed is how to get there. There are 2 paths: A) modify our templates/css heavily to use Bootstrap and base the new Flamingo on that B) keep the current templates as much as possible, with possibly some changes and move templates specific to Colibri in the Colibri skin and templates specific to Flamingo in the flamingo skin, keeping common templates in the templates directory. No bootstrap integration.
Pros and Cons of solution A: ============================ + foundation for the future + allow us to perform cleanup of our templates + ability to use bootstrap themes (an issue we've had for a long since so far we've never been able to support more than 1 skin - We could do color changes but not structural changes) - more costly - will take more time to have Flamingo ready for end users - need to rethink the notion of Color Themes into a more global notion of Skin Theme which affects not only colors but also other parameters (centered or not, etc)
Pros and Cons of solution B: ============================ + less costly + quicker to get in the hands of our users and thus quicker adoption of XWiki as a product - only able to support one skin as we've done in the past - not building for the future and not able to leverage the work done by others on bootstrap
Obviously A is the best option if you have all the devs in the world and all the time in the world... :) Personally I'd like and need to see an evaluation of the work required to do A) before choosing anything. What can be done in 6.0, 6.1, etc? In which XWiki release would we be able to see Flamingo ready if we were to do A?
What is important IMO is to be able to show UI improvements/progress in every release of XWiki (6.0, 6.1, etc) since we've been lagging a bit behind on this.
Thanks! -Vincent
On 24 Feb 2014 at 09:44:57, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:
On Sun, Feb 23, 2014 at 12:58 AM, Denis Gervalle wrote:
Hi Cathy,
You have launch a couple of not so easy threads, and probably why no one have found enough time yet to follow up. I really hope this will change in the upcoming days, since the skin evolution is very important aspect that really need to be thoroughly discussed.
As I see it, choosing between 1. "keeping the colibri look" using the Junco skin, and 2. using a fresh look like flamingo, based on your developed arguments, is more a question about what do we do with our current templates, and how free are we to change them ? Could we afford and impose a new improvement to our markups and templates, while providing enough backward compatibility for existing extensions.
In your Bootstrap integration thread, I develop the technical aspect around these markup issues, showing, I hope, that we have the occasion to smoothly evolve our skin without getting stuck by the past. Regarding the design aspect, your Flamingo proposal is far more refreshing and appealing, providing a more responsive look that I hope could extends our user base. If we could implement it without extending bootstrap, allowing it to be restyled with any bootstrap variants, it would make it a very versatile skin.
So, if we could target that new skin, while keeping an acceptable compromise for existing stuff, I see no reason not to move forward. This is not really a choice between 1) and 2), since what I propose is to use Junco to provide a backward compatibility CSS, and for a while also a modernized colibri skin using our existing templates, and to also evolve our templates, using a more bootstrap based markups to produce that more appealing Flamingo skin. So, it is more 2) than 1), since we will only target 2) for new stuffs.
So what you are saying is that: - if someone wants a backwards compatible skin (with Colibri and with current extensions on e.x.o) should use Junco and - if someone wants a new skin (where we implement new functionality) should use Flamingo.
From your e-mail I understand that your preference goes towards Flamingo. I admit that Junco is more of a compromise solution for our problems and I've seen it as in intermediate step towards Flamingo, while still providing new functionality and making us advanced (in the shortest time possible).
The issue is our development resources and I think it would be hard for us to officially maintain 2 skins.
So maybe some solutions would be: A. Officially: Colibri + Junco + Flamingo - Maintain support for Colibri, but not innovate. We should support this skin for 1 year at least; - Support Junco, as in intermediary solution for Colibri and Flamingo; - Support Flamingo (new stuff).
B. Officially: Colibri + Flamingo - Maintain support for Colibri, but not innovate; - Support Flamingo; - Have Junco on e.x.o as a backwards compatibility solution.
C. Officially: Junco + Flamingo - Stop support for Colibri since Junco will kind of duplicate it (while adding the Bootstrap functionality); - Support Junco - Support Flamingo.
These are just ideas. Thanks, Caty
WDYT ?
_______________________________________________ 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 Marius, I regards to the skin, I do not see why we would require another template language. IMO we should get rid of all those .vm in favor of our rendering engine. It looks now odd to have those templates bootstrapping our far more evolved rendering system. We may of course integrate other scripting languages that provides similar feature to the velocity macro. Regards, On Tue, Feb 25, 2014 at 11:58 PM, Marius Dumitru Florea < [email protected]> wrote:
+1 for a fresh look, so for Flamingo. Regarding the templates, we need to take into account that Velocity is starting to become an old technology (last release is more than 3 years ago) so it may be a good time to look for alternatives. On the server side there is FreeMarker (last release in June 2013). We could also decide to use wiki syntax in the templates. On the client side there are standalone libraries, such as Handlebars used by Ember, or framework-specific implementations like in the case of Angular.
Thanks, Marius
On Mon, Feb 24, 2014 at 2:49 PM, [email protected] <[email protected]> wrote:
Personally all I know is that we need a fresh look in XWiki 6.x so for me there's no doubt that we want Flamingo.
What needs to be discussed is how to get there. There are 2 paths: A) modify our templates/css heavily to use Bootstrap and base the new Flamingo on that B) keep the current templates as much as possible, with possibly some changes and move templates specific to Colibri in the Colibri skin and templates specific to Flamingo in the flamingo skin, keeping common templates in the templates directory. No bootstrap integration.
Pros and Cons of solution A: ============================ + foundation for the future + allow us to perform cleanup of our templates + ability to use bootstrap themes (an issue we've had for a long since so far we've never been able to support more than 1 skin - We could do color changes but not structural changes) - more costly - will take more time to have Flamingo ready for end users - need to rethink the notion of Color Themes into a more global notion of Skin Theme which affects not only colors but also other parameters (centered or not, etc)
Pros and Cons of solution B: ============================ + less costly + quicker to get in the hands of our users and thus quicker adoption of XWiki as a product - only able to support one skin as we've done in the past - not building for the future and not able to leverage the work done by others on bootstrap
Obviously A is the best option if you have all the devs in the world and all the time in the world... :) Personally I'd like and need to see an evaluation of the work required to do A) before choosing anything. What can be done in 6.0, 6.1, etc? In which XWiki release would we be able to see Flamingo ready if we were to do A?
What is important IMO is to be able to show UI improvements/progress in every release of XWiki (6.0, 6.1, etc) since we've been lagging a bit behind on this.
Thanks! -Vincent
On 24 Feb 2014 at 09:44:57, Ecaterina Moraru (Valica) ([email protected] (mailto:[email protected])) wrote:
On Sun, Feb 23, 2014 at 12:58 AM, Denis Gervalle wrote:
Hi Cathy,
You have launch a couple of not so easy threads, and probably why no one have found enough time yet to follow up. I really hope this will change in the upcoming days, since the skin evolution is very important aspect that really need to be thoroughly discussed.
As I see it, choosing between 1. "keeping the colibri look" using the Junco skin, and 2. using a fresh look like flamingo, based on your developed arguments, is more a question about what do we do with our current templates, and how free are we to change them ? Could we afford and impose a new improvement to our markups and templates, while providing enough backward compatibility for existing extensions.
In your Bootstrap integration thread, I develop the technical aspect around these markup issues, showing, I hope, that we have the occasion to smoothly evolve our skin without getting stuck by the past. Regarding the design aspect, your Flamingo proposal is far more refreshing and appealing, providing a more responsive look that I hope could extends our user base. If we could implement it without extending bootstrap, allowing it to be restyled with any bootstrap variants, it would make it a very versatile skin.
So, if we could target that new skin, while keeping an acceptable compromise for existing stuff, I see no reason not to move forward. This is not really a choice between 1) and 2), since what I propose is to use Junco to provide a backward compatibility CSS, and for a while also a modernized colibri skin using our existing templates, and to also evolve our templates, using a more bootstrap based markups to produce that more appealing Flamingo skin. So, it is more 2) than 1), since we will only target 2) for new stuffs.
So what you are saying is that: - if someone wants a backwards compatible skin (with Colibri and with current extensions on e.x.o) should use Junco and - if someone wants a new skin (where we implement new functionality) should use Flamingo.
From your e-mail I understand that your preference goes towards Flamingo. I admit that Junco is more of a compromise solution for our problems and I've seen it as in intermediate step towards Flamingo, while still providing new functionality and making us advanced (in the shortest time possible).
The issue is our development resources and I think it would be hard for us to officially maintain 2 skins.
So maybe some solutions would be: A. Officially: Colibri + Junco + Flamingo - Maintain support for Colibri, but not innovate. We should support this skin for 1 year at least; - Support Junco, as in intermediary solution for Colibri and Flamingo; - Support Flamingo (new stuff).
B. Officially: Colibri + Flamingo - Maintain support for Colibri, but not innovate; - Support Flamingo; - Have Junco on e.x.o as a backwards compatibility solution.
C. Officially: Junco + Flamingo - Stop support for Colibri since Junco will kind of duplicate it (while adding the Bootstrap functionality); - Support Junco - Support Flamingo.
These are just ideas. Thanks, Caty
WDYT ?
_______________________________________________ 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
I agree that it would be nice if we could use our rendering engine. Note that we’d need to implement a new macro to include another page from the filesystem (ATM the {{include}} macro only supports including wiki pages). We’d need to evaluate the cost of moving from our velocity templates to our rendering engine since we need to have a new skin fully production ready by the end of 6.x which means having it done several releases before the end to iron out all the issues (I’d say by 6.2). Thanks -Vincent On 26 Feb 2014 at 10:52:35, Denis Gervalle ([email protected]) wrote: Hi Marius, I regards to the skin, I do not see why we would require another template language. IMO we should get rid of all those .vm in favor of our rendering engine. It looks now odd to have those templates bootstrapping our far more evolved rendering system. We may of course integrate other scripting languages that provides similar feature to the velocity macro. Regards, On Tue, Feb 25, 2014 at 11:58 PM, Marius Dumitru Florea < [email protected]> wrote:
+1 for a fresh look, so for Flamingo. Regarding the templates, we need to take into account that Velocity is starting to become an old technology (last release is more than 3 years ago) so it may be a good time to look for alternatives. On the server side there is FreeMarker (last release in June 2013). We could also decide to use wiki syntax in the templates. On the client side there are standalone libraries, such as Handlebars used by Ember, or framework-specific implementations like in the case of Angular.
Thanks, Marius
On Mon, Feb 24, 2014 at 2:49 PM, [email protected] <[email protected]> wrote:
Personally all I know is that we need a fresh look in XWiki 6.x so for me there's no doubt that we want Flamingo.
What needs to be discussed is how to get there. There are 2 paths: A) modify our templates/css heavily to use Bootstrap and base the new Flamingo on that B) keep the current templates as much as possible, with possibly some changes and move templates specific to Colibri in the Colibri skin and templates specific to Flamingo in the flamingo skin, keeping common templates in the templates directory. No bootstrap integration.
Pros and Cons of solution A: ============================ + foundation for the future + allow us to perform cleanup of our templates + ability to use bootstrap themes (an issue we've had for a long since so far we've never been able to support more than 1 skin - We could do color changes but not structural changes) - more costly - will take more time to have Flamingo ready for end users - need to rethink the notion of Color Themes into a more global notion of Skin Theme which affects not only colors but also other parameters (centered or not, etc)
Pros and Cons of solution B: ============================ + less costly + quicker to get in the hands of our users and thus quicker adoption of XWiki as a product - only able to support one skin as we've done in the past - not building for the future and not able to leverage the work done by others on bootstrap
Obviously A is the best option if you have all the devs in the world and all the time in the world... :) Personally I'd like and need to see an evaluation of the work required to do A) before choosing anything. What can be done in 6.0, 6.1, etc? In which XWiki release would we be able to see Flamingo ready if we were to do A?
What is important IMO is to be able to show UI improvements/progress in every release of XWiki (6.0, 6.1, etc) since we've been lagging a bit behind on this.
Thanks! -Vincent
On 24 Feb 2014 at 09:44:57, Ecaterina Moraru (Valica) ([email protected] (mailto:[email protected])) wrote:
On Sun, Feb 23, 2014 at 12:58 AM, Denis Gervalle wrote:
Hi Cathy,
You have launch a couple of not so easy threads, and probably why no one have found enough time yet to follow up. I really hope this will change in the upcoming days, since the skin evolution is very important aspect that really need to be thoroughly discussed.
As I see it, choosing between 1. "keeping the colibri look" using the Junco skin, and 2. using a fresh look like flamingo, based on your developed arguments, is more a question about what do we do with our current templates, and how free are we to change them ? Could we afford and impose a new improvement to our markups and templates, while providing enough backward compatibility for existing extensions.
In your Bootstrap integration thread, I develop the technical aspect around these markup issues, showing, I hope, that we have the occasion to smoothly evolve our skin without getting stuck by the past. Regarding the design aspect, your Flamingo proposal is far more refreshing and appealing, providing a more responsive look that I hope could extends our user base. If we could implement it without extending bootstrap, allowing it to be restyled with any bootstrap variants, it would make it a very versatile skin.
So, if we could target that new skin, while keeping an acceptable compromise for existing stuff, I see no reason not to move forward. This is not really a choice between 1) and 2), since what I propose is to use Junco to provide a backward compatibility CSS, and for a while also a modernized colibri skin using our existing templates, and to also evolve our templates, using a more bootstrap based markups to produce that more appealing Flamingo skin. So, it is more 2) than 1), since we will only target 2) for new stuffs.
So what you are saying is that: - if someone wants a backwards compatible skin (with Colibri and with current extensions on e.x.o) should use Junco and - if someone wants a new skin (where we implement new functionality) should use Flamingo.
From your e-mail I understand that your preference goes towards Flamingo. I admit that Junco is more of a compromise solution for our problems and I've seen it as in intermediate step towards Flamingo, while still providing new functionality and making us advanced (in the shortest time possible).
The issue is our development resources and I think it would be hard for us to officially maintain 2 skins.
So maybe some solutions would be: A. Officially: Colibri + Junco + Flamingo - Maintain support for Colibri, but not innovate. We should support this skin for 1 year at least; - Support Junco, as in intermediary solution for Colibri and Flamingo; - Support Flamingo (new stuff).
B. Officially: Colibri + Flamingo - Maintain support for Colibri, but not innovate; - Support Flamingo; - Have Junco on e.x.o as a backwards compatibility solution.
C. Officially: Junco + Flamingo - Stop support for Colibri since Junco will kind of duplicate it (while adding the Bootstrap functionality); - Support Junco - Support Flamingo.
These are just ideas. Thanks, Caty
WDYT ?
_______________________________________________ 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Btw, the Distribution Wizard steps (templates) are written in wiki syntax. So Thomas already did some work in this direction. Thanks, Marius On Wed, Feb 26, 2014 at 1:35 PM, [email protected] <[email protected]> wrote:
I agree that it would be nice if we could use our rendering engine.
Note that we'd need to implement a new macro to include another page from the filesystem (ATM the {{include}} macro only supports including wiki pages).
We'd need to evaluate the cost of moving from our velocity templates to our rendering engine since we need to have a new skin fully production ready by the end of 6.x which means having it done several releases before the end to iron out all the issues (I'd say by 6.2).
Thanks -Vincent
On 26 Feb 2014 at 10:52:35, Denis Gervalle ([email protected]) wrote:
Hi Marius,
I regards to the skin, I do not see why we would require another template language. IMO we should get rid of all those .vm in favor of our rendering engine. It looks now odd to have those templates bootstrapping our far more evolved rendering system. We may of course integrate other scripting languages that provides similar feature to the velocity macro.
Regards,
On Tue, Feb 25, 2014 at 11:58 PM, Marius Dumitru Florea < [email protected]> wrote:
+1 for a fresh look, so for Flamingo. Regarding the templates, we need to take into account that Velocity is starting to become an old technology (last release is more than 3 years ago) so it may be a good time to look for alternatives. On the server side there is FreeMarker (last release in June 2013). We could also decide to use wiki syntax in the templates. On the client side there are standalone libraries, such as Handlebars used by Ember, or framework-specific implementations like in the case of Angular.
Thanks, Marius
On Mon, Feb 24, 2014 at 2:49 PM, [email protected] <[email protected]> wrote:
Personally all I know is that we need a fresh look in XWiki 6.x so for me there's no doubt that we want Flamingo.
What needs to be discussed is how to get there. There are 2 paths: A) modify our templates/css heavily to use Bootstrap and base the new Flamingo on that B) keep the current templates as much as possible, with possibly some changes and move templates specific to Colibri in the Colibri skin and templates specific to Flamingo in the flamingo skin, keeping common templates in the templates directory. No bootstrap integration.
Pros and Cons of solution A: ============================ + foundation for the future + allow us to perform cleanup of our templates + ability to use bootstrap themes (an issue we've had for a long since so far we've never been able to support more than 1 skin - We could do color changes but not structural changes) - more costly - will take more time to have Flamingo ready for end users - need to rethink the notion of Color Themes into a more global notion of Skin Theme which affects not only colors but also other parameters (centered or not, etc)
Pros and Cons of solution B: ============================ + less costly + quicker to get in the hands of our users and thus quicker adoption of XWiki as a product - only able to support one skin as we've done in the past - not building for the future and not able to leverage the work done by others on bootstrap
Obviously A is the best option if you have all the devs in the world and all the time in the world... :) Personally I'd like and need to see an evaluation of the work required to do A) before choosing anything. What can be done in 6.0, 6.1, etc? In which XWiki release would we be able to see Flamingo ready if we were to do A?
What is important IMO is to be able to show UI improvements/progress in every release of XWiki (6.0, 6.1, etc) since we've been lagging a bit behind on this.
Thanks! -Vincent
On 24 Feb 2014 at 09:44:57, Ecaterina Moraru (Valica) ([email protected] (mailto:[email protected])) wrote:
On Sun, Feb 23, 2014 at 12:58 AM, Denis Gervalle wrote:
Hi Cathy,
You have launch a couple of not so easy threads, and probably why no one have found enough time yet to follow up. I really hope this will change in the upcoming days, since the skin evolution is very important aspect that really need to be thoroughly discussed.
As I see it, choosing between 1. "keeping the colibri look" using the Junco skin, and 2. using a fresh look like flamingo, based on your developed arguments, is more a question about what do we do with our current templates, and how free are we to change them ? Could we afford and impose a new improvement to our markups and templates, while providing enough backward compatibility for existing extensions.
In your Bootstrap integration thread, I develop the technical aspect around these markup issues, showing, I hope, that we have the occasion to smoothly evolve our skin without getting stuck by the past. Regarding the design aspect, your Flamingo proposal is far more refreshing and appealing, providing a more responsive look that I hope could extends our user base. If we could implement it without extending bootstrap, allowing it to be restyled with any bootstrap variants, it would make it a very versatile skin.
So, if we could target that new skin, while keeping an acceptable compromise for existing stuff, I see no reason not to move forward. This is not really a choice between 1) and 2), since what I propose is to use Junco to provide a backward compatibility CSS, and for a while also a modernized colibri skin using our existing templates, and to also evolve our templates, using a more bootstrap based markups to produce that more appealing Flamingo skin. So, it is more 2) than 1), since we will only target 2) for new stuffs.
So what you are saying is that: - if someone wants a backwards compatible skin (with Colibri and with current extensions on e.x.o) should use Junco and - if someone wants a new skin (where we implement new functionality) should use Flamingo.
From your e-mail I understand that your preference goes towards Flamingo. I admit that Junco is more of a compromise solution for our problems and I've seen it as in intermediate step towards Flamingo, while still providing new functionality and making us advanced (in the shortest time possible).
The issue is our development resources and I think it would be hard for us to officially maintain 2 skins.
So maybe some solutions would be: A. Officially: Colibri + Junco + Flamingo - Maintain support for Colibri, but not innovate. We should support this skin for 1 year at least; - Support Junco, as in intermediary solution for Colibri and Flamingo; - Support Flamingo (new stuff).
B. Officially: Colibri + Flamingo - Maintain support for Colibri, but not innovate; - Support Flamingo; - Have Junco on e.x.o as a backwards compatibility solution.
C. Officially: Junco + Flamingo - Stop support for Colibri since Junco will kind of duplicate it (while adding the Bootstrap functionality); - Support Junco - Support Flamingo.
These are just ideas. Thanks, Caty
WDYT ?
_______________________________________________ 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ 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 (4)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Marius Dumitru Florea -
vincent＠massol.net