When I
initially started using the PerformancePoint 2010 Stack Selector, I thought it
was a great way to provide consumers more options of how they viewed data on a
dashboard, without taking up more screen real estate or bandwidth. But I’ve
finally come to realize that by using them, I was losing some web part features
and introducing some erroneous ones. Below are the primary reasons that I have
since removed them from my dashboards for the project that I am currently
working on.
1. The Stack Selector does not show the
appropriate menu items based on the web part being displayed
This occurs when, for
example, you have Analytic Reports mixed with Reporting Services Reports located
within the same web part zone below a Stack Selector. The Stack Selector menu
will show the Export to PowerPoint menu item for Reporting Services Reports, which
results in the following error.
With some jQuery, it is
possible to locate the Stack Selector’s menu and remove the Export to PowerPoint
menu item when a Reporting Services Report is displayed, seemingly fixing the
problem. Switching to an Analytic Report using the Stack Selector will cause an asynchronous update and the Export to PowerPoint menu will once again appear (again, using jQuery, this time to show the menu item).
The problem occurs when then switching back to the Reporting Services Report:
it will be cached at this point so that an asynchronous update (i.e. partial postback) is not occurring and
my jQuery is not executed, resulting in the Export to PowerPoint menu item being
available for a Reporting Services Report.
2. The Stack Selector does not show the
web part’s description or icon
I initially wasn’t using
descriptions or icons with my web parts being displayed by a Stack Selector.
However, as the dashboards became more complicated and the reports more
sophisticated, I realized a tooltip description of each PerformancePoint web
part would be helpful. Additionally, for the novice consumers, an icon
indicating the different kinds of web parts (i.e. Analytic Reports, Scorecards,
Reporting Services Reports, etc.) would clue them in on the differences in
their capabilities (e.g. don’t waste your time right-clicking a web part with
an icon indicating that it is a Reporting Services Report).
3. The Stack Selector does not retain the
web part selection
This seemed like a minor issue at
first, but as I interacted more and more with the dashboards that I was
creating, I realized that I appreciated that the PerformancePoint Filters
retained their selections between dashboards and between sessions and postbacks (i.e. in the case of using a Query String (URL) Filter). With the Stack Selector, I found myself constantly having to re-select the web part that I was interested in at the time.
Additionally,
by using the Stack Selector, I had to deal with the problem addressed in a
previous blog post: SharePoint Designer and the PerformancePoint StackSelector’s CurrentSelection Property Error.
I still believe the Stack Selector is useful, however its not quite as robust a control as I had initially thought it to be. In the end, I have eliminated the use of the Stack Selector and more heavily relied upon the PerformancePoint Filter's connections and display conditions to control the visibility of web parts on a dashboard.
