Input Controls to simulate Freeze Header

More tips and tricks for Authors wanting to build rich, interactive reports with input controls (Web Intelligence 3.1 SP2). Last time, I wrote about using input controls to create a Input Controls to dynamically rank tables for consumers. This time, I’ll describe a way to enable users to more easily scan the values in tables with large numbers of rows.

Customers over the years have asked for features that enable users to optionally freeze the headers of large tables. This helps those poor users who are sent massive tables with hundreds or even thousands of rows and dozens of columns. In order to identify this or that salient value, users need to be able to keep the sight of the column label as they scroll. Otherwise, they can’t discern which value belongs to which column.

There are countless ways to solve this issue. The best is to ask why users should be forced to scroll huge tables in the first place. Forcing a “needle in the haystack” scrolling session often guarantees the user will overlook one salient detail while looking for another. The most obvious response is for Authors to look for ways to break up the table into more easily viewable “chunks” – sections, breaks, multiple tables with different themes. The authors can also pre-identify the thresholds that would make one value or another interesting (e.g. values that are greater or less than 30% of average), then build some conditional formatting (called “Alerters” in Webi).

Authors can also guide the user to do their own interactivity on the report. If a consumer has the rights, let them create their own section groupings or breaks (simply a right-click). Allow consumers to delete a column, or define their own thresholds for conditional formatting.  Authors can never pre-identify all of the most important values to a range of consumers – the market and business situation changes so frequently. So let them consumers define them on their own.

OK, now you’re saying, “Stop preaching. My users want big tables of data and that’s that.” Fine, here’s a simple way to build an input control to facilitate their navigation (scrolling) so at least they can get to their answers and then out as efficiently as possible. I can’t believe that any user really wants to spend their time inefficiently scrolling around a giant table.

First, it’s based on a simple variable using the rowindex() function. This function simply provides the number for each Row in the table. Note it works across sections so the rows will be counted, not as rows in individual tables within each section, but as rows for the overall table that has been broken into sections.

So, create a variable named “Row#” that has the following formula.

=RowIndex()+1

Second, create an input control that uses this new variable “Row#” as the input dimension.

Fill in the parameters as shown below, note that you are using a “simple slider” widget as the input control. Note that the size of the increment is defined as 20. You can adjust this as needed, depending on the size of the screen and window most users will consume the report.

”

Then you should assign it to the appropriate table in the report. [Note: In the below document, there is only one table so that’s the only choice you have.]

When a user consumes the document, the slider then enables them to jump 20 rows at a time, while the header maintains its place at the top of the table. [Note: You can validate the behavior of the control by adding the variable “row#” as a new column to the table.]

Compare this to a split window or freeze column feature which still requires users to scroll for minutes at a time. With one click on the input control, the user can jump very quickly in 20 row increments. Pretty efficient!

(next time, I’ll show a more sophisticated version)