ReportTracker

Managing a large reporting footprint is a common problem in large corporations. Enter ReportTracker. ReportTracker is a web-based app that is designed to catalog the hundreds of reports that we develop and support. For this app, we defined three customer segments that needed to be satisfied.

1. Front Line Helpdesk Analysts – the people who first triage and research questions from users.
2. Business Analysts and Developers – the people who define requirements for new reports and perform deep analysis existing ones.
3. End Users – the people who use the reports to manage their lines of business.

With these in mind, we met with members from each group. These meetings began with dialogue about the types of questions they needed to answer. Though my team had developed a working prototype, we wanted to independently verify our assumptions before presenting our work.

Luckily, our prototype tracked closely to their needs. We did identify one key area where we could improve their experience. Our research found that their search strategies were highly variable. One group preferred hierarchical navigation whereas another preferred text searches. Furthermore, search methods varied depending upon the questions being asked.

With this in mind, we focused on exposing different yet complementary methods for accessing the information. This included:

• A hierarchical, fixed taxonomy: this reflected the nested directories that physically stored the reports.
• A controlled vocabulary: this reflected the fields returned, parameters used, databases queried and other non-ambiguous metadata
• A keyword system: this reflected the tags that were used to annotate the reports. This will also help us cluster similar reports on the fly.
• A qualified search: this reflected the text search that a user can “tune” to restrict results to only certain metadata elements, like field names

The wireframes at right illustrate these concepts.

fig 1 – Wireframe for the report display page. Each report is annotated with metadata such as field type and keyword. This enables users to find reports that are similar to the one displayed

fig 2 – Detail of wireframe. Each report is categorized by a structured taxonomy (hierarchy), fixed vocabulary (input/output field types), and a folksonomy (keywords).

fig 3 – Wireframe for the text search interface. By default, the search is full text of each reports' metadata: description, fields, keywords, hierarchy, and notes.

fig 4 – Detail of text search interface showing filters and ordering controls. After results are returned, the user is able to limit the search by a series of predefined fields. In addition, they can group and order the results based upon report type, date updated, or status.