SSW Rules to Better Interfaces - Reports, Charts and Dates

Home > SSW Standards > Rules To Better Interfaces - Reports, Charts and Dates

I've been putting together Development Guidelines for my employer and in the process have reviewed many published standards (in the .Net arena) from around the world. In each category, the suggestions at SSW are always among the best. Leon Bambrick -

Do you agree with them all? Are we missing some? Let us know what you think.

Rules To Better Interfaces - Reports, Charts and Dates

Reports - Do you have a standard Report footer?
Reports - Do you keep Reporting criteria simple?
Reports - Do you always make sure the dimensions All Captions = All?
Charts - Do you make graphs easy to digest?
Charts - Do you use bar graph rather than pie graph?
Dates - Do you keep Time Precision format consistent?
Dates - Do you keep Date Precision format consistent?
Dates - Do you use Calendar controls effectively?

Reports - Do you have a standard Report footer?

When designing custom applications you want to include branding on reports. There are two ways to design a standard footer. As a minimum, you can have a line "Generated from [e.g.] SSW SQL Deploy - www.ssw.com.au".

Or, even better, you can send or keep detailed information about the report for you and your company:

For more details about how to generate a footer like this, check our Rules to Better SQL Reporting Services.
Reports - Do you keep Reporting criteria simple?
1. Have Selection for filters e.g. Date Ranges
2. Have Selection for chart options e.g. Show Legend
3. Don't have selection for chart groupings e.g. By Month or By Product
  - Crystal and Access these are built into the report and it is very complex to have a generic solution.
  - Also it is disorientating for the user to have this as a selection
  More Options for Reporting
Reports - Do you always make sure the dimensions All Captions = All?

When you are carrying out reporting (using Reporting Services) based on some OLAP cube you should change the "All Caption" property of each dimension to be have the value "All". By default the caption for the dimension will be "All " (e.g. All Products). This default is distracting when used in reporting solutions and doesn't particularly clarify anything anyway.

Read more
Charts - Do you make graphs easy to digest?

Graphs are a great way to display data in an easy to follow visual format. Some graphs, however, are easier to read than others. We recommend staying away from 3-D Graphs and keeping it simple! If you have complex data, it's also a good idea to display 2 or 3 simpler graphs rather than one complex one - the aim of the game is to make digesting the information as simple as possible for your audience.

Figure: Good Example - Are your graphs simple to understand?

Figure: Bad Example - When there's more than four preceptual units, a graph becomes hard to digest

Figure: Good Example - You can split your graphs to make them easer to understand
Charts - Do you use bar graph rather than pie graph?

Bar graph provides an easy way to pick the top size items and group the rest.

Figure: Bad Example - Use Pie Graph

Figure: Good Example - Use Bar Graph

Dates - Do you use Calendar controls effectively?

In Outlook, the Calendar control has a number of important features:

Saturday and Sunday are displayed at the end.
Days that have data associated with them are bold
The current day is highlighted with a box

Users are familiar with the Outlook calendar control. When the calendar control is used it should incorporate all of these features of the Outlook calendar control.

: Figure: Bad Example - Calendar Control - Sunday is at the front, today's date is not highlighted, and items with data are not bolded

: Figure: Good Example - Calendar Control - Monday is at the front, today's date is highlighted, and items with data are bolded

We have a program called SSW Code Auditor to check for this rule.

Dates - Do you keep Time formats consistent across your application?

Time formats should be consistent across your application, to give the application a very professional and consistent look.

Figure: Bad Example - Three screens with inconsistent time formats

Figure: Good Example - Three screens with consistent formats
Dates - Do you keep Date formats consistent across your application?

Date formats should always be kept consistent across your application, more importantly, it should be kept consistent with the operating system's regional settings otherwise this will cause significant confusion for your users.

Figure: Operating System's Regional Settings

Figure: Bad Example - Two screens with inconsistent date formats

Figure: Good Example - Two screens with consistent date formats

The best way to do this in your code is to grab the culture information from the application thread and use it to automatically format your Datetime data type. Do not use hard coded datetime formatting strings unless it's absolutely necessary.
```
startTimeTextBox.Text = resultResults.StartTime.ToString("dd/MM/yyyy hh:mm:ss");
                    
```
Figure: Bad Example - using hard coded formatting string
```
'VB.NET
'Initial CultureInfo settings for the application
Public initialCulture As CultureInfo
...
...
txtDateCreate.Text = CType(txtDateCreate.Tag, System.DateTime).ToString(initialCulture.DateTimeFormat)
                    
```
Figure: Good Example - Using culture info to format datetime