Orienteering Start Time Allocation Project
This document is intended to be a report showing the various stages that were involved in the creation of a project designed to allocate start times to all competitors in an orienteering competition. It outlines the current system and why a new one is desired, as well as the overall aims of the project. It documents how the problem is intended to be solved, then explains the designs for the system and follows the process through to how the designs were implemented to actually solve the problem. The results and conclusions that were drawn illustrate how the project was, on the whole, a success. It also describes the main achievements of the project as well as various problems that were encountered at different stages of the process and how solutions to these were attempted. It shows that a clear, fully working, neatly presented solution to the problem has been achieved with complexity that is initially abstracted away for improved usability. Appendices have been added in order to keep the technical details separate from the main body of the report, but also to supply extra information that would not fit neatly into the main sections of it.
Why The Work Is Being Done:
Currently, the way the start times are allocated is purely manual. A list of competitors with their details is stored in a text file and the event organiser must scroll back and forth through the list (which could be in excess of one hundred competitors) 'cutting' and 'pasting' competitors until a suitable solution has been reached. This system obviously has many problems that make it inefficient and, quite possibly, unreliable. Not only is it extremely cumbersome to cut and paste competitors, but it also can take an extremely long time. Mistakes could easily be made, such as deleting a competitor without realising it, or pasting a competitor in when it was never removed from its original position. There is also no easy way for the event organiser to know whether it is actually possible to produce a solution that does not conflict with any of the competition rules.
As well as this, once the list has been ordered, the competitors are notified of their start time by post. This also causes some problems because if, for instance, someone could not start at a particular time, they would have to notify the event organiser, who would then have to reorganise the list. Other competitors may then have to be re-notified of their start time, again by post. So all of this can take a fair bit of time. It would be so much more efficient if the ordering of the competitors was easily changed dynamically and then the competitors were notified of their start time via the Internet, as well as a confirmation by post. This would mean that if changes need to be made, then it can be done a lot quicker. This would give all of the competitors more chance to organise their day, or weekend, because the start time list is finalised earlier.
Manual Ordering Environment:
The first major task that is essential to the project is to allow the user to manually change the order in which the competitors start the race. To achieve this, it will be necessary to create an area to display names the competitors, along with selected information about them, competing in each race.
This needs to be easy to understand for the user, because the information about the competitors will be required to make changes to the running order as easily and quickly as possible, whilst attempting to create the best solution possible. Once this has been achieved it will be essential to be able to 'load' and 'save' running orders for several competitions. This means that a particular format for storing the running order must be established. The user must have the option to load into the application any competition details that have already been saved. It is almost certain that there will be more than one competition needing to have the running order organised at any given time, so this feature is not a desirable, it is a necessity.
The next objective will be to enable the running order to be manipulated. This will require each competitor in the current competition to be a different entity, so that they can be separated from the list as a whole and placed back where the user desires. The first stage in creating this manual ordering environment is to enable the user to move a chosen competitor up and down in the running order whilst maintaining the rest of it. The user should also have the ability to remove a competitor from the list and replace it anywhere they wish in the running order. This will save them from having to move a competitor from the top of the running order to the bottom, by moving them down one place at a time. If there are lots of competitors, then this would prove very time consuming. Once this has been successfully completed, the first milestone will have been reached. Extra functionality may be added later to give the user greater flexibility, but the essential tools will be in place for the running order to be changed. The main purpose of the manual ordering environment will hopefully be to supplement the auto-ordering capabilities of the application. So, once an ordering has been automatically created to abide by competition rules, the manual options can be used to tighten the order up with regards to the other restrictions that it is desirable to follow where possible.