Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Report guidelines 1
- Thread starter ddeegan
- Start date
Ken Hamady has good resources and is a respected member of this community.
Reebo
UK
Reebo
UK
Mike Lewis
Programmer
Reebo,
Like DDeegan, I would also like to see some documentation for report design guidelines.
You mentioned Ken Hamady's site. I know there is a lot of very useful stuff there, but I don't see anything specifically on design guidelines. Can you point us to a particular document? (I'm not being lazy; I have looked all over the site without success.)
Thanks.
Mike
Mike Lewis
Edinburgh, Scotland
Like DDeegan, I would also like to see some documentation for report design guidelines.
You mentioned Ken Hamady's site. I know there is a lot of very useful stuff there, but I don't see anything specifically on design guidelines. Can you point us to a particular document? (I'm not being lazy; I have looked all over the site without success.)
Thanks.
Mike
Mike Lewis
Edinburgh, Scotland
Mike:
There are several good books out there.
You can get the most recent copy of George Peck's "Crystal Reports 9, The Complete Reference" or a copy related to the version that yo uare using. He also has a good book that came out recently called "Crystal Reports Professional Results".
There is also a good book called "Crystal Reports 9 Essentials" by Jill Howe.
These will give you the basics of good report design. Some of the best knowledge you can pick up beyond that is right here at Tek-Tips. You have the best pool of resources right here in one place.
~Brian
There are several good books out there.
You can get the most recent copy of George Peck's "Crystal Reports 9, The Complete Reference" or a copy related to the version that yo uare using. He also has a good book that came out recently called "Crystal Reports Professional Results".
There is also a good book called "Crystal Reports 9 Essentials" by Jill Howe.
These will give you the basics of good report design. Some of the best knowledge you can pick up beyond that is right here at Tek-Tips. You have the best pool of resources right here in one place.
~Brian
Mike Lewis
Programmer
Brian,
Thanks for those tips. I've got Peck's book (and very well-worn it is too). I'm planning on getting a couple of others.
However, what I (and I think the original questioner) was asking about was not for technical information about Crystal Reports, but general guidelines on the design principles to apply when building reports - partly a matter of aesthetics, but also general guidelines about layout and structure.
Mike
Mike Lewis
Edinburgh, Scotland
Thanks for those tips. I've got Peck's book (and very well-worn it is too). I'm planning on getting a couple of others.
However, what I (and I think the original questioner) was asking about was not for technical information about Crystal Reports, but general guidelines on the design principles to apply when building reports - partly a matter of aesthetics, but also general guidelines about layout and structure.
Mike
Mike Lewis
Edinburgh, Scotland
- Thread starter
- #6
Exactly, Mike.
Sometimes complicated reports can be hard to understand. It looks plain as day to me, but the end users perception may differ.
I was hoping to have more success by incorporating some standardization. Things like...
What should all reports have...
Should page #s be in the center or the right corner
Should a report heading always be centered
What are standard fonts that should be used in a business environment
....things like that, things that may seem trivial when designing the report. I know there are standards for GUIs, I was thinking there must be some for report writing.
Thank
Dave
Sometimes complicated reports can be hard to understand. It looks plain as day to me, but the end users perception may differ.
I was hoping to have more success by incorporating some standardization. Things like...
What should all reports have...
Should page #s be in the center or the right corner
Should a report heading always be centered
What are standard fonts that should be used in a business environment
....things like that, things that may seem trivial when designing the report. I know there are standards for GUIs, I was thinking there must be some for report writing.
Thank
Dave
-
1
- #7
The only standards are the ones that you incorporate. For my current contract, I've created a Crystal Reports Design Standards Checklist document. The document Groups and lists various standards by Category: [ul][li]General Formatting[ul][li]Every report is based on a predefined .rpt template[/li][li]Each report is designed for export to Paginated Text at 55 lines per page and 132 characters per line[/li][li]The default printer must be an HP Laserjet 5000 Series PS[/li][li]The font must be Courier 10[/li][li]etc...[/li][/li][/ul][li]Report Header[/li][li]Page Header[/li][li]etc...[/li][/ul]
Each Crystal Reports section gets its own Category. There are also categories for Database/Data Objects and Client Business Rules. The document is designed as Form with Checkboxes for both the developer and the system tester. Lastly, there is a column for comments on each standard. This is where the developer would justify not adhering to a standard (for example most reports are landscape, but the report in question is a portrait form letter - the justification would be that the design differed from the standard per the User's requirements and specifications).
I implement some version of this standards document for every client. When you work in a full lifecycle development environment, it is important to enforce consistency and adherence to standards. This document requires the developer to adhere to the standards established for the project and provides a checkpoint. Obviously, if a system tester finds that a standard hasn't been met, but was checked off by the developer then there is a disconnect. It may be technology related (the system tester might not have the correct printer and, therefore, the correct font, for example) or it may be laziness.
In order for one of my team to submit a report as 'complete' to system test, they must submit the completed Design Standards Checklist and a custom Release Notes document with the report. The format of the Release Notes document is also standardized.
~Kurt
Each Crystal Reports section gets its own Category. There are also categories for Database/Data Objects and Client Business Rules. The document is designed as Form with Checkboxes for both the developer and the system tester. Lastly, there is a column for comments on each standard. This is where the developer would justify not adhering to a standard (for example most reports are landscape, but the report in question is a portrait form letter - the justification would be that the design differed from the standard per the User's requirements and specifications).
I implement some version of this standards document for every client. When you work in a full lifecycle development environment, it is important to enforce consistency and adherence to standards. This document requires the developer to adhere to the standards established for the project and provides a checkpoint. Obviously, if a system tester finds that a standard hasn't been met, but was checked off by the developer then there is a disconnect. It may be technology related (the system tester might not have the correct printer and, therefore, the correct font, for example) or it may be laziness.
In order for one of my team to submit a report as 'complete' to system test, they must submit the completed Design Standards Checklist and a custom Release Notes document with the report. The format of the Release Notes document is also standardized.
~Kurt
Mike Lewis
Programmer
Kurt,
That's exactly the sort of thing I had in mind. I don't work in a team environment, and my clients - for the most part - do not go in for that kind of formal standard. But I think it would be good for me to work with a set of guidelines along the lines you described. It would help to promote consistency in my own reports, and would indicate to the clients that I take good design seriously.
I'll maybe think about creating a set of report design guidelines for myself.
Mike
Mike Lewis
Edinburgh, Scotland
That's exactly the sort of thing I had in mind. I don't work in a team environment, and my clients - for the most part - do not go in for that kind of formal standard. But I think it would be good for me to work with a set of guidelines along the lines you described. It would help to promote consistency in my own reports, and would indicate to the clients that I take good design seriously.
I'll maybe think about creating a set of report design guidelines for myself.
Mike
Mike Lewis
Edinburgh, Scotland
- Thread starter
- #10
It is hard to define a set of report standards for all reports....there are just so many special cases....the easy reports don't require much anyway.
But here are some things I employ to make my reports more readable (especially REALLY complicated ones) take from these ideas as you will.
1. If the report has special features that are hard to understand...(you will be amazed at how much you will forget if you come back to a report 3 months later)...I put a README formula in the footer of the report...with a background of RED so it will be highlighted design mode and conditionally suppressed with 1 = 1 this way the color stays in design.
The README formula contains all the notes about the report design in comment form....it is not compiled at run time and is not limited to 254 chars.
it is great for future developers to document their changes and keep them in the report...would look something ike this
//Tricky features of this report
//1. ffdsfndsfjdsfdsfd
//2. lskdjklsdfsdlfjldsfjldsjfdsfj
//3. kfjwerjierjewwe
//Maintenance log Comments
//--------------- --------
// 01/10/2003 - JNB Initial creation
// 15/01/2003 - JNB Updated to correct date formula problem
// changed from .....{you get the idea}
2. I use color coding alot in my really complicated reports. Say for example you have a group that can be changed dynamically depending on a parameter and as a result a different detail section will be enabled for each choice and perhaps a group or report footer section will vary.
I will put a small text box in the left cornor of each section that is related to eachother and color them the same. They will be conditionally suppressed with 1 = 1 so they are visible in design but not when run....so all sections relating to param option 1 will have one color and all sections with param option 2 will have another...if a section is common to both they both get a small color box
It makes it so simple to sort out the layout months later...of course the color scheme is documented in the README.
3. I also color code formulas as well....so that I can easily find the Initialize, calc and display formulas in a complicated report.
4. I ALWAYS color code my subreports RED conditionally so I can find them.
I will NEVER forget the 3 hours I spent trying to find a subreport someone had written that was only 1 gridsnap x 1 gridsnap and suppressed. Conditionally color coding them RED makes them jump out in design.
Those are some ideas I use in standardizing some aspects of my reports to make maintenance easier.
Hope this helps you
Jim Broadbent
The quality of the answer is directly proportional to the quality of the problem statement!
But here are some things I employ to make my reports more readable (especially REALLY complicated ones) take from these ideas as you will.
1. If the report has special features that are hard to understand...(you will be amazed at how much you will forget if you come back to a report 3 months later)...I put a README formula in the footer of the report...with a background of RED so it will be highlighted design mode and conditionally suppressed with 1 = 1 this way the color stays in design.
The README formula contains all the notes about the report design in comment form....it is not compiled at run time and is not limited to 254 chars.
it is great for future developers to document their changes and keep them in the report...would look something ike this
//Tricky features of this report
//1. ffdsfndsfjdsfdsfd
//2. lskdjklsdfsdlfjldsfjldsjfdsfj
//3. kfjwerjierjewwe
//Maintenance log Comments
//--------------- --------
// 01/10/2003 - JNB Initial creation
// 15/01/2003 - JNB Updated to correct date formula problem
// changed from .....{you get the idea}
2. I use color coding alot in my really complicated reports. Say for example you have a group that can be changed dynamically depending on a parameter and as a result a different detail section will be enabled for each choice and perhaps a group or report footer section will vary.
I will put a small text box in the left cornor of each section that is related to eachother and color them the same. They will be conditionally suppressed with 1 = 1 so they are visible in design but not when run....so all sections relating to param option 1 will have one color and all sections with param option 2 will have another...if a section is common to both they both get a small color box
It makes it so simple to sort out the layout months later...of course the color scheme is documented in the README.
3. I also color code formulas as well....so that I can easily find the Initialize, calc and display formulas in a complicated report.
4. I ALWAYS color code my subreports RED conditionally so I can find them.
I will NEVER forget the 3 hours I spent trying to find a subreport someone had written that was only 1 gridsnap x 1 gridsnap and suppressed. Conditionally color coding them RED makes them jump out in design.
Those are some ideas I use in standardizing some aspects of my reports to make maintenance easier.
Hope this helps you
Jim Broadbent
The quality of the answer is directly proportional to the quality of the problem statement!
bzzyplayin
Programmer
Thanks Ddeegan for posting the question on report standards. I am also interested in getting some examples of report guidelines and standards that other developers follow.
Just to provide you with some background, I work with AS400 developers, so we are all pretty new to Crystal and never needed to worry about fonts, colors, etc. Since we'd develop reports in RPG on the AS400.... nothing fancy there!
We are currently in the process of upgrading to version 9 and want to begin creating templates and using the repository (for headers, footers, etc.). We felt that this is a perfect time for us to clean up the reports and get a consistent look and feel! We have simply played around with various options and haven't yet decided on any one particular combination (we currently have only about 40 reports).
Rhinok - Can you email the document with examples to me as well? My email is>Enuff2Do@comcast.net
Also, if anyone could provide me with any formatting advice, I would appreciate it!
Thanks in advance,
Kim
Just to provide you with some background, I work with AS400 developers, so we are all pretty new to Crystal and never needed to worry about fonts, colors, etc. Since we'd develop reports in RPG on the AS400.... nothing fancy there!
We are currently in the process of upgrading to version 9 and want to begin creating templates and using the repository (for headers, footers, etc.). We felt that this is a perfect time for us to clean up the reports and get a consistent look and feel! We have simply played around with various options and haven't yet decided on any one particular combination (we currently have only about 40 reports).
Rhinok - Can you email the document with examples to me as well? My email is>Enuff2Do@comcast.net
Also, if anyone could provide me with any formatting advice, I would appreciate it!
Thanks in advance,
Kim
Hi,
we have recently bought crystal reports to use with AS400. The problem I am facing is that whenever I try to extract data from my DB2/400 database, all my character field data are getting converted to hex by itself. The numeric figures come out just fine though the date figures are also converted to numeric with two decimal places. If you can suggest any help it will be greatly appreciated.
Cheers,
Sanjeev
we have recently bought crystal reports to use with AS400. The problem I am facing is that whenever I try to extract data from my DB2/400 database, all my character field data are getting converted to hex by itself. The numeric figures come out just fine though the date figures are also converted to numeric with two decimal places. If you can suggest any help it will be greatly appreciated.
Cheers,
Sanjeev
Mike Lewis
Programmer
Sanjeev,
You accidentally posted your question as a reply to another thread. There is very litle chance you will get it answered that way.
You need to post your question again, as a new thread (do that from the main forum screen). Also, give it a title that will tell people what the question is about. That way, you're likely to get a good response.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
You accidentally posted your question as a reply to another thread. There is very litle chance you will get it answered that way.
You need to post your question again, as a new thread (do that from the main forum screen). Also, give it a title that will tell people what the question is about. That way, you're likely to get a good response.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
writer2000
MIS
I am in the process of writing some crystal standards for our group. I a looking for some more ideas. If you could please send me some of the samples it would be greatly appreciated. Thanks in advance.
Latausha
Latausha
davidwendelken
Programmer
I would love a copy of the guidelines you've been sending out! 
Here's some additional ones as a thank you for your trouble, in no particular order:
1) If you are sorting the data by one or more columns, put the columns you are sorting by on the left.
(Ok, for Arabic, maybe it should be on the right.
This isn't a hard and fast rule, there are valid exceptions to it, but it does make things easier to comprehend right up front.
2) Use the same label for the same data item on all reports unless forced (by layout constraints) to do otherwise. (And then be consistent with the short version of the label when you need to use it again!)
3) If the report has parameters, the selected parameter values should be visible in the report output. This way, someone who picks up a copy of the report knows exactly what portion of the data was included on the report.
4) If you have a numeric value that people might want to add up, don't put anything else above or below it in the same column. Makes it very hard to do that.
5) I view a report as the answer to a question. Make sure you understand the question! Make sure you understand what information is needed in order to take action on a problem revealed by the report - and try to make sure that information - or at least the full key to it - is on the report.
David Wendelken
Here's some additional ones as a thank you for your trouble, in no particular order:
1) If you are sorting the data by one or more columns, put the columns you are sorting by on the left.
(Ok, for Arabic, maybe it should be on the right.
This isn't a hard and fast rule, there are valid exceptions to it, but it does make things easier to comprehend right up front.
2) Use the same label for the same data item on all reports unless forced (by layout constraints) to do otherwise. (And then be consistent with the short version of the label when you need to use it again!)
3) If the report has parameters, the selected parameter values should be visible in the report output. This way, someone who picks up a copy of the report knows exactly what portion of the data was included on the report.
4) If you have a numeric value that people might want to add up, don't put anything else above or below it in the same column. Makes it very hard to do that.
5) I view a report as the answer to a question. Make sure you understand the question! Make sure you understand what information is needed in order to take action on a problem revealed by the report - and try to make sure that information - or at least the full key to it - is on the report.
David Wendelken
synapsevampire
Programmer
I've been through lots of these types of threads, and I still say that there are very few common conventions other than to be consistent and try to leverage resuability and minimize maintenance. One of the posts here was on best practices and I think that people agreed that there isn't such a thing using Crystal, as it's relative to many other factors.
How standards are created will be based on the database/connectivity used, and the requirements of the organization.
My current contract can't use Views because of the database Nazis. This is ridiculous and will add to the cost of doing business significantly, yet the standard is to use Add Commands and try to limit the user to NOT using multi value parameters (in other words make IT drive what the client needs, another stepud notion).
Best practices are relative, although there are some things that are almost golden:
Process on the database server whenever possible.
Avoid proprietary technologies
Set standards and abide by them
Satisfy or exceed your clients requirements
Pay contractors lots and lots and lots of money
-k
How standards are created will be based on the database/connectivity used, and the requirements of the organization.
My current contract can't use Views because of the database Nazis. This is ridiculous and will add to the cost of doing business significantly, yet the standard is to use Add Commands and try to limit the user to NOT using multi value parameters (in other words make IT drive what the client needs, another stepud notion).
Best practices are relative, although there are some things that are almost golden:
Process on the database server whenever possible.
Avoid proprietary technologies
Set standards and abide by them
Satisfy or exceed your clients requirements
Pay contractors lots and lots and lots of money
-k
writer2000
MIS
rhinok,
I am really interested in seeing the Design Standards Checklist and custom Release Notes. Although our standards may differ. I think a checklist that the tester and the developer has to sign off is a great idea. If you could send me a sample I would appreciate it.
hopperjrp@aol.com
I am really interested in seeing the Design Standards Checklist and custom Release Notes. Although our standards may differ. I think a checklist that the tester and the developer has to sign off is a great idea. If you could send me a sample I would appreciate it.
hopperjrp@aol.com
Sorry - I don't frequent these threads as much as I used to! I agree with SV - there are very few common practices, but his points are excellent (even the one about paying contractors lots of money, as long as they are truly expert).
writer2000, I sent you an email from my spam account - preformedmeatproduct|at|<isp>
~Kurt
writer2000, I sent you an email from my spam account - preformedmeatproduct|at|<isp>
~Kurt
- Status
Similar threads
- Question
- Locked
- Question
- Locked
- Question