[xwiki-devs] [VOTE] Stop supporting the Albatross skin
Hi devs, I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it. The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future. -- Sergiu Dumitriu http://purl.org/net/sergiu/
+1 I think it's a wise decision, My recollection is Albatross functionality was a bit tenuous and even at best it didn't do justice to the new features which have been added. Caleb On 10/10/2010 08:21 AM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future.
+1 On Sun, Oct 10, 2010 at 14:21, Sergiu Dumitriu <[email protected]> wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 Thanks, Marius On 10/10/2010 03:21 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future.
+1 In time we should make Colibri, Toucan and other skins to be independent of each other. By doing this, they will be more easily maintained. And Albatross is obsolete by it's design. Regards, Sorin B. On 10/10/2010 8:32 PM, Marius Dumitru Florea wrote:
+1
Thanks, Marius
On 10/10/2010 03:21 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi all, On Oct 10, 2010, at 11:52 PM, Sorin Burjan wrote:
+1 In time we should make Colibri, Toucan and other skins to be independent of each other. By doing this, they will be more easily maintained
They should be independent but that doesn't make more maintainable, quite the opposite since it means sharing less. Instead we need to find ways to make skins more easily maintainable and I think this means sharing more between skins based on the same "concepts", i.e. having skin "variants" instead of completely new skins. Actually I don't know what makes a skin easy to write and easy to maintain. What I see is that some webapp have lots of skins for example wordpress so it seems it's possible to have lots of skin. I'm still not sure what element of our skin system makes it hard to maintain our skins. Any idea? Thanks -Vincent
. And Albatross is obsolete by it's design.
Regards, Sorin B.
On 10/10/2010 8:32 PM, Marius Dumitru Florea wrote:
+1
Thanks, Marius
On 10/10/2010 03:21 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future.
On Mon, Oct 11, 2010 at 08:49, Vincent Massol <[email protected]> wrote:
Hi all,
On Oct 10, 2010, at 11:52 PM, Sorin Burjan wrote:
+1 In time we should make Colibri, Toucan and other skins to be independent of each other. By doing this, they will be more easily maintained
They should be independent but that doesn't make more maintainable, quite the opposite since it means sharing less. Instead we need to find ways to make skins more easily maintainable and I think this means sharing more between skins based on the same "concepts", i.e. having skin "variants" instead of completely new skins. Actually I don't know what makes a skin easy to write and easy to maintain.
What I see is that some webapp have lots of skins for example wordpress so it seems it's possible to have lots of skin. I'm still not sure what element of our skin system makes it hard to maintain our skins.
Any idea?
In my understanding, we should distinct: 1) the velocity templates 2) CSS, pictures and so on For 1), for ease of maintenance we need to share as much as possible. For 2), we should just be able, based on 1), to fully customize the visual representation of 1). IMO, ideally, 1) should be shared by all 2). At the same time, we should keep the current behavior that allow users to customize 1) and 2) themselves more deeply, but we should avoid to maintain several 1) ourselves. Note that 1) should be driven by building an unstyled accessible (WAI compliant) document that could be properly styled in many ways to fullfil the need of 2). This why I see no point to maintain different 1). Moreover that 1) could be built conditionally when require. Maintaining several 1) is just doubling the work without much benefit IMHO. I see just one really good reason to have several 1), which is to support different level of markup, for example, we may think about starting a 1) that use HTML5 feature during a transitioning period, until its is well adopted. WDYT ? +1 for deprecating Albatros and keeping independancy of 2) and targeting unity of 1) Denis
Thanks -Vincent
. And Albatross is obsolete by it's design.
Regards, Sorin B.
On 10/10/2010 8:32 PM, Marius Dumitru Florea wrote:
+1
Thanks, Marius
On 10/10/2010 03:21 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Oct 11, 2010, at 9:45 AM, Denis Gervalle wrote:
On Mon, Oct 11, 2010 at 08:49, Vincent Massol <[email protected]> wrote:
Hi all,
On Oct 10, 2010, at 11:52 PM, Sorin Burjan wrote:
+1 In time we should make Colibri, Toucan and other skins to be independent of each other. By doing this, they will be more easily maintained
They should be independent but that doesn't make more maintainable, quite the opposite since it means sharing less. Instead we need to find ways to make skins more easily maintainable and I think this means sharing more between skins based on the same "concepts", i.e. having skin "variants" instead of completely new skins. Actually I don't know what makes a skin easy to write and easy to maintain.
What I see is that some webapp have lots of skins for example wordpress so it seems it's possible to have lots of skin. I'm still not sure what element of our skin system makes it hard to maintain our skins.
Any idea?
In my understanding, we should distinct:
1) the velocity templates 2) CSS, pictures and so on
For 1), for ease of maintenance we need to share as much as possible. For 2), we should just be able, based on 1), to fully customize the visual representation of 1). IMO, ideally, 1) should be shared by all 2). At the same time, we should keep the current behavior that allow users to customize 1) and 2) themselves more deeply, but we should avoid to maintain several 1) ourselves.
Note that 1) should be driven by building an unstyled accessible (WAI compliant) document that could be properly styled in many ways to fullfil the need of 2). This why I see no point to maintain different 1). Moreover that 1) could be built conditionally when require. Maintaining several 1) is just doubling the work without much benefit IMHO. I see just one really good reason to have several 1), which is to support different level of markup, for example, we may think about starting a 1) that use HTML5 feature during a transitioning period, until its is well adopted.
WDYT ?
Sounds good to me. Who would be interested to work on this? Thanks -Vincent
+1 for deprecating Albatros and keeping independancy of 2) and targeting unity of 1)
Denis
Thanks -Vincent
. And Albatross is obsolete by it's design.
Regards, Sorin B.
On 10/10/2010 8:32 PM, Marius Dumitru Florea wrote:
+1
Thanks, Marius
On 10/10/2010 03:21 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future.
On 10/11/2010 08:49 AM, Vincent Massol wrote:
Hi all,
On Oct 10, 2010, at 11:52 PM, Sorin Burjan wrote:
+1 In time we should make Colibri, Toucan and other skins to be independent of each other. By doing this, they will be more easily maintained
They should be independent but that doesn't make more maintainable, quite the opposite since it means sharing less. Instead we need to find ways to make skins more easily maintainable and I think this means sharing more between skins based on the same "concepts", i.e. having skin "variants" instead of completely new skins. Actually I don't know what makes a skin easy to write and easy to maintain.
We're slowly moving in this direction. Lately, we've been developing "UI components" that are skin-independent. This means moving code out of the huge core skin, which makes it easier to write a new skin from scratch. Color Themes allow us to make Colibri appear as many skins. The planned Layout Themes will make this even simpler. Skin Extensions allows adapting an existing skin very easily. We're not using them for this purpose, but we could write sample extensions that: - make the panels round - add some backgrounds and gradients here and there - change the fonts - shuffle things around Color themes + Skin extensions make it easy to develop something similar to Firefox Personas, lightweight paint jobs over Colibri. We're not doing this yet, but we could start a new section on code.xwiki.org, maybe organize a contest for people to contribute entries.
What I see is that some webapp have lots of skins for example wordpress so it seems it's possible to have lots of skin. I'm still not sure what element of our skin system makes it hard to maintain our skins.
That's because Wordpress skins are a real mess. The equivalent of a Wordpress skin for XWiki would mean packaging both the templates and a skin, along with some images, and we're trying to avoid encouraging people to duplicate the templates. Then, there's a huge difference in terms of features that need to be styled, since Wordpress is just a blogging tool, while XWiki is a development platform. Splitting the skin into even more parts would certainly make writing skins easier, but we're lacking the manpower to work full speed on this.
On 10/10/2010 03:21 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
From the xwikis operators point of view it would be a huge "selling" point if it where possible that exisiting wordpress designs could be used in a certain (may be new) xwiki skin.
The reason for this is that xwiki operators aren't necessarily good and experienced designers but there is a large crowd of designers spcialized in wordpress theme design. And its possible to start design contest e.g. 99designs.com where you can buy individual designs for small money meaining you have an individual and professional looking design at small cost. You might say Xwiki is a wiki and wordpress is a blog but for sure there is a not so small group of usage scenarios where it is justifiable to use one or the other product. And people are tempted to go with the product with the better design options. This is even more true as if you plan a new plattform that should be individual and professional looking and you can't do a professional design yourself you have to hire a designer but with using wordpress you can pick up a design out of the many options and modify it - which is much easier than doing it along yourself. I have no idea how complex it might be to realize such a 'design compatibility layer' though ... Andreas -- View this message in context: http://xwiki.475771.n2.nabble.com/VOTE-Stop-supporting-the-Albatross-skin-tp... Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi As someone with a level of experience there may not be such a stretch to getting to such a place. I think it isn't so much as getting the WP compatibility in the sense of them being the same. I think it is more about moving to a model whereby the content that defines the look and feel in the way a Theme in WP or a Template in Joomla are able to be a separate product from the core code. This leans that certain elements that relate to how things are displayed are done with a set of elements that are completely independent of the core. The main component of a WP them is images and css, but it can and does contain php elements. Does Xwiki want to incorporate php into its product mix for display? I build for other projects themes for WP and templates for Joomla using a tool called Artisteer. It is a good product albeit with a share of bugs, but it allows the ability to create a single look and feel in Joomla and WP if being used within a single site. Can we get a tool like Artisteer to support the Xwiki community, possibly if it is possible to build a skin that provides the sort of model that it needs to build to when creating the skin theme. Understanding what this tool is doing might help those to understand what is going to be required for a skin to support a similar them model to WP or Joomla and allow people to make a simple mod to elements that allow the product to support Xwiki. I would be more than happy to throw out somewhere a copy of the Artisteer output for a WP or Joomla site as a starting point of what they contain to help people understand what they need to work towards. So in this vein I think the first step is moving to a complete separation of CSS, JavaScript, images, HTML markup and anything else. that defines look and feel from the main code tree into a template/theme directory. Both WP and Joomla rely on only selecting a directory within the themes/templates location to define the look and feel. It is also possible in both cases to define individual parts of a site to use different look and feel. HTH Cheers Peter Quoting Andreas Hahn <[email protected]>:
From the xwikis operators point of view it would be a huge "selling" point if it where possible that exisiting wordpress designs could be used in a certain (may be new) xwiki skin.
The reason for this is that xwiki operators aren't necessarily good and experienced designers but there is a large crowd of designers spcialized in wordpress theme design. And its possible to start design contest e.g. 99designs.com where you can buy individual designs for small money meaining you have an individual and professional looking design at small cost.
You might say Xwiki is a wiki and wordpress is a blog but for sure there is a not so small group of usage scenarios where it is justifiable to use one or the other product. And people are tempted to go with the product with the better design options. This is even more true as if you plan a new plattform that should be individual and professional looking and you can't do a professional design yourself you have to hire a designer but with using wordpress you can pick up a design out of the many options and modify it - which is much easier than doing it along yourself.
I have no idea how complex it might be to realize such a 'design compatibility layer' though ...
Andreas
-- View this message in context: http://xwiki.475771.n2.nabble.com/VOTE-Stop-supporting-the-Albatross-skin-tp... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Peter McLarty Senior Consultant, Pacific DBMS Pty Ltd [email protected] 15 Barron Road Margate, QLD 4019 Australia work: 61 7 3883 1086 mobile: 61 4 0209 4238 fax: 61 7 3883 1016 IM: pameacs.cto (Skype) http://au.linkedin.com/in/pameacs Database Consultants across Asia Pacific ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hi! Peter McLarty wrote:
Hi As someone with a level of experience there may not be such a stretch to getting to such a place. I think it isn't so much as getting the WP compatibility in the sense of them being the same. I think it is more about moving to a model whereby the content that defines the look and feel in the way a Theme in WP or a Template in Joomla are able to be a separate product from the core code. This leans that certain elements that relate to how things are displayed are done with a set of elements that are completely independent of the core. The main component of a WP them is images and css, but it can and does contain php elements. Does Xwiki want to incorporate php into its product mix for display?
Please, what does PHP add to the landscape considering XWiki is built in Java and supports Velocity Template Language and Groovy? Thanks!
I build for other projects themes for WP and templates for Joomla using a tool called Artisteer. It is a good product albeit with a share of bugs, but it allows the ability to create a single look and feel in Joomla and WP if being used within a single site. Can we get a tool like Artisteer to support the Xwiki community, possibly if it is possible to build a skin that provides the sort of model that it needs to build to when creating the skin theme. Understanding what this tool is doing might help those to understand what is going to be required for a skin to support a similar them model to WP or Joomla and allow people to make a simple mod to elements that allow the product to support Xwiki.
I would be more than happy to throw out somewhere a copy of the Artisteer output for a WP or Joomla site as a starting point of what they contain to help people understand what they need to work towards. So in this vein I think the first step is moving to a complete separation of CSS, JavaScript, images, HTML markup and anything else. that defines look and feel from the main code tree into a template/theme directory. Both WP and Joomla rely on only selecting a directory within the themes/templates location to define the look and feel. It is also possible in both cases to define individual parts of a site to use different look and feel.
HTH
Cheers
Peter
Quoting Andreas Hahn <[email protected]>:
From the xwikis operators point of view it would be a huge "selling" point if it where possible that exisiting wordpress designs could be used in a certain (may be new) xwiki skin.
The reason for this is that xwiki operators aren't necessarily good and experienced designers but there is a large crowd of designers spcialized in wordpress theme design. And its possible to start design contest e.g. 99designs.com where you can buy individual designs for small money meaining you have an individual and professional looking design at small cost.
You might say Xwiki is a wiki and wordpress is a blog but for sure there is a not so small group of usage scenarios where it is justifiable to use one or the other product. And people are tempted to go with the product with the better design options. This is even more true as if you plan a new plattform that should be individual and professional looking and you can't do a professional design yourself you have to hire a designer but with using wordpress you can pick up a design out of the many options and modify it - which is much easier than doing it along yourself.
I have no idea how complex it might be to realize such a 'design compatibility layer' though ...
Andreas
-- View this message in context: http://xwiki.475771.n2.nabble.com/VOTE-Stop-supporting-the-Albatross-skin-tp... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ricardo RodrÃguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems
Hi Ricardo I doubt it adds anything and probably complicates matters. Both the Joomla templates and WordPress themes contain .php elements. My point was to make people aware that trying to become compatible so as to be able to use WP Themes in Xwiki was likely not such a good solution. I would think a Xwiki skin/theme/template would consist of images, html, JavaScript and possibly Groovy and Velocity in the this, but that stuff needs to only be there for the display of items in your Xwiki and be able to be removed without affecting the core operation of the Xwiki. Hope this helps towards building a great solution Cheers Peter Quoting "[Ricardo Rodriguez] eBioTIC." <[email protected]>:
Hi!
Peter McLarty wrote:
Hi As someone with a level of experience there may not be such a stretch to getting to such a place. I think it isn't so much as getting the WP compatibility in the sense of them being the same. I think it is more about moving to a model whereby the content that defines the look and feel in the way a Theme in WP or a Template in Joomla are able to be a separate product from the core code. This leans that certain elements that relate to how things are displayed are done with a set of elements that are completely independent of the core. The main component of a WP them is images and css, but it can and does contain php elements. Does Xwiki want to incorporate php into its product mix for display?
Please, what does PHP add to the landscape considering XWiki is built in Java and supports Velocity Template Language and Groovy? Thanks!
I build for other projects themes for WP and templates for Joomla using a tool called Artisteer. It is a good product albeit with a share of bugs, but it allows the ability to create a single look and feel in Joomla and WP if being used within a single site. Can we get a tool like Artisteer to support the Xwiki community, possibly if it is possible to build a skin that provides the sort of model that it needs to build to when creating the skin theme. Understanding what this tool is doing might help those to understand what is going to be required for a skin to support a similar them model to WP or Joomla and allow people to make a simple mod to elements that allow the product to support Xwiki.
I would be more than happy to throw out somewhere a copy of the Artisteer output for a WP or Joomla site as a starting point of what they contain to help people understand what they need to work towards. So in this vein I think the first step is moving to a complete separation of CSS, JavaScript, images, HTML markup and anything else. that defines look and feel from the main code tree into a template/theme directory. Both WP and Joomla rely on only selecting a directory within the themes/templates location to define the look and feel. It is also possible in both cases to define individual parts of a site to use different look and feel.
HTH
Cheers
Peter
Quoting Andreas Hahn <[email protected]>:
From the xwikis operators point of view it would be a huge "selling" point if it where possible that exisiting wordpress designs could be used in a certain (may be new) xwiki skin.
The reason for this is that xwiki operators aren't necessarily good and experienced designers but there is a large crowd of designers spcialized in wordpress theme design. And its possible to start design contest e.g. 99designs.com where you can buy individual designs for small money meaining you have an individual and professional looking design at small cost.
You might say Xwiki is a wiki and wordpress is a blog but for sure there is a not so small group of usage scenarios where it is justifiable to use one or the other product. And people are tempted to go with the product with the better design options. This is even more true as if you plan a new plattform that should be individual and professional looking and you can't do a professional design yourself you have to hire a designer but with using wordpress you can pick up a design out of the many options and modify it - which is much easier than doing it along yourself.
I have no idea how complex it might be to realize such a 'design compatibility layer' though ...
Andreas
-- View this message in context: http://xwiki.475771.n2.nabble.com/VOTE-Stop-supporting-the-Albatross-skin-tp... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ricardo RodrÃguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Peter McLarty Senior Consultant, Pacific DBMS Pty Ltd [email protected] 15 Barron Road Margate, QLD 4019 Australia work: 61 7 3883 1086 mobile: 61 4 0209 4238 fax: 61 7 3883 1016 IM: pameacs.cto (Skype) http://au.linkedin.com/in/pameacs Database Consultants across Asia Pacific ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hi Peter, thanks for mentioning Artisteer. I wasn't aware that such a product exists. My point is WP compatibility for skins/themes/ would be valuable even without .php support as there is a marketplace for WP designs. I don't mean strict compatibility but the option to check out existing designs easily and perhaps modify them. It's much easier to ask a designer for a WP design not containing .php elements than finding someone to do a sleek Xwiki design for you. Andreas -- View this message in context: http://xwiki.475771.n2.nabble.com/VOTE-Stop-supporting-the-Albatross-skin-tp... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On Oct 10, 2010, at 2:21 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
AFAIK it's already no longer maintained: http://code.xwiki.org/xwiki/bin/view/Skins/AlbatrossSkin +0 although I'd like to start thinking about how we can support several skins easily in the future, i.e. so that this sections becomes filled with skins: code.xwiki.org/xwiki/bin/view/Skins/ Thanks -Vincent
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future. -- Sergiu Dumitriu http://purl.org/net/sergiu/
+1 Alex On 10/10/2010 02:21 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future.
participants (11)
-
[Ricardo Rodriguez] eBioTIC. -
Alex Busenius -
Andreas Hahn -
Caleb James DeLisle -
Denis Gervalle -
Marius Dumitru Florea -
Peter McLarty -
Sergiu Dumitriu -
Sorin Burjan -
Thomas Mortagne -
Vincent Massol