TechBubble

Customer-driven Business Innovation with DotNetNuke

Tue, 25 Aug 2009 00:37:00 GMT

In an increasingly hyper-competitive world, businesses look for every possible opportunity that can give them an edge over their competition. It’s no secret -- businesses that innovate survive and win, and those that don’t either die, don’t grow or become the walking dead.

But innovation isn’t easy. In fact, it is a challenge for most companies. There are many reasons for this – corporate culture, inertia, risk-aversion – but I think the biggest reason is “expertise.” The quote I have on my desktop wallpaper sums it up nicely:

“In the beginner’s mind there are many possibilities, in the expert’s mind there are few.”

– Shunryu Suzuki

I have this quote on my desktop because it’s a constant reminder that as I become more familiar with a technology or business skill, my ability to come up with innovative ideas about that technology or business area decreases. This is my totally unscientific thesis at a personal level; your experience may differ, but I suspect not by much. Since businesses are primarily just people doing stuff, the corollary is that businesses face the same issue – dearth of innovation due to expertise.

So if a business can’t look internally to its employees, where should it look for those innovative ideas that will propel it to the next level? (NO, the answer is definitely not consultants.) The best source of innovative ideas for your business is your customers and the best place to engage them for these ideas is online.

Many companies have discovered that the same concepts that work amazingly well on a personal and social level with FaceBook and MySpace, work equally well for business (albeit without any sheep being thrown about in the process). Creating an online community for your business is an effective way to engage your customers online and provide a direct channel to them, bereft of the hierarchical and departmental boundaries that stifle discussion and open dialog offline. This should not come as a surprise, after all “people want to connect with people; people want to help and be helped” (Study: Tribalization of Business). Chances are that if you follow some basic guidelines, you can very quickly and easily engage your customers and make innovation an open and collaborative process.

One company that has been successful in creating such an online customer community is ExactTarget. The company has been a long-time sponsor of the DotNetNuke project (thanks!). The “3sixty” community site it created for its customers using DotNetNuke Professional Edition is a prime example of best practices for creating online communities recommended by HiveLive, a SAAS provider of enterprise online customer communities. Since 3sixty was created, the site has become a key competitive differentiator for ExactTarget resulting in over 100 customer-suggested feature innovations into its product. You can get the straight scoop on how ExactTarget achieved this by attending the free webinar “ExactTarget: Using DotNetNuke to Build an Interactive Business Community” on Aug. 26, 2009 (download a recording of the video by following the link if you are reading this after Aug. 26).

While ExactTarget could have developed a custom ASP.NET solution for this site, it selected DotNetNuke because of its ability to easily integrate with existing web-based business applications while providing a robust platform for rapid application development. Let me stop myself right here and not get carried away discussing the merits of DotNetNuke as an excellent platform for building online communities. It is very tempting to look at creating such communities as a technology problem and delve into a discussion about features, API’s and such. But as Dion Hinchcliffe accurately points out in Twelve Best Practices for Online Customer Communities, “community is mostly not a technology problem.” Indeed, as he points out, platforms like DotNetNuke make it easy to create compelling communities. (If you are reading this on DotNetNuke.com, you are looking at the best evidence to support this claim.) Creating successful online business communities is more an exercise in adapting your business to a new form of customer engagement and creating the social architecture for such a community.

In order to succeed, here is a summation of HiveLive’s recommendations:

Best Practice #1: Build a community with clear goals in mind

Start with a narrow and tightly defined scope and develop the community structure from there. This is essential for rallying members and motivating them to contribute. Be prepared to expand the scope quickly as the community evolves.

Best Practice #2: Motivate your members

Online community members are power users, participants or spectators. Explore ways to keep power users engaged to ensure a steady stream of relevant and authentic content. This in turn will motivate others to play a more active role. Also, think of ways in which you can compensate participants. Compensation, does not have to be monetary – insider status, avatars, recognition, they all work.

Best Practice #3: Use Design Thinking Principles

Design Thinking is a process for practical, creative resolution of problems or issues that looks for an improved future result. Using this approach can establish ground rules and foster a culture of crowd-sourced innovation in an online community.

Best Practice #4: Build a Culture of Openness

Direct engagement through genuine interactions will yield significant benefits and convince more members to participate in the innovation process. Don’t try to control the conversation, listen more than you talk, and make sure the culture of openness is not just a façade. Although painful at first, such a culture is critical to the success of an online community.

Best Practice #5: Remain Dedicated to Continuous Improvement

View your online community as a journey, instead of a technology initiative with a defined end-point. Committing to a posture of cultivation will yield tangible results in the form of a steady flow of innovative ideas from the community. This also builds trust and gives members a greater sense of ownership as their ideas and suggestions are realized.

Has your company created an online business community? Do share! What were the challenges you faced? What did you learn from the experience?

If you have not created an online business community yet, hopefully this post and the webinar will give you some ideas that will help guide you in the process.

A Short Story About DotNetNuke

Fri, 07 Aug 2009 19:49:00 GMT

Skinning Portal Images in DNN with ImageSwap

Sat, 04 Jul 2009 05:34:00 GMT

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 script to each layout file in your skin:

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 script sample

DotNetNuke Professional Edition 5.1 - Content Approval

Tue, 30 Jun 2009 08:02:00 GMT

DotNetNuke Business Model and Product Roadmap (Part 2 of 2)

Mon, 20 Apr 2009 22:30:00 GMT

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:

Site forums
Site roadmap
Enhancement requests logged in Gemini
Feedback from site forms and surveys
Feedback from DotNetNuke team volunteers
Feedback from customers (of both editions)
Feedback from customer prospects
Feedback from ISV’s, consultants and designers in our ecosystem
Feedback from ISV’s and consultants not in our ecosystem
Feedback from conference and user group attendees
Analysis of competitive landscape
Industry, market and technology trends
Feedback from experts in Open Source, WCM and enterprise software
Feedback from investors
Experience and intuition

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:

Continued growth in the adoption of Community Edition is essential to the survival of DotNetNuke Corp. Open Source companies cease to exist if they don’t have a thriving community. Communities don’t thrive around products that are stagnant and not evolving or innovating. We want DotNetNuke Corp. to be successful, and therefore, ensuring the continued success of Community Edition is a strategic imperative for us.
We can’t put every feature with value only into Community Edition, nor can we put every feature with value only into Professional Edition. There is a middle ground and finding it is not an exact science. We have to balance our desire to have Community Edition adoption grow, with our need to build a sustainable, profitable business so we can pay our bills and continue to fund the project. The feature selection process outlined above, while subjective, is rational and driven by our prior experience nurturing the growth of this ecosystem.
If you happen to be one of those people with the concerns outlined above, do consider the roadmap for DotNetNuke 5.1 Community and Professional Edition below objectively. I trust that after reviewing the roadmap you will not be as concerned.

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.

DotNetNuke Business Model and Product Roadmap (Part 1 of 2)

Mon, 20 Apr 2009 22:28:00 GMT

Development of DotNetNuke 5.1 Community and Professional Editions is progressing at full speed. It took us quite a bit of time to analyze dependencies, evaluate resource availability, determine viability and clearly define scope. As a result, until now, we did not publish a roadmap for DNN 5.1. The lack of published and authoritative roadmap details and a general misunderstanding about our business model has caused some confusion in the community.

In this, the first of a two-part series, I will make an attempt to clear this confusion and bring clarity on two topics:

1) Our business model: I’ll explain our business model and how it underscores our commitment to Community Edition and the overall DotNetNuke ecosystem. This is the subject of my first post.

2) Product roadmap: I’ll review the research, planning and decision-making process on how the roadmap for both Community and Professional Editions is determined. Then I’ll outline the release 5.1 roadmap for both Community and Professional Editions. This is the subject of my second post.

Our business model

DotNetNuke Corp. has an “Open Core” business model. In plain English this means that our free, community product and our paid, commercial product have a common, free, Open Source Core. This begs the question, what exactly is the DotNetNuke Core?

The DotNetNuke Core refers to the base combination of DotNetNuke framework libraries and extensions required to have an operational DotNetNuke website. Any additional extensions included in the distribution, even if they are not enabled by default, are also considered Core extensions.

The Core thus consists of the DotNetNuke framework libraries; all providers; all administrative modules; all control panels; the Text/HTML module; the default skin/containers; all skin objects; and all widgets included in the DotNetNuke distribution.

Both Community and Professional Editions share this identical DotNetNuke Core, which is why our business model is called “Open Core.” Given this context, it is worth emphasizing the implications of this business model:

The Core is and will remain free and Open Source. This is essential for the continued success of DotNetNuke.
Any enhancements made to the Core framework libraries are ALWAYS available to both Community and Professional Editions.
Any enhancements made to any Core extensions are ALWAYS available to both Community and Professional Editions

On the topic of Core enhancements, there have been some questions about whether any will be made in the future. The answer is an emphatic “Yes!” This is clearly evident by reviewing the DNN 5.1 roadmap. Also consider that since 2006, over 95% of the Core development has been done by employees or consultants paid for by DotNetNuke Corp. Given the investment we have already made and the fact that the Core forms the foundation for both our products, continuing to invest in improving and enhancing it is the best decision for the company and the community.

Now, let’s examine each of the editions to understand how they are similar and different purely from a software standpoint.

The DotNetNuke Community Edition package includes the DotNetNuke Core and DotNetNuke Community Extensions developed and maintained by one of the many volunteer-based DotNetNuke Project teams. The result is a complete solution that is suitable for many different scenarios.

The DotNetNuke Professional Edition package includes the DotNetNuke Core, DotNetNuke Community Extensions and DotNetNuke Professional Extensions. The result is a complete solution that is suitable for mission-critical business scenarios where the desired level of performance or functionality is not achievable using only the Core or Community Extensions. In such situations, the user can purchase the desired extensions from a third-party, develop them in-house or opt for the convenience of getting a single package – DotNetNuke Professional Edition.

Let’s address the questions this raises:

Q: Why is it necessary for DotNetNuke Corp. to bundle its extensions into a separate package instead of making them available separately for purchase like other extensions made by third-party vendors?

A: Our target customer is a business that is looking for a fully-integrated, supported solution and not a build-your-own package. By offering a packaged solution, we address this need. A good analogy is the automotive industry. Consumers do not have the time, skills or resources to assemble a safe and reliable car even though parts are available. They prefer to buy a fully assembled, tested vehicle that has a warranty and which they can start driving immediately.

Q: Does this mean that DotNetNuke Corp. will no longer enhance any of the Core Extensions?

A: That is certainly not the case. Since we have an Open Core business model, we absolutely must continue to enhance the Core Extensions as they are vital to the continued success of both DotNetNuke Community Edition and DotNetNuke Professional Edition. For example, our roadmap for this year includes significant enhancements to the user experience of Core Extensions the scope of which is greater than any prior effort to improve DotNetNuke’s usability.

Q: What types of extensions will DotNetNuke Corp. include with Professional Edition?

A: In general, we will include extensions that are clearly of interest to larger, more mission-critical business. The feature areas will include advanced security, performance, commerce and scalability.

Q: Can third-parties build extensions for Community Edition that provide similar functionality to DotNetNuke Professional Extensions?

A: Of course. Since the DotNetNuke Professional Extensions leverage the extensibility built-into the DotNetNuke Core that is common to both editions, third-parties have an equal opportunity to build similar (or better) extensions. This is no different than what many third-parties are doing today given the vast number of extensions -- free and commercial -- already available to DNN users.

Q: Will source code for DotNetNuke Professional Extensions be included with Professional Edition?

A: No. Source code will not be distributed; however, it will be held in escrow for Professional Edition customers.

Q: Will DotNetNuke Professional Extensions ever be available in Community Edition?

A: Yes. In some cases we may choose to migrate specific extensions from Professional Edition to
Community Edition.

Q: Will third parties be able to build functionality on top of DotNetNuke Professional Extensions?

A: Yes. However, at this time there is no extensibility provided in DotNetNuke Professional Extensions. This does not stop ISVs from building product versions which are targeted at Professional Edition customers.

To summarize:

DotNetNuke Corp. has an Open Core business model
The DotNetNuke Core will continue to be enhanced, benefitting both Community Edition and Professional Edition users
DotNetNuke Community Edition is applicable to most usage scenarios
DotNetNuke Professional Edition is applicable to larger, more mission critical business environments

Hopefully this post answered many of the community's questions about the DotNetNuke Corp. business model, specifically as it pertains to the similarities and differences between DotNetNuke Community and Professional Editions.

In my next post – DotNetNuke Business Model and Product Roadmap (Part 2 of 2) – I will 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.

Blog Platform Switch and Makeover

Mon, 02 Feb 2009 05:18:00 GMT

When I first started blogging in 2004, I had to decide which platform to use. There were some hosted blog sites available, but my rule of thumb #1 is that if it's important to me, then I need to have full control over it and not be at the mercy of some other provider. I need to have unfettered access to make changes, enhancements and backups. At the time, the best .NET-based Open Source blogging platform I could find was DasBlog. I have used it since and it has served me very well. However, the more entrenched I got with the DotNetNuke project, the guiltier I felt due to rule of thumb #2 -- eat your own dog food. I desperately wanted to switch my blog to DotNetNuke but faced three obstacles:

1) Migration: As far as I know, there was no simple way to import everything from DasBlog to the DNN Blog and maintain fidelity.

2) DNN Blog: While the DNN Blog software is good, it lacked a few key attributes that I personally felt very strongly about -- excessive use of tables, inability to completely control the appearance using CSS and inability to control syndication URL's. There were a few other minor issues, but these were the primary ones.

3) Time: Just did not have enough of it to make the switch.

Last year, I had been collaborating with Antonio Chagoury, the DNN Blog Project lead, and had started to make enhancements to the DNN Blog module. However, my work got really busy and I was unable to get these changes done. Meanwhile, the Blog project team continued to make progress and I found my code to be out of sync with the project code. So here I was with some working enhancements to the Blog module, but not able to easily integrate my changes back into the project.

Over the Christmas/New Year break, I made a decision that I would switch my blog to DNN within the month of January. Once I made this decision, things got easier as I work best under deadline pressure. Spending a few hours each week during the past month, I did the following:

Setup a DNN5 site for my blog
Locally reconciled my changes of the Blog module with the code that was in the repository
Wrote a small script to import from DasBlog to the DNN Blog
Implemented many enhancements to the DNN Blog
Created a custom skin for my blog which uses some of the new widgets I created for DNN
Fully ported my blog to the DNN platform

The first three were simple and did not take much time at all. I spent quite a bit of time on the remaining three. Here are the details:

Blog Enhancements: I made the following enhancements:

Templating -- Used the DNN token replacement engine to create template support for Header, Item List, Item Detail and Item Print. All templates support the standard DNN tokens and some custom ones. For the Header template, the permissible tokens are (using { } in place of [ ] to prevent replacement in this post):

{BLOG:TITLE}

{BLOG:OWNER}

{BLOG:DATE-CREATED}

{BLOG:DESCRIPTION}

{BLOG:RSS-URL}

{BLOG:RSS-IMAGE-URL}

For all other templates, the tokens permissible tokens are (using { } in place of [ ] to prevent replacement in this post):

{BLOGITEM:TITLE}

{BLOGITEM:AUTHOR}

{BLOGITEM:BYLINE}

{BLOGITEM:BYLINE-DATE}

{BLOGITEM:DATE-PUBLISHED}

{BLOGITEM:MONTH-PUBLISHED}

{BLOGITEM:DAY-PUBLISHED}

{BLOGITEM:URL}

{BLOGITEM:PRINT-URL}

{BLOGITEM:BLOG-TITLE}

{BLOGITEM:BLOG-URL}

{BLOGITEM:BLOG-CATEGORY-TITLE}

{BLOGITEM:BLOG-CATEGORY-URL}

{BLOGITEM:BLOG-RSS-URL}

{BLOGITEM:BREADCRUMB-HYPERLINK}

{BLOGITEM:TRACKBACK-URL}

{BLOGITEM:RSS-IMAGE-URL}

{BLOGITEM:SEARCH-RANK}

{BLOGITEM:EDIT-URL}

{BLOGITEM:EDIT-HYPERLINK}

{BLOGITEM:COMMENTS-HYPERLINK}

{BLOGITEM:COMMENTS-URL}

{BLOGITEM:COMMENTS-COUNT}

{BLOGITEM:MORE-HYPERLINK}

{BLOGITEM:TAGS}

{BLOGITEM:SUMMARY}

{BLOGITEM:CONTENT}

These tokens make it possible to format the blog list and detail views to be customized precisely with nothing extraneous. I thought about adding a template for RSS, but decided against it to keep things simple. I did however modify the RSS template to always show full content as RSS feeds that show only summaries are a pet peeve of mine (I will not subscribe to any blog that does not post full content in the feed).

CSS-enablement -- Everyplace that I found an HTML table, I removed it and replaced it with the equivalent DIV+CSS code and enabled simple URL actions instead of Javascript-driven postbacks. This reduced the HTML footprint considerably.

Archive -- I added entry counts to each month in the Archive list. I also added the ability to turn off the calendar mostly because from a user experience standpoint, it is not much use. Between the Archive list and search, the bases are covered.

Tagging -- We are currently working on core-provided tagging support, but I wanted to have some quick tagging support and display a tag cloud. My solution -- I created a setting whereby you can specify an HTML element that indicates a word or phrase that should be a tag. The default element I picked is "cite". Using the standard HTML editor, I can simply highlight words and apply "cite" to them. The tags are not stored anywhere separately. When a post is rendered, the tags are extracted with a regular expression and Technorati microformat tag links are automatically created. The same code is used to create a composite tag cloud using jQuery. Since tags don't change too often, with caching this is a simple solution that can be upgraded to the core tagging engine when it is available with minimal effort since there is no data to worry about.

Tab Targeting -- I wanted to display my blog listing on one or more pages, but always wanted to direct the user to a single blog page for details. The solution I implemented for this is a setting called LinkTargetTab. In the blog's settings, you can choose the page where all links should go. I can thus have a listing on the Home page of my blog site, but have the detail and editing occur on the Blog page.

Syndication -- I implemented a setting that allows you to specify the Base Syndication Url such as http://feeds2.feedburner.com. All syndication links are then automatically created by appending the name of the blog/child blog to the base URL as appropriate.

Comments -- I wanted to use Disqus for comments on my blog. Since the module's comments can easily be turned off, adding Disqus was a simple matter of adding the embed code to the Item Detail template. (The same applies for Sharing...I just added the code for ShareThis to the template.)

I implemented a few other minor enhancements, but the above list constitutes a bulk of them. At the time of this writing, the blog I am using has these enhancements. There are probably a few rough edges, but overall, things seem to work. Now that I am here, I'll get this code over to Antonio and the Blog team so they can decide if any of it is desirable for the Blog Project. (I will not post these enhancements for general download as I think the Blog Project team is best equipped to review the code and determine if the changes should be merged. Also, I do not want to be in a position of supporting the code.)

Custom Skin: I modified the appearance of the standard DNN skin slightly to meet my branding choices. I did make a bunch of changes under the hood that make it very different structurally from the default DNN skin. These changes are --

CSS Layout -- I used the built-in DNN super-stylesheets to create a table-less CSS layout.

Mobile-optimized -- I used the new DNN5 RelocationWidget to optimize the skin for search-engines and mobile devices. The entire header and menu block actually appears at the end of the page, but is visually made to appear at the top using the RelocationWidget. Mobile devices should also see a simpler menu system.

TechBubble Blog: Now that my blog is fully ported to DNN, I am very excited to be able to create and share sample code with working examples right here on the site. For instance, I am using the DNN EmbedWidget on the Photo page to display my Flickr photo stream (not much to look at yet).

Overall, the time and effort it took to get here was well worth it. I am VERY happy to be using DotNetNuke for my blog.

Milestones on a Rewarding Journey

Tue, 25 Nov 2008 08:00:00 GMT

Today is a big day for me for two reasons:

1) One year ago today, I moved with my family to Silicon Valley from Washington, DC, a city we love and miss very much.

2) Also today, DotNetNuke Corp., the company I co-founded, announced that we have closed on our Series A round of venture funding.

Adjusting to Silicon Valley has had its challenges. Having to drive everywhere after getting around mostly on DC's Metro was the hardest adjustment. Our friends, DC's breathtakingly beautiful monuments, abundance of fantastic (and free) museums and overall character of the city are all missed. That my daughters were both born at George Washington University hospital in DC means that my family has an unbreakable bond with the city and we expect to live there again in the future (perhaps when I run for Congress, a dream of mine).

The past year in Mountain View has been a year of discovering California, rekindling old friendships, making new ones, enjoying great weather and the many playgrounds in this area. We are slowly adapting and beginning to enjoy what Silicon Valley has to offer. I'll be candid, reaching the funding milestone is certainly going to make a difference in terms of quality of life.

All startup entrepreneurs make sacrifices to see their dreams come true. In this business, it's called "skin in the game." I can say unequivocally that my co-founders (Shaun Walker, Joe Brinkman and Scott Willhite) and I have a lot of skin (and probably additional layers) in this game. Building a company based on a free, Open Source product is challenging, to say the very least. But we had a vision and continued to persist despite the challenges we encountered. Raising growth capital was one of them.

In the summer of 2007, Shaun and I made several trips to Silicon Valley to meet with VC's. Everything that followed was textbook venture fundraising. We had many positive meetings but no takers. Our team quickly realized that we were missing three things:

Feet on the ground. It is expensive to travel to Silicon Valley every couple of weeks for meetings (Note: Most VC's that fund Open Source companies are located in Silicon Valley). It is also a huge disadvantage that you cannot meet with an interested investor at short notice. And finally, missing out on the powerful network effect of Silicon Valley is a serious impediment to raising capital here.
Solid Business Model. While we had achieved tremendous success as the #1 Open Source web project on the Microsoft stack, the business model we articulated to VC's was not polished enough to merit their serious interest.
Experienced Advisors and Management. VC's invest first and foremost in people. Having a solid management team in place is critical for the success of any company, and more so for venture-funded companies. While our team is very strong technically, we did not have the depth and breadth of business experience needed to take the company to the next level. (While DotNetNuke Corp. is the fourth company I have founded/co-founded and the third of my companies to receive investment capital, I still have much to learn.)

We decided to address these three issues as best and as quickly as we could.

Since I had the lead role in the fundraising process and did not have significant constraints on where my family lived, moving here was a no-brainer for me. While it was a major move, I was determined to do what needed to be done to ensure the success and longevity of our business. I did not see any way we could be successful at raising capital without having a local presence in Silicon Valley. Savi, my wife was supportive as ever in this decision. The other co-founders and I agreed on a course of action. I took on the role of CEO with a charge of focusing on raising capital and prepared for the move.

But there were more challenges. Savi was pregnant with our second child due in late October. Gia, our first daughter, was three years old at the time and we had to find a Montessori in Silicon Valley that met the standards for teaching and cultural diversity that we had become accustomed to in DC. Also, since we paid our own health insurance, we could not make the move until after the baby was born, otherwise we would have to assume the full cost of the delivery -- totally impossible for us (and most people, I would imagine). We decided to wait until January 2008 to move.

We made a couple of trips to the Bay Area, checked out schools and settled on a Montessori in Mountain View. With that done, it was now time to find housing. We did not find anything suitable during our visits. It was extremely challenging trying to find housing in Silicon Valley that met our requirements remotely from DC. A couple of these requirements greatly restricted our options and I remember checking CraigsList every 20 mins., all day, hoping to find a place we could call home. We were getting very frustrated and then things took a turn for the worse.

On the evening of Sept. 5, I accompanied Savi for a routine pre-natal check-up, while my parents who were visiting from India at the time, watched Gia. The news we got from the doctor was scary. We were told that we had to go straight to the hospital as our baby was going to arrive five weeks ahead of schedule. With a great sense of fear, we got Savi admitted and began a very long night. In the morning, the chief resident told us that the baby was in distress and they had to deliver. Kaamya was born on Sept. 6. I got to hold her for one minute and then she was taken to the NICU (Neo-natal Intensive Care Unit). The next 12 days were a blur. Savi and I took turns keeping her company in the NICU hoping and praying that she would be OK. Our prayers were answered. Today, Kaamya is a healthy, happy and active one-year-old.

After Kaamya's birth, we were able to move to Silicon Valley a little sooner than planned. Housing was still an issue. On a whim, Savi looked at short-term rentals, and found a place in Mountain View that matched all our criteria, but was only available for 3-6 months. My brother-in-law who lives in San Jose checked out the place, we found it acceptable and signed the lease. We decided that we would move immediately after my Las Vegas trip for Open Force '07.

Thus, on Nov. 25, 2007, we arrived in Silicon Valley.

I immediately began connecting with and setting-up meetings with people/firms to enable progress on the fundraising front and also to identify and work with business advisors and potential additions to our management team. Larry Augustin, founder of VA Linux and one of the most respected names in the Open Source world, was already our business advisor. He referred me to several exceptional people and firms, one of them being Navin Nagiah. At the time, Navin was CEO of Cignex, a company that specialized in services around Open Source CMS solutions.

I met Navin at a Starbucks in San Jose on Dec. 18, 2007. Almost immediately, Navin saw DotNetNuke's tremendous potential. I too saw how Navin's experience in the Open Source Enterprise CMS space would be valuable for DotNetNuke Corp. We started meeting regularly 2-3 evenings a week. Within a couple of months, Navin formally became our business advisor.

Working closely together, and with the support and input of the other co-founders, we developed a solid business model and investor pitch. We were a little slow off the blocks, but with all three of the missing items addressed, we were confident that getting funded was an inevitability. We made rapid progress through the summer culminating in today's announcement. (I have been working on collecting my thoughts around what we learned in the process and will blog about it in the future.)

I am incredibly gratified to have reached this major milestone. There are many, many people who made it possible, many of them are behind the scenes. To all of them, I am grateful. A special thanks to my family and the families of my co-founders, who stood by us and supported us through thick and thin (mostly thin) as we made it to this point. And thanks to everyone in the DotNetNuke community who have time and again demonstrated support for DotNetNuke Corp. and confidence in our product -- DotNetNuke.

This is the first step in a journey. We have a great team and I am looking forward to doing my part in building a very successful and profitable company while making DotNetNuke the platform of choice for .NET-based websites. I am very excited for the future.

Below is a link to Shaun's keynote from the recent DotNetNuke OpenForce '08 conference. It will shed some light on where we are and what our vision is for DotNetNuke Corporation.

DotNetNuke-OpenForce-KeyNote.pptx (1.45 MB)

This is Our Moment

Tue, 04 Nov 2008 08:00:00 GMT

This is a defining moment for America and I am proud that my country has chosen such a transformational figure as Obama to be its next President.

I was moved and inspired by his speech tonight and look forward to doing my part in moving the country forward. As a father of two little girls, I found his future-looking questions most inspiring:

"So tonight, let us ask ourselves - if our children should live to see the next century; if my daughters should be so lucky to live as long as Ann Nixon Cooper, what change will they see? What progress will we have made?"

After eight years of failed leadership, I am very excited and hopeful for the future of this great nation that I love.

"This is our chance to answer that call. This is our moment. This is our time - to put our people back to work and open doors of opportunity for our kids; to restore prosperity and promote the cause of peace; to reclaim the American Dream and reaffirm that fundamental truth - that out of many, we are one; that while we breathe, we hope, and where we are met with cynicism, and doubt, and those who tell us that we can't, we will respond with that timeless creed that sums up the spirit of a people:
Yes We Can. Thank you, God bless you, and may God Bless the United States of America."
Here's an excellent analysis of the speech by Bert Decker:

Transformational Election - Transformational Speech!

Enabling a Pre-existing Project as a WebRole in Azure Solution

Sat, 01 Nov 2008 08:00:00 GMT

In trying to use an existing VS2008 Project as a WebRole in a Windows Azure Solution, I discovered that the project did not appear as a candidate for selection from the Roles > Add > Web Role Project in solution menu. All the Azure documentation indicates that there is no special requirement for a web project to be a candidate for Azure, so I found this to be odd. The solution, as it turns out, is pretty simple:

1) Open the existing project's .csproj file in a text editor.

2) Add the following two lines of code anywhere within the first element:

Web
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\ServiceHosting\v1.0@InstallPath)

Reload the project and it now becomes available as a WebRole.