I created this slide deck as a fun way to introduce DotNetNuke.
Update: A DotNetNuke community member enhanced the YouTube video of the deck I posted by adding narration and music. The result is quite impressive.
I created this slide deck as a fun way to introduce DotNetNuke.
Update: A DotNetNuke community member enhanced the YouTube video of the deck I posted by adding narration and music. The result is quite impressive.
Here’s the slide deck on DotNetNuke Search Engine Optimization (SEO) from a webinar I hosted with Tom Kraak.
DotNetNuke has powerful skinning support, but skin designers are often frustrated by their inability to customize various images with static links in the portal. In this post, I’ll suggest a technique and some code to enable skinning of such images.
Let’s first understand the problem. Say you have a DNN site and you have created a custom skin. You have tweaked the CSS to perfection and everything looks great. That is, until the user switches to Edit mode. At that point, various icons used by the framework are displayed on the page. These include icons for help, action icons such as Save, Cancel and Delete. If you want to change these images, your only option is to replace them at their default location. Unfortunately, this is not a long-term solution. Firstly, the change will affect all portals on that instance of DNN. Secondly, the next time you upgrade, the images will be over-written.
An ideal solution would be for you to include the desired images with your skin and have the framework use your images instead of the default. In order to do this on the server-side, there would be several changes needed to the DNN Core. And even if these changes were made, chances are the result would not be very performant.
My solution, called ImageSwap, is to leverage jQuery to create a simple, but effective client-side solution to the problem. The solution is something like this:
Step 1: Select all IMG elements in the page whose “src” attribute has a value containing a known path (example: images/)
Step 2: Iterate through the selected elements, and for each element:
a) Check if a similar named image exists in a sub-folder of the current skin
b) If No, then do nothing
c) If Yes, then change the “src” attribute to the URL of the image in the skin folder
That’s it….in two simple steps we have a solution to skin portal images.
To implement this solution, you will need to add some code to your skin. I have provided the requisite code for DNN4/DNN5. I’ll embed this code into a DNN5 Widget and post it here soon to make it even easier to use.
Implementation of ImageSwap
Step 1: Decide which portal images you want to replace, then create a sub-folder in your skin folder with the replacement images. For example, you might create a sub-folder named “portal/images.” Take care to name the files exactly the same as the originals.
Step 2: Add the following HTML to each layout file in your skin:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
Step 3: Embed the following script in your skin:
var searchPath = "/images/";
var replacePath = "<%= SkinPath %>portal/images/";
(function($)
{
$("img[src*='" + searchPath + "']").each(
function()
{
var frags = $(this).attr("src").split("/");
var oldsrc = $(this).attr("src");
$(this).error(
function()
{
$(this).attr("src", oldsrc);
});
$(this).attr("src", replacePath + frags[frags.length-1]);
}
);
})(jQuery);
You will want to change the values for “replacePath” so it corresponds to the actual folder name you use in your skin for the replacement images. If you are using DNN5, you can delete the script reference for jQuery as it is automatically referenced by DNN as long as widgets are enabled (the default).
I have attached a ZIP file that contains an HTML file that demonstrates this approach. In the file, there are several color icons rendered using the IMG element. In another folder, I have grayscale images of all but two of the icons. When you display the page in your browser, you will see that all but two of the color icons are replaced with their grayscale versions, demonstrating how the ImageSwap script functions.
If you use the script, please leave a comment about your experience so I can improve the script and the ImageSwap widget that I will be creating for DNN5.
ImageSwap.zip (10.5 KiB)
In my last post – DotNetNuke Business Model and Product Roadmap (Part 1 of 2) – I provided some insights into the DotNetNuke Corp. business model, specifically as it pertains to the similarities and differences between DotNetNuke Community and Professional Editions.
In this post I provide some background and insights into how we develop the DotNetNuke product roadmap and also share the roadmap for DotNetNuke 5.1 Community and Professional Editions.
There is no shortage of features that existing DotNetNuke users would like to see added to the product. No matter what feature we add, there will be some users who question the addition of that feature over another that may have more importance to them. The best thing we can do is to gather input from as many constituencies as possible, and then prioritize based on strategic objectives and time/resource constraints.
In order to determine the roadmap for DotNetNuke, we use the following sources:
After aggregating the resulting feature requests, we divide them into Community and Professional features.
Community features are those that broad segments of DotNetNuke users would find beneficial and would use on a regular basis. We review how the feature will impact the product’s usability, accessibility, security, performance, scalability, etc. We also evaluate the time and cost of implementing the feature and its strategic importance. All these factors determine if the feature is added to the product roadmap for the Community Edition.
Professional features are those that advanced business users of DotNetNuke would find beneficial and would be willing to pay for. These features are often easy to spot as their use is typically associated with the existence of advanced infrastructure, large site membership, high-traffic or mission critical applications, advanced security requirements or complex business processes. Also, features that would result in significant time savings and improved productivity when managing large sites are candidates. We evaluate the time, cost and return on investment of implementing the feature and its strategic and competitive importance before adding it to the product roadmap for Professional Edition.
Since Professional Edition was first announced, we have often heard comments or concerns about neglecting or withholding features from Community Edition to “force people to buy Professional Edition.” Let me share some insights to help mitigate these concerns:
DotNetNuke 5.1 Roadmap
Now that you have some background and perspective, let’s review the roadmap for DotNetNuke 5.1.
Starting with 5.1 we are embarking on a multi-release, phased improvement of the DotNetNuke User Experience from the ground-up. Our vision is to implement a high degree of consistency, usability and fluidity to the DotNetNuke user experience by employing a pattern-based UI approach. We have created mock-ups of many such patterns, and as you can imagine, the task of implementing them is large with significant enhancements to the Core Framework Libraries and Core Extensions.
Given the nature of user interfaces, they have high complexity or interdependency and therefore are at a high risk of taking longer than planned. (In the roadmap grid below, some UX features have a gray background to indicate their risk of being excluded from the release or adversely impacting the release schedule.)
Another feature we will deliver in 5.1 is the often-requested Content Approval feature. We view this feature as separate and different from Workflow, which may involve complex business rules and processes. Since most “content” in DotNetNuke is managed using the Text/HTML module, we will implement the approval features in this module. Professional Edition users who have more involved Content Approval requirements can continue to use the Text/HTML module or derive additional benefit from the HTML Pro module, a more advanced version of the Text/HTML module that will be included in the Professional Edition package.
Here’s the roadmap feature grid for DotNetNuke 5.1:
|
Feature |
Comment |
Community |
Professional |
|
Content Management |
Content Approval - Single-stage content approval - Select content approver roles at the site level - Text/HTML module enhancement to support Content Approval |
• |
• |
|
|
Content Approval and Versioning - Multi-stage content approval - Define stages and select content approver roles at the site level - HTML Pro module to support multi-stage Content Approval
|
|
• |
|
User Experience |
Control Panel Improvements in usability and appearance through tabbed, ribbon user interface
|
• |
• |
|
|
Advanced Control Panel Add a page or edit common page settings directly from the Control Panel
|
|
• |
|
|
Skin Objects Skin objects code will be XHTML compliant
|
• |
• |
|
|
Action Panel Skin Object An Action Panel Skin Object to provide a consistent way for exposing available actions to users
|
• |
• |
|
|
Management Console Improve access and discoverability of administrative features by aggregating features into a Windows-style control panel
|
• |
• |
|
Analytics & SEO |
Google Analytics Support Support for injection of analytics tracking code on every page
|
• |
• |
|
|
Google Analytics for Marketing Support Support for advanced Google Analytics segmentation based on role membership
|
|
• |
|
|
Per-page Custom Sitemap Rank Define the rank for each page for use in the Sitemap published to search engines.
|
• |
• |
|
Security |
Change Audit Last modified and full history audit trails
|
• |
• |
|
|
Extended Edit Permissions Page, module and folder level permissions that extend existing Edit permissions
|
|
• |
|
Scalability |
Distributed Caching Provider More efficient resource usage in large web farms
|
|
• |
|
Stability |
Application Integrity Checking Checks files in the installation and reports any inconsistencies which may impact website reliability
|
|
• |
|
Network Services |
Health Monitoring Pings the website periodically to identify failures and will notify the site owner. Also ensures the site stays in web server memory for faster user accessibility
|
|
• |
|
|
Vulnerability Database (Basic) Maintains a vulnerability database with basic information for each product version to easily identify potential issues
|
• |
• |
|
|
Vulnerability Database (Detailed) Maintains a vulnerability database with detailed information for each product version to easily identify potential issues
|
|
• |
Hopefully the information in this two-post series was helpful to you and answered more questions than it raised.