WorkFlow Thoughts

I am working on creating a new library and template workflow process, and I wanted to share my thoughts with the gINT group, to discern, if it good or bad idea or if it is already done.

 Problem: numerous varieties of log reports each with different data output

Goal: create only 2 reports, one landscape and one portrait using dynamic and smart entities while giving user control on output parameters

My Solution: create tab that records various graphing and output condition and control output of data.  Make it possible to record all data related to project and output if selected.  Set up values those are selected during the input phase (ie, SPT type, becker/cone) and certain options that are enabled during output phase (ie, draft stamp)

 An example:

Currently there are 3 borehole logs all almost identical with one exception one reads on the SPT graph headers as, “blow count” other reads “SPT N60” and last reads “Becker Hammer”

 The value for all graphs are recorded under the same field “Sample.SPT” the user pick which log to print on depending on how the data was recorded on paper form.

 By creating tab show below, the user can select which type of penetration test was done and the report design using output condition can hide one header and display another.

 

Parents
  • 5.  I would still favor multiple templates rather than control for a single automated morphing template embedded in the project file.  Naming the templates is key so for your example of SPT you could have output templates named as follows

    STD      the standard template that plots any data that is there

    STD-N    does not plot uncorrected blow counts

    STD-N60    does not plot N60

    STD-Becker        does not plot becker

    STD-N60-Becker     does not plot becker or N60 (ie only plots uncorrected blow counts)

    STD+MC    standard plus includes second plot of moisture content/atterburg

    etc.

    You do not need to do one for every possible combination/ permutation, just those that your users frequently use.  Creating each is a simple matter of copying the STD template to a new name and making the changes.  Yes, if you make a change to one that effects all in the library, you have to change them all but that is easily done with copy and paste. If you have rogue users that insist on an unusual combination (and we all have those); they make their own library with their initials that has their combination in it. (Don't burden the rest with one user's hangup)

    The longer descriptive text shows up in the description field of the pulldown when you select an output template to use; so the user does not have to remember the criptic template naming system.  The shorter template name gets printed on any output log through your tracking block so it is allways recoverable by another user if you need to reprint the log.  This allows the user to select how they want the output to look from the output tab and easily preview several options without having to change the input file

    I think what you might find with storing the output options in the project file is that user A will print out the logs for a report, user B will want the logs with SPT N60 data only for analysis so they wil go and change the output options in the data file which gets saved immediately but doesn't get changed back when user B is done.  User A comes back to correct the spelling of "grey" on one log and wonders why his log now only contains N60 results. This defeats the purpose of storing the print options in the project file.

    7. If your color symbols include black lines over solid color fills (as many do), printing gray scale makes the entire symbol an undecipherable mass of black once it is copied and recopied a few times.  That is the reason I have the second color library.  I only use the color library for producing figures that go into presentations or other media where it can be guarenteed that the output will always remain in color.  If your color symbols are composed of colored lines over a white background, your method works fine.

    Just my thoughts.

  • I have always preferred to use Smart Log reports whenever possible instead of have numerous copies of very similar Log reports that only vary by a small number of entities. Users can be confused by similar names for the Log reports and if not careful can select the wrong Log report and end up wasting time and paper after they reprint with the correct Log report. A worse case can happen if the wrong Log report is selected and nobody catches the error and the Log reports go out in a published report.

    So, there are reasons to create and use Smart Log reports whenever possible.

    On the other hand, if you have created Log report names as you suggest and you have provided descriptions that help the user select the correct Log report your method also works.

    As was noted in a previous posting one problem with multiple similar Log reports is what happens when you need to make any across the board design edits/changes? If you have many Log reports you need to make the same changes to each report which takes time and allows for a missed changed or two to occur. Yes copying and pasting helps but it is not always the best method.

    This problem is lessened or eliminated with the use of Smart Log reports.

    Switching back again, if you want to have (and maintain) multiple similar Log reports consider using Internal Log Blocks for the entities that are exactly the same on all (or several) of the Log reports. That way, if you need to edit/change one of these entities you only need to do it in the Internal Log Block.

    Regarding maintaining two library files, one for color and one for black and white.

    Have you tried changing the "Printer colors option" setting on the Output tab under System Properties?

    It has worked for me. This setting is stored in the Setup.gsh file and is usually unique to each user.

    System Property changes usually require you to restart gINT for the changes to take effect because the Setup.gsh file is read when gINT starts up.

    Dave...

Reply
  • I have always preferred to use Smart Log reports whenever possible instead of have numerous copies of very similar Log reports that only vary by a small number of entities. Users can be confused by similar names for the Log reports and if not careful can select the wrong Log report and end up wasting time and paper after they reprint with the correct Log report. A worse case can happen if the wrong Log report is selected and nobody catches the error and the Log reports go out in a published report.

    So, there are reasons to create and use Smart Log reports whenever possible.

    On the other hand, if you have created Log report names as you suggest and you have provided descriptions that help the user select the correct Log report your method also works.

    As was noted in a previous posting one problem with multiple similar Log reports is what happens when you need to make any across the board design edits/changes? If you have many Log reports you need to make the same changes to each report which takes time and allows for a missed changed or two to occur. Yes copying and pasting helps but it is not always the best method.

    This problem is lessened or eliminated with the use of Smart Log reports.

    Switching back again, if you want to have (and maintain) multiple similar Log reports consider using Internal Log Blocks for the entities that are exactly the same on all (or several) of the Log reports. That way, if you need to edit/change one of these entities you only need to do it in the Internal Log Block.

    Regarding maintaining two library files, one for color and one for black and white.

    Have you tried changing the "Printer colors option" setting on the Output tab under System Properties?

    It has worked for me. This setting is stored in the Setup.gsh file and is usually unique to each user.

    System Property changes usually require you to restart gINT for the changes to take effect because the Setup.gsh file is read when gINT starts up.

    Dave...

Children
No Data