[Sigia-l] Reports w/ Horizontal Scrolls

[Will Parker]

On Jun 22, 2007, at 7:08 AM, Susan Rice wrote:

> I'm working on a project where we're providing some reporting  
> online with the option to download to Excel. It's very likely that  
> the data will require the use of a horizontal scroll within the  
> table and depending on the report, the user may or may not need to  
> scroll vertically too. Unfortunately, we can't rely on JavaScript  
> or Web 2.0 for coding the display (e.g., can't do any detects based  
> on amount of data, can't keep the header info in place when  
> scrolling down, etc...).
>
> With that in mind, do you suggest providing an internal vertical  
> scroll which requires that we define a fixed height for the table  
> or should the user use the browser scroll?

All of the above indicates that the online reports are seen as  
requiring the same display attributes as a standard spreadsheet,  
i.e., lots of raw numeric data displayed in a large number of rows  
and columns.

Is this really the case, or is there some alternate visualization  
(charts, maps, executive summary, etc) that would adequately convey  
the meaning of the raw data while shielding the user (and  
coincidentally, the visual designer of the site) from the need to paw  
through a haystack of spreadsheet cells? Isn't that what computers  
are for?

Think of it like this -- if you're providing a spreadsheet download  
anyway, where's the additional value in recreating the spreadsheet  
display metaphor online? Clearly you're dealing with data that's  
sufficiently complex to be of interest to a business and/or technical  
audience. These people _already_ have spreadsheet apps, and they know  
how to use them.

Your value-add for web display should be to offer a view of the data  
that's not readily available in standard spreadsheet software, or you  
should just go home -- i.e., offer a data download page.

> Here are some considerations:
>
> Using an internal vertical scroll would mean that for reports with  
> few rows of data, the table will display a lot of white space.

Again, you're (perhaps) unnecessarily mapping your data to a  
spreadsheet metaphor. Surely you can skip to the next report when the  
user hits end-of-data for a particular section.

Also, why do all your reports have to live on the same rectilinear  
plane? Can't you break this into separate views for separate reports?

> We have a solution in mind, but I just wanted to see what you all  
> thought. Thanks in advance for your help.

Could you provide an outline of your solution?

- Will

Will Parker
wparker at ChannelingDesign.com

“I wish developing great products was as easy as writing a check. If  
that were the case, then Microsoft would have great products.” -  
Steve Jobs