I got the inspiration for this blog about 8 months ago from a Smashing Magazine article entitled, “Designing for Content Management Systems”. So, why write another blog but, specifically for DotNetNuke? Well, they did a great job on their post but, they were generic to just CMS’s in general, and we all know that DNN has some challenges of it’s own.
The main challenge that I have found to be when designing for DNN, is planning for unknown content. You just never know what’s going to happen once you hand the keys over to the client. So, a lot of my designing is actually trying to plan ahead for the many different amounts/content of what could be added to the site. This includes not just content panes, but also menu items. For some reason, once a client gets access to adding their own content, one of the first things they do is create new main menu items. Now, some of my designs have been very specific and the site structure has been discussed w/ the client and they actually understand that they need to leave the main menu items as is, but that’s not always the case.
So how do we actually design specifically for DotNetNuke? I am going to give a list of pointers below that can serve as things to keep in mind.
Keep it consistent. Keep it Simple.
I love consistency on a website! It sets up the site to be able to be quickly learned by the user. It sets an expectation. To me, it also means simplicity. Now, when I say simplicity, that doesn’t mean that your site has to be extremely basic. It can still be artistic and creative, but remember, DotNetNuke uses containers and content panes and any container can be used all over the page. So, keeping a from getting too complex of a design will allow for the flexibility that is needed for a CMS DNN. Use consistent colors, fonts, and layouts.
A key thing to remember is, your design needs to be flexible. Wait, let me say that again, “Flexible”. Okay. You never know what your client is going to end up doing with a page; they may put one sentence on it, a super large image, or a ridiculous amount of text with little to no formatting. So, the best thing you can do is plan for that. How? Try different views of your design, some with a short amount of content and some with a large amount of content. Also, If you are creating columns, make sure that they will still look okay, if the content is not the same length. Experiment with what you wouldn’t do.
Wow. Where do I start here? The owner of the site may add way too many pages to the top structure of the menu. Plan for more than what you expect. That’s not to say you have to go crazy, you still need to create some boundaries for the site owner. If the menu names are going to be quite long, go for a vertical navigation, if you think they will be concise, use a horizontal nav. If it looks like the site will have a large amount of pages, a mega-menu will probably work well for you, but don’t force a mega-menu where it’s not needed. Also, think of helping the user with side navigation for sibling/children navigation. And make use of the footer for some commonly used pages.
Skins and Content Panes
I am a minimalist when it comes to design and skinning. I feel there really isn’t a need to create tens of skin and container designs. This goes with my earlier point of consistency. I have been called in to work on a project that literally had at minimum 30 content panes! What a mess, and talk about poor performance! They explained it as having flexibility… That’s what other skins are for, and really there is no need to make layouts that go from 1 pane wide to 6 panes wide and everything in between. I typically go at most 3 wide with sometimes 4 wide in a mega footer (fat footer). I will typically create a home page design, a sub page design, and a full width design. In my opinion, creating a reverse of the sub page, especially if you have a side navigation, will just confuse the site visitor.
I have found there is little need for having more than 4 containers per design. Too many available containers will confuse the client while integrating their content and the user as they try to navigate the content. But, you have a footer or sidebar with a contrasting background color that just won’t work reusing the container from the body? Enter CSS specificity. Use CSS to override the container’s default styling of font colors and background colors to fit within the content pane that you are in. This takes the guess work out of which container to pick and just makes it automatic. Granted, there are cases where this might not work, but in nearly all cases it will. And it will make it much easier when adding new modules to a page.
Use the available tools of DNN to help the site owner.
One of my favorite improvements of DotNetNuke 6, among many, is the option to specify what formatting tools are available in the WYSIWYG editor. Customizing the RadEditor has always been possible, but it was always through editing an XML file. With this, you can remove many of the editing options that would allow the typical user to introduce elements that would make you beautiful site, well, let’s just say, no longer beautiful. Don’t think of it as removing functionality. Think of it as helping the site editor keep the site beautiful!
While designing for DotNetNuke can introduce some challenges, It really doesn’t have to be too hard. It allows for a design concept to be enforced while still allowing for flexibility. For so long my goal was to make my website look like it wasn’t a DotNetNuke website. I have been impressed at how far DotNetNuke site designs have come in the past 2 years, but we still can do so much better. Now, get out there and create some fantastic DotNetNuke designs!