- In the Beginning
- A New Solution for a Modern Tour
- Real-Time Data for the Subscribing Masses
- TOURCast Behind the Scenes
- Into the Future
Real-Time Data for the Subscribing Masses
The TOURCast application's data framework and architecture was designed by IBM's people who had been working on the ShotLink project, providing for rapid and seamless integration between the two programs. This solution was constructed in a rapid timeframe:
Development began in August of 2002 and was completed in January 2003.
IBM wasn't able to test the application at all until December.
The beta version was tried in January in a tournament scenario
TOURCast went "Live" in February at the Nissan Open for public use.
TOURCast's front end is a Flash application, and so can be run by anyone with an Internet connection, web browser, and Flash support. It's designed to provide the best, most immersive experience possible in golf, with features like these:
Select a group of players to follow at any given moment
Watch a particular hole
Request data on a player's performance in previous tournaments as well as the current one
Read information about a hole (typically written by the local golf pro)
Select two players for a head-to-head comparison of their performance
Receive alerts for significant things happening on other parts of the course
This program might sound bandwidth-intensive for the individual user, but TOURCast is designed to require only a small bandwidth footprint, using an average of 5 Kilobits per second.
To help build drama, a commentary feature shares statistics as players get themselves into particular situations. "If they hit a ball into the left fairway bunker," explains Steve Evans, the PGA TOUR's Vice President of Information Systems, "[TOURCast] will tell you that player's proficiency of making par out of that position, or where [he or she is] ranked on the tour [for that particular problem]." It was this type of feature that proved the most complex to implement. Humans judge in the blink of an eye whether it's more relevant to look at the particular player's statistics in a situation or the whole field's handling of that particular location. Teaching a computer to do this looks simple but is actually a difficult process. This is one of the features of which Evans is proudest.
Difficult lessons are typically learned on such time-compressed projects, but Evans says that three things made the implementation of TOURCast smooth and mostly uneventful:
Because the IBM team had spent 2 years working on ShotLink and thoroughly understood the complexities of the ShotLink data, the TOUR asked them to architect the data feed for TOURCast. There was no need to start from scratch learning about data formats and the range of information available from ShotLink.
PGA TOUR already had a successful relationship with IBM; thus, PGA TOUR was able to trust that IBM would provide an economical hosting solution that "just worked." Starting an operation like this is typically very difficult to accomplish. Given that the nature of tournament golf produces natural peaks and valleys in demand, a scalable solution was very important to the TOUR. PGA TOUR was confident that IBM was ready to take on this challenge from the moment they signed the contract and have it ready for the upcoming season. The fact that IBM met PGA TOUR's expectations only reinforced the strong relationship between these two organizations.
Despite these factors, there were lessons to be learned. For one thing, PGA TOUR discovered that the key to rapid rollout for an application such as TOURCast is quick and thorough layout of specifications for the solution, from which no deviation is allowed. Anytime they wanted to change the requirements, they had to think about how much this alteration would push back the timeline.
Another lesson came from the importance of really listening to potential customers. Even before starting to develop TOURCast, PGA TOUR ran focus groups that tested storyboards of how the resulting tool might look and work. After development began, pieces of the application were tested with more focus groups, and then the entire TOURCast program was tested for feedback. Strongly tying the end-user feedback and usability issues into the development cycle sped up the overall process, and as a side effect prevented a lot of time (and money) being wasted.
Perhaps the most important lesson learned is that developers must really listen to and think about feedback instead of blindly reacting to it. When the entire application was in place, the focus groups complained that the TOURCast program was slow. While the first impulse was to completely redesign the front end, the TOURCast team took the time to look deeper into the problem. They discovered that the TOURCast scrollbar navigation was slowing everything down with heavy use of CPU time. Instead of rewriting the entire program—which would have cost significant time and money—the developers replaced the scrollbars with Back and Next buttons. Like magic, the complaints about performance disappeared.