How to Choose a DotNetNuke Module From Snowcovered

DNN MODULE SELECTION PROCESS

INTRODUCTION

One of DotNetNuke’s greatest attractions is its modular architecture which literally allows you to "plug and play" almost any kind of functionality from Ad Rotators to YouTube plugins. Whilst we could develop all of these tools ourselves, there's really no need when you can pick and choose from the thousands of ready-made modules available, at low cost, through the Snowcovered online market for modules and skins. It's DotNetNuke’s version of the Apple App Store.

By and large, the quality of the modules is pretty high, but in our field where we're integrating DNN into large Enterprises, we need to make sure that the modules we implement are best in class.

To achieve this, we follow a fairly rigorous process to identify, filter, test and implement only those modules that meet our criteria. I've set out below all the points that we consider when selecting a new module. The points cover not only any technical issues but also help you identify how much work you'll need to do to install, skin, set up, train and support a module and your site editors.



1) REQUIREMENTS

It sounds pretty obvious, but before you even start searching Snowcovered, you need to capture the key requirements. Don't forget that what your client is asking for may not be want they want and probably isn't what they need.

• Brainstorm all of the key requirements

• Categorise them: features that are essential, and those which are nice to have.

• Consider where the module will be used; on what pages and how do you want it to look. Does it need to tuck neatly into a narrow column, or is something full width acceptable?

• What will it be used for? For example the most popular use of the FAQ module is to create nice lists of expandable content to save on screen real estate - not to help users find answers.

• Who will be using it and what will be their technical level?

Search Snowcovered for ideas and shortlist. Think laterally, as modules may be categorised or labelled differently from what you would expect. For example, you will find many 'Form' modules provide survey functionality.

Look more widely. Go and ask the DNN community on the DNN forums or on Twitter (hashtags #DNN, #DotNetNuke) if they know of any modules that can help. Some developers don't list on Snowcovered - For example Ventrian Systems has excellent news and document management modules - but doesn't sell them directly on Snowcovered.



2) THE DEVELOPER

Assuming that you are in business for the long haul, you should favour modules from developers who are committed to continually improving their products and who’ll be upgrading their modules as DNN evolves. It’s a hard conversation with a client when you have to pull a module that used to work because the back end is upgrading.

Consider:

• The ratings and feedback they have received on Snowcovered

• How long they have been in business?

• Are they a professional developer or a hobbyist?

• How many modules have they produced?

• Are they continually issuing new versions and improving existing products?

• Is there an on-line demo you can play with or a library of screen shots?


Support:

• Is there a forum?

• Is there a help desk system/tickets? (if they sell through Snowcovered, then you'll be able to raise tickets through them)

• Is there a user guide or training available?



3) THE MODULE




• What is the balance of complexity versus functionality - does it do what you need it to do? Does it do too much which makes it hard to use?

• Will your end user be able to manage it or does it require 'super user' or 'mega user' skills?

• Search web and DNN for references to the module (or module category) for any compliments or complaints.

• Twitter the question (with hashtags #DNN and #DotNetNuke) to see if anyone has any experience with the module.

• Is there a trial version available?





Design:

• Does it look good?

• Look at the module.css file - does it have custom styles and colours that aren't overloaded by your skins?

• Does the module offer template functionality under module settings to allow you to change the layout? Can you change the default template that's available to users?


Testing:

• When the module is installed in DeskTopModules does the module folder name have a "." (e.g. "\desktopmodules\BigShot.Developer" ) in the folder install path? If you are going to run this in an older network envirnment your CSS and javascript files may not load in the client browser.

• Are you running this in a a multi-portal environment? Test it within a number of children - some developers don't cater for Portal IDs.

• Consider browser compatibility, XHTML compliance and accessibility requirements and test against the W3C validation tools.

• Does the module have .resx files for localisation? Whilst you may not be looking to add other languages, if the developer's first language is not English, you may want to clean up some of the module's labels.

• If design (styles etc) is hard coded in a DLL it makes it impossible to clean up later.


Database:

• Look in the PA ZIP and open up the script files in Notepad. Has the developer used tokens for the database prefix and object owner? Don't hardcode DBO as the default database object owner - some DBAs won't allow DBO access to production sites inside Enterprise networks.

• Has the developer included uninstall database scripts? If the module requires no changes to the database (i.e. it has no script files) the install/uninstall risk is low because no structural changes are taking place.


Programming:

• Does the module have any dependencies on other components? For example, we use the Telerik RADcontrol suite extensively and recently had an issue where a module installed an older version of the primary Telerik DLL.

• Is the module searchable? Does it integrate with DNN search? Does it allow search engines to crawl its content? You will want to look at how it redirects pages, its use of cookies and javascript and how it manipulates the URLs.

• Is the module exportable (iPortable)? This is a fantastic feature that allows you to easily backup a module’s setting and content and/or re-use that content elsewhere. The code DNN "Copy Module" functionality relies on this. Can you syndicate content out of the module using the DNN syndication features, or does it have its own?

• Once installed, look at the web.config and make sure you understand the implications of any changes it has made.

• Does it install or use any directories other than under desktop modules? (e.g. App_data or folders e.g. Telerik.)

• Look at the size of the install.zip PA file - if it is too large you may have time-out issues uploading the module.

• Look at the .dnn manifest file - is the friendly name really friendly and will the site administrators identify the module from its name? We prefer to rename modules based on their functionality. For example, it's not really useful if a user looks at the module list and sees "GeeWhiz ezeMap" - we'd change it to "Google Maps".

• Is the .dnn manifest file complete with license information, version (that matches the DLL) and help links?


Installation:

• Can you use the module more than once on a site? For example, if you use the core blog module on multiple pages it will reference the same content. (It is PortaslID and not ModuleID based.)

• Can you put the module more than once on a page? We implemented a ratings module once, but then the site owner wanted to rate several articles on the same page and it didn’t work.

• File uploads and permissions: if the module uses its own file manager and upload tools, check that it is integrated with the DNN file manager and its permissions.

• Does the module use a text editor? If so, is it using your default editor or its own?

• If the module sends out emails – are the templates customisable?

• Look at where module settings are – does it include a section at the bottom of the module settings, or does it create a separate entry in the module action menu? Will the users find where to administer the module?

• When the module is installed, how many modules are created? Are they all needed? For example, do you really need that "Top5" companion module?

• Is the module easy to set up on a page? Some modules, like the blog, add about 5 modules to a page - this can be a daunting process for a user!


Licences:

• What are the terms? (per child; per DNN instance; unlimited; etc)

• Cost - is it cost effective?

• Does it require a licence key? (We have had issues with a module which required text license file in the BIN directory – every time the server was re-started, we had to re-install the licence.)

• Are upgrades free for point releases? Or do you only have to pay for major releases?


Hopefully module developers will consider these points and, by following them, will raise the quality of DNN modules - for the better of the whole DNN ecosystem.


Go to this post's page at www.zinepal.com and get the PDF file or perform various sharing actions.