When leaders had to dig through thousands of reports to view the ones they used on a daily basis, they either abandoned ship or took control over the report display process. In this case, reporting platforms got in the way of usability, and leaders got behind the idea of developing this effective out-of-box SharePoint report gallery web application with a sense of design and light customization.


From the top

Reports developed and hosted on different reporting platforms like InfoView, Hyperspace, SharePoint BI, and Tableau were hard to find and consume. Each platform typically displayed reports in its own virtual file cabinet, which required users to thumb through multiple drawers to find and open reports. With 10,000+ reports filed away in numerous drawers in numerous platforms, the task of reviewing daily report became a tedious ritual of scrolling and clicking, especially for those responsible for viewing several reports daily. The inertia caused avoidance.

Working with Physician Services analysts and leaders led to an initiative which identified and curated the "top" reports from each reporting platform. They chose SharePoint as the web platform for listing report metadata and displaying the reports, because it was handy for low cost development and content maintenance. Quick prototyping suggested a simple slice-and-dice interface design would result in the most value for the least risk and effort.

Top Reports version 1 - the big blue box theme

Taxonomy-wise, only a couple category levels were needed. When clicked, a strip of tabs across the top revealed a column of categories on the left. Rectangular tiles with thumbnails presented the reports visually in a color theme that followed company graphic standards. A NEW! flag identified what reports had been updated in the last three days, while symbols on the tiles either flipped the tile for a description of the product or opened the report in a new web page when clicked.

Click to flip tile for report description.

The idea caught on with leaders in other groups, which led to six separate go-to pages - one each for Clinical Programs, Clinical Quality, Finance & Revenue, Hospital Operations, and Strategy & Business Development.

Six lists fed six different Top Reports pages.

The navigation requirements for Clinical Quality deviated from the norm. Instead of tabs, their taxonomy depended on a choice box and expand/collapse categories.

Droplist and expanding categories for Clinical Quality reports.

One thumbnail served up data directly from a SQL database just to prove it could be done. Although useful and technically cool, the feature was surprisingly not in high demand.

Why open a report, when you can get what you need from the thumbnail?

From the top

With product use came a yearning for more features. Physician Services again led the way, asking to sort the view by Summary and Detail report types. They also added more reports, so the design changed to maintain clarity by fitting more reports on a page and indicating priority. Tile color gave way to fully expressive thumbnails with curved corners and more metadata like access, report source, training, and updated date.

Letting the thumbnails of visualizations speak for themselves.
More metadata on front and flip side.
Summary and Detail sections, with priority report front-loading and highlighting.


These single page apps survived five years of organizational churn on minimal maintenance. Report analysts maintained the metadata and thumbnails on their own, and code changes over that time were so minor, they could be made directly in production. Complaints were related to the limitations of SharePoint, not the design or code. The product was like a good pair of jeans. It was still comfortable when worn out at the knees. Some users were so attached to it, they continued to use it until forced to move to the new and superior solution.

End-to-end builder using out-of-the-box SharePoint functionalities and client side code. Assisted with categorization, terminology, and website setup conventions.


The SharePoint 2010 production platform cached all CSS and JS files, so they ended up inside the HTML file. This made development fast, and non-developers could understand the code enough to tweak it from a simple text editor like Notepad. The app was made up of six code-behind pages and six SharePoint lists, each with custom list display/edit forms.

This HTM file contained all the web part's HTML, CSS styles and JavaScript code, and it resided in a "scripts" document library on the site along with images and jQuery Core, Tools and SharePoint Services library files. I built and maintained icons as a sprite using Photoshop.


The second release of the product required only minor UI look-and-feel updates. I setup the SharePoint 2010 site with a whole bunch of lists and libraries and integrated the app into SharePoint 2010 as a single HTM file which displayed the documents when called from a Content Editor Webpart on the home page of the site.

This HTM file contained all the web part's HTML, CSS styles and JavaScript code, and it resided in a "scripts" document library on the site along with images and jQuery Core and SharePoint Services library files. I built and maintained icons as a sprite using Inkscape.

Role: SharePoint Builder

Setting: Providence St. Joseph Health

Location: Portland, Oregon

Year: 2013 to present