User Interface Standards—Reports

<< Click to Display Table of Contents >>

Navigation:  Other Topics > Smart Access 1996-2006 > Mar-2002 >

User Interface Standards—Reports


Dennis Schumaker


Many of what you think of as reports probably aren’t reports to users—which makes life difficult for both of you. Dennis Schumaker shows how to create reports that make sense to your users, along with the code to implement those reports within a set of standards.


AS Access programmers, we’re all familiar with

the need to create reports in our applications.

However, to a user, the concept of a report is

somewhat different. A user thinks in terms of an

invoice, a purchase order, a check, or some other type

of document. These items are all reports to a

programmer, but, to the user, they’re distinctly different

things. Many programmers tend to think of all of these

items as reports and, therefore, group these items

together in an application in a reporting area—similar

to what’s shown in Figure 1. This isn’t necessarily the

best location for all reports within an application.

Several years ago, our firm implemented

QuickBooks in our accounting department. Writing

checks in QuickBooks wasn’t the most intuitive process.

In the accounts payable portion of the application, the

user made checkmarks by individual line items to

identify items to be paid. After that activity was

completed, though, the user had to exit that portion of

the application and enter the “reporting” area to print

the checks. That wasn’t exactly intuitive to me, but, to

the programmer who wrote the code, a check is a

report. As a user, I’d expected to be able to print the

checks from the same location in the application where

I’d identified items to be paid. In my mind, identifying

items to pay and then paying those items are all part of

the same business process. Why should I have to go to

several different places in an application to get that one

job done?


By critically looking at applications that we’d

developed over the years, we recognized that

there were three elements of reports that needed

to be addressed as a part of our user interface

design standards:


Location: Where do you put the reporting functions

within your application? The simple approach is to

locate all the reporting in some type of report

module, but that may not be the best option from a

user’s perspective.


Format: What standards are you going to implement

to manage the appearance of your reports? For

instance, will all reports have “page X of XX”

appear in the same location, a date printed in the

same location, the titles in the same font, and so

forth? How will you keep your documents’

appearance consistent?


Selection: How will the user select the specific

information to be contained in the report? In most

cases, the user wants a report to show information

just for certain records, sorted in a specific way, to

varying levels of detail, and so on.


At my company, we determined it was necessary to

develop some standard user interface design concepts

for addressing each of the issues identified here. The

CD collection sample database that came with Access

was reprogrammed to demonstrate the standards and act as our gold

standard. This article will both discuss these standards

and show the code that implemented them, using this

simple database as an example.


You may disagree with the standards that we

developed, and the only useful part of this article for

you may be the code and programming techniques that

I’ve included. However, the issues that we addressed

are issues that your users will have also. Even if you

don’t intend to use our standards, you’ll need to decide...



Figure 1.

Reports bar.


Read More Here:

User Interface Standards-Reports