View Full Version : Advice on creating a site with 100s of reports

06-29-2011, 02:56 PM
I'm a graphic designer (i.e. not a programmer/coder) who was invited to a meeting held by one of our departments who wants to redo their website, which is currently just a report-generating tool. The challenge is this: currently their web-based reporting generator has a menu at the top with the five categories for reports, and when you click on one, a drop-down menu appears listing all the reports available; at the moment there are up to twenty reports for each category but they expect this to balloon to 100 reports for each category. So this drop-down method is not going to work for much longer. (They also are receiving complaints from users that one has to "click too many times" to get to the report they need -- not sure anything can be done about that.)

Unfortunately our web programming department isn't the best; you pretty much have to explicitly tell them what you want, rather than present them with the above-scenario and ask what they'd recommend. I can't seem to find any comparable websites to look at as an example of how to handle this...

Does anyone have any examples of existing websites that work in the same manner that I can provide the team with examples? or even provide a description of what would be a good way to handle this type of site architecture?

Thanks in advance!

06-29-2011, 04:22 PM
What kind of reports are being displayed/generated. Are these reports actually being created on the fly? or are they being stored in a database and when a user clicks on one, the site displays the reports.

Most server side languages, well coldfusion and php I know for sure, have the ablility to generate reports. There are also several tools/software that will generate reports based on the criteria its set up with.

06-29-2011, 05:12 PM
Another thing to question is whether all users really need access to all reports. And is there a log-in system or is this just intranet and anyone on the company's system can get on without login?

If there is a login then you can set user report visibility for each report based on need/user group/whatever. Then you won't have hundreds of reports to choose from and most users could probably have a "favorites" list to narrow down the list even more.

In any case, if there are a small number of reports that are most frequently used across-the-board then you could make a "quick-links" type of thing there that allows 1-click access to the most commonly requested reports.

06-29-2011, 05:32 PM
I just posed your question to the pm (I wish I could provide screenshots but that would get me fired -- the security in this place is on steroids!)...the user goes to the report, fills in the form that loads onto the screen, then clicks "run report" which pulls the info from a database.

06-29-2011, 05:36 PM
Its an intranet, anyone in our company's system can get in without logging in. Unfortunately, the pm confirms that everyone needs access to every report because there's so much "overlap" with roles around here. And alas, there are no "frequently used" reports.

To make matters worse, I mentioned the "favorites" list you recommended and he said "there is already a favorites option built into this reporting software but nobody seems to want to use it." (Again, I don't think anyone can help with that!)

06-29-2011, 07:38 PM
Well they've pretty much hog-tied you as far as I can see.

My recommendation would still be a "favorites" system since you can't do much else. The existing one might become more widely used once there are a stunning number of reports available - who knows? How do they do "favorites" without a login or user authentication? It could be anybody at any time who visits the page. Are they using cookies or IP addresses to track that? Is it 1:1 for workstations:employees or are there shared workstations? Favorites using cookies or IP addresses would get sloppy in a shared workstation environment.

You can make adding a favorite simple (or even automatic) when a user pulls up a particular report. Just add a checkbox to the form that says something to the effect of "save this report to My Favorites?" and, if checked, when the form is submitted the user's cookie gets updated to add the current report to their list of favorites. You could even store links to pre-populated reports that way (in theory) for 1-click reporting by storing not just the report, but also the data that was typed into the fields when it was saved as a favorite. This last bit depends on how the reporting structure is set up, which I don't know anything about. If the report forms use a "post" method (as opposed to "get") then you would need to do some juggling to get that to work.

Anyway... If, in the end, you can't get any narrower list of reports for your users in any way (even a favorites list) then you'll probably be best off using a table of links or several side-by-side vertical lists of links with each column taking the place of one of the current drop-downs. At least that way your users won't have to scroll down a tiny little select box for ages to get where they want to be. You could then implement a javascript search bar at the top of the page to narrow the choices in each column by alphabetical terms, numerical terms, or however these reports are cataloged. Let the user "zoom in" piece by piece that way, perhaps?

Does the IT department really not have any suggestions of their own for this?

06-29-2011, 10:17 PM
Yeah I don't see being able to offer them anything as a solution but I will definitely pass on that part about the Javascript search bar zooming in, that sounds like an option...

Don't even get me started on how bad our "web design dept" is! I did an online newsletter (which used all CSS for the layout, i.e. NO tables) and one of the VPs said he didn't like it being a "fixed width" so because I was on another deadline we handed it over to them to make it a "fluid" width...they converted the whole thing into tables!!! I ended up doing OT to get it done correctly, but then someone said "this doesn't work in IE6" (yeah, we've still got some people on IE6 here) so we asked them how to address this and their recommendation was to get rid of the CSS and use tables -- they didn't even know about conditional style sheets (again, I took it upon myself to google how to do it right). And remember, I'm not even a programmer...!