DotNetNuke Tips & Tricks

Thursday, March 26, 2009 by Cuong Dang

Usability Review: Links in DotNetNuke

Filed under: UI and UX

Many web visitors know what a link does on a web page. For web developers and designers, links can perform certain actions in different context; however, it still is going to look like a link to end-users. Pre-defining the CSS selectors (doing the designer's job) on certain links in DotNetNuke framework or any CMS for that matter is not necessary. Sometimes it can cause some additional work for others.

In DotNetNuke, there are CSS selectors called SkinObject and CommandButton. These two selectors are essential parts of DotNetNuke links to define the look and feel. It is kinda self-expalined that if you want to style the links for any skin objects, you'd find the SkinObject selector and override it in your skin.css file. The same technique goes with CommandButton, but you need to identify which link in the framework that uses SkinObject and which one that uses CommandButton.

Links in DotNetNuke framework

Anyway, I think these two selectors are not necessary needed as most designers would define their overall look and feel of links throughout a web site at the initial stage of development.

The best practice is to deliver a consistent (and recognizable) color for links throughout the site. Therefore, when starting any project, a web designer will define some global elements (i.e. h1, h2, a, blockquote…) and reuse them across the site. When working with DotNetNuke, it takes a bit more time to style SkinObject and CommandButton selectors to be consistent with the rest of the site. Since these links have the exact look and feel, there is no need for the browser to render the additional markup when it loads. If a designer needs to style a certain link to have different design, she still has the ability to do so by adding her own selector the wrapper element and define her own styles as needed.

What do you think? Is there a need for the existence of SkinObject and CommandButton selectors in DotNetNuke framework? I personally don't.


Jeff B.
Sunday, March 29, 2009 7:54 AM
Both of them have given me so much grief in designing that I wish they were GONE as well. I don't mind it so much when I have the control, but when they are embedded, I have to scratch my head in trying to get the look I want without changing source files in DNN or 3rd party modules.
Design by the developer may not always be what his/her customers want.
There's quite a bit of CSS I wish was depreciated from DNN, but that's another matter.
Cuong Dang
Sunday, March 29, 2009 10:39 PM
Jeff, I agree. A link is a link. Is there a difference in making it a skin object or a command button? This is the job that web designers should do or should have control over it themselves.
Thursday, May 14, 2009 3:06 AM
I'm fairly new to DNN and /i'm finding that the system try's to cater for so much straight out of the box that the basics are massively over complicated, granted we are using an older version of DNN but the framework should be made a lot simpler. What are the advantages of restructuring links its just unnecessary processing?
If it is so that pages can be localized easier, DNN complicates that too!
Thursday, November 5, 2009 10:54 PM
No way! based on what I have read on this site it is obvious you have a very strong understanding of HTML/CSS and DotNetNuke. I have always found the skinning and design practices in DNN to be pretty poor. I still love it, but the team that designed the initial framework wasn't to hip to CSS and good accessibility practices. Due to this we still see lots of goofy things that will hopefully slowly evolve and no longer be needed. Such as skinObjects, CommandButtons, wrapping everything in crazy spans etc.

Don't get me started on solpart, have to scrap that move one!

James - DotNetNuke and Drupal Consulting

blog comments powered by Disqus