I made a few updates to the school reports at the request of the researchers.

• Added a save feature so that packet/item selections for a report can be retrieved at a later date.
• Added the ability to set thresholds that must be met before the script will include statistics in the report.
• Updated tables to reflect changes in displayed information and formatting.

In regards to the above changes, the save feature is of particular note for it inscrutibility. While the technique used to save/retrieve the report setting is adequate, the code to enable this functionality is not well-implemented. Unfortunately, time constraints required a fast, rather than best, implementation.

As modifications are requested this script is getting to be a little harder to work with. The code was created over the course of a week or two back in January. I was able to make quick work of it by using some concepts I initially worked out for summary table generation (and based on discussions with Brian W). While the data is stored in a psuedo object-oriented format, the script itself is fairly linear in design. If more modifications are requested the script may need some rewrites to enable a bit more flexibility.

The number produced by summary table 8 in the items utility were not quite correct. The researchers noted that the means by which calculation of answer selection was performed was not quite as they wanted it.

Luckily table 8 uses a new summary table generation technique I borrowed from the school reports. The data, display, and summarization code is segregated to a certain degree (though not as much as would be preferred). This allows me to update one aspect of the script without having to monkey around too much with other aspects.

The data is currently stored in a data array that is organized to allow for relatively easy access. The summary information is currently compiled inline in the code. While this isn’t ideal, the method used (summary arrays) should allow for better segregation in the future. The calculation of concern is stored in its own function, answer_selected(). That function includes some basic versioning capability and so I was able to add a new version of the calculation that matches the researchers expectation without changing anything else in the code.

I think a modification of this technique would work well for all tables in the utility and should not require significant investment in development time. As additional tables need work I may investigate adding them as components of the new summary table script (summary_table.php).