This afternoon I spent some playing with a jQuery Form Validation plugin to determine if it will help me resolve the issue with required fields. The initial results look fairly promising as I was able to tag a couple fields on a test form and they were flagged when I submitted it.
In the image above, the jQuery Validation plugin added the “Thus field is required” when I submitted the form with those fields empty. This is exactly the behavior I want, the challenge now is to scale my Proof of Concept (PoC) to work in the generic case of the plugin. The Google form defines a block for each input field and the class the denotes a field as required is assigned to one of the DIV blocks that wraps the label and form element (e.g. INPUT or TEXTAREA tag) as opposed to the form element tag itself. This makes finding the required elements a little tricky.
The real challenge I think will be input groups (e.g. radio buttons and check boxes). I need to do some jQuery research before I have a solution but assuming I can figure out which elements to select, I believe this will solve the problem with required fields.
I have just committed v0.5 of the WordPress Google Form plugin. It addresses the problem with the Tabs on the Settings page not working correctly. It turns out that I had a couple of problems which were masked by the theme I was using. I have moved my development environment back to the stock Twenty-Eleven theme and turned off all other plugins.
By doing this I determined that the jQuery UI libraries I expected to be loaded, were in fact, not loaded at all. They were being loaded by the theme! Once I got the libraries loaded correctly the Tabs started working but they didn’t have the proper styling. WordPress doesn’t appear to include the jQuery UI CSS so I ended up loading it from Google’s CDN.
Everything seems to be working correctly now, v0.5 should appear as an update shortly if it hasn’t already.
The WordPress Google Forms settings page makes use of tabs to show information about the plugin and set its options. It appears that the theme I was using, which I am in the process developing, is the culprit. It loads some new jQuery functionality from Google’s API that apparently allowed the tabs to work as I expected. I am not sure yet why the builtin WordPress jQuery functionality isn’t working correctly as I expect it should.
Now that I know where the problem is, I think it should be pretty straight forward to fix it.
As I continue working on my School Sports project I am discovering some pretty cool stuff when it comes to displaying content on Google Docs as part of a WordPress based site. I am particularly interested in this because lots of people make lists in Excel and making lists in Google Docs is basically the same process just done via a Web Browser instead of Excel.
Our Middle School has 10 sports (6 girls, 4 boys) teams. Each has a different coach and along with one or more parents who help coordinate things like concessions, team banquets, weather updates, time changes, etc. If you’ve been involved with youth or school sports, you know how much things change and information needs to be communicated to parents and participants.
I cannot envision training 12-20 people to manage content on a web site and have any prayer of the content keeping any sort of consistent look and feel. I need a solution that is low touch (for me) but simple enough that anyone who can create a spreadsheet can keep a fair amount of content up to date.
Which brings me to Google Docs. It turns out Google makes it pretty easy to publish content from Google Docs (documents, spreadsheets, presentations, etc.) in a form that can be embedded on another web site. This will allow me to have content owners have to do nothing more than keep a couple spreadsheets up to date in order to keep the web site updated. While this works pretty well, the downside of this solution is the control over the look and feel of what Google will allow you to embed is pretty limited.
There are a couple of Google Docs plugins but it looks like Google Inline Spreadsheet Viewer will do exactly what I want. This plugin allows you to add Google Docs spreadsheets to your pages and posts using a shortcode. The resulting output has a plethora of CSS classes which means styling the spreadsheet content (which is displayed as a table) to be consistent with your theme is pretty straight forward.
The only issue I’ve encountered so far is empty cells on the spreadsheet don’t seem to be output at all, not even as an empty table cell. I think this only happens when the empty spreadsheet cells are at the end of a row of data. If there are populated cells later in the row it seems to work fine. This was a minor issue for me, one I fixed by simply populating the spreadsheet with a reasonable value.
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.
There was a bug in the scratch process where if you started on the Meets tab when the Scratch action was selected, there was not a list of swimmers presented for the user to scratch. When starting on the Roster page and selecting a swimmer to scratch did work properly. The bug has been fixed and v0.2.488 is now available for download and both paths, starting with a meet or starting with a swimmer, now work correctly. The same bug would have affected Opt-In meets as well.
Over the last couple of days I have finally made some visible progress on the Jobs module. I am still not wild about the term “allocate” but it is the best I have come up so I am proceeding with it.
At this point I am able to define jobs, allocate a job and quantity required against a swim meet and make some refinements of the allocation. I also have the beginning of the assignment to a specific user GUI done but not the backend functionality. I am optimistic that I may finish a first pass this weekend.
Like a lot of projects, documentation for wp-SwimTeam is severely lacking. It has been on my to-do list for a long time and I have been thinking about it recently. I was heading down the Wiki route recently and actually got one set up. I’ve never been a big Wiki fan but I do see their attraction for certain types of projects.
I personally prefer “real” documentation and by “real” I mean something you can print and read away from the computer. I’ve always like the model that used by Version Control with Subversion has used. The source is in DocBook format which means it can easily be produced as web pages, a PDF file, or an actual book.
Right now I am leaning toward using the DocBook format. At a minimum I am going to try it and see how it goes. Stay tuned!