While I completely agree with the recent focus of DotNetNuke on the Cloud, Mobile and Social aspects of DotNetNuke V6 as a way to increase the adoption of the product, I believe there is an alternative focus that the more technical among us can consider. This “other” focus is centered on strategic changes to the framework of DotNetNuke – the underlying bones.

For many years, DotNetNuke was referred to as the DotNetNuke Framework that supported the creation of a Content Management System. For end-users, the term framework was lost – DotNetNuke was a Content Management System. However, that framework provided a standardized way to build web pages with a defined plug-in infrastructure, security and underlying database. Over the years the framework aspect of the product(s) has been down played.

More...

XMod Pro 4 is packed with new features. Among them is a brand new ability to leverage the customizable, highly flexible forms of XMod Pro to create a custom login form for your DNN website.

Since WillStrohl.com has been up and running, its primary function or purpose has been to host my personal blog about many things, but mostly DotNetNuke.  During this time, it has always run on the “core” Blog Module.  Say what you want about the core blog module, but it has always been a very functional way to build and maintain a blog presence on DNN.  There has always been a way to accomplish anything you wanted using it, whether it was adding other modules to the page, adjusting the design, or simply recompiling the module with any adjustments I’ve needed.  I’ve traditionally had time to do this, all with the intention of helping to make the blog module a better module.  Though, I recently changed blog modules, and that’s what this article is about.

Disclaimer:  First, I work for DotNetNuke Corporation, if you didn’t already know.  So, even though I have it posted everywhere, I should mention that this blog entry contains comments and opinions that are my own, and have no endorsement whatsoever from DNN Corp.  Second, I am doing a thorough write-up of my experience with a specific blog module.  While I feel that I have tried to not make this come off as an advertisement, I want you to know outright that I am not advertising for them. 

The “core” blog module has had a very exciting, long, fun, and rough past.  At some points it was simply misunderstood.  Other times it was missing features.  And yet other times, it was laying dormant, waiting someone to give it some long overdue TLC (tender loving care).  Such is the nature of a purely open source project.  It’s always at the mercy of those that hopefully have the necessary time needed to keep it updated.  I’ve always been very patient with the module myself because I love doing things with “core” modules first before going to the ecosystem.  After all, how else can the project know where and how to proceed if people are not using it and offering feedback, requests, fixes, code, and more?

Well, these days I have much less time to dedicate to helping that project than I used to.  I mean, I already run or contribute to more than 15 other projects on CodePlex.  This entire time I was basically working on a fork of the blog module anyway, since I had some specific requirements (or ideas) about how I best wanted my blog to do things on my site.  After all, this is one of the many benefits of using an open source module to begin with.  Unfortunately for the module itself, I needed to take that off of my plate, so the search for other blog modules began…

The Blog Selection Process

The DotNetNuke ecosystem has several modules that are either built to support blogging, or can be configured to support a blog.  Whether it comes from the Store or the Forge, you’re given many quality options.  Among them are some really great choices, and even some very flexible ones that aren’t a blog out-of-the-box, but can be after some configuration (some requiring more configuration than others). 

After a bit of research, I decided to use Live Blog by Mandeeps.  Mandeep Singh heads up Mandeeps, has long been in the DotNetNuke community, and their solutions have always had a positive reputation during this time.  All of their modules have regular releases and very responsive support.  I tested this through the Store before moving forward.  This was the first step to feeling better about choosing Live Blog as my solution. 

Next, with very few exceptions, all of his extensions that have been reviewed continue to have 5 star reviews.  Whether I looked there, on twitter, or in the DNN forums, Mandeeps overall has had great feedback from those that use their modules.

The final piece that really sealed the deal was that it seemed that no matter which blog solution I was coming from, Live Blog had the hardest part of the migration path already solved for me.  It would simply import all of my blog posts and comments for me, maintaining the original integrity of by blog with nearly no effort at all.  I tested this several times in a staging environment, and it always worked great!  This alone is highly impressive.

The three components mentioned above were the critical first steps in my selection process.  Mandeeps Live Blog had very responsive support, great reputation & reviews, and it allowed me to easily migrate my content to it.

My Feature Requirements

Not every blog is created equal.  Although many blogs are created or used for the same general purpose, they all have their own agendas and goals.  My main goal is SEO.  I want to make sure that by blog entries can be found by people, regardless to whether those people were coming from Google, Bing, or {Gasp!} Yahoo.  Yes.  Yahoo is still around.  ;)

Since my main goal was SEO, I needed a solution that practiced some very specific key things in order to not hurt whatever goodness my SEO had already attained.  I needed H1’s and H2’s in the right places, great looking page titles and URLs, categories with friendly URLs, site maps, and so on.  Live Blog has all of these features and more. 

Comments are important to any blog.  I have wanted to transition to use Disqus for my blog comments for a long time because their comment engine is unmatched in capabilities and stickiness.  Unfortunately, I’ve either been too busy or too lazy to write the code to export my comments using their WP standard.  There were two great things about Live Blog in this area…  First, it already has them implemented as a forward only feature.  However, a very recent release also allows you to export your existing comments to Disqus, allowing you to choose to use their comment engine at any time!  Suh-weet!

I also track my own feed status through Feedburner.  I have really grown to like this service and didn’t want to move away from it for my RSS links.  Live Blog doesn’t get in the way here at all.

The final requirement I had was to be able to make the new blog fit into my own design.  Luckily, my design isn’t terribly complicated.  Regardless though, the template feature in Live Blog makes generating your own template to suit your needs incredibly easy. 

Any Bells or Whistles?

If you’re not familiar with the term “bells and whistles,” it is simply a slang way of talking about really cool add-ons or features.  Live Blog has plenty of them. 

Beyond what I’ve already mentioned, you get some really cool things like deep Windows Live Writer integration.  You can choose your own URL structure for each new blog post.  It has an easy to use control panel-style settings view.  It will automatically “ping” some common ping services for you such as blog search and feedburner.  You can simply paste in social bookmark code from sites like AddThis or ShareThis.  It will also allow you to automatically post new blog entries to twitter, but I have to admit that I haven’t tried using this feature yet.

I am sure that you will find some other things to be your own bells and whistles, but these few things are what stood out to me.

Is It Missing Anything?

Unfortunately, like with many 3rd party extensions, Live Blog has the need to fill the use case requirements of a large range of customers, including customers on many different versions of DotNetNuke.  As a result, this prevents Live Blog from implementing newer DNN features and APIs, such as editing pop-ups, client dependency framework, integration with the taxonomy API, cloud folder providers, mobile-friendly displays, and more.  This is not a deal-breaker (yet), but it will likely be frustrating for me moving forward since I always like to be on the latest version of DotNetNuke.

Did I Have Any Problems?

First, I would like you to know that I tested this module thoroughly in a staging environment before deploying this on my own website.  And even then, I made sure to retest everything since I was on my production website.  I highly recommend that you do this as well.  You never know what might creep up as a problem if you don’t.  I was able to do this side-by-side on my production site with the core blog module still actively in use.  However, in order to test on my own site and to mitigate any need to re-sync the data, I made sure to cease any blog posts during the testing phase, and I turned off comments during this time frame as well.  This made the migration path one that only needed to be followed once.  I wouldn’t categorize this as a problem, but you definitely need to be aware of this as well.  Otherwise, you will need to manually import and new blog posts or comments when you do the same thing.

There was one specific problem.  Unfortunately, the URL structure in Live Blog did not match that of my original URLs.  This is not an uncommon issue when switching module vendors or creating a new section on your website.  In this case, the original URLs used EntryId to denote the blog id number used to generate the blog post page dynamically in DNN.  Live Blog does this same thing, but uses PostId instead.  Unfortunately, there is no way to change this in Live Blog.  Along the same lines, the imported blog content did not respect the original ID numbers.  So a blog post that was previously 123 could be another value like 119 after import.  Finally, the URLs that are generated by Live Blog follow a different set of rules when created.  Basically, this could result in a scenario where your new URLs are essentially very different from their original URLs.

Initially, I looked to IFinity’s URL Master to fix this since I use this on my site, but without a bit of development by Mandeeps, a solution wasn’t available here.  However, if you do have a vendor ready and willing to do so, Ifinity has a module provider solution that allows you as a module vendor to map and generate URLs on sites that use URL Master.

At the end of the day, I couldn’t use a built-in or existing feature to re-map URLs to ensure that when search engines visited or visitors clicked on existing inbound links, the visitor would not only get the content they were looking for, but they would also get the SEO-friendly HTTP 301 redirect.  So, in order to fulfill this requirement, I ended up writing a slick little module called Simple Redirect.  It’s sole purpose in life was what you just read – and, to keep things simple in doing so.

What About the Future?

One of the things I am going to miss deeply is the ability to immediately support the latest and greatest features in DotNetNuke for the reasons mentioned above.  However, the convenience of being able to not need to maintain a separate code base right now is too great to ignore.  Mandeeps has been incredibly responsive to feature requests so far though. 

Summary

So that’s it.  I wanted to have a supported blogging solution that didn’t require me to have a forked and self-maintained version of the code base to achieve my blogging platform requirements.  I also wanted to see active releases that incorporated more and more features without the need for me to merge my codebase.  In looking for possible blog solution providers that could give my site what it needed and more, I found and moved forward with Live Blog.  It was able to meet all of my needs, has great support, actively releases, and is extremely reactive to feedback.  At this point, I couldn’t be any happier with my chosen path.

It is quite often that when working on a new version of a site that you will have a development, test, upgrade copy of the site that might be around for a while.  It is also possible that if you are working for a third-party that you might stage client sites on your server for a period of time before go-live.  At first glance this all seems common place and not something that you would be concerned about.  However, that is not the case.  Search engines have become overly aggressive in indexing sites, including those that have no direct back links but have been e-mailed to individuals or similar processes. In this post I'll discuss some important considerations when working with these "non-production" installations to help you ensure that search engines will NOT index the content and cause confusion.

On June 2nd, DotNetNuke Corp. will be releasing DNN 6.2. I doubt the numerology is lost on anyone. This year, they've chosen to announce this new release at the Day of DotNetNuke (DoDNN) being hosted by the Charlotte DotNetNuke User Group (QCDUG).

It's not surprising the QCDUG is hosting the event this year. They're group is really gaining traction in the area and brings a lot of positive energy to the DotNetNuke community.

If you've never been to a DoDNN and you're anywhere near Charlotte, NC, you should definitely go... free sessions, free networking, and free food! It's a fabulous deal. Of course, the only way these events can be free is if they find sponsors.

I'm happy to announce the DNNDev.com is proud to support the QCDUG and DotNetNuke by sponsoring the Day of DotNetNuke. So, check it out and eat some of the food we helped pay for :)

More ...

Since there have been so many additions in the latest major release of this best-selling form application builder for DotNetNuke, we thought it would be best to cover them in serial fashion. In this series of blog posts we’re covering the major new features in XMod Pro 4. In this installment let’s look at the brand new code editor.

With the release of XMod Pro version 4.0, we've modified our licensing to make it simpler and more straightforward.

My blogging has been a bit patchy in this first quarter of 2012, as has my open-source output.  The reason for this is that I have been involved and working on a new startup project that should hopefully launch soon and prove to be a big success.

The investors behind the project hadn’t done a web startup before, so they obtained the advice of the first person they found. I don’t really know the history behind this choice, and it scarcely matters now anyway. By the time I arrived, technology choices were in granite and the runway end was fast approaching.

Upon arrival I was disappointed to find out that this was what I call a ‘scratch build’.  The first person on the project literally went into Visual Studio and said ‘New Project…’.

The first question I asked was ‘did the original person who chose this technology consider using a CMS of any type?’.  The answer was ‘Yes, but it was ruled out’. 

Again, there is little value in turning over old rocks when there is a project to finish and the answers make no difference to the outcome of that project.  So I have left it at that.

But I wanted to do a little analysis of this in case the topic ever comes up again with anyone else.

The true cost of scratch building

When you get to see the invoices for time that get paid to developers for building the different components of a fully functional subscription-based website, you get a good insight into how much ‘scratch building’ costs.

What I have done is go through and develop estimates of how much time has been spent developing different subsystems.  Note that none of these subsystems are the actual bulk of the work.  They are just the peripheral bits and pieces that go into the bulk of sites of this type.

As my personal CMS of choice is DotNetNuke, I’ll consider some of these features alongside their DotNetNuke equivalent:

Built Feature	DotNetNuke	Difference / Notes
Membership System*(login,register,forgotten email, etc) Approx Time Taken: 60 hours of development time, email templates, custom mail sending code, skinning	Built-in. Skinnable. Templated Emails. Approx Time needed: 8 hours of installing and editing emails	Additionally, DotNetNuke has option of custom login modules. 52 hours longer Probably still more bugs to find.  May yet require Facebook login integration or similar.
Scheduling System Service to run scheduled tasks in the application. Approx Time Taken: 15 hours of development for a Windows scheduled service, configuration to make scheduled payments, send emails, etc	Built-in. Includes reporting and control. Approx time needed: 0 hours	The DotNetNuke scheduler doesn’t require any extra software to be installed on the webserver. 15 hours longer
Event Log Implementation of text-based server log using open-source component. Approx Time Taken: 10 hours of implementation	Built-in.  Easily extended for custom applications through creating new event types. Nothing to build, all exceptions captured and logged, custom logging done in one line.	The DotNetNuke event log includes the ability to view remotely through the admin pages of the site, and can be filtered for different types of events. 10 hours longer
Design Implementation of MasterPages design.  Conversion of designer-specified Html into .aspx pages. Approx Time Taken (excluding designer) 40 hours.	Install skin through menu and apply to pages as needed.  Completely separate from code. Approx time needed 8 hours (to refine and apply to different pages)	DotNetNuke skins can be developed by a designer in Html and then converted by the platform itself into a DNN Specific skin. 32 hours longer.
Menu System Design and implementation of a 4-level menu system and breadcrumbs for all pages. Static and requires config changes to add/remove pages. Approx Time Taken 40 hours	Built-in.  New choices in providers such as Mega-menu. Approx time needed 1 hour	There are many different menu styles to choose from.  Menu designers can quickly and easily setup the styles.  From then on, you just choose which pages go into the menu, and where they go. Easily adjusted by the owner of the site. 39 hours longer
Content Display Creation of a way to allow authorised end users to edit site content. Requires separate WYSIWYG Html editor and FTP program. Approx Time Taken (excluding authoring content) 35 hours	Built-in, including different content for different authentication levels. Approx time needed: 0 hours	DotNetNuke Professional versions include a content staging solution for approving content for live sites. 35 hours longer

*note: the system is using the same asp.net Authentication provider that DotNetNuke uses.  This saves a significant amount of time, but there is still a lot of work in plugging all the ASP.NET components into an overall site, and refining the plainly-awful default ASP.NET designs.

There is more I could list.  Search engine sitemaps.  Analytics integration.  Caching for performance. Administrator control panels.  User administration – if you want it, it all has to be built while the CMS packages it all up for you, tested, debugged and ready to use.

To save you adding up, the calculated extra time taken is 183 hours.  Even to me, this sounds very conservative, as I’m just extracting the information in a rough manner from management reports.

But let’s turn that into dollars and time, the two singularly most crucial data points for any startup.   Let’s assume you can average a developer hour at $100/hr – that is an extra $18,300, and close enough to 5 weeks of extra time.

Some people in large organisations might laugh at that- $18k is probably their stationery bill – but in a scrappy small startup watching the pennies it is an enormous amount.  More crucially, every week the product isn’t launched is every week revenue doesn’t come in, and gets closer to the time when the runway end appears and the investors get nervous.

Where does the platform really end?

When building a project like this, it’s amazing how cheaply a site like this can be put together.  A similar startup ten years ago would have needed a 7 figure bankroll to get the same amount of functionality in the same amount of time.  Open source libraries, Microsoft helper code – it all helps to put something together quickly.  We’ve leveraged jQuery and jQuery UI, used Knockout.js to give great UI interactions, leveraged email and payment provider libraries to speed up things immeasurably. 

The point here is that when you’re already using open-source libraries to speed up development and improve quality, then it’s bizarre to draw the line at the actual project itself.  Everything on the web runs on a huge stack of layers, so, in my view, it isn’t productive to dip down and build one more layer when a suitable candidate is there.  Nobody actually contemplates writing their own version of jQuery now, so why the actual Web Application?

But - It’s more than the cost

At this point, someone who was sceptical of implementing a CMS as a base for a startup might reasonably come back with ‘yes, but how much time would adapting the design to the CMS have cost’.  This is a fair point and one that needs expanding.  If you start with CMS-inexperienced developers, you may find that this time difference is soaked up in the developers trying to get their head around building an application on top of a CMS, instead of just creating a new codefile every time they need a new feature.

It doesn’t need to be like that, though.  The pool of developers skilled in a platform like DotNetNuke is pretty vast, and pretty deep.  And even if you’re a bit green, there are endless online forums, Q&A and other resources to tap into.   Code is code, no matter where it is written, so adapting to a different way of display is very low cost.

My hypothetical sceptic might come back and say ‘but yes, now you’re tied into the project’.  This is true.  Your future and that of your donor CMS are now one and the same.  But that is why you would choose and open source solution like DotNetNuke.  Even if the entire project disappeared off the face of the Earth tomorrow, you’d still have all of the source code, all of the things required to build it, and you could continue to move forwards.   But I’ll throw it back the other way, without a major platform, you don’t get any new features for free.  You don’t get lots of people finding security problems and patching them for you.  You don’t get a vibrant developer community trying to push things forwards continually.

A scratch-built solution has a talent-pool of a handful of developers deep.  When one of them walks out the door and onto other pastures, a ton of knowledge leaves with them.  This type of hidden reef is impossible to calculate in terms of cost, but it can be quite significant.

It’s also about the future

Already, the project is thinking about the future past launch day.  If all goes well, there will be plenty of site members and plenty of activity.  It’s about then that new ideas for site features will start popping up.   What about a company blog?  How about some social features to let users of the system compare notes, talk to each other, build a community?    With a scratch-built site, it’s back to square one.  With the authentication system built in, trying to tie in a stand-alone forum system would come across as clunky and poor.   Creating single-sign-on between different codebases is difficult.  Harmonising design is troublesome. 

And that’s when a CMS like DotNetNuke really pulls out into clean air.  In the next couple of months, the platform will release the long-awaited Social Features and a new Services layer.   There is no way an individual team can possibly compete with a team of fulltime developers working on a single feature like this alone.  The startup site could really use some of those social features like the new Journal module.  But there is no way it is ever going to happen, save maybe for a buyout by Facebook like some others.

A Virtual Comparison

Perhaps the best way I can put it is this: if two teams funded by two different investors worked on this same project, and one decided to use DotNetNuke as the base, and the other decided upon a scratch build, the one based on DotNetNuke would be to market by now, with more features and less bugs.  And they’d have extra cash saved over for promotion.  They’d even have a ready-built community to show their new site off to for feedback and perhaps the first customers!

It’s pretty obvious to me which one would be the eventual winner.  The ‘Not Invented Here’ syndrome is a costly one to acquire.

So I’ll ask the question again, in case you’re just starting out and chewing over this question : You are going to use a CMS for that startup, aren’t you!

More ...

It’s always been a topic, but even more so recently…  People are asking more and more about various things that relate to public speaking.  Whether it’s for user group meetings, code camps, DotNetNuke World, meetings with colleagues, or strategic business meetings with partners and prospective customers – public speaking is a critical tool to have honed and in your professional toolbox for your career.  Honestly, many of us believe that we are good at speaking in front of an audience, or at least good enough.  This first part of the year, I took it upon myself to build some presentation-style videos to explore and teach some of the most important components for public speakers.

I joined DotNetNuke Corporation in June of 2010.  I was already speaking at many events before accepting the position.  I had countless public events as well as business-centric presentations under my belt.  While I knew I wasn’t an expert at public speaking, I knew that I could hold my own and get things done.  The position I took was to not only do some of the very things I was already doing, but it also entailed representing a brand and company that I was pretty much obsessing over.  The last thing in the world I wanted to do was misrepresent the brand in any way through my presentations.

As a result, I quickly did some research to find out who the “experts” on public speaking were.  I found a small handful of people that specialize in the topic and not only authored books, but also had businesses based on the subject.  Some of my favorite include Garr Reynolds and Nancy Duarte.  I literally spent many hours reading their books, attending live webinars, reading their blogs, and more learning what they had through real world experience.  I had already blogged on their books in the past, and I invite you to read them as well.

What I put together over the past couple of months is the beginning of a larger amount of resources that are intended to help everyone, and especially the DotNetNuke community, become better at public speaking as well.  Introducing, the public speaking series of videos on the DNN YouTube channel…  The channel is also embedded below.

As of today, there are nearly 2 hours of videos that introduce ideas, experience, tips, best practices, and more that all help you to ensure that you always have the best presentation possible, regardless of your audience.  The videos start from the very beginning, and continue through to DotNetNuke demonstrations.

There are of course plans to add more resources just like this.  Hopefully, you enjoy this as well.