It's been known for some time that the PageCapt code needs a major overhaul in one crucial area: getting item list data into the system. It doesn't matter all that much how it gets in; once a PDF or such is available, a competent computer jockey and a pile of scripts can make short work of normalizing the thing and converting it to useful data structures.
A major lesson of the past couple of years, though, has been that an electronic copy of the list is never available in a timely fashion, and that not having the database available in that first crucial half-day greatly reduces its potential utility over the course of the hunt. So unless we can find a good source of much higher-quality scanning software than we generally have lying around, and given the amount of manpower in a team of decent size, several people have suggested that it might just be easiest to round up a half dozen people and type in it.
To do this without making people feel like they're being forced to work in the salt mines, you want the job to go quickly and smoothly, which particularly necessitates a system that infrequently breaks the rhythm of typing, and mostly takes care of formatting for the user. The general consensus has been that having a round-trip to the server, plus the attendant overhead of re-rendering a page, etc., would make entering item data one by one an excessively annoying task. Moreover, people don't like just being set down in front of a blank editor page and told to type the list in, and here's how we need you to format it. We can obviously do better than that.
Previously what this has suggested is a system where an array of, say, ten item entry forms is presented to the user, which can be filled in and submitted as a batch. But this is an obvious kludge, which poses some unnecessary stumbling blocks. Ten items is a lot of typing to lose if the window accidentally closes, or if the submit operation fails for some reason. There's no good reason to cut off the typist at ten, either, when they could probably work longer and faster if not interrupted. There are also locking issues if you have lots of people entering items at once. There will inevitably be some overlap, and you'd like people not to enter an item and then be told that someone else has gotten there first.
Instructions are programmatically easy, but some thought will need to go into making them concise and non-distracting. The entry form will include boxes for the item number, description, scoring, category, and a guess at points. The last two need to be optional, as they ask for information that may not be easy to discern at the time of entry. Additionally, the background code should make an effort to fill in the points box based on the scoring string. For the progress indicator, I'm thinking of a small tabular structure with a cell for each item in the (eventual) list, which could be filled in as items are entered. Clicking on an empty cell would allow starting work at a new point in the list.