Custom Reports for WinSwim

We use WinSwim to manage and run swim meets for the MacDolphins and now that our season has started, I have been doing a lot of work with WinSwim and not too much with wp-SwimTeam.  There are some things I need to fix but right now nothing is broken.

A year ago when I started using WinSwim I ended up creating a slew of custom reports mostly to deal with the fact that our pool is one of the few in the area which is a 25 meter pool – most are 25 yards.  We needed times in both meters and yards and the reports which came with WinSwim didn’t really handle it.  So I created a bunch of my own.  The only real downside of using custom reports is it required a file that is installed with WinSwim (language.xml) to be modified.  This was a maintenance headache as it would be overwritten with each WinSwim update.

WinSwim 4.0.21 introduced a new model for custom reports which removes the need to modify the language.xml file (yeah!).  Now each report is paired with a corresponding XML file and they all reside in a directory called “custom” within the WinSwim installation tree.

The reports are mostly geared around Heat Sheets and end of year reports.  To use the new reports, download the ZIP file and unzip into your top level WinSwim installation directory. 

WinSwim Custom Reportsv07-05, last updated on 2009-07-06

For example. in my case, I have WinSwim installed like this:

image

When the reports are installed correctly you will have a new “Custom” menu available in the Report Viewer as a new top level menu item to the right of “Reports”.  Note that the old “Custom” menu under the “Reports” but will still be there and will likely be empty unless you are using the old style of custom reports (which is still supported).

image

Administrative Fields for Users and Swimmers

I had a request to support fields that weren’t visible to the end users when they used the system.  I decided to support these “administrative” fields as I have been referring to them by enhancing the optional fields for swimmers and users to be tagged as “user” fields or “administrative” fields.

When a field is defined as “administrative”, only users with WordPress permissions of EDITOR or higher will have the fields visible.  For all other users, they are hidden.  An Admin or Editor can change the value of the field and it will be saved when the user or swimmer data is saved.

The first practical usage of this is with a team that wants to mark registration fees as paid on a per swimmer basis.  Not the sort of thing you would expose to a parent but useful from a logistics perspective.

Both user and administrative fields are available in reports.

wp-SwimTeam v0.1.371 – UI improvements, Opt-In, Opt-Out

This afternoon I posted v0.1.371 of the wp-SwimTeam plugin on the download page.  This build cleans up some UI issues and adds the baseline functionality for Opt-In/Opt-Out (aka Register and Scratch).

I have been noodling on how to implement the MacDolphins need for an online scratch sheet solution since I started this project.  It was one of the areas we really struggle with.  We’ve had a scratch sheet posted on the bulletin board for people to sign up on but it was ineffective.  We’ve tried using e-mail which worked better but getting the information from the collection point to the heat sheet continued to be problematic.  Hopefully connecting it to the web site will be a good solution to this ongoing problem.

The basic functionality is now working.  When a swim meet is entered into the system, it is characterized as either Opt-In or Opt-Out (the labels can be set from the Options menu).  An Opt-In meet requires all swimmers to register in order to participate.  An Opt-Out swim meet assumes all active swimmers are participating unless the swimmer withdraws from a meet (or subset of meet events).  For the MacDolphins, all dual meets are Opt-Out events and our local invitational city meet is an Opt-In event.

In addition to the new Opt-In/Opt-Out functionality (which doesn’t include reports yet), I made quite a few improvements to the UI, particularly with the messages which are displayed after an action is executed.  I also took care of some CSS issues which were most notable when using the default light blue Dashboard color scheme.  I prefer the grey one which is why I hadn’t noticed the problem previously.

The next phase of Opt-In/Opt-Out will be reporting followed by exporting a meet specific roster in SDIF format.

Reports working again

This afternoon I finished updating the Report Generator so it completely supports the new option model.  Both CSV and HTML reports are working.  Filtering works too but right now only YES-NO optional fields are available as filters.  I am not sure if I will change that or not.

I need to run through some additional testing and then I’ll post a release.  This is enough of a change that I’ll probably bump the revision from 0.0.x to 0.1.x for both the software and database version.

Noodling on the Volunteer System

Over the last couple days I have been thinking about how to manage the volunteer system.  I suspect most teams are like the MacDolphins and the parents of the swimmers are required to complete some level of volunteering in the plethora of roles required to run a swim meet.  But how do you account for the dramatic difference in time each role requires?

I am leaning toward implementing a system where the roles are defined and then assigned some sort of unit value.  Each parent would be required to volunteer for some team specified units and the system would track how many units people worked.  For example, a timer might be 10 units and pizza selling might be 5 units.  If a parent volunteered as a timer at one meet and sold pizza at another meet, they have completed 15 units of volunteer time.  The units per role could be assigned such that the season long jobs (e.g. chair person) might be worth 50 units.

Just an idea, we’ll see where it goes.