Glanton Hits Vegas - DotNetNuke Openforce 2009

John, Amisha and I sat back after the last session at Openforce 09 and, over a well-deserved Margarita at Cleopatra’s in Caesars Palace, we reflected on what had made the Openforce conference a success for us and why we’d recommend it to others.



Firstly, it was an appreciation of the DNN community. This is not your usual, large scale gathering of folks with a passing interest in technology on a company funded junket – this was more like a City Hall gathering in a small town – everyone was there because they wanted to be there, because they had something to contribute, something to share and because they wanted to see their community and its infrastructure grow stronger.



With our livelihoods so dependent on DotNetNuke Corp and how it manages its people, its strategy and the product, it was very re-assuring to meet all the main people, to experience first-hand how approachable they are and to feel that their door is always open. Navin Nagiah, the CEO, gave us a shout out in his session on DotNetNuke Commerce and Community as new Fusion partners.



Our mindsets have changed about our role in the ecosystem. No longer do we have to work so hard to sell DotNetNuke on its merits and its backing – Doug Howell (Director of Alliances) and Tom Kress (VP Sales) are there to support those activities and we’ll expect to see more sales and marketing support from these great guys. Now we can focus on selling our capabilities on top of this great product.

Being a young and evolving product, there were plenty of breaking news items delivered during the conference.

It was great to hear the announcements on Professional and Elite editions. Future announcements like the implementation of a file management provider will be a great boost to our enterprise clients. It will also open up an opportunity to develop on top of SharePoint as we see many of our customers opt for SharePoint for document management and collaboration.

The announcement of a deal on the inclusion of the Telerik RAD controls was very welcome. We’ve used Telerik from the beginning so it was nice to see we are making the right decisions. What that actually means is that user experience and the extensibility of modules will taken to a new level.

Integration of Google Analytics and segmentation of traffic is also a welcome addition.

There was plenty of lively debate on what the acquisition of Snowcovered means and what the community felt DotNetNuke Corp needed to do to clean it up and further raise module development standards. We'd like to see some standards and a QA process before modules are listed there. Even if that means the cost of individual modules goes up.

Probably the most contentious issue discussed was licensing and it was interesting to see the different perspectives on the chosen “per instance” model. Those running DNN across large server farms were understandably concerned and those running very large single instance, multi-portal implementations were very quiet!

With two DNN tracks running over the three days and six sessions a day, there was plenty of information being dispersed. We even snuck into a couple of Sharepoint sessions running as part of the larger ASP.Net Connections conference which was helpful in understanding the relative strengths and differences of both platforms.

All in all, an event well worth attending, and one which will pay for itself over the coming year through new found contacts and knowledge.





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

Twitter Account Syndication Part 2 - WebAdvantage®

Using Twitter feeds in WebAdvantage®

Last time I showed how easy it is to syndicate single or multiple Twitter feeds by putting them in a web page. Here in Part Two I will show that it is even easier to do the same in a WebAdvantage® page.



As a WebAdvantage® site administrator you can go to the page into which you want to import a Twitter feed; select 'RSSFeeds' from the drop-down module menu; select the 'pane' in which the module will appear; give the module a title and click 'Add'. The new (empty) module will appear in the selected pane.




At the left of every module title is a little 'drop-down' arrow. In the case of the 'RSSFeeds' module it provides the menu at left.





Click on 'NukeFeeds Admin' and you will see this menu - again at left.




Click on 'Edit Feeds' and you will see this.





Click on 'New Feed' and you will see this:



Put your Twitter RSS feed URL in the appropriate field, as indicated. (To get your Twitter RSS feed, please see Part One.) Click 'Save' and your feed will appear in the module on your page, picking up your 'Style' in the process. A capture of the glantonsolution Twitter feed appears below. (There are other options for setting up the feed in the module: for instance, you can include and exclude tweets based on keywords, but I suspect most people will be happy to show the whole stream.)



Now, what if your organisation has multiple departmental Twitter accounts and you would like to show them all in your page, but you don't want to clumsily use up hectares of real estate? Then it is a job for 'The Aggregator'. Not, as you might imagine, a 1960s 007 television rip-off (nor, more prosaically, a trade mag for the concrete industry), but one of the most useful modules available.

The Aggregator is added to a page in exactly the same way as the 'RSSFeeds' and all other modules. Once installed, you create and name tabs and then suck a Twitter RSS feed into each tab. The easiest way to do this is to put each feed in turn in its own RSSFeed module and then tell the Aggregator to grab it and put it in the tab of your choice. The 'RSSFeed' module it came from will then disappear. Repeat until all your departmental feeds are in the Aggregator. Below is a capture of the Glanton Twitter Feed Aggregator, with glantonsolution (our main account), JohnJRoyle (John Royle), glantonian (Ian Sampson) and adalwadi (Amisha Dalwadi) in the tabs.



However, if you prefer, you can put a 'mash-up' of your departmental Twitter feeds into a WebAdvantage® page. In other words, a single feed containing all the tweets from all the departments posted in chronological order. Just like I made last time with Yahoo Pipes. This time, get the RSS feed for the 'Pipe' and put it in a plain 'RSSFeeds' module in WebAdvantage®. Below is the result for the same four Twitter accounts that are in 'The Aggregator' above. Note that the source account of each tweet is clearly indicated.



This is only a 'taster' for what is possible with WebAdvantage®. For the full User Guides and Support Pages, please visit http://training.glanton.com/

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

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.