No lie, these articles were difficult for me to get through. Cervone’s was straightforward and informative, while the article by Zhang et. al seemed packed with fascinating information but written in such a way to discourage interested readers. Despite their readability, both articles presented useful material which I found very useful. The perplexing notion that has stuck in my mind is that librarians rarely design their own software and systems - while some companies do hire librarians to help with the design, there’s a huge gap between the users and the designers.
I’ve used about three different library systems over the last several years: Voyager, Sierra, and LibraryWorld. When I say that I used LibraryWorld, I mean that I used the version which was installed on my high school’s computer which was still running Windows 98 in the early half of the 2000s. Hours spent copy cataloging and wrestling with the large graphical interface that looked like a 3 year-old’s first laptop toy. So when I say that I prefer that experience over the current release of Sierra, you know that I mean business. The reason for my distaste for the version of Sierra that the WRLC uses (rather, that Georgetown and GMU use) is its interface design and inefficient functionality. The slow loading time, inconsistent displays, bright teal interface, and menus that appear to be loosely based on Excel are not something I would wish on my worst enemy. Not to ignore Voyager: while I’m not overly fond of its jargon-heavy menus and buttons, I don’t dislike it. Having used it for a while now it has begun to make sense. While it’s not intuitive or pretty, its functionality wins out.
All these systems were designed for librarians to use and operate, and using these systems “involves a strong cognitive component” that is difficult for the non-librarian/library staff member unused to complicated software or jargon-heavy language Zhang, 2005). Sutcliffe’s research is cited by Zhang as supporting the statement that “[while Human-Computer Interaction] created structured methods from both academic research and industrial authors, these ideas were largely ignored by software engineers” (Sutcliffe, 2000). The software we are currently using is meant for functionality but not usability. So when technology starts moving in the direction of smooth, clean, lovely interfaces and the designers behind our professional software don’t keep up, what then? Frustration abounds. This is the dark side of changes in technology and policy, when a solution exists but is ignored by those who can make a difference. When companies/corporations/designers/publishers restrict access to materials, users complain and put their own skills to use. They circumvent DRM through bypassing software, using their own non-electronic digital hardware (“I say to you, “Behold, the typist.””).
What do librarians do?
What can librarians do when our own systems discourage us from using them by being all but unusable?
Design our own highly-complex-but-usable cataloging software? Certainly not. We don’t have the money to hire a developer, don’t have the skills of our own, can’t come to an agreement on formats, standards, and compatibility. We are stuck with badly-designed, clunky, slow, expensive software. We are a stubborn bunch who choose to weather out the difficulties of interface design and curmudgeonly complain (not without some inner joy) about it rather than raise pitchforks or put hand to the grindstone and learn how to make the software ourselves.
Our own system development life cycle gets a wrench thrown in its wheel as soon as design enters the picture. We choose software that is as flexible as possible for the patron interface. Sacrificing our own usability for functionality. The training period, which is usually completed during the initial installation and transition between systems, becomes stretched and elongated, costing significant costs in time and mistakes. The continuous feedback is quickly exhausted and turns into frustrated sighs, and by the time we realize how long it will take to get the kinks worked out it’s too late to turn back. (Cervone, 2007)
A librarian’s response is to make the patron-facing side of the software as usable as possible and be as personally knowledgeable as we can in order to help with the learning curve. To once again be a buffer between the corporation and the patron. Most OPAC software is pretty snazzy, usable, and (largely) easy to use. Unfortunately, systems like Sierra often come with really nice patron-side interfaces OPACs or have nice add-ons like Encore that make things prettier for patrons, but fail to have beauty deeper than the smooth lines of the CSS file in their demo.
Fortunately, librarians have become Internet-savvy and vocal, and companies are beginning to open channels for collaboration. Innovative Interfaces has a user group forum that encourages feedback and sharing of solutions. User interface design is becoming more and more a focal point, thanks to the fact that patrons are using their own technology and beginning to realize that the power of a piece of software and difficulty of use shouldn’t have a positive correlation. Encouraging companies to use human-computer interaction development as a focal point for their usability tests may be the most useful thing to do for everyone involved. There are many, many very talented designers in the vast Internet, and companies now recognize the need for them.
Jessamyn West once called librarians a “dumb market… dumb in that I don’t think they’re aware as a homogenous group of just how powerful they are…. Well, tell [the companies] to stuff it, and tell them to come back with a better [product]. Theoretically we have the power to do that” (Carlson, 2007). While she was referring to scholarly publications and contracts, I believe that her statement rings true in many cases. When libraries begin to become a sea of hands instead of just a sea of voices we will begin to start seeing change. Put aside our comforting complaints and begin to really create a feedback loop with companies, get dedicated ongoing evaluations and share our training experiences. I can’t say it will solve the world’s problems, but it might make the world’s information a little easier to access.
Works Cited
I’ve used about three different library systems over the last several years: Voyager, Sierra, and LibraryWorld. When I say that I used LibraryWorld, I mean that I used the version which was installed on my high school’s computer which was still running Windows 98 in the early half of the 2000s. Hours spent copy cataloging and wrestling with the large graphical interface that looked like a 3 year-old’s first laptop toy. So when I say that I prefer that experience over the current release of Sierra, you know that I mean business. The reason for my distaste for the version of Sierra that the WRLC uses (rather, that Georgetown and GMU use) is its interface design and inefficient functionality. The slow loading time, inconsistent displays, bright teal interface, and menus that appear to be loosely based on Excel are not something I would wish on my worst enemy. Not to ignore Voyager: while I’m not overly fond of its jargon-heavy menus and buttons, I don’t dislike it. Having used it for a while now it has begun to make sense. While it’s not intuitive or pretty, its functionality wins out.
All these systems were designed for librarians to use and operate, and using these systems “involves a strong cognitive component” that is difficult for the non-librarian/library staff member unused to complicated software or jargon-heavy language Zhang, 2005). Sutcliffe’s research is cited by Zhang as supporting the statement that “[while Human-Computer Interaction] created structured methods from both academic research and industrial authors, these ideas were largely ignored by software engineers” (Sutcliffe, 2000). The software we are currently using is meant for functionality but not usability. So when technology starts moving in the direction of smooth, clean, lovely interfaces and the designers behind our professional software don’t keep up, what then? Frustration abounds. This is the dark side of changes in technology and policy, when a solution exists but is ignored by those who can make a difference. When companies/corporations/designers/publishers restrict access to materials, users complain and put their own skills to use. They circumvent DRM through bypassing software, using their own non-electronic digital hardware (“I say to you, “Behold, the typist.””).
What do librarians do?
What can librarians do when our own systems discourage us from using them by being all but unusable?
Design our own highly-complex-but-usable cataloging software? Certainly not. We don’t have the money to hire a developer, don’t have the skills of our own, can’t come to an agreement on formats, standards, and compatibility. We are stuck with badly-designed, clunky, slow, expensive software. We are a stubborn bunch who choose to weather out the difficulties of interface design and curmudgeonly complain (not without some inner joy) about it rather than raise pitchforks or put hand to the grindstone and learn how to make the software ourselves.
Our own system development life cycle gets a wrench thrown in its wheel as soon as design enters the picture. We choose software that is as flexible as possible for the patron interface. Sacrificing our own usability for functionality. The training period, which is usually completed during the initial installation and transition between systems, becomes stretched and elongated, costing significant costs in time and mistakes. The continuous feedback is quickly exhausted and turns into frustrated sighs, and by the time we realize how long it will take to get the kinks worked out it’s too late to turn back. (Cervone, 2007)
A librarian’s response is to make the patron-facing side of the software as usable as possible and be as personally knowledgeable as we can in order to help with the learning curve. To once again be a buffer between the corporation and the patron. Most OPAC software is pretty snazzy, usable, and (largely) easy to use. Unfortunately, systems like Sierra often come with really nice patron-side interfaces OPACs or have nice add-ons like Encore that make things prettier for patrons, but fail to have beauty deeper than the smooth lines of the CSS file in their demo.
Fortunately, librarians have become Internet-savvy and vocal, and companies are beginning to open channels for collaboration. Innovative Interfaces has a user group forum that encourages feedback and sharing of solutions. User interface design is becoming more and more a focal point, thanks to the fact that patrons are using their own technology and beginning to realize that the power of a piece of software and difficulty of use shouldn’t have a positive correlation. Encouraging companies to use human-computer interaction development as a focal point for their usability tests may be the most useful thing to do for everyone involved. There are many, many very talented designers in the vast Internet, and companies now recognize the need for them.
Jessamyn West once called librarians a “dumb market… dumb in that I don’t think they’re aware as a homogenous group of just how powerful they are…. Well, tell [the companies] to stuff it, and tell them to come back with a better [product]. Theoretically we have the power to do that” (Carlson, 2007). While she was referring to scholarly publications and contracts, I believe that her statement rings true in many cases. When libraries begin to become a sea of hands instead of just a sea of voices we will begin to start seeing change. Put aside our comforting complaints and begin to really create a feedback loop with companies, get dedicated ongoing evaluations and share our training experiences. I can’t say it will solve the world’s problems, but it might make the world’s information a little easier to access.
Works Cited
Carlson, S. (2007). Young Librarians, Talkin’ Bout Their Generation. Chronicle of Higher Education, 54(8), A28-A30.
Cervone, F. (2007). The system development life cycle and digital library development. OCLC Systems & Services, 23(4). 348-352.
Sutcliffe, A. (2000). On the Effective Use and Reuse of HCI Knowledge. ACM Transactions on Computer-Human Interactions, (7)2.
Zhang, P., Carey, J., Te-eni, Dov, & Tremaine, M. (2005). Integrating Human-Computer Interaction Development into the Systems Development Life Cycle: A Methodology. Communications of the Association for Information Systems, (15). 512-543.
Cervone, F. (2007). The system development life cycle and digital library development. OCLC Systems & Services, 23(4). 348-352.
Sutcliffe, A. (2000). On the Effective Use and Reuse of HCI Knowledge. ACM Transactions on Computer-Human Interactions, (7)2.
Zhang, P., Carey, J., Te-eni, Dov, & Tremaine, M. (2005). Integrating Human-Computer Interaction Development into the Systems Development Life Cycle: A Methodology. Communications of the Association for Information Systems, (15). 512-543.
No comments:
Post a Comment