October 26, 2004

PageCaptain Issues

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.

Having taken some time yesterday to learn Javascript (it's a very derivative language) I'm now thinking about this problem again.

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.

What this has led me to think in the past is that some kind of multi-threaded app is called for, which would be able to accept input in several windows, just requiring a TAB or similar keystroke to advance from one field to the next, and which could then handle the server update when finished while the user proceeds to enter the next item. But I realized yesterday that, in a Javascript program, each browser window behaves effectively as a separate thread.

The strategy I'm looking at now involves a simple single-item entry form with a lot of preloaded data behind the scenes, manipulated by a Javascript program, that spits off windows with item data for submission as the typist finishes entering them. The master window could then just present three basic elements: some instructions, the entry form, and a progress indicator.

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.

Ideally, the progress structure would be updated by the script running in the other window. For that matter, I'm wondering if there is a good way to open a third window that loads some normalized form of the list that can be read by a Javascript program traversing the document tree; it would then be possible to reload the list status, also in the background, without having a huge chunk of data to (not) render in the working window.

My major concern so far is that I haven't found any standardized documentation for the top-level window object in Javascript. I get the impression that it's one of those extensions that is widely supported but not standardized, which means that any solution I devise might wind up being unusable under IE. Not disastrous, but mildly inconvenient perhaps.

Posted by mill1974 at October 26, 2004 10:57 AM