Dynamic Duo: The Web Developer and the Public Services Librarian

By Eric Frierson

When I undertook my first library website redesign a few years ago, I stumbled upon an ongoing culture clash in web-based industries between the developer and the designer. Developers are programmers – they have coding skills and speak languages like PHP, jQuery, and AJAX. For them, Cake isn’t something you eat – it’s a development framework. They use these tools to make technology do what they want.

Designers, on the other hand, are artists. They work with clients to understand their needs, sketch potential designs using tools like Photoshop® or pencil and paper. They deal with the frustrations of the client relationship (e.g., telling the client pictures of his cat shouldn’t go on his website).

Designer vs Developer from anistar sung on Vimeo.

Here’s the rub: many designers can’t code and can’t make the websites they draw. Some designers wield CSS well enough to set the visuals of a website, but they don’t know how to get search boxes, dropdown menus, and interactive elements to do what they want. Conversely, most developers don’t understand the relationship with the client or have training in visual design. They believe they know best when it comes to a website that works, and as a result, don’t work well with fickle clients.

Relationships between designers and developers range from antagonistic to cooperative, and the best of these relationships embody the complimentary nature of the two roles. However, some designer/developer relationships devolve into name-calling and contempt. At the heart of these kinds of relationships is a lack of understanding and respect for one another.

In libraries, there is an obvious parallel: the library’s web developer[1] and the public services librarian[2]. The web developers spend the day making library websites and systems work, rarely taking shifts at public service points. They work within the constraints of proprietary systems they can’t change and grapple with the web environments of larger systems in which they work (e.g., a city or university’s web infrastructure).

Public services librarians put out a lot of fires. They teaches people how to navigate library systems that for some reason never seem as good as Google. Because of their constant contact with users, they understand the heartbeat of the community. They focus on developing relationships with users and stakeholders.

Sometimes, these two clash in the same way designers and developers do, each clamoring for respect. Having occupied both sides of the divide, I find myself in a unique position to understand how both sides may perceive the relationship.

For example, I understand the frustrations public services librarians feel when they work with end users on systems that are deficient. These librarians are the eyes and ears of our organization, and yet, they are often powerless to do anything about it except to bemoan the inefficiencies of these systems to their web developers, who don’t seem to understand the community’s needs.

I also understand that web developers are frequently hamstrung by inflexible interfaces and conflicting opinions of how the systems should be optimized. Some librarians clamor for more controlled search features, while others request simpler search options that provide “good enough” results. Some librarians come armed with research studies from the literature supporting their position, and others call upon anecdotes from their interactions with users. The demands of their colleagues may even contradict their own expert opinion.

The frustrations web developers and public services librarians feel sometimes boil over into animosity:

• “The web developer doesn’t understand what our users need! Why can’t she just fix the problem?”
• “The public services librarian brings me these anecdotes, but no evidence! Does he expect me to change the whole website based on one story?”

Resolving this disconnect requests a deeper understanding of each other’s territory. In addition, new tools and skills are required for both types of librarians to become better partners in a web developer/public services relationship. These include the use of APIs to break free of the out-of-the-box interfaces our vendors provide and ethnographic research skills that provide insight into the needs of our users.

A Systems and Services Team

It’s clear that public services librarians can’t do it alone: they don’t have the capability to change the systems that users interact with. Similarly, web developers can’t do it alone either: guessing at user needs without interacting with actual end users is a losing battle. The answer is developing a team with shared goals and an attitude that lends itself to collaboration and learning.

First, you’ll need to identify the right people for the team. In small libraries, you may not have a choice if you only have one web developer. In Good to Great, Jim Collins (2001) wrote that excellent “teams consist of people who debate vigorously in search of the best answers, yet who unify behind decisions, regardless of parochial interests” (p. 63). This means both the web development and public services staff must be committed to users, not their respective departments.

A positive, optimistic attitude also contributes to team success, especially in newly formed teams (West, Patera, & Carsten, 2009). Someone with a sour attitude who is only interested in protecting ‘their domain’ will not be a good candidate for the kind of collaborative work this team will be doing.

But what if the attitudes are not there? Collins (2001) notes that some employees join companies because they like the job and the direction the organization is going. This becomes a problem when the organization shifts direction and jobs begin to change; those same employees become discontent and start putting on the brakes.

Collins (2001) would recommend that library directors confront bad attitudes directly by stating plainly what the new directions of the organization are, and inviting employees to commit or quit. He quotes David Maxwell, who focused his first years as CEO of Fannie Mae finding the right people to work at the organization and getting the wrong people to leave. Maxwell would say, “Look, this is going to be a very hard challenge. I want you to think about how demanding this is going to be. If you don’t think you’re going to like it, that’s fine. Nobody’s going to hate you” (Collins, 2001, p. 45). Several Fannie Mae employees left the company, but on amicable terms, and Maxwell was able to hire people who came to Fannie Mae because of its mission and the people who worked there, not because of the nature of the job.

In a down economy and with tenure systems in place, getting the wrong employees to leave is almost impossible, but there may still be hope for developing the type of culture needed for a successful systems and services team, but it will be extremely difficult without gaining buy in from the curmudgeons. If your organization doesn’t have the right attitude, the systems and services team may not be a good fit for you.

New Tools: Ethnographic Research and API

Once the team is assembled, there’s another element to making it work: new tools. Anecdotes are not enough, and out-of-the-box systems are inadequate. Public services needs new ways to gather data and web developers need better ways to change the interfaces users encounter.

Ethnographic Research

If web developers have anything to complain about the kind of feedback they get from public services librarians, it’s that the feedback is entirely anecdotal. Users that come to the physical services desk in tears because they can’t figure out how to use the website leave a lasting, significant impression on the public services librarians that try to help them. However, to a web developer, one person is not enough to merit changing an entire site.

In this situation, neither the public services nor the web developer has a clear view of how the vast majority of people use the website. One distraught user cannot dictate the design of the site; conversely, web analytics don’t tell the “why” of the paths people take through the site.

Ethnographic research provides a way to improve upon anecdote and analytics by examining “the context in which activities occur, usually involving a researcher working with participants as they go about their daily lives. Ethnographers typically describe a particular situation or process by asking multiple people about it, and by analyzing multiple types of data, such as interviews, direct observation…” (Duke & Asher, 2012, p. 24).

Ethnography isn’t new in libraries. A good first step might be to learn from what previous ethnographies of libraries have discovered, and consider what opportunities you already have to introduce change based on their findings.

Ethnographic research solves the dilemma of the anecdote by providing an analysis of situations that go beyond the surface; in other words, we’ll know why our users interact with our sites in the way that they do, and we’ll be able to identify patterns in user behavior.

In an era of fewer and fewer reference demands, ethnography presents an interesting new role for public services librarians. In a sense, they become not only the eyes and ears of the library, but they also contribute a deep understanding of users based on qualitative research. For a web developer, having access to this kind of analysis of user behavior is invaluable.

APIs and Web Services

For some time, librarians have recognized that library instructional content must come at the point of need (Stevens, 2009). Digital learning objects, online tutorials, and guides relegated to a remote corner of the website do not get traffic – they must be embedded in places where students struggle.

The problem with most libraries’ current set of tools is the inflexibility of the systems that students interact with. As we have recognized at St. Edward’s University, the library website is little more than a pass-through site for EBSCO Discovery Service (EDS). Most of our users land on our page and then immediately leave via the search box to enter EDS.

Unfortunately, when users get to EDS, we have little control over the user experience. We can toggle certain elements on our page, re-label some of the facets, and add a little bit of branding to the page, but little else. We are constrained by the administrative controls of EBSCOhost, and as a result, most of users time in library resources only vaguely resembles the library site at all:

Deeper problems happen with the folder feature. Many of our students access EDS from off-campus. As a result, they explicitly log in to our library’s proxy server in order to conduct searches and access full-text. They assume that when they add items to the “folder,” those items will be associated with their login. Instead, they discover days later that all of their folder items are lost, because they did not log into EBSCOhost in addition to the library’s proxy server.

While EBSCO will likely find a way to tie folders to university authentication in the future, we are stuck waiting for that to happen. Even if this were solved, the folder of items still lives on EBSCOhost, disconnected from where students are using those items.

The solution lies with an API (application programming interface). EBSCO provides programmers with tools to use EDS metadata, its search algorithm, and facets and filters without having to use EBSCOhost as the user interface. This allows web developers to create a search interface from scratch, including a folder system that ties into university authentication.

Google, WorldCat, Facebook, and Twitter all provide APIs that could be used to enhance the digital experience for users. For example, previews of library books can be displayed in an OPAC using Google Books previews. The ability to “like” and “share” library web pages and materials via Facebook also ties use of the library to the user’s social circles – something public library users may be inclined to do.

APIs free us from the constraints of out-of-the-box interfaces, and there are a lot of them to select from. They require a different set of programming skills than typical web development.

Bullets to Cannonballs

Ethnography and APIs represent an incredible opportunity, but at what costs? Is it worth reinventing the whole discovery search interface using an API? How likely is it that an inexperienced public services staff of one person can add a comprehensive ethnographic research study to their “to do” list? A reasonable answer comes once again from business author Jim Collins and co-author Morten T. Hansen, who recommend that organizations try new initiatives in small doses before investing significant resources (Collins & Hansen, 2010). They use the metaphor of a ship at sea engaged in a fight:

“Picture yourself at sea, a hostile ship bearing down on you. You have a limited amount of gunpowder. You take all your gunpowder and use it to fire a big cannonball. The cannonball flies out over the ocean…and misses the target, off by 40 degrees. You turn to your stockpile and discover that you’re out of gunpowder. You die” (p. 78).

The moral of this story is that new initiatives are inherently risky; a misfire could result in lost profits, lost time, and ultimately may sink a company altogether. A better strategy is to fire bullets – ventures that require less “gunpowder” – until one hits a target, then fire your cannonball.

For us, this means starting slow. A fully fleshed out ethnographic research study could take years of data gathering using sophisticated research techniques. However, you could start as we have as St. Edward’s University with focus groups that try to get at the context of library research. Rather than directing questions at the use of library resources, the focus group should be about the whole research experience, from topic selection to completed paper. For public libraries, questions might be addressed to local business owners in order to determine what information they need to run a successful business and where they find that information.

A small focus group may not get you the same level of understanding as a full ethnographic study would, but it will uncover some aspects of the context in which library users interact with our resources and services. The focus group would require far less time, staff, and expertise to carry out.

If the focus group results in ideas to improve services or systems, library directors might be more willing to provide resources to expand ethnographic studies of library users. Andrew Asher and Susan Miller provide A Practical Guide to Ethnographic Research in Academic Libraries as a toolkit for libraries to begin a more in-depth study.

For APIs, perhaps the bullet is in smaller projects that add value to the site, not an entire site redesign. For example, our website makes use of an API to dynamically pull the number of computers that are available in our lab. Other APIs, such as those provided from WorldCat.org, can pull APA or MLA citations into a catalog based on an item’s ISBN or OCLC number.

Valuable entry-level projects like this can be used to gauge the time and effort working with APIs might require, along with experience that helps us consider possibilities APIs introduce. For example, an API-driven discovery interface can position libraries to integrate deeply into campus portals (instead of just linking to the library, users can search and mark library materials they want to use right from their library management system), solve usability issues in out-of-the-box interfaces, and embed context-sensitive links and resources into the search experience (e.g., video tutorials on search strategies when a user gets no results; or ‘help’ messages that pop up the first time a user logs in, but not during subsequent visits).

Jason Clark offers an online LITA workshop designed to get library web developers using APIs, and code4lib provides articles and conferences that are worthwhile investments for library directors looking to fire bullets at APIs before asking their web developers to commit to bigger projects.

Ethnography and APIs are tools that not many people in libraries can use, and it will take a serious commitment of time, money, and reorganization of job duties in order to make the fullest use of them. Small investments and pilot projects like these provide ways to fire a few bullets before deciding if it’s time to fire a cannonball.

Managing the Team and Making the Time

Even if small pilot projects are successful, library directors and librarians themselves may have difficulty committing to a new set of responsibilities. How can ethnography and API programming be added to job duties when librarians and web developers are already spread thin? The answer is a commitment to learning and growth.

For example, 3M has been recognized as one of the most innovative companies for several decades (Kretkowski, 1998; Nelson & Quick, 2011). Business analysts credit the company’s innovative culture to the “15 percent” rule, which gives professional employees permission to use up to fifteen percent of their work time on personal projects and constructive daydreaming.

Fifteen percent might seem like a lot to sacrifice, especially if librarians are already busy enough maintaining current levels of service. However, in How the Mighty Fall, Jim Collins (2009) notes that companies that succeed in turbulent times are the ones that invest in research and development and growth, not in maintaining the status quo. A close examination of what legacy services should be dropped may free up the room for employees to explore, learn, and grow the library in new directions.

The right employees will relish this opportunity. Buckingham and Coffman (1999) point out that managers who put employees in positions where they have to learn a new skill are more satisfied with their work, because they are growing as a result of it. Speaking from experience, there has not been a more satisfying project at my own workplace than learning how to use APIs to do more with our Discovery Service. It is a new skill I’ve picked up as a result of the project and I am energized by the opportunity to grow as an individual.

But what should we drop if we allocate our time elsewhere? At our library, we didn’t drop anything – we hired. Having second employee in our systems unit has increased our capacity to maintain library systems and expand into new areas of web development. The funding for this position came from recently vacated positions in technical services, administration, and acquisitions.

For public services, slow hours at the desk were converted to office time for our reference staff. There are many months of the year where traffic at our desk does not merit having professional staff waiting for questions, and this time can be recouped for projects like focus groups and ethnography.

Gaining Respect

Public services librarians will garner more respect from their web development colleagues when they present findings from studies that illustrate real, measured, and significant user needs. Unlike an anecdote from the reference desk, ethnographic study comes with legitimacy. Recommendations seem less like complaints about the systems, and more like steps to take to meeting a shared goal of improved user experience.

Conversely, the web developer equipped with the skills to design a system that addresses identified needs gets more respect as well. Instead of blaming inflexible interfaces for bad user experience, web developers can invent solutions and fix problems.

Gaining Momentum

Usability tests are the perfect introduction to developing a deeper public services and systems partnership. It isn’t ethnography and it requires no technical training, and lightweight usability methods are easy to adopt and use. It exposes public services libraries to the work of designing websites, and it exposes web developers to working closely with end users trying to accomplish specific goals.

Pick up Steve Krug’s book, Rocket Surgery Made Easy. Krug explains how to conduct a low-effort, high-reward usability test that pulls upon the talents of many people in the organization and produces an actionable list of fixes for a site.

The process is as follows:

1. Develop some goals for the usability test: what part of the site do you want to improve?

We’ve done tests on eBook access, front-page design, and EBSCO Discovery Service among others.

2. Identify one person to conduct the usability test, and write the script for the test.

Krug provides tips on how to develop the script and even provides templates on his site to use to take care of the privacy and permissions aspects of working with end users.

3. Conduct only three short tests, with the idea being that 3 users will capture 80% of the problems on the site. It will also not require a huge time commitment.

4. Screencast[3] the usability test to a room where people interested in improving the site can watch the test and record notes.

This allows the tester to focus on conducting the test, not on taking notes. It also provides the opportunity for varied perspectives on the user’s behavior.

5. When testing is over, immediately conduct a debriefing with everyone who watched the test. Use this time to identify the top three or five things to fix on the website.

Krug provides guidelines on what kind of fixes deserve priority, and which ones can wait.

A well-executed usability study following Krug’s guidelines results in action and productive change. It sets the tone for teams to engage in more time-intensive projects like ethnographic research studies and API-based web development. The usability test may uncover some deficiencies in systems that only API development can fix, or it may lead to questions about the users that a simple usability test cannot answer. More than anything, it will start discussions that are user-centric between people that may not ordinarily come into contact.

Onward, Library!

Every aspect of the library profession is retooling. Catalogers are working with batch loads of records more than they do original cataloging. Collection development librarians are working with patron-driven acquisition models more than approval plans or firm orders. Archivists are deriving new value from their digitized collections with text mining techniques. Public services are spending less time at the reference desk, and ethnography might be their new tool for learning about users. APIs are the newest tools of web developers.

We are vastly different than we were a few short years ago. Our libraries need to be able to grow and change as the world around us does. There is little room for silos and the status quo, and no room for those who are unwilling to grow and learn the new skills required to thrive. Collaboration is about gaining new skills and gaining respect for one another. It is about finding a way for us to apply our talents to achieve success together.

Finally, we need to recognize that not all libraries need to do original coding or ethnographic research. Code can be shared, and ethnographic studies already exist. Libraries unable to commit the resources needed to do local work can use the work of others. What may seem like unique situations and circumstances are actually commonplace from library to library. If your library engages in work that provides insight into user behavior or develops code that enhances the user experience, share it!

I cannot thank the smashing editing work and candor of Ellie Collier and Erin Dorney enough – they are my editing heroes!  Similar kudos and thanks to Pongracz Sennyey, director of the library at St. Edward’s University, and reviewer for this post.  His contributions of ideas and directions for this post were invaluable!

References

Asher, A. D., & Duke, L. M. (2012). A practical guide to ethnographic research in academic libraries. Retrieved from http://www.erialproject.org/publications/toolkit/

Booth, C. (2009). Informing innovation: Tracking student interest in emerging library technologies at Ohio University. Chicago: Association of College and Research Libraries, American Library Association.

Buckingham, M., & Coffman, C. (1999). First, break all the rules: What the world’s greatest managers do differently. New York, NY: Simon & Schuster.

Collins, J. C. (2001). Good to great: Why some companies make the leap–and others don’t. New York, NY: HarperBusiness.

Collins, J. C. (2009). How the mighty fall: And why some companies never give in. New York: HarperCollins.

Collins, J., & Hansen, M. T. (2011). Great by choice: Uncertainty, chaos, and luck : why some thrive despite them all. New York, NY: HarperCollins Publishers.

Duke, L. M., & Asher, A. D. (2012). College libraries and student culture: What we now know. Chicago: American Library Association.

Foster, N. F., & Gibbons, S. (2007). Studying students: The Undergraduate Research Project at the University of Rochester. Chicago: Association of College and Research Libraries.

Krug, S. (2010). Rocket surgery made easy: The do-it-yourself guide to finding and fixing usability problems. Berkeley, Calif: New Riders.

McDaniel, C. (2011). Two cats in a sack: Designer-developer discord. Smashing Magazine. Retrieved from http://www.smashingmagazine.com/2011/05/13/two-cats-in-a-sack-designer-developer-discord/

Nelson, D. L., & Quick, J. C. (2011). Organizational behavior: Science, the real world and you. Australia: South-Western Cengage Learning.

Stevens, M. (2009). Being at the point of need. Tame the Web [blog]. Retrieved from http://tametheweb.com/2009/09/20/being-at-the-point-of-need/