Provide new themes

Next topic

Author	Message
Pierre T.	Tuesday 20 May 2008 1:43:19 am Why don't you provide more themes for ezpublish ? We can currently find a few themes in the contribution area, but all don't work well with ez4. Creating a theme is quite difficult I think, and getting more themes should be very very VERY interesting for the community. Typo3 for example provides many templates. Why not opening a new contribution for getting new themes ?
Thomas Koch	Tuesday 20 May 2008 1:48:35 am I think it makes no sense, to create new themes right now, since the template engine of eZPublish should be replaced by the new engine from the eZComponents project. That means, if you would create a new theme for the old engine, it would be incompatible with the new one. --- Thomas Koch \| http://koch.ro YMC - eZ Publish in Switzerland \| http://ymc.ch
Bruce Morrison	Tuesday 20 May 2008 3:04:57 am Hi Thomas Maybe we have different understandings of what themes are I but I have always taken them to be the look and feel. In eZ's case creating new ones is just about design in the form of CSS & images. There is an article here http://ez.no/developer/articles/how_to_skin_an_ez_publish_now_site The template language in eZ components looks to be very similar to the existing template syntax http://ezcomponents.org/docs/tutorials/Template I guess depending on the complexities of any templates will determine just how difficult they would be to convert. cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Pierre T.	Tuesday 20 May 2008 3:09:28 am By "themes" I mean look & feel, provided by ezpkg eg.
André R.	Tuesday 20 May 2008 3:15:49 am > Why don't you provide more themes for ezpublish ? What do you mean by 'you'? eZ? Why us? Why not you? Anyone with css knowledge can create one. >I think it makes no sense, to create new themes right now, since the template engine of eZPublish should be replaced by the new engine from the eZComponents project. The themes/ look and feel are as pointed out not linked with the template language but rather the html output they produce. eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom
Pierre T.	Tuesday 20 May 2008 4:00:05 am 'You' => ezpublish staff :p I'd say ezpublish community instead of "you" ! I have css knowledge but not enough to create my own themes. I always work with a designer when I create websites (not under ez)..
Gaetano Giunta	Tuesday 20 May 2008 1:59:30 pm eZPublish templates are a bit different from other CMS templates in some subtle and fundamental aspects: an eZ Publish page is made up of many many different small templates, and general usage templates are not made for page "blocks" but for objects and attributes. This makes it a little bit harder on one hand to do a new skin, as there are many more templates to modify and they do not easily map to the outputted page (at least for the unexperienced developer). On the other hand I have not yet come across an eZ Publish installation where the design was not reimplemented from the ground up according to the needs of the customer, ie. custom templates are implemented after the custom classes have been designed. It is just the nature of the tool... Principal Consultant International Business Member of the Community Project Board
Łukasz Serwatka	Wednesday 21 May 2008 1:42:36 am In eZ Publish something like "themes" does not exist I would say. eZ Publish was tend to be flexible as much as possible, thus using template language you have freedom in content presentation thinking not only about colors, backgrounds, etc, but also about content architecture/layout. Theme approach needs commodity which usually set limitations. In addition to what Gaetano wrote most of projects follows in general 1. Content architecture planning 2. Design process (visual part) 3. Implementation (template codding, CSS styling) As every larger company/customer usually has different content architecture needs it hard to keep it generic. Some parts can be reused, but usually the "themes" approach won't work. Also think about corporate identity. Website Interface has currently 2 design examples, next version will get one more in addition. Personal website -> http://serwatka.net Blog (about eZ Publish) -> http://serwatka.net/blog
David Boman	Wednesday 21 May 2008 10:00:25 am I think we are touching a very interesting topic here. I agree with Lukasz that for a 'real' eZ project the the Planning->Design->Implementation is generally the way to go. But i believe that the lack of pre-created template (or site-styles) packages (community or out-of-box) is on the of the largest drawbacks of eZPublish. (By templates, in this context, I mean everything including images, css, and .tpl-files. a.k.a. themes, site-style, skin etc.) Looking at different eZ-powered sites they tend to look quite the same. CSS and Image-changes of course but you can still 'feel' that it is the same base-template (the old plain-template) in the bottom. This is of course both good and bad but I believe that with more template packages I believe eZ would become more widespread. With the new Website Interface things are looking very good - I want more of this! A good thing about eZPublish is that it has a good package system. Use this! By using the package system you could pack everything so that it would be easy to install for beginners and easy to distribute for people who create templates. Constantly reading the forum I often see that there are a lot of questions on who to change this or edit that. By having more template-packages hopefully these questions could be reduced. So what to do? Formalize it. Create a spot where people could publish their template-packages (contrib-area might be enough). Promote it! Rate them! Have a competition! Award people that upload stuff! Give the partners points for creating template-packages! For large sites I agree that there are a lot of work that has to be done but for smaller sites I believe that an Out-of-the-box installation with a good template-package could be sufficient in many places.
Łukasz Serwatka	Wednesday 21 May 2008 11:25:13 am Hi David, Some good points in your comment. We see and understand user needs for websites with "common" content architecture and layout and we will not close the door here. However current design package approach has some limitations and in practice does not work as it should. I would even say it is hard to use it for both designers and users. That is one of reasons why not so many site packages is available. eZ Publish is moving forward and this part need re-thinking and re-design as current site style packages still following old eZ Publish 3.x concepts. E.g only 2 CSS files are used which were tend to change only colors and it should not be datatype oriented as it is not a content at all. Introducing Website Interface was a big step compare to the old packages not only in functionality but also in visual (professional designs). But there is still space to make things better and easier to use on styling ground. We have some ideas to make CSS framework, flexible enough in order to handle more advanced designs but also keep creation and installation packages built on top of it in simpler way. Basically we will drop site styles packages concept in future introducing new repository system for handling custom designs. I believe we will have a discussion about it during eZ Conference and Developer Day. I also can't provide exact date or eZ Publish version as it is matter of planning and resources allocation. Personal website -> http://serwatka.net Blog (about eZ Publish) -> http://serwatka.net/blog
Bruce Morrison	Wednesday 21 May 2008 5:07:50 pm Hi all Very interesting discussions. I've been mulling over the issue of lack of community themes that seem to be abundant for many of the other OS CMS platforms. I've got a couple of thoughts. I must admit that I'd not looked too closely at the underlying ezwebmin HTML until today, now having done so there is a pretty obvious issue...it's just too complicated. In many cases the DOM tree path will not fit across a 22' monitor! Also the 2 CSS file site package are just too limiting. I think there is a need for a "plain" design (3 col, header /footer ) that has nice clean underlying (X)HTML with just enough hooks to do some design. It should have a good set of functionality (default content classes, ezweb design toolbar thingi) This is the approach I took at designIT. In the early days before the pre packaged designs I created what we call a "white site". You can see an example here : http://demo.designit.com.au/ This forms the starting point of all the sites done by designIT. When the design/requirements are simple a site is set up and the CSS is implemented with no intervention from a "developer". A lot of web design is done with the "designers" doing static (HTML/CSS) mockups, these are then given to the "developer" to implement in the particular CMS. In eZ it's not a simple process to package designs on top of the pre-packaged installs while retaining the functionally. And certainly not a process that can be done by someone who has just downloaded and installed the system. In comparison, without knowing anything about Drupal I was able to download, install, configure and theme an install in 4hours (from a static HTML page). Now, if only someone could explain to me how the underlying content model works I'd be set! This is one area where eZ publish kicks butt. I'd love to see a list like this for eZ publish: http://mashable.com/2008/05/17/70-plus-new-and-beautiful-blogger-templates/ Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Piotrek Karaś	Wednesday 21 May 2008 9:13:09 pm Interesting topic indeed, but I have slightly different perspectives on that. I have to agree that easier theme management and exchange would help to widespread eZ Publish. Personalization seems like the big thing right now and even if it's not about that, ability to implement selected themes easily might be one of the key factors when deciding on a particular CMS. However, we need to realize what theme engines we're talking about when trying to incorporate that idea into eZ Publish. Most themes that I know of are prepared for systems that have a very isolated and precise functionality due to the kind of system they are (CMS blogs, forums, shops, web galleries, CRMs, or CMSs with preexisting module sets, etc..), and whose content model, internal structure etc. do not change. Meanwhile, with eZ Publish we have a content engine that makes it possible to handle most of the above functionalities and nearly everything can be customized. With the system we don't have preset roles for a forum, for a blog etc - we have to arrange that ourselves, minding all the implementation details. There's entire list of other dimensions that have to be taken under consideration (sections, access rules, caching, custom overrides, class modifications, structure...). Many of those things are handled or reach to the presentation layer (*.tpl), many of them in a customized way, again. If some of the themes available for those other, isolated systems, have to be versioned along with the core (for example: theme for version 2.0, theme for version 2.1, etc..), how do we want to handle the change with eZ Publish and its complexity? Would that be possible without limiting of what's one of eZ's key features - extensibility? Wouldn't that concrete the development of the core in some ways? If I look at ezwebin, I see an intelligent GUI, not a skin. This interface is crucial for developers to ease the learning curve and also pick up some good practices, but with around 40 eZ Publish implementations, we haven't yet had a customer who would fit into ezwebin precisely (or sometimes - at all). Yet, another perspective. Much as I appreciate the marketing goals, I don't think they are that important for this level of CMS (and ezwebin versions do just fine for that matter), and nowhere near as important as the core of the system. And there's only so much time eZ people have. I believe we're all much better off getting solutions such as eZ toolbar or eZ Flow (or bugfree stability and security) rather than color variations of backgrounds... -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Felix Laate	Thursday 22 May 2008 12:19:57 am Hi all, I agree with Piotrek. I think providing more <i>themes</i> is the wrong track. While it might be a selling point in small scenarios, I believe that in bigger cases its not relevant at all. I think focus should be on the admin/webin sites, as ultimately UI is what really counts for customers (along with price and what the local IT-boss prefers). For developers, a blank (plain) design combined with the functionality provided in webin is all that is needed. To summarize: the UI should be improved by eZ and the community, the design-magic should be left for all the brilliant designers out there. Felix Publlic Relations Manager Greater Stavanger www.greaterstavanger.com
Bruce Morrison	Thursday 22 May 2008 1:00:15 am So who starts new projects with the ezwebmin or ezflow interface and customises from there? Or are people starting the the plain install or something custom? I <i>think</i> we are all on the same page in this thread. My position is that if one of the install options allows for an easier to style, with cleaner underlying HTML then the themes will come from the community. At the moment it's just too complicated and difficult. I think there is a great advantage to having a "product" that designers can download, install and style in a professional manner without requiring to be a ez publish/template expert. This will encourage use of eZ publish and increase business for those providing technical solutions as custom features are required. Looking forward to hearing any plans in this area at the conference. cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
André R.	Thursday 22 May 2008 2:14:13 am After having worked on webin together with Lukaz, hers are some thoughts: 1. (As pointed out earlier in this thread) themes should be something you put on top of a pretty basic design, not like today when you have to re style the whole page, witch is more time consuming and you need to be very css skilled to pull off a good design. Basically only core.css (without the color / bg parts), and a layout.css that defines a 1, 2 and 3 column design with support for the menu layouts in ezwebin 1.4 (trunk): single top, double top, top - left and left only. Note to self: take a look at the css included in YUI and combine it with the eZ Publish parts in core.css. 2. We should start to use the css / js packer that I'm using in OE so that we can without feeling bad about it, include a lot more css files, and here is why: Instead of monolithic content.css file, each datatype should have there own optional basic css file so it can be included in datatype extensions, each class should have its own optional basic content css file if there is a specific design for the class (overriding the style of the datatype if needed on that class) so new classes in extensions can be bundled with their basic layout css. On top of this the theme css files are the ones that should define all colors, borders, background images, orientation and adjustments to paddings/margins and so on as pointed out in #1. It doesn't need to be exactly like this of course, but the main pont is to make it easier to override a specific thing in css without having to re implement content.css. 3. We also need to define rules for how the markup in line / full / embed view should look like if it wants to be 'ez theme able'. eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom
Bruce Morrison	Thursday 22 May 2008 3:44:21 am Hi André Thanks for the info. Great to get a glimpse of what's brewing for the next versions! Your description of what you have done strikes me as being quite configurable and follows the eZ publish conventions where components can be overridden. I assume that by "css / js packer" you are talking about some code that compresses the js/css by removing the white space etc? Would the packer "compile" the various css/js snippets associated with the datatypes into the one CSS file? ezwebmin already has many CSS files that each require separate connections to download and this can effect page load times. It sounds like the new ezwebmin is going to have many more options and be easier to configure, however it does sounds like you are going to have to be a bit more than a HTML/CSS coder to be able to make it fit a particular design. Many of the design/CSS/HTML people I work with have a workflow that that involves firstly creating a photshop mockup and then converting this to XHTML & CSS (or outsourcing a service to do it). The HTML/CSS then needs to be fitted into eZ publish templates. ( Nominally pagelayout.tpl + CSS, JS & images ) It seems like with eZ & the current methodologies that these users would have to change the way they work. For me, this is why there are next to no contributed "themes" (by "themes" I mean skins for ezwebmin) - with eZwebmin people have to to learn a new way of doing things and they simply don't have the inclination to do so. It would be great to have a "theme" where the design parameters, like menu options, layout etc were part of the theme. After the theme was installed only the options defined as part of the theme were enabled as modifiable choices in the admin interface. I do realise that the problem I'm discussing is quite different from one that ezwebmin addresses. Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
André R.	Thursday 22 May 2008 4:51:20 am Bruce: The things I mentione is not done, it is a suggestion to how we can make things better. The 'theme' change I prupose does not cover cases where you get css + html from designer and want to implement that. In that case your probably better off by using plain site package. The case I'm talking about is when you use ezwebin / ezflow and want to style it to your needs easier then today. The approach I have used on a couple of sites latly is start with ezwebin and override everything that needs to change in a design extension, but I have to duplicate css more or less completly becuse of the complexity of the css in ezwebin / ezflow. Packer: Pack/merge files thogheter, rewrites the image urls in styesheets, strips out whitespace and stores the result in var/*/cache/[stylesheets\|javascript] folder, it also supports development mode where files are included as they are to ease development. Code here: http://svn.ez.no/svn/extensions/eztinymce/trunk/ezoe/autoloads/ezoepacker.php eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom
Łukasz Serwatka	Thursday 22 May 2008 5:42:28 am The more complex design the more additional tag-sets must be used in DOM in order to keep flexibility. ezwebin/ezflow pagelayout is very lightweight I would say. It follows common to many website nowadays structure header-path-left-main-right-footer structure. Similar Bruce's "white design". The most complex tags sets comes from node templates due to design complexity. Just test by removing content.css and commenting out {$module_result.conent}. You will see that structure is simple enough and it is very easy to understand it. The main idea with new CSS framework it to have mechanism that allow designers/developers to enable or disable such additional tag-sets when needed. I believe you had to many times repeat a lot of tag-sets while working with admin templates which could be easily replaced with template block/operator to save time and avoid mistakes and developer should not really care about it here focusing more on the tpl language then on markup. When simple design must be implemented the additional tag-sets will be not used, thus whole DOM structure will be very simple enough. However more complex design might require additional tag-sets and designers/developers should have more flexibility here. In addition to that mechanism the standardization must me introduced like mention above for datatypes, content classes, etc. for easier overrides creation. I also disagree with opinion that themes is the wrong track. For GUI such as Website Interface I don't see any problem with make it more standardized and easier to style/use for website with common content architecture. It is just GUI built at the top of eZ Publish which provides certain functionality. For custom projects you can start with "white design" (from scratch) or re-use the functionality you need from ezwebin. The problem with eZ Publish in the past was that was threat as CMF more then CMS. We did one step closer to CMS while introducing the Website Interface and heaving solid foundation for easy visual customization is something what should have. Also we should take care about how many users eZ Publish have. With more design variations and simplicity in editing more users can adopt it. André, your packager is a nice tool and we should use it in next ezwebin/ezflow generation. Personal website -> http://serwatka.net Blog (about eZ Publish) -> http://serwatka.net/blog
Pierre T.	Friday 11 July 2008 12:53:20 am I reup this post in order to know what do you think about building a web community providing ezpublish themes (eg. a website where people can upload there own themes, like ezpkg). We could find some articles explaining how to custom ezpublish themes, build an ezpkg, etc... These articles will be posted also on the ez.no website ;) What do you think about this idea ? Are there people interested in getting involved in a project like this ? I think it could be a great thing :)
Robert G.	Tuesday 01 September 2009 4:24:52 am I have launched a new blog where is possible to find some site style packages for Ezpublish: http://www.z2us.com New themes will be online as soon as possible, subscribe feed rss to stay updated.