I have often heard it said that people have difficulty creating skins for DotNetNuke. I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms. In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.
During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site. This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.
Myths and Misconceptions
Over the past several years designers have expressed a number of frustrations about the DotNetNuke skinning engine. Often these frustrations may be based on some particular difficulty they are having and therefore there is a kernel of truth to the issue. What I frequently find when digging into these challenges is that there is a misunderstanding by the designer which leads to the frustration or the design is constrained by limitations in HTML and CSS. Fundamentally, we need to do a better job of providing documentation to the design community which helps them to better address their points of frustration. Below I present some of the common myths about DotNetNuke skinning.
Myth #1 – All DotNetNuke sites look the same
I have heard more than one user say that all DotNetNuke sites have the same basic layout and look. I think there was a time when this might have been true, when designers were just learning to use the skinning engine. Today, I think the only reason why skins and websites have the same basic layout is because designers have honed in on some standard layouts which have been found to work best for certain categories of websites. As shown in the recent skinning contest and the Community Choice Awards, and on dnngallery.net, DotNetNuke website design does not need to be boring, plain or be constrained to standard design layouts. Designers have complete freedom in their site designs, and from the looks of many recent sites, they are taking advantage of that freedom to create some stunning designs.
Myth #2 – DotNetNuke skins are not XHTML compliant
With DotNetNuke, skinners are in control of the markup that is generated by their skins and containers. Designers who desire XHTML compliant skins are free to create skins that conform to HTML 4, XHTML or even HTML 5 standards. The only constraint on the designer is the choice of skin objects that are used in the skin and the modules that are placed on the site. If strict XHTML compliance is desired, then the designer may need to forgo the use of some skin objects and may want to guide their customers in their choice of modules. Many of the modules created in the last 2 years are already XHTML compliant. If you find a module that is not compliant then you should let the developer know that this requirement is important to you.
Myth #3 – DotNetNuke skins have to use tables for layout
While it is true that many skins use tables to provide some minimal structure that is resilient to drastic content changes, it is equally true that the use of tables is a design choice that is totally under the control of the skin developer. The reality is that in many cases table-less designs can be more fragile than a corresponding design that uses a small table to constrain page elements. In fact you can find countless articles online describing methods for achieving 3-column table-less designs that exhibit the same behaviors that are readily achievable with the simple use of a 3 column table. The problem with these designs is that they generally assume that you have complete control over the content that is placed in the 3 columns which is often not the case with CMS skins. Regardless of your personal beliefs regarding the use of tables in page design, DotNetNuke skins can accommodate your preference.
Myth #4 – DotNetNuke menus don’t use semantic markup
Like many of the misconceptions which have grown up around DotNetNuke skinning, this one has a kernel of truth to it, but only in a very narrow sense. The default DotNetNuke menu renders menus using JavaScript with the core menu data provided via JSON. The JavaScript subsequently renders the menus using a series of tables. There are plenty of designers who do not care for this menu. The great thing about DotNetNuke is that there are many menuing options available to the developer when creating skins. During the course of this skinning Series, I developed the sample skin using the menu from DNN Garden. This is but one of the available menus that utilizes unordered lists to render semantic markup for menus. Like everything in DotNetNuke skinning, the designer is ultimately in control of how they want to build their skin.
Myth #5 – DotNetNuke skins are difficult to create
The DotNetNuke skinning engine is extremely flexible and provides complete control over the design. Simple DotNetNuke designs are fairly easy to achieve as shown in this series. As your designs become more and more complex, then the skin will become correspondingly complex. This is not a characteristic of DotNetNuke but rather of the design itself. Since DotNetNuke skins are basically html and css, designers with a solid understanding of html and css will have an easier time converting their designs to skins. The most complicated part of skinning is actually getting a skin packaged for distribution. This is an area which has not been well documented in the developer docs. This is rapidly changing and I expect that the manifest format will be completely documented on the DotNetNuke wiki within the next month.
In Part 6 of the series, I’ll compare the DotNetNuke skinning engine with skinning from several competitive products.