Planning Your Report Design in Microsoft SQL Server 2012 Reporting Services

  • 4/15/2013

Developing standards

When your reports have a consistent look and feel, users know what to expect when they view a report and can focus on its important elements rather than spending time trying to figure out how to use the report. Similarly, during the report development cycle, standards provide clear guidelines that you can apply to your report quickly without resorting to trial and error to see what might look good. When you have a set of standards established, you can create a variety of templates with common elements in place to shortcut the development process, as we explain in the Knowing your audience section of this chapter.

If you don’t already have reporting standards already established in your organization, consider defining standards for the following report elements:

  • Fonts Use a single font family. Be consistent with font sizes for different elements. For example, you might use a 10pt font for detail records and a 12pt font for column headers. Use 14pt or 16pt for titles. Use smaller fonts for text in page headers and page footers. Consider using a lighter shading for text in page headers and page footers, such as gray rather than black, to reduce the emphasis on the text. The user’s eye should be drawn towards the primary information on the report through the use of larger fonts, darker colors, and bolding where appropriate.

  • Colors Use a consistent palette of colors for text and elements (other than data visualizations) that place color onto the report, such as lines, borders, or fill. Ideally, colors should be soft and neutral and should not distract from the information on the report.

  • Logo If your company has a logo to include on reports, upload it directly to the report server and then reference it as an external image in each report by using its URL access path (described in Chapter 35). That way, if the logo changes in the future, you can replace the file on the report server without the need to update each report individually.

  • Page Header Include a text box to display the report title and another text box to display the page number and total pages (such as Page 1 of 3). If you prefer, you can place the page number in the page footer. Suppress the page header on the first page if using a text box to display a title on the report body. Use a font smaller than the detail row fonts in the report.

  • Report Header The report does not include an explicit report header. We use this term to describe any report items, such as a free-standing text box, a rectangle, a line, or an image, that display at the top of the report in the body above a data region. The report header displays only once in the rendered report at the top of the first page. You can use this area to display a title and supplemental information as a subtitle, such as parameter selections and a date. Use a large font for the report title and a slightly smaller font for the subtitle.

  • Group Header or Footer Use a consistent styling for group headers and footers when you include them in a Tablix. Typically, you use a bold font to distinguish headers and footers from details. Consider using border or background color properties as another means to differentiate group headers and footers from details. Decide whether to include totals in the group header or footer. You should be consistent with the placement of totals in all reports.

  • Page Footer Include a text box to display the report execution date, report path, and the page numbering if you don’t include it in the page header. Use a font smaller than the detail row fonts in the report.

  • Margins Set a minimum margin of 0.5in on each side of the page.

  • Parameters When defining a common set of parameters across multiple reports, use the same sequence in each report.

  • Calculations Decide how to handle a potential divide by zero error. You might use a conditional expression to test the calculation first and return a default string such as N/A or a dash (-).

  • Empty strings and NULL values You should use a consistent rule for handling empty strings or NULL values returned in the dataset. You might prefer to display nothing, convert numeric data types to a 0, or display a string. Whatever you decide to do, be consistent.

  • No rows If it is possible for a dataset query to return no rows, you can display a message to the user by setting the NoRowsMessage property of the data region. If you leave this property blank, the data region does not display. If it’s the only element in the report, the user might not realize the problem is related to data and might think that the report server has failed to render the report correctly.