These are high level descriptions of what's happening. Let this page be a start, and we can add to it as new ideas come up or as points need to be clarified.

Reader: a lot of this work may still be unfinished by the time you're reading it. Input is welcome (input is even more welcome if it includes detailed designs, or even better, mockup screenshots).

Dan Wells is working on a serials interface that works like this:

Three main tabs: Manage Items, Manage Subscriptions, and Manage Units

1. Manage Items has two modes, Receive and Bind, and consists of two XUL 'tree' windows, one for individual items and one for the 'working' unit. You 'receive' from one into the other.
2. Manage Subscriptions has a left tree pane with an arrangement of Subscriptions, Distributions, CAPs, and Issuances and a right pane for viewing/editing.
3. Manage Units will be a tree of units with the appropriate items as leaves. This view may eventually be integrated into the current Holdings Maintenance view.

The current work is XUL-style and is strongly derivative of the circ and cataloging interfaces. I have done nothing code-wise for the caption_and_pattern and routing list interfaces.

Lebbeous came up with this after a talk with Bill Erickson and Mike Rylander, but without knowing the extent of Dan's work in progress:

I'm planning to build staff client interfaces shortly that will serve as a starting point for the serials management UI. These will be basic interfaces for defining subscriptions, caption_and_pattern objects, distributions, streams, and routing list users (the objects I'm talking about here are tables from the serials schema as it now exists in trunk).

From there I'd move to work on a receiving interface. At the same time, there will be work happening in the middle layer code to get issuances generated from subscriptions, *_summaries generated from the combination records, subscriptions and distributions, and so on.

The interfaces I'm picturing will be rough at first just to allow data to flow through all parts of the serials schema, so that there's a foundation on which workflows can be tested and refinements can later be made.

It's uncertain whether this could address an area as yet undefined by Dan's work, or whether this would be redundant with what Dan's already done:

My plan for the subscriptions interface would have the user choose a bib record as a starting point and enter the values for the other basic fields that go into the subscription table. Then for caption_and_pattern, we would:

1. check for SREs associated with the bib, and if there are any, allow the user to pick which one of these from which we'll extract the MFHD parts needed to populate caption_and_pattern
2. if no SREs (or none that the user approves), look to the BRE itself for MFHD data, and populate caption_and_pattern therewith if the user approves
3. if we still don't have caption_and_pattern data, let the user enter it through dropdowns suggesting possible values (rather than making him write MARC, of course).