Kilg.us – Fantasy Stat Tracker …Tracker

Over the last couple weeks, I have received numerous emails from people having trouble signing-in to their accounts. With a little digging I was able to find a consistent theme: they were all using Internet Explorer 8 or 9.

Specifically what was happening was that a person would type their existing username into the sign-in form and would then be prompted to create an account. As everyone is probably aware, Kilg.us uses the same form for logging in and signing up. If you enter an existing username, it asks you to log-in. If you enter a username that doesn’t exist, it asks you to sign-up.

To manage this functionality, Kilg.us generates an AJAX request after you enter your username then move focus to the password field. This is creates a “change” event on the username field. When that event happens, Kilg.us asks the database whether the username you entered exists. The database returns a response in the form of XML. The XML has one message: the username is valid (it exists in the database) or it is invalid (it doesn’t exist in the database).

Once the XML response is returned, some JavaScript parses it to read whether it says “valid” or “invalid”. If the value is “invalid” the form asks you to create an account. The JavaScript to read this follows standard practices to navigate the document object model (DOM) and find the value in question. This works in Firefox, Chrome, Safari, Konqueror, Mobile Safari, Opera, Android Browser, Blackberry Browser, etc., etc. Apparently, how Internet Explorer handles the XML is different. It doesn’t create all the parameters that the standard approach would.

This shouldn’t come as a surprise to anyone.

What I ultimately found is that Internet Explorer will parse the value out and save it in a “text” parameter for the XML object. Rather than navigating the DOM in a standard fashion, I’m now taking a shortcut and checking if that “text” parameter exists on the XML object. If it does, I read it in as the returned value. If it doesn’t (obviously, all the other browsers to generate this rogue parameter), I continue to navigate the tree and get the value in the proper manner. This only works because the only value of the XML is the “valid” or “invalid” message.

The end result: the log-in/sign-up form logic should now be working again in IE. And still working in every other browser. If you find that not to be the case, please let me know (comment, email, Facebook, Tweet).

Now that Kilg.us is migrated and–seemingly–stable, I can actually make some improvements!

First up are some stats additions. The easiest request was to include total bases. Because this is calculated based on data we already have, I was able to implement it pretty quickly. To enable Total Bases for any of your teams, visit the “Select Stats” page for that team. You will see a checkbox for “TB.” Checking that box and saving your changes should add a TB column right after strikeouts.

The most commonly requested stats that Kilg.us does not currently have are games played. While this data isn’t conveniently available in the MLB XML data Kilg.us uses, I think I have determined a way to deduce whether a player has played in the day’s game(s) or not. That will take significantly more effort, though, so it will have to wait. Perhaps this weekend I’ll find some time.

I noticed the other day that Kilg.us had recorded a save for one of my pitchers that, in fact, had blown a save. Reviewing the code that collects these stats, I think I’ve identified the issue.

Unlike most stats which come from a dedicated attribute in the XML files, saves, wins, losses, and holds need to be parsed out of a generic “notes” attribute. The logic performing this parsing was looking for “S,” to identify a save. While this matches the pattern (S,9)–a pitcher who recorded his 9th save–it also matches the pattern (BS,3)–a pitcher who has blown his 3rd save. I have updated this parsing pattern to look for “S,” in the absense of “BS,”. Hopefully this will fix the problem. I’ll be keeping an eye on this throughout the evening, but ping me if you notice any issues.

Since the release of season-to-date stats, a lot of people have been asking for games played and games started to be included. I’m doing some research to find a reliable place to find such a statistic. If I can find it–and figure out how it plays into a paradigm with daily stats, too–I will incorporate it. The level of effort to include it is pretty minimal, assuming it can be found. More details to come.

One of the longest running requests of Kilg.us has been to include game progress information. I can definitely see the value in knowing whether the game your pitcher was pitching in is done yet or not (will there be a win coming or is it all over already?). This is a different kind of statistic than what Kilg.us otherwise collects, so it has been low on the priority list. As I got tired of stored procedures earlier today, though, it finally sounded like an appealing project.

The scoreboard is displayed across the top of the page in the banner area. It displays abbreviated linescores: team, runs, hits, errors, and inning (or “F” if Final). The banner area only has room for 8 scores at a time, so there are left and right arrows to slide the scoreboard side-to-side to view all games.

The first draft of the implementation pulls XML data from MLB each time a page is loaded that displays the scoreboard. Currently the Kilg.us homepage, your Dashboard, and all Team pages include the scoreboard. The data is collected from the XML, looped through, and populated into a list/table combination of mark-up. Some JQuery sets up click events on the arrow buttons when the page loads (if they are needed; if 8 or less games are occuring that day, no arrows will appear) and calculates how far the scoreboard needs to slide to display all games.

I only had time to perform a very quick testing on IE8, Safari, and Chrome (in addition to Firefox, on which all my development occurs) so if you experience any problems with your browser, please let me know.

More development will be ongoing with the scoreboard. I expect I will update the process to store the game scores so Kilg.us doesn’t need to continue pulling in game scores even after all game are done. It will function similar to how player stats are collected. It will first check if the XML feed has been updated. If not, it will pull data from the database. If so, it will update the database and use those stats.

While clicking through my team stats today on Kilg.us, I noticed that the stats display layer seemed to be out of date. After a little investigation, I found that the XML feed for the stats had not been updated since June 16. A little more digging turned up what looks like a change in the way MLB is storing their data. The format of the data itself seems to be the same, but they moved its home on the server. After updating the path to the data, all seems to be well and cumulative stats are up-to-date again.

In other news, I resolved an issue that yesterday’s IE7 “fixes” introduced. In the mega-drop-down, the new JavaScript set a negative top-margin for IE browsers. Turns out IE8 is enough better than IE7 for this to be a problem. So that method has been updated to only apply the margin to Internet Explorer version 7.

And lastly, some new language throughout the site. The Account Info page now displays an alert message if the User’s profile is set to Public but they don’t have a first or last name defined. Obviously it is difficult to find people in a search if you can’t search on their name(s). The new language encourages the inclusion of a name to help other Users in their searches. The Account Info and Sign-up pages now also have note text added to the password sections indicating that passwords must be at least 6 characters long. Previously the only way to know this would be to enter a password that was too short and try to submit it. At that point an alert would pop-up identifying the shortcoming. Now the User is informed up front.

As I noted last week, making Kilg.us handle double-headers and postponements better was a priority for this week. After doing some fun work with avatars yesterday, I dug back into the guts of the app today. Kilg.us now checks for two games worth of stats for each player, each day. There is a particular pattern for the URL to gather a player’s stats, so the stat gathering process now checks for that pattern for both “_1″ and “_2″ games (games 1 and 2 of a double-header, respectively).

Checking for the second game is handled in the same manner as checking for the first game: first we check if the file exists, then we check if it was updated since we last collected it, then (if the previous two conditions pass) we collect the data. Hopefully this means we won’t see a noticeable slow-down in the performance of Kilg.us gathering stats.

At this point, all I can verify is that the code doesn’t break with the new additions. We’ll have to wait for an actual double-header before we know if the additions actually work or not. I know the Rangers have one on Friday, so I’ll be paying close attention to see how things go. Please be fore-warned, though: if something is wrong with my updates, it will become apparent on Friday. If I notice any peculiarities, I’ll post a note here on the Tracker describing what is happening.

Postponements

Postponements have been another pain-point for some users. In scanning the data coming from MLB, I believe when there is a postponement the data for players involved in the game are removed from the server. If this is true, the recent effort to schedule regular checks on player stats should, theoretically, address this issue. When stats are checked early in the morning, Kilg.us should notice that stats for any player involved in a postponed game are missing and correspondingly clear out that player’s day. This probably will happen before boxscore emails are sent, but likely won’t occur immediately after a postponement is called.

If I am wrong and MLB does not remove the data for players involved in a postponement, I’ll need to add some further logic. The Linescore file for each game notes if there is a postponement, but it is done through a text field so I’ll need to extensively research all the possible terms they could be using (postponed, postponement, cancelled, delayed, delay, etc.) before I can start checking for them. Because that will be significant work, I’m going to put off that effort until I’ve verified whether the previous described mechanism is working. Should it not be, please bear with me.

Avatars

Last night I posted briefly on the addition of avatars for Users and Teams in kilg.us. To elaborate a litte, the avatars are used exclusively on the Dashboard at this point and consist of a pre-defined set of images. My goal with the avatars is to help make Kilg.us more scannable. I think the first step (the dashboard) has been successful. I hope to pull those avatars into other areas of the application where they could be helpful. Activities around finding, approving, and defining permissions for other Owners in Industries are an obvious opportunity.

To implement avatars I added a table (to store the default Kilg.us images) and a couple of columns (to associate avatar filenames with Users and Teams) to the Kilg.us database. This structure will allow me to define avatars that any User can choose from (basically, those you see as options right now) and allow for Users to upload their own avatars without exposing them for other people to use. Until I build-out the file upload and image manipulation mechanisms, the only options for avatars will be those I draw and add. Once those mechanisms are built, you’ll be able to upload your own avatars.

The biggest obstacle to being able to use your own avatars is the image manipulation that will need to be done when files are uploaded. Kilg.us is using two sizes of avatars: 48×48 pixel images for Users/Owners and 32×32 pixel images for Teams. For the sake of consistency, all uploaded images will need to be re-sized to fit the proper dimensions. I think I should be able to handle that with manipulations and masks using ImageMagick. It is not something I’ve done before, though, so I imagine a fair bit of trial-and-error.

Tonight I updated the mechanism in which Kilg.us gathers all the players for the Major League Baseball Teams. The old process involved some manual intervention. The new process is entirely programmatic. At the moment, I need to kick off the process manually, but I hope to get it scheduled here in the near future. I want to optimize the process a bit before tossing it in a CRON job, though. Right now the process takes about 2 minutes to run and generates about 3200 PHP Warning messages.

All the warning messages are generated by a series of HTTP requests. The way the process determines if a player is on a major league roster is by checking if the player has an XML file on the MLB server for the current day. If the file exists, Kilg.us ensures that player is on the proper Kilg.us team. If the file doesn’t exist, Kilg.us deletes any records of that player from the proper Kilg.us team. This also generates 2 Warning messages per failed HTTP request, though.

I’ll keep an eye on things, see if I can clean it up, and run the script every few days to keep the MLB teams up-to-date. Depending on how things go, I might go ahead and schedule the task or I might re-write it.

Another update today was in the Javascript that calculates the number of innings your pitchers have thrown on a given day. In the past, if your team had thrown an increment of innings that included 1/3 of an inning, your total innings probably rounded that up to 2/3.  This was because of a basic flaw in my logic for calculating those partial innings. I’ve corrected it (actually re-writing the entire function) and now innings pitched should be tallied properly.

A few refinement today centered around the live stats bubbles I implemented the other day. On the Team pages, I removed the title attribute from the massive tables on the page. Some browsers render that attribute as a tooltip when mousing over the element. With the introduction of the stat bubbles, this led to a lot more mouse-over, mouse-off, mouse-over actions which caused the tooltips to repeatedly redisplay. Perhaps a minor hit on accessibilty, but well worth it to remove the irritant for most users.
More substantially, I added the stats bubbles to the Add Player page. Now when you are looking for a player to add to your team, you’ll be able to reference his picture and season stats to help ensure you’re selecting the correct player. Throughout Kilg.us now, whenever you click on a player’s name, you’ll always get the same behavior: a stats bubble. Score one for usability!
On a global effort, I added some logic to the stat bubble code for batters to check if they have any at-bats by which to calculate their in-base percentage and slugging percentage. If the player has no at-bats, they will be given values of “.—” instead of the code throughing an error for trying to divide by zero.

Per a User request today, I’ve added in season stats to the Team Stats pages. Previously, clicking on a player’s name would open a new window and take you to that player’s MLB.com detail page. Now when you click on a link, one of two things could happen.

1. The preferred scenario: if you have JavaScript enabled, a bubble layer will appear that pulls in the player’s photo, name, link to their MLB.com detail page, and their total stats for the season.
2. The alternate scenario: if you don’t have JavaScript enabled, you’ll be taken directly to the player’s MLB.com detail page.

As is always the case, I’m restricted by the stats that are coming from MLB.com. I added in crude calculations for OBP and SLG for batters, but those will only be approximations and may vary by a very slight margin from the official stats. All the other stats should be official and accurate.

The goal of this new functionality is to provide a little more perspective on each player’s overall performance without needing to head off to another site. It was also requested to include the player’s last 7 days of stats. As I discussed a few weeks ago, though, Kilg.us is intended to be a live stat-tracker. It isn’t an aggregating, collecting, statistical database. Nor is it a one-stop shop for managing your fantasy teams. For the same reasons I decided against allowing Users to view stats for any specific date (see the entries about box score emails), it isn’t possible to total stats over 7 day periods.

I was able to pull in the to-date season stats simply because they are easily available. They aren’t being stored in Kilg.us anywhere. Every time a layer is generated, a new AJAX request is made to the XML data sources to pull in the stats (and the player photo). Hopefully this will be a helpful compromise solution.