Google+
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 on 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 webbased 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 new 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 on 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 webbased 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 new category for that report.
Comments
as usual there is no fixed answer <g>.
Aggregating data is a domain where Crystal is very good.
Also using LEI6/DECS works VERY well
It depends what you need. The trick is: aggregate as early as (possible means: making business sense!!!!), pull the data as asynchronous as possible, use some smart triggers/procedures for aggregating. The XML stuff can be used for the final formatting:
let the data result in an XML document, render it using XLST and store it as a MIME object in Notes. Use hyperlinks notes:// to activate the drill-down from this result.
<advertisement>Hire TAO consulting for a development coaching and architecture review</advertisement>
Hth
Posted by Stephan H. Wissel At 02:11:27 On 03/23/2004 | - Website - |
Posted by Stephan At 15:21:34 On 08/22/2003 | - Website - |
I am evaluating the same line of products that you have mentioned. Essentially, our application requires aggregation of data from various databases(which could be on different servers) and consolidating that data in a report.
Any input from you regarding which would be the best reporting product to achieve the above, will be greatly appreciated.
Thanks in advance,
Shikha.
Posted by Shikha At 17:53:27 On 03/22/2004 | - Website - |
In your words "I like Crystal Reports, it's siblings" what products u mean by siblings ?
Ramasamy
Posted by Ramasamy At 19:09:32 On 08/21/2003 | - Website - |