Making DNN More Design-Centric

The roots of DNN are in Webforms. In the early days of asp.net this was Microsoft’s evolution of the Active Server Pages technology. Since then the world has moved on quite a bit. Various alternatives to Webforms have been introduced on the Winstack and by and large PHP has grown more explosively than any .net based technology. In part, because the php-based cms solutions have been kinder to web designers. How else to explain the vast amount of skins (themes) available to them and the general disdain of any web design firm for .net? OK. Maybe this is not entirely accurate, but the feeling I get is that we could make progress by making DNN more design-centric. And in my opinion that translates to: ensuring a designer has a better grip of where the HTML and CSS is coming from and where to change this.

One of the complexities, here, is that due to the plethora of coding technologies/methodologies now available to us, no module is like another. This makes it harder for anyone to tweak a complete site as one needs to “get into” a new module countless times. Another is that with our in-line editing approach (as opposed to a management interface) to pages, it is not easy to understand what is going on just by looking at a page. Even in edit or layout mode. E.g. which modules are being displayed and which containers? Or if there are any tweaks to the containers in terms of HTML/CSS. This article proposes a solution consisting of two parts: a uniform approach to templating and a management part dedicated to design.

A unified approach to templating

I’ve already written at length about a specific solution for templating in DNN modules. In this post I’d like to focus on a broader strategy for templating. A quick research on the module I’ve used on a couple of recent sites I’ve worked on shows me there are 3 places where templates are stored:

In one or more files on disk
In the resx file
In module settings
In a custom format (e.g. NBStore uses xml files)

There are several disadvantages with having various methods mixed in a single system. For one it is hard for a designer to know where physically a piece of HTML is coming from. And secondly: the editing experience tends to be very different for each. We could gain a lot by having a single mechanism prevail and become “best practice”. And that standard should be in files on disk. Why?

Well, consider the resx file solution. It is quite commonplace in DNN modules to store templates in there (even the core modules do this) and it stems from using the resource file for email templates. The resource file is most commonly used to store texts that need to be translatable. There is a “cascade” to ensure that the best match text is retrieved. You can have a resource file at portal level and at system. So you can override a text in the portal for a specific language. Very useful. But templates operate at module level. In most application areas you must be able to apply/choose a template for a module individually. Maybe multiple modules share the same template, but by choice. So the resource file as storage for your template is not a good idea as it cannot cope with all these scenarios. I can see how it’s OK for email templates, but not for display templates.

Now to the module settings approach. A number of modules, such as Events for instance, get their templates from the resource file and then store them in module settings. With this mechanism, the advantage of localization of resource files is of course lost, but what is gained is the module level control of the template. But this system not only loses localization it also loses a lot of its portability. Sure we can use DNN’s IPortable, but preparing something in staging and porting it to production becomes a big hassle.

Finally the custom solution. I’m sure there are solutions that can’t be caught in one of the other approaches. But what you lose in this situation is that you require the designer to get familiar with your way of doing things. It increases the overall complexity of the system. There is a whole cottage industry of people that know how to skin module XYZ. In itself not too bad (everyone makes a buck) but it leads to the whole platform being seen as difficult to design.

My proposal boils down to this:

Use a file based approach to templating
Given that not all templates can be caught as a single file, let’s use a folder to group one template together
Let’s agree on a standard way to store the templates, e.g. DesktopModules/MyCompany/MyModule/Templates/TemplateX
Let’s agree on a standard cascading mechanism (system, portal, etc)

Of course we will also want to ensure that they can be localized which should/will be the topic of another post. Now, what are the biggest advantages we can gain with this approach?

Designers will find it easier to find your templates
Easy to move/redistribute
We can make a generic template editor
You could roll a template into a skin
We can even imagine a “template exchange”
A better template management

I’ll elaborate on a number of these.

A generic template editor

One thing that has bugged me is that as attractive as the use of templates is, it’s a drag to have to implement an editor in your module. It’s a lot of work and if you’ve done it twice you keep thinking to yourself: this should be centralized. And because the template editor is not necessarily “core functionality” of a module, it ends up being the “not so pretty part” of the application. It doesn’t get a lot of love. Most modules just implement a straightforward textbox on the main settings screen or rely on the core’s resource editor.

So how about centralizing that? How about a “core” template editor that can be leveraged by modules and the designer to edit the templates? The editor would be primed with just a path to the template folder and would be able to edit any file underneath this. And we could then make a really decent editor. I’m thinking of using the Codemirror library, for instance. This is used in the new SQL module if you want to see what that’s like. And we could define a standard for the module to communicate to the designer what is allowed and what isn’t. Specifically: the tokens and what they mean. The editor could then display these neatly alongside the editor. If done consistently by modules, then editors will get a consistent editing experience, making working with DNN a joy!

Templates as part of a skin

I’ve recently implemented this for the Blog module. The possible places where templates can be stored for the Blog module are:

In the module directory (i.e. DesktopModules/Blog/Templates)
In the portal directory (Portals/0/Blog/Templates)
In the skin directory ({templateDirectory}/Templates/Blog)

Now this is not yet perfect. I’d like to add host level templates (so under Portals/_default) and we need to unify the path naming (so in all cases Templates/MyCompany/MyModule). But the important take-away, here, is that a designer could group all the work in the skin folder and redistribute that as a complete package that skins not just DNN, but also individual modules. That is a huge win, IMO.

A template exchange

Like skins, templates can be a lot of work to do nicely. So why not allow people to share their work. One of the ideas I’ve had for future development for the Blog module is to have some sort of central template repository where users can exchange their templates. Naturally, if we have a unified approach to templating we could make a more generic exchange.

Template management

The template editor, then, should be able to manage the templates. I.e. upload, download, and copy. With copying, you’d have the opportunity to copy a template from a distributed level (in the module directory for instance) to the portal level.

Baby steps

The first thing I need to do is to create the generic editor to show you the power of this idea. Rome wasn’t built in a day and for sure we’re not going to have all module immediately follow this pattern unless it is clear that the tooling is there and that there is a real advantage. Anyone is welcome to join this effort with me.

This post is cross posted from my blog at DNN-Connect

Comments

Good article.

But the issue goes much deeper than just templates. Step 1 should be a to completely get rid of 'default.css'. There is so much bloat and a global CSS rules in there that it makes my head spin. The first thing any competent skin designer does when building a custom skin is override all the silly global CSS rules included in here. Things like H3 {letter-spacing: -1px}. Who in their right mind though this was a good thing to include as a global CSS rule in default.css? This file needs to be cleaned up or better yet dumped completely. Any rules specific to DNN control should be moved to the appropriate 'module.css' for those controls. Or at the very least, these 'global' rules should be prepended with a 'dnn' prefix to make them targeted for DNN controls.

As for templating, I've seen a number of different solutions and I agree their needs to be a common approach adopted by the core. There a lot of good ideas out there but right now its a little bit like the wild west with everyone doing their own thing. Unfortunately, asking people to just 'agree' to do it one way probably won't achieve the reach it needs to be successful. A framework provided by the core would be better.

I suggest using the new dnn-connect.org to form a team to build a solution a propose it for inclusion in the core.

Jay Mathis Monday, February 10, 2014 8:51 AM (link)

Thanks, Jay. I realize that just writing an article is not going to change the world. But I hope that maybe one or two beginning module developers will pause to think how they approach templating and that at the very least they won't go down the path of resx or module settings.

About default.css: if I had my way, it'd be out. Definitely. But that's probably not going to happen any time soon. Instead, I think we can hope to roll something into the skinning mechanism whereby the skin flags that it does the css reset itself and doesn't want default.css.

Peter Donker Monday, February 10, 2014 11:27 AM (link)

Sorry, Peter, but I have to disagree.

While a bunch of small files look nice in the first place and has the benefit of easy transportation, there is a lack of flexibility and integrity for more complex scenarios. If you consider a list, it is easy to provide a template for Header, Footer, Item and maybe alternate item as individual files. however, this require the hosting module to provide the control structure, i.e. sequence Header {+ Item + AlternateItem} + Footer. However, as soon as the developer decides to add a separator template as well and chooses a non-empty default, the approach fails. Same applies to hierarchical situations (client with bills, each with items on it). Shouldn't the site owner decide, whether he displays a list with or without child items?

Unfortunately, the only convincing approach I have seen so far, is XSL - Stephan Cullmann did a great job in Form and List module. AND, he also took the first step into the right direction: hiding the generation defaults from the public by using a generator - IMHO the best generator for the masses would be a visual designer. This might not produce the best code and there are designers keen on optimizing it, but it would combine flexibility, power and easy of use.

Whether the result is stored locally in files (please don't abuse the portal folder again) or the database (per language), is just a minor details - though for module instances, I'd prefer a database approach, e.g. using TabModuleSettings, which get automatically cleared, when the module is deleted and purged from the recycle bin.

Sebastian Leupold Tuesday, February 11, 2014 5:02 AM (link)

I'm not sure I follow. The debate I'm trying to start here is not about which templating mechanism you should use. It's up to you how you do it. It is a very controversial subject and I don't want to get burned again stepping into that. You know where I stand (and I love XSL, but it is only a very select group of people that are able to work with that). But here I want to focus on where you keep things. And most importantly my point is that by keeping them as (a group of) files on disk we can come to a common editing and transport mechanism.

"please don't abuse the portal folder again" I'm trying to understand what you mean by this. Abuse? Anything that needs to be at portal level needs to go to the portal folder. Period. You can't store portal specific stuff at host level. You shouldn't use the desktopmodules folder to store stuff that is specific to the installation. Period. The portal directory is all about containing things that are specific to a portal. If your template is shared between modules but only within a particular portal, it belongs in the portal folder. Nowhere else.

As I argue above, the database approach more or less invalidates the entire thing I wrote unless we have a special "templates" table. But even then, we will probably run into issues where this does not quite work for people. E.g. in cases where the template files can't be loaded dynamically but must reside on disk. Like for instance css files would be better off on disk. Secondly: it makes local editing scenarios even harder. What a designer would typically do is to edit the template locally and then upload.

Peter Donker Tuesday, February 11, 2014 5:48 AM (link)

I can see a compelling reason for storing the template in ModuleSettings or TabModuleSettings instead of the Portal directory in the file system. The advantage of that approach is that if the module is deleted it wont leave a bunch of orphaned templates around. Of course, there is also some downsides of making it easy to share or reuse templates but those use cases could be managed via module level code.

I've come to really appreciate XSL in working with DDR Menu but it was a bit of a learning curve and I suspect a lot of developers/designers don't know it or won't take the time to learn it.

Jay Mathis Tuesday, February 11, 2014 10:22 AM (link)

I'd like to contribute to the discussion, even though my involvement in the DNN ecosystem has only been a recent journey, I can tell you that the learning curve is so extremely steep, if DNN does not eliminate the bloat and confusion with the "required" design files (default.css etc) it will stagnate and paying customers will find a way to move away from the architecture all together. Look at all the top design websites out there selling design services online.....not a single one of them sells DNN skins...none of them...why? Reference Jays comment above "H3 {letter-spacing: -1px}" or the core transforming basic html input elements like the checkbox into an image sprite...come on. No one wants to learn how to build DNN skins because even if they do take the time to do so, the likelihood some core change in the code base or god forbid the core design elements is so high, they don't want to have to support their legacy designs when they break. 2 years into this and I still don't know how to use the resx files to store emails....what is that?

Kevin Forte Friday, February 14, 2014 4:08 AM (link)

Sorry, you are correct, this is more a platform issue - IMHO DNN needs to separate core and module data from content files - despite file type, users should not get to see cache items, skins, containers and module settings - even templates should have a dedicated place outside the content files section. I would suggest moving skins and containers to /skins path (like /desktopmodules) and all other files to /app_data/[vendor]/[modulename] (settings etc.) and /app_data/content/[portalid] for all content files uploaded by admins and users.

Sebastian Leupold Friday, February 14, 2014 7:13 AM (link)

@Jay: yes, cleanup is indeed an issue. But, IMHO, not so important as to not do this. I.e. the benefits far outweigh the disadvantages. XSLT is waaaay to difficult for the target audience (web designers). I love it myself and work a lot with it, but XSLT is incredibly picky and very quickly bombs. And when you add namespaces to the equation ...

Peter Donker Friday, February 14, 2014 7:16 AM (link)

@Kevin: I couldn't agree more. Note that this post was not meant to resolve all issues surrounding design, but contribute to its solution by binding templates closer to skins. I feel that the lack of accessible quality designs for DNN is hurting the platform as a whole.

Peter Donker Friday, February 14, 2014 7:20 AM (link)

@Kevin: I agree completely. It's alarming when you look at ThemeForest.com or TemplateMonster.com and see whole categories devoted to WordPress, Joomla, Drupal, Moto, and many others that are smaller than DNN and yet no DNN skins.

The marketplace is speaking and it seems like DNNCorp is not listening. It's a major roadblock for DNN and if it isn't addressed soon, it may be too late. More and more of my clients are asking for WordPress because "it's just easier".

And it's not just skins, look at CodeCanyon.net and see the vast multitude of WordPress plugins (often available for less than $20). No DNN categories, and the average price for DNN modules on the DNN store is probably around $50. Why is that? I believe it is the core licensing mechanism. WordPress has a built in licensing system that manages licenses for the plug-ins. That is why developers can sell their plug-ins for so cheap because they know the platform will force the buyer to purchase another license for a new site. With DNN, developers are forced to invent their own license management solution. I'd like to see the core have a built-in licensing management system. Allow developers to set a per-site license, per-installation license, or a enterprise license., To make it even better, allow it be a one-time flat fee or a recurring periodic (monthly/yearly) fee.

Unfortunately, I fear DNNCorp is focused on the revenue generating opportunities right now with Evoq Social and Evoq Content. I understand that, you need to pay the bills. But, meanwhile, the competition is passing them by with (what appears like) a more solid foundation to build upon.

It's going to take some community project teams to devise a solution and propose it for inclusion in the core. I'd volunteer to help, but I worry that the core is too slow to adopt community solutions. I've offered code fixes before in the Support system and it sometimes takes like 9 months before anyone even looks at it.

Jay Mathis Friday, February 14, 2014 9:35 AM (link)

@Jay Mathis - Whilst I agree that contributions were poorly dealt with in the old Gemini days, since we reorganised internally, added additional resources to the platform team and moved to github contributions are now dealt with in a timely fashion - we've take ~65 from github pull requests and ~85 from jira (predominantly SQL optimisations from Sebastian Leupold) in the past 4 months.

If you have bugfixes/enhancements you'd like to make take a look at https://github.com/dnnsoftware/Dnn.Platform/blob/master/CONTRIBUTING.md . Note: for larger enhancements it's good to discuss them with the platform team first (bugfixes can always be taken, but a larger feature may already be in development or may clash with plans, so better to get some sort of approval before committing lots of time to it)

cathal connolly Friday, February 14, 2014 10:09 AM (link)

Great! Thanks Cathal! That is certainly encouraging to hear. What is the best way to get in touch with the platform team to discuss ideas? I've got a bunch of things I'd like to contribute but like you said, I don't want to waste time on it if they are already working on something.

Jay Mathis Friday, February 14, 2014 10:13 AM (link)

@All: please try not to veer off topic in this discussion. It was about making DNN more design centric by encouraging module developers to use a similar development pattern so designers would know where to look if they wanted to adjust HTML output. I don't want this thread to descend into some kind of flame war about how some think DNN sucks.

Peter Donker Friday, February 14, 2014 10:31 AM (link)

I hope I didn't come off sounding like I think DNN sucks. I certainly don't. I'm passionate about DNN and believe it to be the best CMS around.

But I do think "Making DNN More Design-Centric" is going to require a lot more than instructing module developers where to put their templates. There are some fundamental 'design' related flaws in the platform that need to be addressed first in order to have a solid foundation to build upon.

Jay Mathis Friday, February 14, 2014 11:13 AM (link)

What designers want:

Use the tools they're comfortable with. Their favorite editor. Work directly with files. Save over FTP, WebDAV, etc.

Use template engines they already know. XSLT and XML are for engineers. They are so brittle that most developers can never learn them. They want something modern like Handlebars (json templating with basic logic.)

I think making DNN design centric is a noble goal, but I also think it should be done with insights from developers and designers *outside* this community.

Lucas Jans Friday, February 14, 2014 7:51 PM (link)

I don't disagree, Lucas. But access to people *outside* our community is something we don't have. I.e. they're not hanging out here. I'm trying to come up with babysteps to improve what we have.

Peter Donker Sunday, February 16, 2014 5:55 AM (link)

Since this is my first post in the community blog, albeit a member since 2008, I would like to add my two cents into this discussion.

I have been making my own skins for the past 7-8 years and loving it every time the same. There are two major flaws I can think of right now:

1) default.css / portal.css
Never understood why they have to have all the classes... I mean, I am doing my own skin and it has it's own stylesheet. For starters it would be great for the default.css stylesheet to include only styles like forms, checkboxes etc and not headers, body etc. It would be ever more awesome if DNN actually sees the change of the skin from Gravity (I believe is the default skin) and stops loading the default.css automatically. Hope I am making sense here.

2) module.css get's overwritten in each update
Have you ever made a dark / black portal? Let me tell you, it's a headache. And when you update you get all your styles replaced by the upgrade in the module / portal. You have to actually keep track of all your changes and walk through em one by one. This is especially nerve-wracking with the social modules or the modules that come with the installation. Lately I resolved to CSS hacks and tricks so to overide the original values and tweak the layout a bit but still we are limited to that.

I believe that DNN has a great potential for skinning and lately I've been seing companies doing a great job in store.dotnetnuke.com but I would love the aforementioned to be fixed just to be able to work faster and better.

Anyways, that's my two cents :)

loukas bafatakis Sunday, February 16, 2014 4:13 PM (link)

@loukas

Just FYI, you shouldn't be modifying any module.css (or default.css) for the very reasons you mentioned. Your changes will get wiped out on the next upgrade. There is a specific order in which the stylesheets get loaded and that is on purpose.

default.css -> module.css -> skin.css -> container.css -> portal.css

If you need to override any CSS settings in default.css or a module.css, it's best to put those in your own custom skin.css file so your changes won't be overwritten. Portal.css is meant to be the last resort but in my opinion it usually bad practice to put anything in there.

Quick tip: if you don't need any CSS rules in portal.css, you can delete that file and save your bandwidth an unnecessary HTTP request.

Jay Mathis Sunday, February 16, 2014 8:29 PM (link)

I am sorry. By override I meant creating classes in the skin.css (mostly with !important) so to keep the module loading my classes instead of the ones in the module stylesheet. I was working non-stop and didn't really thought of the syntax of my sentense.

Also, with regards to your tip, because of the time needed to analyze and change the default.css / portal.css in each update I resolved to just keep it and try "building" the skins around it. Unfortunately, clients do want a competitive price and our time is limited so we have to keep the cost down in terms of time spend fixing up things that we can easily "live with". Thus, black skins are a nightmare. For example (www.theconcept.gr / www.musicfestival.gr). One thing that bothered me most (out of the top of my head) was to change the telerik html editor to have white background and dark font color while the body of the skin has black background and white font color...

Thanks Jay :)

loukas bafatakis Monday, February 17, 2014 12:23 PM (link)

I agree black skins are a major pain. Most of the defaults are designed for white backgrounds with dark fore colors. Having to reverse all of those is very painful. Another reason default.css should not assume anything about how I want the site skinned.

I agree with leaving default.css and portal.css alone. I wouldn't advise spending time modify those with each upgrade. But for overriding module.css, you should be able to do it in skin.css without using '!important' if you are using the same level of CSS specificity.

Jay Mathis Monday, February 17, 2014 1:14 PM (link)

My dream for DNN is to ditch webforms altogether and transition to cleaner mvc generated markup.
http://www.dnnsoftware.com/voice/cid/149579

Obviously this is a big departure, but I think it is a natural evolution. New standards can be implemented so a uniform experience is achieved.

Also agree that default.css is the bane of my existence. As is telerik. ;-)

Erik Hinds Monday, February 17, 2014 5:34 PM (link)

Erik, please be aware that backward compatibility is the outstanding value for most of the users. If you are able to provide an option for DNN to integrate all existing modules within an MVC migrated version of DNN, I am sure, DNN Corp. will be more than happy and grateful.
Btw, wouldn't an MVVM only version even more up2date - just requiring html and WebAPI on the server?

Sebastian Leupold Monday, February 17, 2014 6:21 PM (link)

I remember some exploration a long time ago about moving a MVC but it was ruled out for various reasons. Backwards compatibility probably being number 1.

But like Sebastian said, look into client side MVVM. It's a bit of a learning curve but it's very cool. Knockout together with WebAPI is very cool.

Jay Mathis Monday, February 17, 2014 9:58 PM (link)

My scepsis regarding converting everything to MV* is that every few years there's a new thing. If we had taken this approach to technology, DNN wouldn't have been webforms a long time ago, but would have passed through 3 other rewrites, probably. Not only is that a distraction, it would also mean that you basically have to reinvent your market every few years. IMO people like some form of stability so they know how to address their client's demands in a consistent fashion over the years.

Peter Donker Tuesday, February 18, 2014 3:23 AM (link)

Sebastian - Better to have this discussion in the forums. Backwards compatibility obviously is not my concern. A clean cut and separate path altogether. There are plenty of models out there for this transition, look at iOS development for example. If the roadmap is established ahead of time and developers have the resources necessary, it can happen. Or Orchard, I could just use Orchard. ;-)

Erik Hinds Thursday, February 20, 2014 1:49 PM (link)

I really don't understand the resistance I'm getting on this. I've dug into Active Forums today. And, IMO, it completely underscores my point. I've now spent an hour trying to figure out where a specific bit of HTML is coming from and I'm still totally lost.

It uses its own templating mechanism with naming that is confusing at best. If you don't know what topics vs posts vs replies are, you are left guessing what does what. The editor is a plain text box which makes it very hard to create valid HTML. The templates are copied from disk (in .txt files!?!) to module settings. This makes it (1) impossible to do a disk search for a specific sequence of characters and (2) if the module gets upgraded I don't get to benefit from improvements to templates. There are also template files suffixed with version nrs. Again, I'm at a loss as to why and what I should focus on.

It's frustrating because without a minimum level of agreement (which I tried to create), the old crappy stuff remains as is. And we just keep trundling on with our messy platform. And we keep complaining that we can't attract designers to our platform.

Peter Donker Thursday, February 27, 2014 2:06 PM (link)

You're clearly frustrated and I get that. That module is a beast to work with from a design standpoint.

But I don't think anyone is necessarily disagreeing with you. I'm just saying the reason we can't attract designers goes way deeper than where or how module developers handle their templates.

DNN has always been a developer first platform and it shows.

Jay Mathis Thursday, February 27, 2014 2:58 PM (link)

Here is a discussion of another reason why designers hate to skin for DNN.

http://www.dnnsoftware.com/forums/forumid/109/threadid/491635/scope/posts

Was this style absolutely necessary for Edit mode to work in 7+? The workaround is tedious and does anyone on this thread think a new designer would have been able to know the styles were being added in the source code and not in any design files anywhere? This is something that has frustrated me to no end.

Kevin Forte Friday, February 28, 2014 12:47 AM (link)

Excellent post. I like standard templating approach using files and folders.
- Excellent for localization
- Logical
- If templates are stored in file system, you can modify your templates on the fly on your site with ftp
- Copy - paste the folder and you got a new template copy to work with

Gregory Demotchkine Saturday, March 22, 2014 4:20 PM (link)

@Kevin
Regarding the padding added to the content panes, I recently ran into the same problem when designing a skin based on BootStrap. I was adding a BootStrap class like "col-md-6" to the content pane div. What I learned is this is bad idea for the reason you discovered. When you go into edit mode, the DNN CSS will override your css on this element. I don't necessarily think that is wrong as this is really a DNN control and we should expect DNN to modify it as needed (not saying it is really needed). What I suggest instead is to just wrap that div in another div and put your CSS on that bounding element.

Jay Mathis Saturday, March 22, 2014 6:41 PM (link)

Products

Solutions

Resources

Partners

Community

About

New Community Website