Over the last 18 months I have been working on a series of DotNetNuke extensions aimed at providing Twitter support in DotNetNuke.  The effort started with Monitter4DNN which is a DotNetNuke Module for displaying an auto-updating list of tweets based on some search criteria.  The search terms are completely configurable by the module administrator.  This module was subsequently renamed to SocialScapes which is more indicative of the long-term vision for the project.

SocialScapes is envisioned as a social framework with a supporting suite of modules, widgets and mobile applications.  Ultimately the goal is to incorporate data and services from multiple social networks, with the core platform running on DotNetNuke.  The administrator should be able to configure the platform through a set of plugins to interact with one or more social platforms. 

In late 2007, Nik Kalyani created what I think is one of the coolest new DotNetNuke features to arrive in quit a while – DotNetNuke Widgets.  Nik recently started work on a multi-part blog series on Widgets.  As he explains, DotNetNuke Widgets are a powerful client-side counterpart to the server based extension model exemplified by DotNetNuke Modules.  Where a module generally consists of code that is executed on the server, a widget primarily consists of JavaScript to be executed in the browser.  This is not to say that a module can’t include rich client functionality or that widgets can’t include server-side code:  indeed both options are certainly possible.   With widgets the focus is on building functionality that is easily added through custom object tags.  You can emit these tags from a Module, in a Skin or directly in an HTML module.  Anywhere you can add HTML to the page output, is a place you can add a widget.

With any new technology there is always the question of why someone would use it.  Why would someone not just add custom JavaScript or use an existing widget framework (there certainly are a lot to choose from)?  I have used a number of widgets and scripts on my pages and in general I don’t find that they are particularly geared for use by many of the non-technical users who ultimately edit and maintain DotNetNuke websites.  Most widgets and scripts require a certain level of technical knowledge by the end user, and in many cases, they impose some dependency on a third party website.  DotNetNuke Widgets attempt to resolve these issues and many others.  Since widgets are first class citizens in the DotNetNuke extensibility model, they can be packaged, versioned and installed just like any other DotNetNuke extension.  This eliminates any dependency on a third party website since many widgets are fully self-contained.  Also, because the widget is created on the page with a simple Object tag, they are much easier for a non-programmer to understand and add to the page (there is still some room for improvement which I hope to address in 2010).