OPAC Survey results – part 4

Technology Adoption
Let’s look at how widely the 10 features have been implemented now, and also how many respondents are planning to implement them soon…
If we then plug that into the Technology Adoption Lifecycle (see this blog post for more info), then we can see which group the feature is currently with.
If we then make an assumption that everyone who said that they were planning to implement the feature soon actually does so, and also does it before the end of 2007, then we can attempt to predict which group the feature will be with by the end of the year…
Remember, anything in green (i.e. over 16%) is said by Moore to have “crossed the chasm” and has the potential to become widely adopted.
In a future post, I’m going to try and look at how innovation and adoption is actually driven. My hunch is that it’s a small number of libraries who do the actual innovation (i.e. they are the risk takers and pioneers) and it’s the system vendors who then pick up the technology in the early adoption phase and help push it across the “chasm” into widespread adoption.

3 thoughts on “OPAC Survey results – part 4”

  1. I’m convinced that the “did you mean” feature would already be widely adopted if it were available in our integrated library systems. We certainly would have turned on that feature if it were available in our Voyager catalog. Currently it is not. There are Voyager libraries that have implemented some spell-checking, but it requires having a programmer on staff who can write scripts that provide functionality missing from the ILS. Most of us don’t have that kind of expertise available, so we’re dependent on the vendors to make it available in their systems.
    The fact that we haven’t implemented one of these features doesn’t necessarily mean we don’t want it. Your theory that the vendors help push it across the adoption chasm is right, but in many cases it’s because we’re so dependent on them to supply the functionality. If the “did you mean” functionality had been there years ago, when libraries were already asking for it, it would have been widely adopted by now.

  2. I think you’re right Irene.
    The thing that frustrates me the most, and perhaps is one of the reasons why we’ve done so many of these things ourselves at Huddersfield, is that it often takes too long for vendors to add new features.
    It’s not as if some of these are technically difficult to implement — once we’d decided to use Aspell for our “did you mean”, it only took 3 or 4 hours to complete the development.
    In fact, I probably spent twice as long in meetings saying why we should do it 🙂
    I’m a strong advocate of libraries having their own developer (even if it’s just a part-time position).
    In an ideal world, OPACs would have been developed to be easily extensible. That way, just one customer would need to do the development, and the code could be easily and safely shared amongst everyone else.
    I’m always more than happy to share our code, but it often requires setting up a separate web server and MySQL database, as well as making alterations to the OPAC pages (which may then cause issues with getting technical support from your vendor).

Comments are closed.