Our 2011 Summer Season is over and I will actually have some time to get back to work on wp-SwimTeam. I find it hard to work on it during the season as I spend a lot of time doing swim team stuff. Other than fixing something serious, I don’t have much free time to work on the plugin during the season.
But now the season is over and I won’t be working with our coach on line ups, spending time at the pool, etc, and I can spend some time on it again. After our season there are a number of things I want to implement that I know we need for the MacDolphins:
- GUI improvements – there are a number of places the GUI can be confusing and needs some help. I also hope to add some icons to make things a bit more intuitive.
- Export Meet Entries – all of the information can be stored with wp-SwimTeam, there is no reason why a Meet Entries file can’t be exported per the SDIF specification.
- Swimmer Reminders – similar to the volunteer reminder e-mails that can be sent in bulk, I plan to add the ability to send out swimmer reminder emails. I am hoping that these reminder e-mails will improve the scratch process for us and eliminate our no-shows.
- Results – I have some work done (see the Flip-Turn demo) but do not have it integrated with wp-SwimTeam yet. It isn’t complicated work but there is a lot of it to do.
- Hy-tek compatibility – there is some work done by others that should enable better Hy-tek compatibility. I am hopeful that I can actually generate and/or process Hy3 and HYV files for entries, result, and events.
- New Theme – the MacDolphins theme needs to be updated. It is based on the Sandbox theme and WordPress has evolved quite a bit since Sandbox was developed and even my extensions to Sandbox for the Sandbox-SwimTeam theme are showing their age.
Several clubs, including my own, have asked if I would add a feature to send out reminder e-mails to people for the Jobs they have signed up for. Today I implemented this feature and am in the process of testing it on the wp-SwimTeam Demo site.
The Job Reminder e-mail will look fairly similar to a Job Sign Up e-mail and will be sent when the Admin chooses to initiate the action. E-mails can be controlled to limit who receives them based on the Job Duration (Full Meet, Partial Meet, Full Season, etc.). In most cases, the Reminders need to be sent out to the people working the Meet Jobs.
Look for this update in the next day or so after I’ve done a bit of testing with it.
Over the past week or so I’ve been working on some new functionality that is finally ready to go. The opt-in/opt-out module has been based on strokes since the initial implementation and this model worked well for the MacDolphins but some other teams prefer to register (or scratch) swimmers on a per event basis.
Events have been supported for a while but other than adding them to a swim meet, nothing has been done with them. The existing event functionality is the basis for the results work I hope to complete some day. Because the Event information is already defined, allowing the Opt-In/Opt-Out module to be based on the actual events was pretty straight forward. There is a new setting on the Options->Swim Team tab which controls which Opt-In/Opt-Out model wp-SwimTeam uses (Event or Stroke). By default it will continue to use Stroke since that was the original functionality.
The new functionality had a ripple effect across much of the plugin, causing changes to the Reports module and other places too. While working on the Reports I decided to expose the Job Assignments and Swimmers Reports for all users however non-admin users will only see their own job assignments or their own swimmers. This new functionality also came from one of the MacDolphins parents who wanted to be able to see which jobs she had signed up for. In the same conversation, another parent asked me if I could make it so she could see if she had scratched her swimmers. These two requests led to exposing some of the Reports in a limited fashion to all users.
The last major feature is the ability to run a report that shows the parents of active swimmers and their status against the volunteer (jobs) commitment set by the team (set it to zero for no commitment). This is a feature our volunteer coordinator has been after me to implement for some time. While the Report works fine, it is a little slow, particularly the first time it is run so be patient.
The new version modifies the database tables so PLEASE BACKUP your database before you install it. I don’t expect any issues and I’ve been running it on the MacDolphins site for the last two days but it is always a good idea to backup your database before upgrading.
There are still some things to improve – I’d like the list of events a swimmer can be registered for be limited to the events for their age group but don’t have good solution for that right now. I am considering using icons across the action bar instead of the drop down menu. I had moved away from buttons because they didn’t fit but the dropdown actions are confusing so don’t be surprised to see icons in the near future if I can find some I like!
The WordPress plugin repository has been updated so the plugin should begin to auto-update soon too but in the meantime, you can find the latest release on the download page.
This evening I finished the Job Commitment Report. I am not sure why but I had a tough time getting going on this one. It will appear as a new tab on the Reports menu and will report the total number of credits a user has committed to for the requested season. The report is limited to the users who have swimmers registered for the specified season.
While working on this new functionality I also found a couple of minor bug which I have also fixed. One of the bug failed to account for a swimmer unregistering for a season so they still would have been seen as active.
I hope to have a release out in the next day or so.
I’ve made a fair amount of progress today on the new Opt-In/Opt-Out Event model. One of the big benefits of this model is it will facilitate being able to generate a Meet Entries file (SDIF) which could be consumed by Hy-tek Meet Manager or WinSwim.
The meet event information has been in wp-SwimTeam for quite some time but I’ve yet to do anything with it as other things, like the Jobs system, have taken priority. Knowing which swimmers are registered for which event will make the generation of a Meet Entries file fairly straight forward to implement.
I’ve had an ongoing dialog with a team in Texas using wp-SwimTeam that has a much different usage model for participating in Swim Meets than the MacDolphins do. Instead of registering or scratching for a meet, their team has their swimmers register for particular events. In speaking with a parent of one of our year round swimmers, they do the same type of thing for their year round meets.
Wp-SwimTeam doesn’t currently support this usage model but I can see the need to do so. The system already allows the definition and assignment of events to a swim meet, it needs to be extended to allow swimmers to register to particular events instead of the global Opt-In/Opt-Out option which is currently available.
I don’t plan to eliminate the current usage model because it works well for our swim team but I plan to extend it by allowing what I am referring to as the Opt-In/Opt-Out usage model which will either be by Stroke (the existing model) or by Event (the new model).
Fortunately the data model I set up when I first implemented Opt-In/Opt-Out will handle this change fairly easily with one exception. For some odd reason I called the field in the database which stores the stroke code ‘eventcode’. This was a bad idea and I am going to change it to ‘strokecode’ in the next release of the plugin which will cause a bump in the database version. This isn’t the first time I’ve changed a database column name so I am not too worried about it but I wanted to be up front about what I am doing and why.
In the current Opt-In/Opt-Out Stroke based usage model a user can start from a swim meet and update all of their swimmers on a per meet basis or they can start from a swimmer and update all of the meets on a per swimmer basis. This will remain the case.
However, for the Event based usage model all action will have to be initiated from the swimmer, it will not be possible to update multiple swimmers for a single meet. This change is due to the swimmers being in different age groups so the events have to be relevant to a swimmer which isn’t possible (or easy anyway, I guess anything is possible) for multiple swimmers.
What about swim ups? I am not sure how I want to handle swim ups right now. In the first implementation I will allow an Admin user to register a swimmer into any event but a parent/guardian (standard user) will only be allowed to register their swimmer for the events that correspond to the swimmer’s age group.
Feel free to comment on whether or not I have missed anything and I am looking for someone to validate the usage model once I have it up and running on the wp-SwimTeam Demo site.
The major feature that I had been working on which I didn’t complete is the ability to generate a Jobs vs. Commitment report. The Jobs module allows each job to assigned some number of credits and there is a setting to set the minimum number of credits each user is responsible for. By default the system will use zero which means there isn’t a minimum. In the latest release, when a user looks at their My Jobs tab, it will show the jobs they have committed to and sum up the credits. If the sum of the credits is less than the minimum, an error notification will be displayed for the user.
Right now this message is only displayed on the My Jobs tab but an administrator will also see it when view selecting the Jobs action for any user from the Manage->Users tab. I had given some thought to displaying the notification anytime a user logged in but have conclude that would be too intrusive. I may make it an optional setting at some point though.
The one thing I haven’t figured out is how to handle a situation like we have with our own team. On our team we ask each family to volunteer four times (four credits) for the season regardless of how many swimmers they have. If both parents are in the system (primary and secondary contacts) right now they would be erroneously flagged if each signed up for two jobs because together, they have met our requirement.
Reporting job commitments versus user is pretty easy and I will do that in the next few days but I have also considered reporting job commitments versus swimmer so that both contacts can be accounted for. In speaking with some teams locally, they require two volunteer commitments per swimmer so that is yet another permutation to account for. In the short term I will likely only report commitments versus users and leave it at that for now and revisit it after the season as there are some other things I need for our season which starts in three weeks: Results, Meet Entries, and some work on WinSwim/Hy-tek interoperability.
I have one more feature to add to the Jobs module before I consider it complete. I have a request to be able to send out Reminder Notifications on a per swim meet basis which should be pretty straight forward to implement and I hope to have it done in the next day or two.
Once that is complete, I need to decide what to do next. I have a couple of choices.
- I’ve had a couple requests to be able to import a roster into wp-SwimTeam. I don’t think this will be too difficult technically but it does require a couple decisions. Since swimmers in wp-SwimTeam are connected to parent or guardian users, what WordPress userid would the imported swimmers be connected to? The obvious choice is the Admin user or user running the import. Swimmers could then be updated at a later time to connect them to the appropriate WordPress user if/when it exists.
- Import results. This has long been on my to-do list because the MacDolphins need it. I’ve been working on processing results off an on as a side project (see Flip-Turn) with the intent to fold that work into wp-SwimTeam when it is functioning and useful. I already have a lot the functionality working and the GUI will look familiar to wp-SwimTeam users but I have yet to tackle relays and really push the robustness of the SDIF parsing.
- Hy-tek/SDIF compatibility. This is also something I need for the upcoming season. Anyone who has read much of this blog knows that I am not a big fan of Hy-tek and their goofy checksum and weak support of SDIF. Since it isn’t likely to change and lots of teams use Hy-tek, we need to resolve the data exchange problem. This issue may be the highest priority for me personally and I’ve debated whether to build some functionality into wp-SwimTeam to try and resolve sharing data with Hy-tek teams.
Comments and suggestions are welcome. I try to incorporate suggestions quickly if I can.
WordPress 3.0 introduced a concept called Contextual Help. Contextual Help provides a mechanism for plugins to hook into the standard WordPress Help system. This is pretty cool because it provides a way to provide Help that is consistent with the WordPress Dashboard.
I’ve had something I’ve called Guidance on almost every page and tab through the plugin and while helpful, it tends to clutter up the interface. I had a question from our swimteam’s volunteer coordinator about adding more help to the page and I was worried about adding even more clutter. I tried a couple experiments with a jQuery Dialog solution but I wasn’t happy with the results. It was then that I wondered if I could make use of the existing Help button in the Dashboard as it is always there on the Dashboard.
After a bit of reading and some experiments I was able to have custom content displayed within the Swim Team Dashboard pages. However, trying to have different content for each tab was a little more of a challenge. I ended up solving this problem using a simple jQuery script to swap the default content with some tab specific HTML. Awesome! Elegant Help solution achieved!
I am now in the process of retrofitting this new model for every page and every tab which will take a little while. I expect I will have a build available in a few days but in the mean time, here are a couple screen shots to get an idea of what this new Help model will look like.
A few weeks ago I mentioned that I had started working on a new swim team project. I am calling it Flip-Turn. Flip-Turn is a basic PHP/MySQL web application which allows a swim team or swim association to publish swim results on the web in a format that is easy to navigate and view.
Dealing with results has been the last real big hole in wp-SwimTeam and I’ve started working on it a couple times only to abandon it because I didn’t like where it was headed. Over the winter I had an e-mail dialog where a team was simply looking to store results in a database so they could be easily displayed on a web page. As I started thinking about this I came to the conclusion that it would be an interesting project to work on and would be an easy way for me to find a better way to manage results.
For the last couple weeks I have been working on Flip-Turn as time permits and I now have a basic demo up and running. You can see it here: http://demo.flip-turn.com The demo is pretty simple, it allows a user to upload results in SDIF format and parses the results and stores them in a database. The results can then be queried based on swimmer, event, or swim meet. While pretty basic, it works pretty well.
In its current state Flip-Turn doesn’t deal with relay (E0) records but does handle individual (D0) records correctly. In most cases, what people seem to be concerned with are their individual results so that is what I have focused on. I don’t anything I have done will prevent dealing with relay records at a later date but for now, I don’t plan to address them.
Wile the code seems fairly robust, I am not ready to distribute the code yet as I don’t have a great solution for initializing the database tables or changes to the tables. I need to figure something out there – right now I have an SQL script that needs to be run against the database to create the tables. I used phpMyAdmin to initialize mine.
I fully expect to roll this effort back into wp-SwimTeam as this is something I’ve wanted to do for our swim team for a couple seasons.