The success or failure of a custom-developed report will almost always be judged on how well it matches the requirement, how easy it is to use, and how much time it took to deliver the solution, as well as on the quality and accuracy of the output. Examining a traditional method of producing custom reports might help highlight why it is so difficult to meet user expectations.
The same data is usually reported in two formats: on screen and on paper. On screen, the data is often displayed in text fields or other controls on a form; when sent to a printer, the data appears on paper (although don’t forget that most applications provide a Print Preview feature, in which data appears on screen in the same format that is sent to the printer). Independent methods must be provided for the selection, display, and processing of the output for the screen output and for the printer output. The different methods are often necessary because of the limitations of the software and hardware technology used. As a result, applications are designed to have separate menu options, toolbars, and selection criteria for essentially the same output information. The biggest complication is that because two methods of programming are required for one logical process, the opportunity for errors to creep into the solution doubles. The net result of this dual programming is a disjointed view of the user requirement, forcing the user to think nonintuitively.
User requirements, application complexity and training requirements, technology, and development schedules all contribute to the challenge of developing reports. Each of these issues is discussed briefly in the following sections to help identify alternative approaches for your development projects.