Click here to Skip to main content
Click here to Skip to main content
Go to top

Selecting the Right Dashboard Platform: Thoughts from a Lowly Dashboard Developer

, 8 Nov 2007
Choosing the right technology to use for building an in-house digital dashboard solution is important to the success of your project.

Editorial Note

This article is in the Product Showcase section for our sponsors at CodeProject. These reviews are intended to provide you with information on products and services that we consider useful and of value to developers.

Screenshot - Dundas_Logo_JPEG.jpg

With the world producing the equivalent of about 1.5 billion gigabytes of information annually there is little alternative but to gravitate towards digital storage. This data massif necessitates the need for the creation and upkeep of systems to disseminate information in an effective manner. In many scenarios digital dashboards provide the perfect means to achieve information clarity.

A quick Internet search will reveal no shortage of individuals and companies professing to be dashboard experts, declaring the importance of A, B and sometimes C, and why you should choose Platform X over Platform Y. I'm not going to do that, mainly because I don't think it is possible to make such definitive assertions given the overlap in technologies. Instead, I'd like to take a conversational look at each of the platforms based on how adequately they have satisfied non-functional requirements by which other pieces of software are commonly assessed:

  • Interoperability
  • Maintainability
  • Performance
  • Scalability
  • Customizability
  • Usability
  • Aesthetics

The aesthetics debate is a non-starter; many vendors sell products to enhance the appearance of dashboards across these platforms. My own employer — Dundas Data Visualization — has Dundas Chart, Dundas Gauge and Dundas Map controls that produce equally strong looking products on all four platforms.

So where do I start?

If you find yourself needing to implement a digital dashboard solution and already have a SharePoint installation in place (or plan to have one in the near future) both flavors of the newest generation of SharePoint (MOSS and WSS) bring a lot to the table: the asset management, collaboration and search tools can be invaluable. However, the task of sharing digital dashboards alone does not merit the time, effort and cost associated with installing and maintaining a SharePoint portal.

Screenshot - SharePointGallery.png
"Some Digital Dashboards Created with Dundas Data Visualization WebParts - click here to view them in action "

Microsoft has described SharePoint as a conduit to connecting people, process, and information. Given that description, you would expect that some of the major considerations mentioned at the outset have been addressed, and fortunately in a number of respects this is the case. For instance, SharePoint offers tremendous customizability at both the portal and page levels. Since we are dealing with what amounts to the presentation layer, this customizability is imperative. Beyond that, SharePoint affords good performance and a high degree of scalability. Furthermore, given its server-based model, maintainability is greatly simplified. There are, however, relatively few vendors providing multiple true visualization oriented WebParts. I believe Dundas is the only company offering both a Chart and Gauge WebPart.

In terms of interoperability the server-side of a SharePoint installation is as versatile as its ordinary web-server cousin. SharePoint eclipses ordinary web applications in its handling of file types commonly used in small and medium sized businesses, specifically Microsoft Office files. By harnessing this advantage it is possible to have personnel with limited (dare I say, rudimentary) software skills creating, editing and sharing meaningful dashboards. This usability is something none of the other platforms can boast.

Like SharePoint, SQL Server Reporting Services (SSRS) has quite a few unique features which make it desirable. For starters, you can develop read-only reports in SSRS much more swiftly than in ASP.NET. In many cases this can be achieved with little or no coding, including drill-downs and automation. Given the lack of need for code and the fact that parameters are built-in, the task of maintenance is greatly simplified. In instances where minimal coding is desirable or limited programming hours are available SSRS is usually a safe bet. Unfortunately deploying and exposing SSRS reports can be a painful process. If you are implementing a one-off SSRS solution do yourself a favor: hire somebody with expertise in the area — unless you relish the prospect of deployment and customization headaches.


Screenshot - RSGallery.png
"Some Digital Dashboards Reports Created with Dundas Data Visualization Controls - click here to view them in action "

A quick visit to MSDN will give you all details you need to configure and deploy SSRS to meet your scalability and performance needs.

SSRS has trumped other reporting products with its interoperability which is founded on that fact that SSRS compiles reports into a .NET readable assembly. This opens up a feast of integration possibilities.

Now that the two specialized products are out of the way, that leaves raw web applications and Windows desktop applications remaining for discussion.

There is no doubt that desktop application-based digital dashboards have a pronounced advantage over other platforms with regard to interoperability. By their very nature desktop applications allow developers to more easily plug into just about any other software entity while incurring comparatively small performance penalties. The desktop environment also affords terrific usability and customizability that is to be expected as desktop applications are not constricted by browser limitations. However, as browsers improve and web programming methodologies and implementations converge there are few instances (in the DD space) where I would choose the desktop over the web. Perhaps the only situation would be where a digital dashboard would have to double as a human machine interface. In these cases interactivity and response are critical, and would merit the jump from web to desktop.

Screenshot - ASPGallery.png
"Some Digital Dashboards Created in ASP.NET with Dundas Data Visualization - click here to view them in action "

While ASP.NET applications can also be versatile, their scope of interoperability is typically confined to the server side. This is in part due to the restrictions that browsers impose on web applications. A further complication of ASP.NET powered digital dashboards is ensuring uniformity. This is anything but simple; there are just too many variables to assure uniform appearance and behavior across the board. Despite browser related complications and limitations, ASP.NET-driven digital dashboards are still highly customizable and can deliver tremendous performance. This, however, is contingent on having a developer experienced enough to maximize the benefits of AJAX methodology as well as better bandwidth and task management.

While few things are definite here are my rules of thumb:

  • If you will only ever need a fixed number of reports, go with ASP.NET — it is the easiest to get up and running.
  • If you plan to have a varying number of reports, use Reporting Services — it is well worth the initial setup times.
  • If responsiveness and interactivity are imperative, use a desktop application.
  • Unless you have a SharePoint installation in play, or plan to in the near future, steer clear of SharePoint.
  • When in doubt use ASP.NET

Click here to download any of Dundas's components discussed in this artice.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Ayush Yash Shrestha
Software Developer (Senior) Dundas Consulting
Canada Canada
No Biography provided

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web02 | 2.8.140905.1 | Last Updated 8 Nov 2007
Article Copyright 2007 by Ayush Yash Shrestha
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid