Minutes
Attending: Patricia O'Neill (chair), Susan Barnes (recorder), Carmen Blankenship, Tony Cosgrave, Michael Engle, Peter MacDonald, Barbara Prior, Nancy Skipper
Barbara has taken the responsibility for looking at CUL Web pages with the Mosaic and Lynx browsers, since html output is radically different viewed through the text-basec Lynx and can be slightly different viewed with Mosaic. Sometimes minor adjustments to html can result in enormous improvements in how pages look when viewed with other browsers than Netscape. Barbara will report what she finds about library pages to those individual libraries, and she'll also keep the committee informed.
The remainder of the meeting was spent discussing forms for CUL pages. Patricia began by presenting some basic principles to which the group agreed:
Principle #1: Forms should be made as easy as possible for library users
Principle #2: As much standardization as is practical will be encouraged because Cornellians use multiple libraries. But if standardization interferes with function in our variegated environment, utility will remain the formost concern. Forms have to meet individual libraries' needs.
Principle #2a: Nevertheless, language used in forms should be standardized across the system.
Principle #3: Form designs are suggestions from this committee, with the intention of making a set of basic library forms available from which units can choose (so units do not all have to start at the beginning). The design committee is in no way intending to imply a requirement to use the forms it recommends.
Patricia outlined the two basic categories of forms:
I. Circulation-based forms, for example recalls/holds, renewals, annex requests, reserve requests, reserve holds, uncataloged item requests. Carmen pointed out that NOTIS 6.2 is very likely to bring changes that will have great impacts on some of these forms. The committee agreed to go ahead and look at existing forms, with an eye to making adjustments as necessary after 6.2 is implemented.
II. Non-circulation-based forms, or "other" forms -- all the other library functions and services which could be made available on the Web via forms -- for example collection development, ILS, reference, feedback, facility/room requests, instruction requests, workshop/tour registration.
Finally, the group was reminded of some important facts: not all libraries are totally converted; those libraries may need 2 forms (one for converted and the other for non-converted materials). Also, some policy statements may be needed on, or linked to, each form to inform users of such things as what items can be renewed or recalled, or how many volumes will be sent from the Annex.
The philosophical issue of which forms can or should be centralized engendered a good deal of discussion in the group. Whatever centralization is deemed advantageous to the system, policy issues are needed which are outside this committee's charge. The committee decided that it would work on recommending forms which could be easily adapted by individual units. The form pages will be made easily customizable by units, but forms will probably require some html knowledge on the part of each unit since the unit will be responsible for the customization.
These forms would probably be "pointed to" from the CUL home pages, using a
structure that might look like this:
Tony will do a little more work on a form based on Africana's; adding an image of a barcode, an example of an email address, and 5 more blocks in which barcode numbers can be entered. He will change some of the wording: "CU ID" will become "Cornell ID number," "name" will become "My name, as shown on my Cornell ID card," the reset button will be relabelled "clear this form," and the submit button will be relabelled "submit this request."
Every form should generate a reply screen that echos the text of the submitted request. The reply will also inform the user how the request will be handled. Users will be directed to contact the renewing library with questions; the individual libraries will be responsible for adding this contact information to their forms. All fields on a form should be required, and an error message should be generated if any fields are left blank; Tony will work on these and will make sure that error messages and replies that forms generate will lead to no dead ends (ie, there should always be links leading to other pages). Reply screens and error messages should meet all standard CUL page design criteria.
The committee then looked at recall forms, in which more information is needed because the patron has no way of knowing the barcode number. Between the Africana design and the OKU design, the committee preferred the OKU introductory text but again preferred the overall design shown on the Africana page -- cleaner and simpler, no tables.
Tony and his implementation group will work on modifications to renewal and recall forms and the design committee will look at their work in 2 weeks.
Other agenda items for the next meeting: Barbara will provide information about what sorts of problems show up on pages viewed via Lynx and Mosaic; and the group will discuss the continuing question of what information should be displayed at the top of each page.
Susan Barnes
Posted June 7, 1996
MOE