Skinning Utopia... or taking DNN skins to the next level

Posted by Vasilis on Friday, June 26, 2009

Skinning Utopia... or taking DNN skins to the next level

I am just thinking of this so much time that I cannot keep it for myself for any longer. I love DNN skinning engine but I really think there is something important that is missing. Something that will take DNN skins to the next level.

So what is the problem

The problem is more obvious with the skins for sale on Snowcovered or on the DNN Marketplace. Those skins are not enough dynamic. DNN site owners need to be able to customize a skin upon their needs. They can do that now only if the know HTML and CSS or if they hire someone to do it for them. Skinners try to make their skins flexible and give their customers some power over the look and feel of their site by offering many page skins. Obviously creating more and more page skins is not the solution. Ten, fifty or a hundred page skins are not enough to cover all possible combinations. Not to mention that in most cases, the only difference between the page skins that included within a package is different headers or background colors.

Looking for the solution

DNN site owners need to be able to customize their skins through a friendly interface. Skinners need tools so they can offer this kind of flexibility with their skins. Skins need to be as powerful as the modules are. Skin Designer feature in the recent DNN versions seems to walk in this direction but what I envision is much more than that.

WordPress is a good place for inspiration

The first time I saw a WordPress theme with a Theme Options page I thought "Yes, this is a great idea!". DotNetNuke and WordPress have not much in common. But I find the idea to have a Skin Options page really exciting. A user friendly interface where the site owner will be able to customize a skin without HTML and CSS to be a requirement.

Implementation

OK, now begins the imaginative part. I'm not a programmer so what you will read in the following lines is probably far far away from a real world implementation.

We want the site owner to be able to customize both the HTML and the CSS part of a skin through a dynamically generated form. We'll do that with a module. Let's name it the "Skin Options" module. Through the module we can customize the skin at portal level or at page level. So a "Skin Options" page will be created automatically, when we install the module, under the "Admin" site section where we can set the skin options at portal level. But we can also override these options at page level just be dropping the module in a page and set new skin options for that particular page. The module will work only for the skins that include an options.xml file in the skin folder. In the options.xml file the skinner will be able to define what kind of input needs from the site owner and how this input will affect the skin.

Overriding skin.css

So for example the skinner could ask for a text input with "Background color:" label that will override a style within a CSS selector in skin.css (ideally multiple styles within multiple CSS selectors in skin.css). Or a select box where the user will be able to choose between several background images. Or a Boolean value based on which we'll be able to know if the user wants the login link to be visible or not. The module will create a new css file based on the user input that will override skin.css either for the whole portal or for a specific page.

Beyond skin objects

With the same process we can get some input from the site owner and put it in the DB. Then we can use that input in the skin.ascx to add logic to our skin code. So for example on some pages instead of the breadcrumbs skin object we show the page title or we don't show anything. Why not and small text parts in areas of the skin that panes are not appropriate. For example a custom message before the register link or two three additional links on the right of the login and register links. So in options.xml the skinner would be able to define custom tags that will return either a text or a Boolean value.

Conclusion

As I wrote, the implementation part of this post is imaginative. I have no idea if it makes any sense or not. What I wanted to do was to point out something that I see as a need in the DNN skinning market and then just imagine a possible solution from the perspective of a skinner.

I would love to read your thoughts in the comments.

Comments

Dylan Barb er says:

Great idea and i would love to see it but working with Wordpress users (meaning people just using it to blog who arent techies) most of them dont understand the skin stuff - DNN works the same way most users get a skin installed then dont touch it on a regular basis

Not saying its not a great idea - I would love to see it - but beyond developing skins i dont think it would get a huge amount of use

Of course I could be very wrong !

Vasilis says:

Hi Dylan and thanks for your feedback. From what I can say, the Theme Options page is getting very popular lately in the WordPress community. All serious themes include one.

I think everybody would love to give a personal touch to a skin that bought with less than a hundred bucks, without the need to know HTML and CSS.

Ian Sampson says:

One main difference between Wordpress and DNN is the user signup model. I.e. In DNN we'd create/ add a portal sign up module and allow users to create their children portal.

You could build a module (added to an Admin view page) that interacted with your specialist style sheets to create the functionality you wanted (i.e. simple find and replace operations for your Class strings).

A nice touch with Onyak Techs portal sign up module is the ability to create a portal and add the the user to a default editor role other than Admin so they they don't bogged down in all the technical settings.

It's an interesting concept.

Cheers
Ian

Mark Allan says:

A few of my skins have something along these lines already, e.g. "If this page is under the Services tab then give the heading this background". With a bit of care, it should be possible to create a UI that extends this to add general parameters for the CSS and ASCX files, with options to override the portal-wide settings at a tree or page level. Now if only I could think of a programmer who'd be able to do the work ...

Doug says:

It is a very interesting Idea you have. It would be great to have a module that would enable a site Admin to create a custom site using elements that come with the module and also encorporate out side graphic files.

I have stumbled onto a application call Artiseer which can create a website for DNN, Wordpress, Joomla & Druppal.

www.artisteer.com

It is lacking a lot of things like flowing support for DNN and uses some third party menu for DNN and not one of the ones that come with it. It has a long way to go. I've created a design i Like for my kid's boyscout website. Now to disect it so I can create a more standard skin then the end product it creates.

But to incorporate something like this within DNN or as a design module would be very interesting. It would be a boom for someone like me that would like to offer DNN sites to scouting organizations and have them do a ""Build a Site" wizard type of DNN site where they or I could quickly create a one of a kind website buy using varoius elements that comes with the program as well as graphics they have.

IT would maybe put some skin designers out of business!

Doug

David Haggard says:

Interesting discussion. When I created the DotNetNuke HTML skinning engine way back when (which was combined with other ideas from other developers to make the DNN skinning engine we have today), I had included what I called "User-Level Skinning."

In my original design, the portal Admin could choose to allow individual users to choose their own skins, colours, fonts, etc.

The final decision-makers at the time decided not to include User-Level skinning. If I remember right, they thought no Admins would like letting individuals choose the look and feel.

Has the idea of User-Level Skinning now come back around full-circle?

Ian Sampson says:

One problem with Skinning in DNN is the number of levels to which it is applied:
- Default.css - catch all style sheet
- skin.css - either in _default or portal skins folder which is the primary driver of the site design.
- container.css - which wraps around module content.
- module.css. which sets out how specific module content is laid out. To me, this is the anomoly in the system because we're letting the module developer control some of the layout on our site. The other problem is that this layout applies to ALL child portals.

To me, to allow flexible skinning on a portal by portal basis by non-designers, has to be around the use of CSS Variables. In other words we set our base font class once, and all styles sheets adopt that variable to achieve a truly consistant look and feel.

There is a lot of discussion on the web about this with CSS purists seeming to win the debate against CSS variables. In the DNN world however, there is a very strong "function over form" argument in support of variables.

The way to implement this is probably going to be through the development of a custom module that:
- parses all styles sheets on the fly, swaps out variables and probably does some performance optimisation (comprehension and consolidation).

I was at Microsoft's TechEd a few weeks back learned that:
- browsers can only download 6 objects at a time (i.e CSS, script, images etc) so the more you can do to reduce the number of embedded objects the better.
- mobile devices, like the iPhone, manage their cache very aggresively and will not cache any object above 25k.
- script files should be added to the end of pages as browesrs stop at a script reference, wait until all the script is loaded and then carry on rendering the page. Better to let the user set a complete page and then pull down the scripts.

So there is a strong argument for better CSS optimisataion inside of DNN.

Cheers
Ian

Love poetry says:

I think everybody would love to give a personal touch to a skin that bought with less than a hundred bucks, without the need to know HTML and CSS.

Chris says:

Absolutely a great idea!

I have used DNN for about a year as admin and site owner. The "mystery" of skinning and css is absolutely a showstopper for DNN.

You will always need a designer who can make a nice and appropriate design for your project in for example PhotoShop.
Then the design needs to be converted into HTML which then needs to be converted into a DNNskin taking all css levels into account.

I have bought custom skin from different sources who claim they are DNN skin developers but even they obviously have problems getting this right. This makes the process complicated, frustrating, slow and expensive. So an admin tool to make minor changes in a a skin would be useful. I have had thoughts in this direction myself.

One skin developer that I think has taken steps in this direction is http://www.bind.pt/ with their skin tuning. But it is still that you need them to generate a new skin. The skin tuning should be dynamic and possible to use for the site admin.

Besides dynamic changes of colours etc there is a need to dynamically make changes in which type of menu/navigation to be used.

Name (required)

Email (required)

Website

Enter the code shown above:

Notify me of followup comments via e-mail

DotNetNuke Skins and Resources by ThinkofDesign