Ban The Reports!
I do a lot of requirement analysis and software specifications. It is exiting work because you never know what you will get in the end. Researching what is needed includes contextual enquiries, workplace artifacts, paper prototypes, focus group, competitor analysis etc. Since no system is an island any more users have certain expectations. One of it I find very funny/irritating/stupid/brainwashed/unreflected/conditioned*(*make your pick): "We want reports". I usually tell users in the new system: " Reports are forbidden!" After the panic attack settles I explain why. Don't get me wrong: Software that creates reports is not forbidden. I even made them part of my standard solution building blocks (I like Crystal Reports, it's siblings, Intelliprint (for Notes), PDFPump and ShowBusiness Cuber ). However I stand firm: Ban the Reports!So how (= the efficient short form in Singlish for: Hhm. I do not understand, it doesn't seem obvious, could you please explain and make your point)?
Let's look a little in the history of reports. In the beginning there were punch cards and printouts. We were preached I-P-O (not the stock game) Input Processing Output. There was no way, but a printed report to get something out a computer. Then came the terminal. With it's incredible 80x25 character output it was no match to the paper used for reports. Since then we are used to develop our dialogue systems and then in a separate step design our reports.
What's wrong with this approach?
Mainly two items: first it is based on the assumption, that our business documentation is still living mainly OUTSIDE of computers. Secondly you miss a big chance to get your data model right. I witnessed a number of projects where the reports weren't taken into account until late in the project (reports?- The report software package does it!) and the projects failed. The so called paper artefacts give you enormous clues where the special needs of the systems are. (On of my best tricks: look for documents/reports where there is a lot of handwriting added).
How to do it better?
Integrate it. For every report there is a business case (sometimes strong, sometimes weak like "We always print one of these) and question, so make sure your interactive system can answer easily every of these questions. With the power of hyperlinking (hyperlinks are not limited to browsers) you can build interfaces, where any item in a list could become the new information category. Then just add a "Print this" button and there you are. If your application is web based you even might not need this, a proper formatted css stylesheet for print will do.
There are examples
Intuit's Quicken goes a long way there. Wherever you are, you can call up a report and drill down until you are back at an single entry. When you use Crystal Reports to do a web report, it provides the drill down until you link it back to a single entry. I think it's a step in the right direction, that could be followed by a number of additional steps: Make it seamless, reports (until printed) should look like the rest of the application. Allow (if authorized) changes as early as possible, so you don't need to drill down the whole information tree. Make change of the report parameters as modeless as possible (e.g. when you drag an line item to a category it becomes the n ew category for that report).
Let's look a little in the history of reports. In the beginning there were punch cards and printouts. We were preached I-P-O (not the stock game) Input Processing Output. There was no way, but a printed report to get something out a computer. Then came the terminal. With it's incredible 80x25 character output it was no match to the paper used for reports. Since then we are used to develop our dialogue systems and then in a separate step design our reports.
What's wrong with this approach?
Mainly two items: first it is based on the assumption, that our business documentation is still living mainly OUTSIDE of computers. Secondly you miss a big chance to get your data model right. I witnessed a number of projects where the reports weren't taken into account until late in the project (reports?- The report software package does it!) and the projects failed. The so called paper artefacts give you enormous clues where the special needs of the systems are. (On of my best tricks: look for documents/reports where there is a lot of handwriting added).
How to do it better?
Integrate it. For every report there is a business case (sometimes strong, sometimes weak like "We always print one of these) and question, so make sure your interactive system can answer easily every of these questions. With the power of hyperlinking (hyperlinks are not limited to browsers) you can build interfaces, where any item in a list could become the new information category. Then just add a "Print this" button and there you are. If your application is web based you even might not need this, a proper formatted css stylesheet for print will do.
There are examples
Intuit's Quicken goes a long way there. Wherever you are, you can call up a report and drill down until you are back at an single entry. When you use Crystal Reports to do a web report, it provides the drill down until you link it back to a single entry. I think it's a step in the right direction, that could be followed by a number of additional steps: Make it seamless, reports (until printed) should look like the rest of the application. Allow (if authorized) changes as early as possible, so you don't need to drill down the whole information tree. Make change of the report parameters as modeless as possible (e.g. when you drag an line item to a category it becomes the n ew category for that report).
Posted by Stephan H Wissel on 16 August 2003 | Comments (4) | categories: Software
stw