Projects in eLib have been encouraged to learn from the experience of designing and implementing their products and services, so contributing to the collective learning of all those involved in the programme. The annual reporting framework asked projects to report on difficulties as well as achievements in managing the project and carrying out activities and to reflect on what the project partners have learned from their experiences of innovation and development.
In synthesising the responses to the open-ended questions about implementation we firstly comment on the broad themes that run through this section of the annual reports. We then consider, under a number of sub-headings, the main generic experiences of implementation reported by projects. The focus here is both on the difficulties experienced and on what projects are learning about the factors underlying successful achievement of their objectives. Finally, we briefly consider those problems, experiences and lessons which are specific to the domain areas.
In analysing the annual reports, we can discern a number of recurring themes which reflect projects’ broad experience of the organisational, technical and social dimensions of the innovation process. Even though projects are positioned at different points in an innovation lifecycle from the initial stages of software development and systems integration to the later stages of validation and implementation in real organisational settings, we nonetheless find important commonalities in their experiences.
The eLib projects, as we have seen, draw together a number of partners from different institutions and sectors who are characteristically geographically dispersed and may also stand in different relationships to the innovation process. This mode of project organisation is novel for most participants, including those in lead partner coordinating roles. Whilst the demands and requirements of consortium organisation and management had perhaps not been appreciated at the outset, most projects have come to a new realisation that partnership functioning and the capability of the partners for collective reflection about the development path of their project is important for its success.
Many of the problems and difficulties recounted by projects in their reports relate to project organisation and management. We discuss these in more detail below, confining our comments here to some general observations:
First, the management aspects of projects were generally under-estimated by projects and thus many have been caught by surprise not only by the ongoing administrative tasks and responsibilities which are particularly burdensome for project leaders involved on a part-time and often voluntary basis, but also by the difficulties of engendering a whole team approach and managing a productive dialogue between the partners.
Second, whilst there is an awareness that partners bring different perceptions, orientations and priorities to the project, particularly when they represent different stakeholder groups, many projects are uncertain about how to build good communication or to deal effectively with the organisational dynamics within the consortium. This is not surprising: most systems engineering development processes suffer from problems of differing interests, values and perspectives, power differentials and inadequate communication between developers, clients and users. However, methodologies and techniques for managing the human and social aspects of this complex activity can be built into the development process. They require a knowledge of social processes (organisational and group dynamics, professional identities etc.) and appropriate skills for dealing with different stakeholding groups. (Evaluators are well placed to foster dialogue and consensus building, where the need for this kind of role as ‘process consultant’ is recognised and valued. In eLib projects, however, evaluators generally did not view their role in this way or were not legitimated to take such a role. Nor in most cases would their profile of evaluation skills, experience and expertise have equipped them to play such a role.)
In the eLib programme, many projects have a future-oriented experimental and developmental rationale even while they are concerned in the immediate term with implementation and exploitation in a real world context. A number of projects experienced a tension between these two objectives, finding themselves in a position where the functionalities required to satisfy the immediate needs of users for their service at the same time mitigated against experimentation with the technical configuration which might better meet the needs of future users. An example of such a project is ROADS which was pursuing its own developmental agenda as well as having to meet the needs of the subject gateways for a well specified systems architecture to be integrated into their own applications.
The kinds of learning reported by projects in their annual reports reflect an evolving understanding of the innovation process and of their role in it. For some individuals, this is a new awareness whereas for others it represents a deeper understanding of the uncertainties that surround software development projects. Typical of the more reflexive comments are the following:
"The eLib projects are not only experimenting with uncharted technical solutions but also the way in which technology becomes institutionalised and used in practice."
"Originally we saw the different project activities as sequential, but we are now much more aware of their inter-relationship."
"Partners need to recognise that flexibility is the key to innovation and the workplan must be flexible and capable of being redrawn and modified to meet unforeseen circumstances."
"We have become aware of the complexity and inter-relationship of what is being tackled, and of our naiveté at the start."
"Its important for all partners to have a shared vision of where we’re going, of where we are, and how to get to the destination."
Also evident in some of the annual reports was a good awareness of what is involved gathering feedback as part of an iterative development process. Such understanding was articulated clearly in one annual report:
‘Both a formal system for tracking bugs and a formal requirements gathering process have been in place since early on in the project and have both functioned well. However it has become apparent that by themselves these are not sufficient to capture all the feedback from users and to reassure users that their feedback is important and is receiving attention. There is a grey area where bugs merge into wondering whether "I’ve done something wrong" and where it is unclear where enhancements begin and bugs end - "It would be nice if X wasn’t so difficult". To capture these ‘soft issues’ it is important that there is regular contact, close and informal enough to allow seemingly trivial feedback to emerge. it is also vital that such contact with users is recorded and archived through a single mechanism. It has taken too long for us to realise the importance of such issues.’
Projects were very open in their acknowledgement of the difficulties they were experiencing as well as in identifying lessons from the process of implementation. Their comments can be grouped around the following categories which are discussed in more detail below:
Many of the difficulties experienced by projects in this area have been alluded to earlier or discussed in more general terms in the preceding section. Here, we comment on some of the more specific issues that were shared by a number of projects.
First, the recruitment and turnover of staff has been problematic for many projects. This reflects the distinctive profile of skills and expertise required by eLib projects, with the result that it is both difficult to attract and retain staff in a highly competitive labour market where such skills are in short supply. The progress of several projects has been set back by the mobility of staff, particularly in those cases where the person moving on has been a prime driver of the project or is well networked within the institution.
Staffing difficulties have been exacerbated in some instances by the heavy demands made on existing staff, many of whom are in part-time and unremunerated positions within the project. A recurring comment was the over-commitment of project team members, whose contribution extended well beyond what could reasonably be expected. There are already instances of burn-out where individual members of staff have left the project as well as a widely shared concern that the level of unacknowledged staff input and resourcing cannot be sustained beyond the initial piloting stage.
Second, a number of projects have found that there is a mismatch between the skills profile of project staff as envisaged at the outset of the project, and the actuality of the tasks and activities to be undertaken which call for different skills and project roles. This is not a surprising finding, given that there is so much uncertainty in the environment in which projects are operating and the range of skills required is evolving as the technology itself evolves. Some projects have been able to defer appointing staff until they have a clearer sense of what skills are needed at different stages in the project lifecycle; others have found it necessary to redeploy staff or to recruit to new positions by making savings elsewhere. A good many projects have drawn on the services of technical and other staff in their institutions to compensate for the lack of requisite skills in their own project team. A common lesson for projects is the need to be able to deploy staff flexibly, although this is often difficult to achieve.
The internal management of projects has preoccupied many projects. Lack of clarity about the respective roles of project director and manager, between project manager and steering group members with local management functions, and between the project groups in different test sites, has been one source of difficulty, although having acknowledged the problem some projects have been able to deal effectively with it. Several projects commented on the unanticipated difficulties of managing a consortium project over dispersed sites and their lack of appreciation at the outset of the need to take an active role in building cohesion between partners. One project described a beneficial shift that had taken place from a site oriented to a team oriented approach whilst the importance of engendering a whole team approach was a familiar theme in many annual reports.
At the same time, we should acknowledge that many projects have commented most favourably on their project team cohesion and the very positive contribution being made by partners who are keen to see the project succeed and to maximise their learning from the experience.
We noted in an earlier section the different modes adopted for communicating between project team members and between projects and their steering group members, editorial advisory groups and the like. Whilst most projects made use of email as a medium for communication, with one or two exceptions it was felt to be insufficient on its own. Most projects saw periodic face to face meetings as essential, notwithstanding the logistical difficulties and costs involved. The use of Mailbase discussion lists as a method for fostering dialogue between partners and a wider group of stakeholders was also thought to suffer considerably if members had not previously met face to face.
Although the majority of projects reported some changes to their initial plan to take account of new opportunities or unforeseen difficulties, only a small handful had been led to question the central concept or vision of their project. In some instances, such questioning arose from early evaluation findings which cast doubt on the likely effectiveness of the innovation as presently conceived. In one or two other cases, the project considered the coherence of their innovation had been jeopardised at the outset by FIGIT in the requirements it imposed as a condition of funding.
Some projects have also found that the grand ideas they started with need to be tempered by more realistic and pragmatic considerations. On occasions this has become apparent when talking through the evaluation, at other times it has emerged from their implementation experiences. As several reports commented, the partners in their project are only now beginning to realise the full complexity of the project and the inter-relatedness of technical, social and organisational elements. One or two people have referred to their naiveté about what was involved, especially with respect to processes of cultural change.
Reflection on what is innovative about their project has been a positive and fruitful activity in some cases, leading to a sharper definition and shared understanding of what the project is trying to achieve. For instance, one project is now much more clear that its key output is knowledge, not a system or product. This has implications for evaluation design and for how the partners need to work together to produce knowledge of sufficient quality and relevance to inform future decision-making.
As project team members develop a better understanding of the innovation process and its inherent uncertainties, so they are coming to recognise that the workplan must be flexible and capable of being redrawn or modified to meet changing circumstances. Some annual reports are unapologetic about the need for flexibility and change, others see the need to modify their workplans to meet unforeseen circumstances as reflecting poorly on their project concept and management.
Although many projects experienced technical difficulties, these were generally temporary or capable of resolution. Problems which also appeared to be technical in the first instance subsequently manifest themselves more as socio-technical in nature, requiring more imaginative solutions of a human or organisational kind.
The most common technical problem was delay in the delivery of technical equipment and difficulties associated with faulty parts and incorrectly supplied equipment. Technology, moreover, often lacked the required functionalities that projects had been led to expect. The domain areas where technology was most frequently problematic were those employing scanning technology.
A tension for several projects was whether to purchase proprietary software or to develop their own customised software. Those following down the first path were not always satisfied with what was available, finding it insufficiently robust, inflexible or lacking in interface compatibility. For one project, off-the-shelf hardware and software has mean loss of control, brought about by the lack of access to the code; it eventually moved to customising its own software. The advantages of working with available software rather than becoming enmeshed in systems development and integration were nonetheless compensatory factors for many. Some projects did however take the decision to be technically self-reliant, especially where advanced technical expertise was available within the project. The advantages of taking this path were that they were able quickly to develop software and to experiment in various ways as well as to build flexibility for customisation to the different test sites into the design process.
Systems integration was also a recurring problem, notably where existing technical infrastructure in institutions lagged behind the more advanced technology of eLib projects. Several projects in the On Demand Publishing domain, for instance, faced difficulties when it came to integrating their new systems into existing structures and technologies.
Developing applications within an R&D environment has an attendant set of problems, a reality which has been acknowledged by FIGIT. These include, for example, scaling up from the pilot or experimental phase to wider diffusion and exploitation. One or two projects have commented on the difference in attitude and orientation among publishers who are included among the partners and are willing to explore alternative pricing models, and the wider set of publishers the project is now seeking to involve who are not interested in experimentation but wish to ensure a commercial return from the outset.
Scaling up has also arisen as an issue in a project which is faced with the choice between custom built and proprietary software. Partner institutions choosing their own routes might opt for the former, whilst the centrally focused interests of FIGIT for exploitation and diffusion might argue for the latter.
A recurring theme in the project reports is the rapid advance in technology and the networked information environment, coupled with fast changing user requirements. Projects experience this as a constant moving of the goal posts. There are examples where technology developments have already moved ahead of the project, forcing a leapfrogging to a WWW solution. In On Demand Publishing, for instance, the exponential growth of familiarity with the Internet has spawned a demand from users electronic courseware delivered through the WWW in preference to coursepacks that are linked into LANs. Training and awareness projects have also been forced to amend their offerings in response to changing user requirements, one such example being the heavy demand for HTML authoring courses.
The importance of early demos or rapid prototypes for hands-on experience and early feedback from users was remarked upon by several projects. Such testing has revealed the widely varying levels of skills, awareness and attitudes to learning and communication technologies and the need for training and systemic organisational change to proceed alongside technical development.
Implementation issues have been at the fore in some projects which have discovered in fieldtesting that there is little grasp of IT concepts among their target student group. Lecturers’ reluctance to consider new methods of teaching and an unfavourable academic environment for the development of coursepacks stemming from knowledge of their previous high cost, have also been deterrent factors in successful implementation. Lack of ownership of On Demand materials by tutors responsible for using them also emerged as an issue in one project, reflecting inadequate involvement of tutors as a user stakeholder group in the development process.
With a few notable exceptions, there appears to be a general lack of awareness of user-centred development processes and the importance of a good knowledge of users and the context in which the innovation is to be introduced as a key input into design. Instead, we find that projects are ‘discovering’ these realities at the implementation stage of fieldtesting.
The lessons emerging from the experiences of individual Electronic Journals projects include the following:
The lessons emerging from the experiences of individual Access to Network Resources projects include:
|
Electronic Journals: Some Lessons • ‘It was clear that there were differing expectations on the part of the collaborators, with the learned society participants becoming irritated by the apparent slow rate of progress of their university colleagues. This may have been due, at least in part, to poor understanding of the skills necessary in establishing the electronic foundations of the system and of the substantial investment in time and publishing effort of the learned societies.’ (Electronic Journal and Learned Societies) • ‘It has also come to be appreciated that computer specialists are often unaware of matters taken for granted by journal publishers and vice versa and that much time needs to be devoted to promoting understanding on both sides.’ (Electronic Journal and Learned Societies) • ‘The key to the success of this magazine is the active participation by the ‘readers’ in the production of the magazine through discussion and more formal contribution. The aims is that the HE community should adopt DeLiberations as a means of ‘talking to’ each other, in contrast to ‘commenting on’ articles. We are some way toward this goal, not least through a clearer appreciation of the cultural constraints and the nature of the new media.’ (DeLiberations) • ‘The conclusion is that new technology of itself does not automatically alter peoples’ behaviour, but that the power of email and the resources of the WWW can be incorporated into existing relationships and can help to create new ones.’ (DeLiberations) • ‘While not having found that costs were higher than anticipated what we have concluded is that the costs of running an electronic journal are not lower than those associated with a more traditional print journal and indeed may in the long term, when issues such as preservation and long term access are taken into account, be higher.’ (Internet Archaeology) • ‘A further and more immediate realisation is that where we included purchase and maintenance costs for hardware and software in the infrastructure start-up costs we did not take into account renewal costs. While this has not impact on the project during its three-year eLib life, we need now to begin to consider how these additional infrastructure costs can be met in the future. So while the near-term costs remain within our expectations, in the medium term we will need to generate revenue of higher-than-anticipated levels to support renewal of our hardware and software systems. We are actively investigating ways to address this financial issue.’ (Internet Archaeology) • ‘One discovery we made early on was that the whole idea of an article is transformed by electronic publication. Whereas in print, articles were of relatively fixed length and type, in the electronic environment they are quite different. They can consist of databases as readily as extended multimedia essays.’ • ‘Another culture gap is that between traditional publishers, who own the print journals, and the new generation of would-be Web publishers . A publisher can be both at the same time, but the gap is still there. Traditional publishers are naturally conservative and, under pressure to preserve commercial profitability, are faced with a new medium that has not demonstrated the capacity for sustained revenue generation. Such publishers are not inclined to be ‘open’ in the same terms that support the Web philosophy: the publishing process itself is staunchly resistant to any apparent form of standardisation. It is against this background that the project has to involve publishers in developing new products that may, or may not, be consistent with their existing commercial strategies, and for which the demand from the academic community is unclear. An added dimension for the project is the extension of the Web culture to its underlying link culture.’ (Open Journal Project) |
|
Electronic Journals: Technical Issues and Learning |
|
• ‘Client/server software is relatively new and products are immature. This is particularly true of application software for the journal applications. Network products like NetAnswer and DynaWeb have only recently been developed from stand-alone predecessors. They are still evolving, and not all the functionality we expect is there now.’ (SuperJournal) |
|
• ‘Creating applications and systems that are scaleable is more difficult than hand-crafting one-offs. Its comparatively easy to create a single electronic journal such as a Web site, use a standard HTML editor to tag new articles, and update the site as they are ready. Its more difficult to design systems that can scalably process large numbers of articles from different publishers accurately and as automatically as possible.’ (SuperJournal) |
|
• ‘Manchester Computing has established an excellent development capability and created processes to accept production files from multiple publishers, convert and store the data, and provide access via WWW within six months of the formation of the team.’ (SuperJournal) |
|
• ‘The project found that the task of managing reader registration was more difficult than expected. This reflected the variety of ways in which potential readers might access the journal.’ (Internet Archaeology) |
|
• ‘It was necessary to test the articles using a variety of different browsers because of the variation in how different browsers handle HTML. Even in the area of HTML there were problems because it was not possible to use the HTML 3.0 standard - or even now the 3.2 standard - as few browsers supported it at the start of the project - and many still don’t.’ (Internet Archaeology) |
|
• ‘Although the project anticipated that all the material would be provided in electronic form, this proved not to be possible with the initial contributions offered and it proved necessary to purchase a scanner and a laser printer.’ (Internet Archaeology) |
|
• ‘A critical issue the project must solve is that of creating high quality links in volume. The project has demonstrated the application of links on a large scale, but not yet the effectiveness to produce only useful links on the scale that commercial link publishing will demand. First tests with biology links have begun to indicate what a quality link is, but it can differ for a given user or group of users.’ (Open Journal Project) |
|
Access to Network Resources: Some Lessons • ‘The manual approach to resource cataloguing is extremely labour intensive, and is likely to prove untenable in the long term as the costs continue to increase and cheaper technology-driven solutions are developed. However, it is also apparent that the user community attach great value to the service, particularly the quality-control aspect of the cataloguing process. Consequently, it is envisaged that the emphasis of projects such as ADAM will begin to shift away from resource discovery and descriptions as these are increasingly dealt with by information producers and technological solutions, and will move increasingly toward the quality control, classification and peer review functions that users seem to value so highly.’ (ADAM) • ‘The provision of a seamless interface between the SBIGs is not a particularly high priority for the users of the EEVL service. It has become apparent that the needs of engineers vis-a-vis electronic information mirrors their needs for printed information. Bibliographic information, plus easy access to quality Internet resources, but access to trade literature is also very important to engineers, whether in print or electronic formats. The composition of resources in the EEVL database reflects this, and makes that database quite different in character to those of OMNI and SOSIG. We feel that a focused main service database, and the ‘value added services’ may be far more appreciated by engineers than a seamless interface to all the SBIGs.’ (EEVL) • As a result of the activities, difficulties and lessons learnt, we are now more aware than ever of the need to keep an open mind in such a rapidly developing area.’ (SOSIG) • ‘A continuing source of concern for us, and confusion in the minds of users, has been the lack of clarity about the role of NISS and BUBL, in relation to the subject services.’ (SOSIG) • ‘There have been and continue to be differences of opinion within the project about the mechanisms for internal and external communications, particularly the value of face to face meetings. In spite of the high degree of commitment to the use of email and electronic document and information transfer at all collaborating sites, there remains disagreement about how completely these mechanisms can fulfil all communication needs. It seems that three cultures are represented within the project: technical/development oriented, intellectual/research oriented, and service/user oriented. There is certainly room for some research into how completely current tools allow collaborative distance working within such projects.’ (ROADS) • ‘There is an inherent conflict between development and service provision. On the one hand is a team, collecting requirements, developing software and participating in setting of standards and agenda in a highly volatile area of work, who want to keep open to new ideas and incorporate as many as possible of them into an exciting and developing product. On the other hand is a group of subject service providers who are very concerned that they have a limited time to establish a reputation for stable, reliable services. Unfortunately, within the short eLib time scale both have to happen at the same time and this has inevitably meant compromise and, in some case disappointment. However it could be argued that the constraints imposed by this need for compromise will produce high quality product in a short time. Any judgement must be suspended for now.’ (ROADS) |
|
Access to Network Resources: Technical Issues and Learning: • It has become apparent that some method for describing relationships between resources is needed to enable coherent cataloguing and efficient retrieval. The present structure of IAFA/ROADS Templates does not allow any provision for creating named relationships between resource descriptions (such a facility is necessary for describing the contents of FTP archives, the purpose for which the templates were originally created), which is one of the primary reasons ADAM chose to investigate the use of a relational data model.’ (ADAM) • ‘The server is required to use the UNIX operating system in order to make use of the ROADS software, which means that administration of the server can only be realistically carried out by the Technical Officer. Deployment of the Windows NT operating system would have allowed more systems administration to have been carried out by other members of the project team.’ (ADAM) • ‘EEVL feels that the decision to be technically self-reliant was correct. Its technical expertise has allowed the project as a whole to progress more quickly and has also resulted in a very capable and responsive service. The match of the EEVL software to its hardware means that the core service will continue to use this software, while its information can be made available to any integrated service through its compatibility with ROADS.’ (EEVL) • ‘SOSIG is hosted on a shared server (with the Economics Department) and this has raised several technical challenges.’ (SOSIG) • ‘Initially, it was planned to migrate the SOSIG production service to each revision of the ROADS software as it was released. As other subject services became increasingly involved in producing and adding to the list of requirements for ROADS, it became clear that not all of the enhancements were necessary or desirable for SOSIG. The project hence decided not to upgrade from the 0.2.5 version to version 3.0 but to wait a little longer for v.1.0.’ (SOSIG) • ‘In hindsight, it would have been better to use an off-the-shelf general database product to create OMNI during the first year and then migrate to ROADS as v1.0.0 was released as a mature product. Developing the UMLS interface has proved to be a more technically challenging task than was anticipated in the original proposal. The problem has been examined from a theoretical point of view but substantial technical work is also required.’ (OMNI) |
|
|
|
|
|
On Demand Publishing: Some Lessons • ‘Course Directors have been wary of committing resources to the development of coursepacks and unwilling to consider new methods of teaching. Indeed there are questions whether the concept of ‘on demand’ publishing appeals at all, since at present they would prefer to set a course and not need to change it for five years or so. This in turn has created difficulties in involving users to take up the packs or to provide feedback.’ • ‘It was clear that there were differing expectations on the part of the [participating institutions]. Aside from the resource based resistance to course packs from academics, the positive responses in the Project Phoenix initiative have been primarily orientated towards web delivery instead of course packs. [The course directors at two test site universities] who have been prepared to consider new methods of delivery for learning materials, would prefer to move directly towards the most current form of technology.’ (Phoenix) • ‘The most unanticipated outcome so far is that academics who have expressed interest in the project would prefer to leap across the development of course packs and move instead to WWW delivery. There are two reasons for this: - first, the merit to be gained by technologically improving the delivery of their courses would appear to be higher if development is towards the most current learning developments; - secondly, it is perceived that the costs in producing an electronic course book will be less than a course pack due to the implications of reduced printing costs. Project Phoenix has yet to fully assess how realistic this may be. Whilst printing costs for course packs are not an inconsequential figure it represents but a small proportion of the cost compared to the copyright fees. Electronic copyright permissions are more expensive than reprographic rights but will transfer the costs to students on a pay-as-you-go basis. Once the media hype surrounding the WWW dies down, it will be interesting to see how readily students are prepared to pay for the service and whether there may be a return to an interest in course pack delivery which may eventually prove to be the cheaper option.’ (ODP in the Humanities) • ‘Both parties to the negotiations [on network licence agreements] have had a considerable amount of learning to do about where the other is ‘coming from’. Both of us had ideas about the likely shape of an agreement which have had to be modified in the light of growing knowledge of the other’s circumstances. There was little in the way of previous practical experience or precedent to guide us and both of us are, understandably, reluctant to enter into agreements which might later turn out to be prejudicial to our interests.’ (ODP in the Humanities) • ‘It is only with the development work undertaken in the first year of the project that the full complexity of the project has been identified. The initial proposal had a concept but fleshing out these ideas has led to several conflicts within the project group as to what should be in and out of the system. The conflicts have been resolved by the publication of the SEREN Scope and SEREN Release Plan documents. ....[Following changes in project personnel] it subsequently became apparent that the nature of the project required a ‘rapid prototype’ approach to develop a model which could then be demonstrated. This prototype could then enhance the discussion on the system aiding the formal SSADM approach which provides the final system specification.’ (SEREN) |
|
On Demand Publishing: Technical Issues and Learning • ‘The reasons for not using the Rank Xerox equipment are interrelated, concerning the need for an open system which could be transferred to other universities and interfaced with other applications and the fact that the system is becoming outmoded by other technologies. Firstly, the XDOD is a highly proprietary system; secondly, the hardware and software required for its operation are not competitively priced; thirdly, the copyright permission fees required to enable the production of course packs has decreased the demand for them, making substantial investment in systems to produce them unworthwhile; fourthly, academics are demanding access to Web-based resources for their students, and although XDOD managed resource can be Web-enabled, this has a not inconsiderable cost attached to it.’ (Phoenix) • ‘The Open Learning Foundation materials which were supplied had been prepared using Word for Windows and Quark Express not HTML. To prepare the documents for mounting onto the eOn sever they needed to be converted to HTML. However this was found not to be a practical solution as the documents contained complex formatting and graphics which HTML was unable to handle. The solution adopted was to use Adobe Acrobat as it allows documents to be converted into PDF files which can be viewed and printed from different machine types. To access this material Netscape and Acrobat Reader are required.’ (eOn) • ‘The speed of downloading files between remote sites varies widely because of technical infrastructures in the institutions. The interim solution has been to use Adobe Acrobats bookmarks facility to create a table of contents for each document with links to each section/chapter. This allows quick access to specific locations in the document.’ (eOn) • ‘Printing a complete document in a student access area is not currently practical due to the time it takes to print a document. It would appear that the specification of printers has a measurable effect on printing times.’ (eOn) • ‘The materials made available by the Open Learning Foundation are intended for interactive use in hard copy. For example in the text ‘Accounting’ there are multiple choice tests, in others there are questions to be answered and written down in tick boxes. It is not currently possible to do this in an electronic format.’ (eOn) • ‘During the evaluation, draft printing from the Xerox Documents on Demand (XDOD) proved far more difficult to implement than was anticipated. The conclusion is that the product, although appearing to be reasonably effective in achieving its objectives is too proprietary, insufficiently robust and too limited in its ability to interface with other systems and to meet the needs of Phoenix. Its high cost can also not be ignored.’ (Phoenix) |
|
On Demand Publishing: Technical Issues and Learning (continued) • ‘The original plan for printing control included software to be supplied by Docutext, a Rank Xerox re-seller. Access to the server would be controlled by user registration and printing metered against user accounts. After six months of discussion, however, the company admitted that the software was not actually available. An alternative strategy, based on EMOS flexi-cards and UnipriNT, a recently developed client-server print accounting system, is being considered. This system will use pre-credited cards rather than an account of credited-account mechanism.’ (Phoenix) • ‘Project Phoenix overestimated the ease with which commercial suppliers could develop software. Whilst Ran Xerox have participated wholeheartedly in the project, development of both PackBuilder and XDOD has to take place at the US Headquarters and whilst the changes and adaptations suggested by Phoenix have been taken on board, the next version cannot be developed in time for the project.’ (Phoenix) • ‘Our original assumption was that we would be able to acquire electronic originals of, perhaps, half the items we need from publishers. We were resigned to stripping out typesetter’s codes and adding HTML tags but believed that electronic originals would be obtainable. To date, we have not received a single electronic original from any publisher with whom we have dealt - however benevolent their attitude to our project. Almost invariably, the original field is with the originator, and the filed used for typesetting remains with the typesetter.’ ‘Instead we are obliged to work from paper originals. We have chosen, so far, to create text versions of the materials rather than bit-mapped images or PDF files. Creating text files is more expensive than creating bit-maps, in terms of staff time, but our (provisional) view is that it is currently the only feasible way to create materials which are acceptable visually both when read on screen and when printed out.’ (ODP in the Humanities) • ‘The accuracy of the character recognition system when dealing with poor quality originals, especially footnotes, left much work to be done through proof-reading and subsequent correction. (Scope) Digitilisation reduces production costs for texts considerably, but as yet, publishers are unwilling or unable to supply texts in digital form. As a result, the overall cost of digitalising for print production is prohibitively expensive due to the requirement that all scanned material must be proofread.’ (Scope) • ‘Standards developed for scanning and OCR in the Digitisation project: - archive scans should be done at 300 dpi and 24-bit colour, stored as a TIFF, using PC byte order, then conversion to JPEG; - 16 greyscales should be employed for maximum accuracy of OCR.’ (DIAD) • ‘Huge file sizes of TIFFs created by high resolution scanning resulted infilling up available disc space quickly. This was solved by batch conversion to JPEG format using level 15 compression which was found to exhibit no discernible loss of quality. These files were then archived on to writeable CD and the originals deleted.’ (DIAD) • ‘The EFS WebFile could not display grey-scale images but this limitation is circumvented by Webfile which does not provide its own support for displaying images, but depends on helper routines. Any image format can therefore be counted, including JPEG grey-scale images, and display capabilities will depend on the functionalities of the end-user’s browser.’ (DIAD) • ‘Preliminary studies and recent initial tests indicate that the 19th century journals could give satisfactory OCR results with bitonal scanning; but the 18th century journals with heavy show-through and high variability in type face quality will not.’ |
A further two concerns raised by EDD projects are the potential for scaling up, and the limited timeframe for producing project impacts.
|
Electronic Document Delivery: Some Lessons • ‘The milestone in the second stage has not been reached because a change in the functional requirements was requested by the consortium librarian members. They rightly thought, that with the rapid expansion of use of the WWW, that we needed to bring in a Web element earlier than had been originally planned. The functionality change caused major disruption to the project timescales and meant that we had to revise the Functional Specification, the High Level Design and also make changes to lower level design.’ (Infobike) • ‘Another example of events overtaking the project was the rapid movement by publishers to mount their own document servers. Originally the project planned to duplicate document servers geographically but the experiences of the Academic Press document server showed us that the administration and support required for document servers is expensive and duplicating servers was not a good idea.’ (Infobike) Electronic Document Delivery: Technical Issues and Learning • ‘The copyright restriction on EU texts whereby documents may be freely reproduced except in facsimile has had a great impact on the project. Documents scanned in PDF format (for greater accuracy) have to be saved in MS Word and then marked up in HTML in order to change the appearance.’ (Eurotext) • ‘The initial use of Omnipage OCR software for scanning resulted in many efforts necessitating time consuming proof reading. Furthermore it could not cope with tables embedded in the text. The combination of the poor quality of the original documents and their complex nature together with the restriction on facsimile reproduction and the initial choice of scanning software has had a deleterious effect on the project.’ (Eurotext) ‘LAMDA’s major strength, `and also in a sense its major vulnerability is the use of off-the-shelf software and hardware. The major advantage of having no development programme was offset by the loss of control brought about by lack of access to the code. Only the introduction of a new driver software from RLG, together with the introduction of Fujitsu scanners at the key sites solved the problem.’ (LAMDA) |
|
Training and Awareness: Some Lessons • ‘The need to deliver a complicated product in two formats according to a strict schedule left less time for consultation and discussion than is idea. This was exacerbated by a reliance on email, a medium which we have found limited for the purposes of certain types of decision-making and constructive debate.’ (Ariadne) • ‘A tension exists between the need for a frequent magazine publication such as ARIADNE to be provided with a regular supply of copy and the risks inherent in journalism. Without significant financial resources behind the publication, our capacity for risk-taking is diminished. Even with agreements from authors to take responsibility for their writings, many of the articles we publish are the work of staff writers, which means that it is impossible to eliminate the possibility of litigation being pursued against us. We seek to reduce this risk by gaining the prior approval of authors and subjects for most of the material we publish. Nevertheless, the dangers of litigation are such that the prospect of the publication being adopted by a mainstream publisher becomes quite attractive.’ (Ariadne) |
The Electronic Libraries Programme (eLib) was funded
by the Joint Information Systems Committee (JISC)
Page version: 1;
Web page maintained by
UKOLN Systems Team
and hosted by
UKOLN
- feedback to
systems@ukoln.ac.uk
.
Site last revised on: Tuesday, 24-Nov-1998 14:21:04 UTC
DC Metadata
Last updated 04-Apr-1997