A colleague of mine in the USA Kevin Smolkowicz (http://linkd.in/K5vwRS ) put together the following around what he thinks are the compelling arguments to make Rich Client available to users. Having read the list I thought it was of interest to a wider audience and Kevin kindly agreed for me to reproduce it on my Blog.
- The most significant plus for using WebI Rich Client is where off line interactivity is needed or beneficial. Almost every developer creating advanced/complex reports I come across will use Rich Client for the bulk of their developing. They like not having to keep a web session active, nor the unexpected network slowdown to disrupt progress.
- The business would benefit considerably as analysts will work from home often after hours. It can be especially frustrating to work with the Web version while connecting via a VPN. Moving report elements around and even adding variables can be sluggish over a VPN.
- A big advantage with working in Rich Client is the speed at which you can format large reports. Time savings can be achieved by switching to the ‘Structure’ view in the Web version of the tool, but developers often like to see the actual output of the report while developing. Rich client handles the larger/complex reports better than web based.
- Sometimes developers want to integrate with an existing “Source Safe” tool as the Rich Client allows saving of files to client file system or a shared File Server (i.e. TMS_CPF Integration Shared Docs).
- Having Rich Client would be an effective and efficient tool for any troubleshooting exercises where he needs to isolate an issue as a report issue…or a web application issue. Sometimes odd behaviours are believed to be an issue with the report itself…when it turns out to be a web application issue. Sometimes Rich Client helps you get to a conclusion or bring a problem into greater focus. Not a critical reason…but you are glad you have the tool available in those situations.
- It may be out of alignment with the overall objectives of BI, but some analysts do actively use non-universe data sources (Excel files) to create some reports in an effort to turn around “fire drill” requests. The goal of any BI project should strive to reduce such activity, but not necessarily prevent it. Developing against these file types is possible in Rich Client and not web based WebI.
- A downside to deploying Rich Client to selective users is that it must be kept in sync with the server version. This would be an IT consideration obviously. To help facilitate end user acceptance on the business side, at some point IT has to trust business report developers to use the tool according to any guidelines and support them with keeping the tool up to date.
What are your thoughts? Do you see any other value or negatives in releasing the Rich Client to users?
I have been working in the BI arena since the late 1990’s specializing in Front End Reporting and visualizing data using the SAP BusinessObjects toolset for well over a decade. Along with countless others I have experienced first hand the changes in BI from Client Server Apps to Web Based and now the drive for mobility, the decline of EIS systems and now the prominence of Data Visualization and Dashboarding.
This last week I spent a day with a client delivering a Data Visualization and Dashboard Design workshop and so many aspects of how to approach a Dashboard project crystallized in my thinking. I often see many companies and individuals I engage start their journey into Dashboarding following an edict from above stating “We need a dashboard on that plasma screen” and then delivery team often fall into the trap that Dilbert points out so well below.
Where do you start ?
For me it is the “Mission Statement”
There absolutely must be a clearly defined reason for the Dashboard to exist that can be expressed concisely. This can often be harder to do then first thought as I found in the session described above where this took over an hour to agree between a small group of people. But if you start from this the following steps become easier.
For me the key to the successful delivery of dashboard projects are iterations, iterations and iterations …. Be mindful up front that the first design that was drawn on a napkin over coffee that evolves into a straw man/ prototype will not be the final solution. I see this is of often due to members of the project team from the stakeholders down to then end users having different agendas and opinions for on all aspects of the design from the look and feel along coupled with the desire not to have a Red traffic light against the KPI they are responsible for. Also don’t get me started on the impact on the design when you involve the corporate marketing brand police !
My experience so far suggests using an Agile development methodology and timeboxed iterations (Sprints) is the best way to succeed.
And one last thing …
The diagram below is one I come back to time and time again in dashboard design sessions as my summary of the backbone of data visualization specifically for dashboarding.
- The ultimate goal of a dashboard is to drive an Action from the information consumer. If there is no action driven then why does the dashboard exist. If you get philosophical about this point ponder this … http://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest
- Without the values displayed on a dashboard having associated Targets, Trends, a context and a comparative then they might as well be displayed in a list report in Crystal reports
- Finally, don’t expect your first dashboard to follow in line with the academic thinking of Stephen Few and such like. In my opinion the first dashboard will have multiple agendas, not only to meet it’s mission statement but drive user adoption and become “Sticky” to the user community. This “stickiness” is not gained from a boring looking dashboard but over time I am seeing that both the user community and the developers loose interest in the BLING and move away from the “Flashy to FEW”.