Discussion about skinning mechanism

A place for discussion about skinning and design. Before posting questions here you should review the documentation about creating skins.

This thread is closed to new posts. You must sign in to post in the forums.
9/1/2009 5:12:25 AM
Gravatar
Total Posts 9

Discussion about skinning mechanism

Hello, we did an extensive research on all open source ASP.NET CMS'ses on the market to find a flexible alternative for our own CMS. In fact we installed and tested them all. MOJO PORTAL clearly stood out in terms of functionality. MOJO is very well build and we have the utmost respect for the archievement of Joe and his people. But there is one thing that we find cumbersome. The skinning process is quite a lot more timeconsuming than necessary. This might be a more fundamental discussion than normal on this forum, but i want to bring it up anyway.

Our remarks are about this:

  1. Too many stylesheets involved. Selectors are spread seemingly randomly over the stylesheets. Stylesheets are organised for structure (lay out), colors, texts, borders, etc. In practice developers are "searching their butts off" to find the relevant selectors in the relevant stylesheet.
  2. The way stylesheets are organised in a way that is not correct in hierarchy. The various stylesheets inherit from each other and cascade down. There is no good reason why "texts" should override "colors" or "borders". Texts have colors too. Layout-elements have borders and colors. Why can't these be combined?
  3. CSS overdesigning. We are one of the four webagencies allowed to deliver webdesign for the Dutch Government, who demands working up to the highest standards in the world on usability, semantic coding, code-reuse, etc, etc. The way MOJO structures it's HTML and CSS would never get past the tests. We are really sorry we can not use this great CMS for this important client. The CSS suffers from an abundancy of classes. Often classes are set, overridden and overridden again.
  4. An architectural choice is that MOJO hardcodes elements and element names. From a developers point of view this makes sense. From the clients point of view and from a designers point of view this is the other way around. The average client is focussed on appearance. From this design HTML-templates are build. The HTML templates are then integrated as skins in a CMS. This is the normal and accepted way of working. It is also widely considered the logical way of working. In Mojo this is however not the case. In Mojo the designer/developer/client has little or no freedom when it comes to defining the structure of the HTML. The only advice we have got is: find a skin that is a bit similar to what you want to archieve and try to modify it. What if we want something completely different? Shouldn't developers and designer have the freedom to create their markup/structure in the way they need it? Would it be an idea to organise MOJO in such a way that developers can simply plug in functionality placeholders into their optimised HTML/CSS?
  5. One of the reasons we choose MOJO was that it allowes to run multiple websites on one installation. Not only this saves server-resources, it would also enable us to offer hosting with a state of the art CMS for a lower price to clients. I mean, this could be a time-saver. But the rigid structure of MOJO and the amount of time it takes to archieve realtively simple skin-adjustments greatly reduces this advantage. Skinning is actually much easier in other CMS'ses.
  6. In general: A CMS is meant to manage content (functionality). A CMS should leave design and markup to designers.

I would really apprecciate a discussion about this and hear your opinions. The above is simply the result of our experiences building our first website with MOJO. Maybe things are easier than we know because we overlook options.

Kind regards,

Tjerk

9/1/2009 1:14:00 PM
Gravatar
Total Posts 2187

Re: Discussion about skinning mechanism

Hi Tjerk,

I would like to address your concerns with how mojoPortal handles skinning. My experience is from a site developer’s stand-point, not a mojoPortal developer position.

I have found mojo to be very easy to skin, whether I am simply modifying a skin that comes with the deployment package, adapting a site to use mojoPortal but keep its original layout, or designing a new skin for mojoPortal. If you care to take a look at two sites I have developed recently, http://i7media.net and http://acckc.org, you will see that both of these sites do not look like other mojoPortal sites. The i7MEDIA site was a pre-existing site to which I added mojoPortal. The ACCKC site was developed from the ground up to be a mojoPortal skin.

Okay, with that said, I will address your remarks more directly:

  1. I agree that there a lot of style sheets involved and this can be confusing and waste time. I have found that while developing or heavily modifying a mojo skin, I need to have a few settings configured in the web.config (or user.config). The settings are the CombineCSS and MinifyCSS, and they must be set to false. I also use FireBug when skinning because it will display the name of the style sheets from which the style and all overridden styles are set.
  2. It is important to note here that it is not a mojoPortal requirement to use multiple style sheets. One could create one style sheet file and put a reference to it in your skin.config configuration file.
  3. From my understanding, the abundance of css classes in mojoPortal is a result of efforts to allow each and every element of a mojo site to be "skinnable". If an element doesn't have a class and it isn't always displayed in the same path of elements, it is very difficult (if not impossible) to apply css attributes to that element.
  4. Some other CMS's have the ability to allow one to build all the elements of the site from "scratch". While this does appeal to some, it is a little ridiculous to others because those systems require so much work to get setup and ready for production, that it can be easier to just build a simple CMS for the site.
  5. Can you give an example of a CMS that has a better skinning model? The ones I have worked are quite a headache to me (DNN, Mambo, Joomla, and WordPress (if you want to call WP a CMS)).

I hope I have answered some of your questions. Again, my answers are not from a mojoPortal developer’s stand-point.

-Joe Davis

9/1/2009 2:23:40 PM
Gravatar
Total Posts 18439

Re: Discussion about skinning mechanism

Hi Tjerk,

As Joe mentioned, you are complately free to organise your css files as you see fit by defining them in the style.config file they will be combined and minified so its possible to organize in multiple files as I did or you could put it all in one and you can put common ones in a shared location. The  only reason all the included skins are done the same way is because I made them and I tend to do them the same way. A Few years ago I read a CSS book where the author mentioned it was a useful strategy to break things up by functionality like colors in one file borders in one file, background images in one file, then you could easily change just the colors by swapping out a different color file or change borders etc. I admit that over time as I have added new things to the css I tend to just add stuff to the bottom of the stylelayout.css because its less work than editing multiple files especially when I'm needing to add some css to all the skins I include. Different designers have different preferences about how to organize them so we support that by our style.config file and css combiner/minifier.

Its true you don't have control over css class names but enough classes are used in the markup to allow any kind of selectors for any kind of styling. The markup is structured with good semantic headings and structure but it does have extra non semantic divs primarily to make it easy to skin.

Its true that you don't have control over the markup of features but you do have control over some markup in the layout.master and you also have control over all the markup in your content like within an html module or within a blog post. Please understand to make it possible to skin a site with CSS there have to be consistent markup otherwise how can I make css based skins to style it. I've looked at ways of trying to make templates for different features but it would be complicated and would result in an explosion of files because the templates would have to exist in each skin to meet my goal that skins are self contained and can be changed with one click. Also upgrades would be problematic because templates would have to have some code in them so if my code changes and someone has a skin with an old template it becomes a problem.

I do have some future plans for some extensibility points that will allow you to inject some extra markup in various places like the side bar of the blog for example.

There are some differences with working with a pre-compiled language vs an interpeted scripting language like PHP. They have easy mechanisms for include files for both markup and script and if you are used to that it can seem like you are losing some control things you had more control over in that environment. But really our markup is pretty good and limitations mainly come from lack of CSS knowledge. Those who are really good with CSS don't have much trouble skinning mojoPortal at all.

So, in short its not easy to provide something that both provides consistent markup and a set of skins that work and also give you complete control over markup. If there were an easy way to do it I would but all ways I see are complex. its a little better in the new ASP.NET MVC model where you can override views it becomes easier but its still problematic because there is code in the views and a custom view could easily break when a feature is changed or upgraded. And its gigantic task to move to the MVC framework from WebForms. Over the long haul I plan to begin a separate project for and MVC UI on top of the same plumbing as our WebForms version but it will be a long time before it has anywhere near the functionality we have now in WebForms. Any CMS is going to take away some control over markup, the only palce where you have complete control is static html, there is always a tradeoff.

Best,

Joe

 

9/1/2009 2:32:30 PM
Gravatar
Total Posts 71

Re: Discussion about skinning mechanism

I am very new in mojo but i love it, mojo is fun :D

9/3/2009 11:36:56 AM
Gravatar
Total Posts 9

Re: Discussion about skinning mechanism

@Joe Davis,

Dear Joe, thanks a lot for all the kind tips. I did look at your two examples and they are very much different indeed. I realise that any CMS is a compromise. Joe made a good choice indeed to build a CMS with a lot of functionality that is ready to run as is. Somewhat like a boilerplate CMS. That is fine. What concerns me is not Mojo as a CMS, but just the skinning process. While it is flexible, it is also - in my eyes - needlessly complicated. Skinning costs more time than necessary. We are in this business to get things done a.s.a.p. The entire problem we see is not even the abundance of css-files. It is in the way these are inheriting from each other, which is semanticly just not correct. And the fact that the is an abundance of classes used which is just not necessary and make Mojo an invalid choice for any customer who is keen on following webstandards.  In other words the CMS is great, especcially the data and BL-tier, but the presentation-layer has rough edges.

Of course it is possible to get the skinning done. The question is, in what time-frame?

9/3/2009 11:51:50 AM
Gravatar
Total Posts 18439

Re: Discussion about skinning mechanism

Hi Tjerk,

It is in the way these are inheriting from each other, which is semanticly just not correct. And the fact that the is an abundance of classes used which is just not necessary and make Mojo an invalid choice for any customer who is keen on following webstandards.

You're going to have to explain what you mean by inheriting and not semantically correct. Give specific concrete examples where we are doing something wrong or against web standards.

There is nothing unsemantic or against web standards. As far as I know discussions of semantics are stricly speaking of html markup and document structure. CSS is just for styling and was never really meant for adding semantic meaning though it has started to be used for semantics in microformats and we even support that where applicable like hcard, hcalendar, hReview and hproduct.

My opinion is that the difficulty and time consumption comes from lack of css skills. I can turn almost any xhtml template into a skin in 1 to 2 days max myself.

Best,

Joe

9/3/2009 11:55:13 AM
Gravatar
Total Posts 9

Re: Discussion about skinning mechanism

@Joe Audette,

thank you very much for being so kind to write such an extensive answer. I appreciate that knowing how busy you are.
Please understand that i truly love MojoPortal. The reason for starting this discussion is simply because i feel there is room for improvement.

Can i suggest you organise the CSS in an other way? Not border, colors, etc?

But: layout (structure), text, mojomodules, forms? In other words: seperated based on function.

Each selector should only appear once. That would make things much easier to search and navigate. (The search function in Visual Studio isn't on the level of Dreamweavers anyway).

Good CSS means simple CSS, in general.
The more rules, the more complicated it gets and the greater is the chance for browser-related issues.
Allmost any CSS-file can be purified.
There are a lot of ways to write CSS and solve things, but a long experience have tought us that keeping the CSS as simple as pobbile allways works best. You'd be surprised how much more elegant things can be most of the time.
I don't think we lack CSS-knowledge as we work for one of the most demanding clients in the world. The Dutch government has every single character in our CSS tested and tested again. So in all hummility i think we have some valid experience here.

I agree with your remark about compiled versus interpretated languages, being a classic ASP - guy. I must admit that i have some trouble giving away some of the control. That is my fault. Allthough i will learn in the end.

I will get working on MOJO. It is worth it.

9/3/2009 11:56:49 AM
Gravatar
Total Posts 9

Re: Discussion about skinning mechanism

Examples of easy skinning: Sitefinity, Drupal, Silverstripe, Graffity.

Wordpress is not a CMS and Joomla has to much problems to be taken seriously.

9/3/2009 12:00:16 PM
Gravatar
Total Posts 2187

Re: Discussion about skinning mechanism

The "over-complication" you speak of is a matter of preference in how to keep the css files organized. You can have just one css file and mojo will work fine. You, as the designer, control the inheritance in CSS. When you move the selectors around inside of your single CSS file, you control the inheritance. Also, if you choose to use multiple css files, you can change the inheritance by (1) organizing the content of those css files and (2) changing the order in which the skin.config file lists all of your css files.

I agree, WordPress is not a CMS. Smile Now if we could just get all the WP junkies to realize this simple fact.

-Joe D.

9/3/2009 12:19:27 PM
Gravatar
Total Posts 18439

Re: Discussion about skinning mechanism

Hi Tjerk,

You can organise the css for your skin as you wish. The style.config file enables this. See the link to a post by Stef about how he starts a new skin from scratch with 1 css file on the Skinning Tips page.

I do not have time or interest nor see a need to re-organize the css files of existing skins. While you may not like the way they are organised there is nothing incorrect or unsemantic about it. In the future if I create more skins I may just use 1 CSS file. mojoPortal did not just spring up overnight, it evolved over 5 years and css classes were added over time. The css organization was based on a book I read at least 2 years ago. While I have found it does make it more maintenance to have the separated files by functions and therefore I have not followed the approach rigorously, I do still think the author had valid points. Having all the colors in one css file allows you to change the color scheme by swapping in a different color.css file. If you want to style your site differenty for holidays for example this could be useful. Then after the holiday you could change back to the original color file. How you organize CSS files is a designer preference not a standard so there is no web standards violation to beat me up with here ;-). Thats why I made it possible to organise them as you like. 

I am glad you like mojoPortal. Obviously we are hitting some right notes or you would be using one of those easier to skin CMSs you mention.

I suggest you start with an existing skin, re-organise and condense the css according to your preferences then going forward use that as the start for other skins.

If you find any testable violations of standards or accessibility in your work with the Dutch govt, I would be glad for the feedback especially if you suggest specific fixes for specific issues. I pay close attention to web standards and accessibility.

Best,

Joe

9/3/2009 1:52:42 PM
Gravatar
Total Posts 18439

Re: Discussion about skinning mechanism

Hi Tjerk,

Also wanted to say that if you do take an existing skin and re-organize and condense the css to one file I would be glad to have it in the project to replace the existing version and have an example for others to follow that is more simple. I do get your points and see the value of that.

Best,

Joe

You must sign in to post in the forums. This thread is closed to new posts.