I recently was asked a question about how to change the width of bars in a histogram chart. Specifically with Report Builder. I’m not generally a fan of Report Builder…
Looking at the limited features of Report Builder , it’s probably not wise to try and edit a report in Report Builder that was created in Visual Studio. Vice versa if an end user has created a report in Report Builder then it’s probably not wise to then edit it with BIDS and potentially make use of features that are not supported in Report Builder hence making it not further editable by end users.
It’s admirable to think that end users would take Report Builder and run with it thereby freeing up IT departments but the downside of this kind of thinking is that some developers are forced into using Report Builder.
The idea behind Report Builder is good and the software works well but I think it was a mistake to limit the functionality. It makes perfect sense to leverage the powerful shell of Visual Studio in creating a BI development enviroment (BIDS) . Equally it makes no sense to install BIDS on lots of user’s systems. It’s not an easy application to deploy.
There does seem to be a general theme in IT that probably derives from marketing where a product is described as “no programmers required”. I’ve worked on a project like that before where the company bought an “off the shelf” application that end users could customise visually… to a point. I joined the project after a point in time where it was realised that anything slightly beyond basic actions predicted by the vendor required delving into the scripting framework. Oh and it was a proprietary scripting language littered with the [sacrcasm] awesome power of GO TO [/sarcasm]. The application in question *cough* StarLIMS *cough* has improved remarkably since then including becoming web-based and includes the option of using Jscript.NET instead of the proprietary scripting language SSL.
Completely visual programming is a lofty goal but there are some decent examples where it works. Lego mindstorms and LabVIEW spring to mind. Interestingly the Lego Mindstorms environment was based on LabVIEW, I did not know that. I guess the name “Visual Studio” stems from this goal as well and it’s certainly a very helpful IDE when adding .NET controls to webpages or forms, but clearly you need to get your hands dirty with the code to make it do anything remarkable.
In the end, the sort of users who would create reports like this are power-users who probably already know a bit of VBA and are probably famous around the office as the go-to person for Excel macro stuff. Those users, such as accountants who have previously used Crystal Reports or other technically inclined people, would be better served by the full version of BIDS and some other type of semantic model that is not a ‘Report Model’ as used in Report Builder.
In another previous project I worked on, there were a couple of Accountants who fit that criteria described and after installing and giving some guidance in BIDS they developed some very useful reports which their intimate business knowledge enabled. Many other users in the business also wanted to access this data and where appropriate the tool I provided them was one they already had, Excel. The semantic model requirement – to separate the complexity of the datasource from the users – in that case was served by a very useful multidimensional cube. Connecting Excel to an OLAP data source, particularly SSAS, is very easy and the only potential learning curve is how a pivot table works. Pivot tables can be quite confronting and intimidating when you first see them but when you use them for a while they become quite easy. You also get all the functionality of Excel and formula experience of the users. Ultimately data analysts usually want to muck around with data in Excel anyway and will frequently export from the Report Manager website into that format (yes I’ve looked at real stats in the catalogue tables behind SSRS).
Report Builder as a product sits somewhere between Excel pivot tables and BIDS in complexity and in my opinion is unnecessary. Not that the product is bad, it’s very polished and stable, just knackered. If the powerful features of BIDS were in Report Builder, even if they were hidden by default, it would be a much more valuable proposition.
Click-once is awesome! BUT It assumes that users are allowed to install stuff without admin rights… That goes for the print control too, but there are workarounds for deploying those.
It seems like the new Power View product is quite similar to Report Builder and co-exists with it but is focussed on Self-Service BI from within SharePoint. I haven’t used it yet but I hope it hasn’t also had it’s hands tied.
Self Service BI and Visual Programming both share that same dream. My point is that the data analysts and other power users who actually want to make use of Self Service BI are already technical users with complex requirements. No no I hear you saying, it’s the C-suite and senior managers. Ha! Do you think those people have time to learn and play with Report Builder or Power View let alone SharePoint in any way? No they will get someone else to create the report, preferably pre-summarised.
One the one hand you want to restrict a user’s access so they don’t place unnecessary load on the datasource and reduce complexity to both shorten the learning curve and improve productivity, but in doing that you are just increasing reliance on IT and BI practitioners.