Tag Archives: SSRS

Post is related to MS SQL Server Reporting Services.

Print Ready Report

Leave a reply
Print Ready Report

Print Ready Report

Read a print-readiness check-list, apply it during report design and avoid various printing problems. Try it with SSRS, Excel, Word, Visio, BIRT, JasperReports, and any other manual or automated reporting tool.

Have you ever printed a one page document with unexpected empty second page coming from your printer? Have you seen how the report binding makes documents unreadable? Have you seen a great report with no way to know when the data was gathered? Read further and you will never experience these printing problems again.

Following the rules and suggestions below will make your reports looking good on paper, save you toner and paper, make it easier to print, and make your boss a little happier.

  • Set report orientation. Otherwise report consumers will lose time and tons of paper;
  • Set the standard page size to avoid unnecessary automatic resizing;
  • Make sure a printed copy of the report contains:
    1. Date and time when report was generated. Include full four-digit year.
    2. Contact info of report author or publisher: name, URL, email or phone number;
  • If report contains colors print on black and white printer and check shades of gray are distinctive;
  • Keep reports bindable:
    1. Design margins so the report content is fully visible when report is bound horizontally or vertically;
    2. If a report is usually printed on both sides of paper make all margins the same width. Otherwise consider making right or bottom margins narrow to use more space for the report content;
    3. Make top and right margins wider If users may leave notes on the report.
    4. Keep report layout size 0.1 inch smaller than the page size minus margins. This is to avoid empty sheets of paper coming from the printer every time you print the report;
  • Include page number if the report is longer than two-three pages;
  • Consider including total page numbers such as “1 out of 15”;
  • Table reports:
    1. Show table header on every page;
    2. Avoid showing table footer without details on a separate page. Include a line or two of data from the previous page (along with the table header) and add the totals of the table footer;
  • Always use report covers or binders when you share printed reports with your clients, bosses and colleagues. Research available options: from cheap sliding bar report covers to more expensive hardcover and coil binders.

Thank you for reading this post. Try using this checklist during your report design.

Traceability Matrix

Traceability Matrix

Traceability Matrix

Traceability matrix visualizes complex relationships between multiple entities. In this post I will describe traceability matrix and traceability table with graphical examples. Traceability matrix entities can be of one, two or more different types. For example, traceability matrix that shows direct flights between different cities has nodes of the same type (cities). In contrast, the requirements traceability matrix (RTM) helps to trace relationships between two types of entities: requirements and tests.

Complex relationships can be visualized using matrix or table formats. The matrix format allows tracing relationships in bi-directional way, but if the number of nodes is big enough the matrix may be difficult to use or print as it often grows exponentially. The matrix cells show both: existence of relation and lack of it.

A traceability matrix report can use less space and still be useful if there is a way to group nodes. Using the flight matrix example, it may not be practical to visualize the matrix of direct flights between hundreds of cities, but it may be useful to analyze the matrix when cities are grouped by a state or a region. When the nodes are grouped together the matrix cells contain a number that represents the relation count. The example below is a requirements traceability matrix report where requirements and tests are grouped by folders in a test management system:

Requirements Traceability Matrix report

Requirements Traceability Matrix

Traceability table helps to track relationships in one direction only. It uses less space as it doesn’t need to show lack of relations. Additionally the table format allows tracing relationship between three or more types of entities; a good example is a requirements traceability table (RTT) report to trace relationships between requirements, tests and defects:

Traceability Table

Traceability Table

Below is a traceability matrix example that visualizes data from one of my previous projects. This matrix shows defect priority/severity distributions and allows finding anomalies such a blocker defect with the lowest priority. I put the lightning on top of the screenshot to highlight the distribution pattern. From the report design point of view notice that the ‘total’ columns show both percentage and absolute values; pale colors don’t obstruct readability.

Traceability Matrix

Traceability Matrix

Summary: traceability matrix is a very powerful tool. It is commonly used to analyze relationships, connections and associations. It is easy for human brain to find patterns in the data arranged in a matrix layout. The real power of traceability matrix compared to tables is in its two dimensional nature. Look for OLAP cubes if you need even more reporting power.

Thank you for reading this post. Try to fit your data in the traceability matrix layout and see if you find some interesting patterns.

Four rules for designing an ideal report

Leave a reply

During my career as a Software Engineer/Report Architect I have defined several rules for designing automated reports. I always follow these rules and get positive feedback from the report users. I hope these rules will help you too.

Rule 1: Actionable Report

A report should be actionable. That means that after reviewing the report a report user should be able to make decisions to correct an identified business problem. Also the report is considered actionable if it helps to identify areas for further investigation.

Review the report example below that supports a real-estate renting business. The report calculates count of every weekday per year. Potentially years with most weekends would bring bigger rent profit for the business.

Year  Su Mo Tu We Th Fr Sa Days   Year  Su Mo Tu We Th Fr Sa Days
1999: 52 52 52 52 52 53 52 365    2015: 52 52 52 52 53 52 52 365
2000: 53 52 52 52 52 52 53 366    2016: 52 52 52 52 52 53 53 366
2001: 52 53 52 52 52 52 52 365    2017: 53 52 52 52 52 52 52 365
2002: 52 52 53 52 52 52 52 365    2018: 52 53 52 52 52 52 52 365
2003: 52 52 52 53 52 52 52 365    2019: 52 52 53 52 52 52 52 365
2004: 52 52 52 52 53 53 52 366    2020: 52 52 52 53 53 52 52 366
2005: 52 52 52 52 52 52 53 365    2021: 52 52 52 52 52 53 52 365
2006: 53 52 52 52 52 52 52 365    2022: 52 52 52 52 52 52 53 365
2007: 52 53 52 52 52 52 52 365    2023: 53 52 52 52 52 52 52 365
2008: 52 52 53 53 52 52 52 366    2024: 52 53 53 52 52 52 52 366
2009: 52 52 52 52 53 52 52 365    2025: 52 52 52 53 52 52 52 365
2010: 52 52 52 52 52 53 52 365    2026: 52 52 52 52 53 52 52 365
2011: 52 52 52 52 52 52 53 365    2027: 52 52 52 52 52 53 52 365
2012: 53 53 52 52 52 52 52 366    2028: 53 52 52 52 52 52 53 366
2013: 52 52 53 52 52 52 52 365    2029: 52 53 52 52 52 52 52 365
2014: 52 52 52 53 52 52 52 365    2030: 52 52 53 52 52 52 52 365

The report shows that the years with maximum weekend days are very rare – they are at least 28 years apart: see the years 2000 and 2028. That means the potential profit difference is insignificant (less than 0.5%). What actions or decisions can we make based on the data from this report? Have we identified a problem for further investigation? No! This report is nice since it shows information not known before, but it is completely useless for any real business. Sometimes the reporting requirements only appear to be solid. Identify and retire useless reports.

Summary: Design each report to support actions and decisions. Avoid showing “nice-to-know” but useless data.

Rule 2: One Objective for One Report

Design every report with only one objective to reflect aspects of only one major business area. A very complex business area may be covered by several reports linked to each other: the main report shows summary of the business area and a few sub-reports present various aspects of that area.

Enhancing an existing report to support unrelated reporting objectives may decrease the report ability to serve its main objective. As report users get familiar with their reporting solution they start requesting new features and enhancements to the existing reports. Most of these feature requests hide new reporting objectives. Carefully analyze all incoming requests from customers and try to identify new business areas which deserve their own report.

The report “Warehouse Status” shown below is an example of fitting too many objectives into one report. This report presents a list of products with related information: price, return policy and next arrival details.

Warehouse Status Report Example

The report shows useful information in clear format, but different customers will have problems with using this report as the report design has an issue. The report tries to cover use-cases of three different departments responsible for product inventory, order processing and shipment logistics. Since the report space is used to fit unrelated data there is simply no space left to provide all important details to make the report actionable in any of these areas. For example, employees responsible for logistics don’t need return policy data, but they need more details about next arrival. We should split this report into three different reports based on the requirements from three different departments.

Summary: Design each report to describe only one business area.

Rule 3: Report Readability

A well designed report should be easy to analyze on a computer screen or paper when printed. Simple techniques such as graying every second record in a table, rendering table headers on every page, aligning numbers to the right, providing legend to every chart/graph and many more – all these techniques improve the report readability. Not all techniques should be implemented in every report, but all of them should be considered during the report design phase.

The best advice is to learn all those techniques. Read a few books for designing web-pages and printed materials. Most topics described in the design books apply to the reporting industry as well. You will learn which font suites best for titles, headers, descriptions; how to choose colors to highlight report elements; the same color could mean completely different concepts in different cultures.

Organize a usability study to prove that reports are easy to read and understand. If your budget is tight show the reports to your colleagues, customers or friends and think about their feedback. Remember about accessibility. People with eye sight disorders, such as color-blinding, may struggle with badly designed reports.

Summary: Know your report customers. Learn the design techniques.

Rule 4: Amount of Data

A report should contain certain amount of data to be actionable. Too much data hurts readability while lack of data makes the report less actionable. It is difficult to define the “ideal amount” of data, so the example below helps to describe this rule.

Consider a report that shows information about products stored in a warehouse. The report shows all the products with their 20-30 properties and description. Information about one product fits in half of a printed page and provides all the needed data to warehouse administrators about a particular product. The problem with this report is that it shows a long list of products that, if printed, may spread across hundreds or thousands of pages. This report is not possible to use without computerized search/filter functionality or without “table of contents” if printed. This example describes the product catalog, not the actionable report. Don’t be confused by used technology, the same technology can be used to implement catalog systems and reporting solutions.

If your reporting solution contains this type of reports don’t throw them away, add filtering parameters, table of content or interactive navigation. Add new actionable reports to the related business areas.

If your report contains details that are shown on multiple pages consider adding short summary to the first page of the report. See the example below:

Report begins with the short summary.

Summary: Avoid very long reports.

Thanks for reading this article. Now try to design your ideal report!

Feel free to share your rules in the comments below.