An End User's View
University librarians are often referred to as 'end users' so I've sometimes been jokingly introduced as an end-end user - I'm Oliver de Peyer and I'm a biochemistry postgraduate at the University of Reading. Like my fellow students, I use services like Biosis, Medline and BIDS for online literature searches and so on. I am on the committee of the JISC-funded Bibliographic Dataservices User Group, or JIBS UG, where my job is to offer naive comments rather like the ones I'm going to make here - although I hope some may not be so naive after all.
The key issue is, are students like myself satisfied with online dataservices such as BIDS or Edina? The answer is no. Let me emphasise immediately that this is often our fault as students, not yours as information providers. We, the students, fail to make full use of what services and help you have to offer us.
Let's start at how students actually learn of, and learn how to use, an online service such as BIDS. We should go to our campus libraries and ask for self-help literature, or tutorials, and so on. These items are available. But we don't. We turn to our colleagues in the lab and ask them instead - so we get a second hand, scanty account of how to use the service, from somebody who probably had no better introduction in their turn. In a laboratory environment at least, your first port of call in your studies is your fellow students and postdocs and you'll naturally turn to them first. In my opinion, the only way out of this cycle is for the tutorials, the help files etc. to directly confront the user at the point of access to the system.
This leads me on to the next area - online interfaces. In general, my colleagues consider text interfaces adequate but WWW-based interfaces are much more intuitive - instead of having to remember the key combination to access a help file or whatever, you can just click on an easily-identifiable 'help' icon instead.
Another comment to make here is that information providers are in danger of aiming interfaces too much at the cutting edge. Administrators see that 70% of the accesses are from Netscape 3 or 4, or Internet Explorer 3 or whatever and they begin to introduce features like Frames, or Java, or intensive use of graphics. This excludes people with less capable browsers. But, does that matter if such people account for so few of the accesses? Well, I only have access to a slow 486. I can't use Netscape 3. Along with the other students in my lab, I use Lynx, a very low-end browser. I know professors who have even more limited computer facilities, maybe only 286 machines. With limited funding, these machines will be here for some time. But these underequipped people are the same ones that make most expert use of the dataservices, with extensive datasets generated per session, with extensive boolean search elements and so on. My guess is that all those tempting high-version browser accesses are made from undergraduate computer rooms or library terminals - much more up-to-date machines, but probably more simplistic and less involved searches. The power users, perversely, have the lesser machines, so interface design should always have considerable regard for the lowest common denominator. Users who have the facilities should have the option of a more advanced interface, but it should not be imposed universally.
Next, what are the students logging on to? In my field, there are at least three main services used, namely Biosis, Medline and BIDS. I've talked to the respective service providers and they tell me that the services have different features and are complementary - but here's the rub - I don't know anybody who uses more than one service. People get comfortable with one system, usually whichever one they encounter first, and then they stick with it.
When I said this to a service provider, he jokingly replied 'Does this mean it's war?' Well, perhaps it is, especially as the 'Net becomes increasingly commercialised. The different systems will have to compete for users by advertising - reaching the student at his or her lab bench and telling us why your particular system is best. Then we can make an informed choice as to which is best for each of us.
Now I'll move on to the bibliographic data itself. Again, problems here are not your fault - the faults are those of the researchers and journals who write the abstracts in the 1st place. There are minor quibbles, such as authors' names or titles not reproduced exactly between journals and their on-line abstracts. Perhaps more severe is the lack of standard terminology. So far, I have avoided boring you with examples, but here I think one is instructive: I research a protein called membrane intrinsic protein, MIP26. However, some people think it should be Major, not membrane. Some people omit intrinsic. Some people say polypeptide instead of protein. Some people say MIP26. Others say MP26. Some have started calling it Aquaporin 0! To find all the abstracts on my subject, I have to search for all these different permutations. Of course, what is really needed is for MIP26 researchers to sit down and standardise their terminology. Since this is unlikely to happen, my ultimate 'wishlist' would be for some form of neurally networked search engine, that would 'learn' that all such terminologies were really the same thing.
Leading on from my problems with the subjective nature of the abstracts, what if I don't want to read the abstract at all? What if my interest is in some other part of the reference? For instance, I often want to know about the methods used to obtain the results described in the abstract. Eventually of course, people will want to search and retrieve the whole text of references. That's already starting, with services such as BIDS Journals Online. But such whole text services are embryonic at present and are not talking to the bibliographic search engines.
The ultimate aim would be a truly integrated, searchable database of full text references, also with links to other associated datasets - for instance, a genetics paper should link to nucleotide sequences for the genes discussed. There are already gene or chemical databases that link to abstract databases.
If students can't get the whole reference text online, then could we at least have Z39.50, details of local holdings, and automated interlibrary loans if the desired reference isn't locally held? Perhaps COPAC shows the way forward for interlibrary loans. There will probably always be a need for paper-based references, especially for older references of course - here I am talking about EDINA, BIDS and so on but then I find I need scientific references from 30 or 40 years ago. Again, it will greatly expedite students' research if the older material is also eventually searchable electronically.
Perhaps one final wish - if I do need to go into the library, and pick up a conventional paper reference, the final barrier is finding the reference on the shelves, and in my experience, most libraries are pretty labyrinthine! Perhaps the ultimate OPAC could be programmed with floor maps, and even print out a route for you. Maybe that sounds facetious, but it is something that takes up a lot of time, maybe as much as all the rest that I've discussed put together.
Well, those are all my ideas and experiences, sensible or otherwise. Perhaps my last comment would be, how can you get more end-user feedback from people like me, so that you get a more quorate view of end users. The JIBS User Group contacted me as part of a shotgun emailing campaign, where thousands of intensive users of Edina were contacted. Only eight asked to know more about the committee, and only me, one person, got involved further. So here I am - the postgraduate voice of bibliographic dataservices. What I say may well be unrepresentative or wrong. The only other way I can think of you contacting more end users is to press-gang them into it - an unedifying thought, but without it, you may never know how effective your decisions as service providers are.
Author detailsOliver de Peyer
School of AMS(Wing)
University of Reading
PO Box 228
Berks RG6 6AJ
Tel: 0118 9875123 x7889
Fax: 0118 9316671
JIBS User Group Webmaster and committee member: