1.4.1 Umpire Indicator
Since this device is going to need to be handheld and record all of the inputs from the umpire, very specific specifications on how this device operates had to be developed. Due to its handheld nature, the group needs this device to be battery operated. Having the umpire indicator battery operated, the group does not want to inconvenience the umpires using these devices by requiring them to change the battery after only a game or two so the device needs to have low power consumption. This device will also need to be wirelessly connected to the network of other devices in this system. With these ideas in mind, the group decided on the following specifications.
-
Has the ability to run off an internal battery for greater than two games – having the device be internally powered by a battery aids in the usability of the product and having the batteries last longer than two games allows time for charging or conveniently changing the batteries.
-
Maintains general dimensions of existing design, maintaining that it can be handheld. – The current device has a very useful, small, ergonomic design. Maintaining the same general size of the device maintains the feel of the device.
-
Wirelessly connects at no less than 30ft from the database connection. – The Umpire device does not directly connect to the database so needs to be close enough to a system that does connect to the database to upload data to the database.
-
Display(s) to show at minimum balls, strikes and outs. – Without having a display the umpire will not be able to recall the appropriate counts of balls, strikes and outs. Without this the device is not a suitable replacement.
-
Push buttons to increment the counts of balls, strikes and outs on the device. – With this human machine interface the plays of the game are stored into the database and represent the wheels of the current device.
-
Accidental push button rejection coded into the device. – Accidental presses of the buttons will happen. Implementing a delay system will decrease the number of these accidental increments.
-
Displays able to show digits 0 through 9. – To properly display the number of outs, balls and strikes with later implementation of innings.
-
Constructed on a PCB based design. – The size of this device makes it near mandatory to build the project on a PCB design for the benefits of the smaller integrated parts available.
-
Device has the ability to connect to both coaching tablets at the same time. – Connecting to both coaching tablets at the same time allows for faster data to the coaches and also can stand as validation for the coaching inputs being valid.
-
Battery life/low battery indicator. – This is for the users convenience on knowing when to charge or change the devices batteries for maximum performance.
-
Push button for resetting device. – When the inevitable mistake of incrementing falsely happens the umpire can fix the issue.
-
Push button for automatic next batter setup. – When the current batter has completed his time at bat the Umpire can easily reset the device for the next batter.
1.4.2 Coach Application:
The coach application will be interface through which the proposed user can perform 3 main functions. The first interface, the pre-game manager, will allow them build and edit their team rosters, showing the currently tracked statistics for each of the players. Additionally, it will allow them to build a batting line-up, which will be required before being able to use the second major function of this application, the in-game manager. The in-game manager is the interface through which the game is tracked play by play and the on field statistics are uploaded almost immediately into the system’s database. Finally, after a game is complete, a user can travel to the third, post-game manager.
-
Will be implemented on an Android Tablet device: Implementing this proposed system on an Android tablet would have several benefits. The amount of new tablet devices that are currently in the market in addition to a large amount that are currently in development would allow an application that can be used on a large number of devices with a huge range of features and prices, rather than developing for the competing platform, Apple, which would require the use of only one specific, expensive device.
-
The Coach Application will feature a home screen that allows quick and easy access to all other facets of the application: There will be a home screen the application will default to when opened by the user. This home screen will provide large, intuitive links to all of the other interfaces of the application.
-
The Application will allow the coach to view and edit the roster to their current team: There will be an interface called the pre-game manager that will allow a coach to view and update their current roster. Adding a new player will bring up a dialog where they can input all the relevant information about the new player (name, position, etc) and add it to the rest of the player in a local database on the device. The entire roster will be visible and search-able in addition to showing all of the currently held statistics of each player currently in it.
-
Adding a player to the roster who has played previously for a team that used this stat-tracking system will carry over all previously recorded stats recorded for that player: If a player has previously recorded stats from playing with a team previously that used this system to track his or her stats, those stats shall carry over from the previous team to keep more accurate overall stats for that particular player.
-
The pre-game manager will have an interface through which a coach can create a lineup for an upcoming game: Within the roster screen, there will be an option to create a new lineup which will be required prior to being able to enter the in-game manager. The lineup editor will simply be an editable list that will be populated with the players on the roster as desired. The lineup editor will allow both for the creation of a batting lineup based (which will follow any rules required by Little League Baseball) in addition to a starting field lineup to be used upon entering the in-game manager section of the application.
-
The system must prevent the user from entering the in-game manager if they do not have any pre-made lineups saved in their local database: Since the in-game manager relies on a pre-made batting/starting field lineup and does not have the capacity to edit them on the fly, a pre-made lineup must be created prior to entering a game.
-
Any change in the umpire device will be reflected instantaneously on the in-game manager: Since the tablet device and the umpire device will be linked via a blue tooth connection, any inputs that come in through the umpire device should be reflected instantaneously on the in-game manager.
-
Statistics will be uploaded to the database in real time as they are being recorded: As plays, innings, pitches, etc are recorded they will be uploaded to the database shortly after being submitted by the user, allowing for correction of false inputs before being uploaded. This allows for the real-time updating of game information between all of the devices utilizing the database in addition to preventing transmission errors of one large packet with all of the games information at the end of a game being recorded.
-
Coaches will be able to flag entries by the opposing team’s coach that they deem questionable: Although all play decisions will be kept as is and left up to the honor rule, if one of the coaching users disagrees with the opposing coaches input, they will be able to flag that play as such. This way, anyone going back to look through the game will have a record on whether or not any of the plays were disputed.
-
Uploading of play statistics will be only be allowed by one coach at a time if both are using this system: When both coaches in a game are using this proposed system, only one will be allowed to upload statistics at a time to prevent multiple entries for a single play. All of the play uploading will be done by the coach who is currently at bat for that half of the inning. Any disagreements over a certain play can be logged as mentioned above.
-
Coach application will be able to accurately record all information that is recorded onto the currently used log books: Dissatisfaction with the currently used log sheets was expressed during the client interviews. However, the information recorded onto them is critical to the coaching staff. The user interface of the application should allow for the intuitive entry of all play by play information that is recorded onto those log sheets such that even the most basic user can at least a permanent, electronic log of their games if they are not going to take advantage of the full feature set of the application.
-
Coach application will have the ability to access specific team data outside of an occurring data to use in preparation for future games: There will be a separate screen in the application hereby referred to as the post-game manager in which a coach can access data from specific games, teams, and players throughout the league in order to prepare a game plan for future games. For example, if Team A has a game against Team B next week, the coach of Team A should be able to go into this screen of the application and look up the previously entered data from Team B’s past games, such as batting average against a certain pitcher, type of pitch, etc., in addition to Team B’s roster and individual stats about each player on that roster.
1.4.3 Fan Application:
The fan application is being developed for the fans to view their favorite team’s information such as scores, stats, and player’s stats. As such it needs to be very user friendly, wireless capable, and fast.
-
The fan application will be implemented on the Android OS platform specific to the android smart phones and Tablets: The Android platform was chosen for the fan-side application of the stat tracking system for a number of reasons, the first of which being the same as for using the Android tablet device for the coach application side of the system, simple ease of development and more freedom with development. Secondly, it is important to maintain consistency throughout the entire system, which the Android platform allows with the Android application.
-
The fan application will allow for wi-fi connectivity to the database if available: Allowing wi-fi connectivity means that android users who cannot get a signal wherever they are or do not have a cellular connection to the internet to use the application.
-
Data will update on the fan’s device as soon as it is input into the database: This is necessary in order to keep the system up to date in real time from play to play. This also allows parents who are not physically at the game to be able to follow what is going on in an almost real time environment. There may be a setting that adjusts the sync ratio of how often to refresh the current game states from the database, or to turn syncing off altogether when not following an active game to reserve the user’s battery.
-
The fan app will have an interface through which they can access individual player data both in the current game and also throughout the league: When following a current game, clicking on a player’s name will open up a different interface similar to the roster in the coaches application that presents the user with information. This interface can also be reached while not following a current game, which will implement a search feature that allows the user to search for the player data of any player currently loaded into the database.
-
Fan app must be able to choose between which game to follow: It is assumed that within a league, there is a likely probability that multiple games will be occurring concurrently. The user must be able to choose which game currently in progress they would like to follow live on their android device.
-
Fan input can be taken into the validity of calls: When a questionable play is flagged by one of the coaches as described in the coach application section, that play will
1.4.4 Database
The system database in addition to have the physical requirements listed above must also the following specifications:
-
For organizational purposes, each team will have its own database entry: Since each team will have its own statistical summary, which includes the summed values of all its players’ statistics, then for optimal performance, each team should receive its own database. Calculating total statistics by filtering players according to their team is cumbersome, time consuming, and resource heavy. By splitting the teams into their own independent databases, this means the team’s stats can be easily calculated just by examining each player within the parent database.
-
The database will be built using FileMaker Pro: There are a number of databasing software tools that can be used to implement this design, but FileMaker Pro provides the usability and interfacing options that are necessary for the baseball players and coaches to effectively interact with the database. Another viable option is MySQL, but the software feels overly complicated for implementing such basic-level database entries and variables, and requires much more intensive (and burdening) coding work. FileMaker Pro additionally provides smaller overhead, as the software itself is less dependant on additional software, such as operating system services.
-
A new database will be created for each individual game, and each game will store data in its own independent database: Since active games must store and retrieve data specific to the game currently being played, the database must be able to differentiate between global statistics (team history data) and actual game scoring data and statistics that is occurring during a game being played. This inherently offers performance enhancements as well, since the database can differentiate between global variables (team data) and local variables (game data) to respond faster to client requests. Combining all data values to a single database entry would require multiple database accesses to determine things such as scores, runs per inning, hits per inning, etc, as the database would have to query each team database and locate the game specific values.
-
The database must manage and migrate new statistical data from an existing game to total team record data: While a game is being played, the database must also update the overall team data. Clients will have access to team statistics which include the summed total and averages of all games played per each team, as well as the current statistics for the game in session. This data flow must be controlled at all times, and all relevant team data must be updated concurrently with game data, as the data is provided.
Share with your friends: |
