Regardless, that was just a moderately long-winded way of saying that I'm going to use perl, which I suspect that you knew anyway. Somewhat more of a challenge is the task of defining an appropriate subset of the overall application to be the subject for this example. My efforts are going to start getting a little meatier here, both from the standpoint of the programming involved and the design of the user interface. As I've said before, sometimes you just have to launch into things and get something out there before required additional levels of functionality and interface characteristics are defined. What I'm about to launch into in some contexts would be considered as prototyping, and in other contexts would be an iteration of the application development process.

Let's imagine that we are starting to score an inning, knowing what we do about the structure of what we want to record. If we don't want to design different interfaces for those with normal eyesight and those with some degree of visual impairment, we should pick a level of detail that can be represented in a fashion accessible to both groups. This is something to which you should give some thought as you think about a user interface. On one level you should do it because it is the right thing to do, and on another level you should recognize that failing to do it can make you the target of lawyers looking for a score. This should not be a concern if you are voluntarily building an application that would be used by volunteers, but if you are developing an application that will be used to fulfill professional responsibilities it would be unwise to implement it in such a fashion as to make it difficult for people with visual or hearing difficulties to use, or which could not be used without a mouse. You should give this consideration even if you are developing the application for free. The only context in which you are safe from lawyers is one of personal poverty. If you don't have any money for lawyers to covet, they will likely leave you alone. Even then, you might not be safe if a lawyer or group of lawyers desired to create a perception that could be used to influence another situation. Regardless, you can't live your life in a hole. Just make sure that what you do does not present any undue hardship. In other words, don't make the screen difficult to read, don't require complex and difficult mouse movements, and don't put any barriers in the way of the implementation of text-to-speech engines. Luckily, this is not all that difficult to do, and a clean interface will largely accomplish these ends simply by being clean. Doing things the right way will not protect you from lawyers, but the knowledge that you are pure of heart and noble of purpose is often sufficient to preserve your strength in the battle against the forces of darkness, and is at times sufficient to carry the day. Should you wish to consult formal guidelines for accessibility design, the W3C (World Wide Web Consortium) guidelines are available here.

Implicit in the notion of an interface with sufficient simplicity to be visually-scalable is a design free of clutter, but with sufficient information displayed to be effective without requiring the user to waste time and motion. In practice, what this means is that the basic structure of the information being recorded should be readily accessible on the page or frame from which the entry is being accomplished. This is easy to say, the trick in any given circumstance is to determine what it means. To view this dynamic in the context of the application, clearly we are going to want to score (keep the record of) games on a pitch-by-pitch basis. It would not be a difficult matter to construct an interface that would allow us to record the game on that level, but to make sure that the interface functions as smoothly as possible is another matter. To work through how the interface should be constructed I've assembled a sequence of events characteristic of the level of detail a user would be likely to record, which will help us get a feel for what will be going on.

The sequence of events above should be read down the left-hand column, then down the right-hand column. The sequence it describes is a fairly characteristic baseball sequence in which a pitch to a batter is fouled off, and the next pitch is hit into the right-center gap for a double. The right-fielder fields it cleanly, but overthrows third base, allowing the runner to advance from second to third. The way the sequence is recorded follows the conventions of baseball scoring, in which the runner's advance from second to third is specifically attributable to the error on the right-fielder. This sample is very finely-grained, but not excessively so, effectively encompassing the same level of information found in standard scorebooks outside of the individual pitches and text descriptions. Note that nothing about the codes I've used is set in stone ... I just picked example codes that are likely to bear some resemblance to the final set of codes that I am likely to use.

One thing that should be obvious is that to be effective the interface should give the user the ability to enter more than one record before submitting the page, simply because at any meaningful level of granularity events can happen far too quickly to require that action as each record is completed. Second, in baseball, as in all sports, there are times of relative calm, followed by times of intense activity. As with most sports, the only way that the length of these episodes can be predicted with the kind of accuracy required to allow the designer to use those predictions to shape the nature of the interface would require that the granularity of the information recorded be sufficiently collapsed to remove much of the detail from the data. To work around that, I'll build in some capability for the user to submit whatever is on the page during a lull in the action without filling in all of the form on the page. This will allow the user to keep as fresh a page as possible to accomodate the rapid entry of multiple records.

OK, now a grid/spreadsheet type of interface would allow the maximum amount o information to be displayed on the screen, but has the disadvantage of minimizing the amount of information that can be displayed for the coded fields, which will represent a primary source of feedback to the user regarding the validity of what was entered. Therefore, I'll set up a basic box layout that will be the basis of our entry page. Obviously, this looks much like the individual event record, the only real difference being the fact that I've moved the role_id field above the participant_id. I'll go into the reason for that a bit later.

If you look at this little form you may spot one problem right away. The form, with a small buffer surrounding the form elements, is 450x180 pixels in size. While the width of the form could probably be reduced sufficiently to fit two forms side-by-side on a 800x600 page, which would then allow an 800x600 page to hold eight forms if the form height is trimmed below 150 pixels, I doubt that such is a very good idea, the clutter on the screen outweighing the benefit of displaying that many forms on a given page. You are, however, welcome to adapt what I do here to that end, and I would suggest that you do just that. Play around with the script I'm going to create until you can freely generate alternative screen layouts after making modifications to the script. That's one of the best ways to get a feeling for how something works ... mess around with it to get it to make something noticeably different, then you'll start getting a sense of how the script executes.

Next - A Simple Generated Form