Building new client software for interfaces to library systems is over. The user community will strongly resist another piece of software to view information. They want to view everything through the one interface, the browser. Attempts to modify this interface, such as the Java based Dynix client, while it may prove attractive features[BIBLIO] will be resisted by the casual user.
I beg to differ on many points made in this paper. *) if the new software looks very similar to the previous software and permits the user to perform the same functions in the same way, but with added second order features (i.e. slow managed evolution), then it is unlikely to be resisted. *) if the new software offers features with high perceived value which are obviously impossible to do though the old user interface (i.e. truly revolutionary UI), then it is unlikely to be resisted. *) if the new software is available on platforms or in natural languages for which the old wasn't available then it is unlikely to be resisted by those using those platforms or languages. *) i disagree that the casual user market is the only target group worth chasing, there are thousands of professional librarians and library workers out there. *) you have a bad value in your table of figures. *) you only mention in passing the difference between formal errors (errors according to the specification) and real world errors (errors that cause problems with any known browser). real world errors are all that matter for web site builders. *) your abstract appears not to be supported by your conclusions. Your actual research approach (running library web sites against validation engines) appeared good, but some of the text you've written about it seems dubious. Nowhere that i noticed did you give feedback to the actual site maintainers to help them improve their sites... stuart -- stuart yeates <s.yeates@cs.waikato.ac.nz> aka `loam' "Oh, havoc," cried Pooh, as he let slip the heffalumps of war. X-no-archive:yes