Endeca, the Phoenix Public Library’s experience.
The catalog is the most important piece of the ILS for our customers and today, many libraries and agencies are unbundling the OPAC from the ILS. In 2007, Phoenix Public Library implemented the “guided navigation” of Endeca for Libraries, as well as Book Industry Systems Advisory Committee (BISAC) headings for its library OPAC. This program will showcase this innovative system and examine what led to undertaking this action. Speakers: Ross McLachlan, Deputy Director, Technical Services, Phoenix Public Library; Jesse Haro, Web Manager, Phoenix Public Library.
The Phoenix Public Library has a rich history of 110 years. 14 branches are soon growing to be 16, serve a metropolitan population of 4.5 million and have an annual circulation of 15 million and 30 million hits on its web site.
In 2002, Phoenix Public Library realized that its ILS wasn’t working for their users. It was not customer driven and faced fierce competition in the retail world. The Phoenix study team, comprised of 30 staff, wanted to add a discovery layer to the OPAC and envisioned a customer driven, fast, easy, intuitive, retail based, and seamless design. On the cheap and customer driven, this was not to be librarians designing for librarians. The team designed a new OPAC, which was recognized by Library Journal in 2004. “A dynamic, database-driven design sets a benchmark for library web sites”
The resulting OPAC, however, had several limitations –
· Underlying functionality limited by ILS
· No patron account integration
· No API (application programming interface) -based access to data
· No ability to influence searching/browsing
Basically Phoenix wanted a better way of connecting its customers on-line without taking years to accomplish. In January 2005, Phoenix’s team began a product evaluation (Endeca, AquaBrowser, TLC/CARL). Endeca met all the established criteria (listed above). So, what is Endeca? Endeca is software, primarily commerce driven (i.e. Home Depot, Barnes & Noble, Wal-Mart). Endeca can harvest data; it is API based. What is API? - Application Programming Interface) Development to the Go-Live-Date took a little over a year. The project scope consisted of
· Integrating Endeca with bibliographic data
· Integrating the Endeca navigation with API
· Adopting BISAC subject headings
· Integrating ILS API
The challenge basically was integrating a commercial application (on a main frame computer) to library and customer data. Data integration was conducted continuously through the development stage using teams of staff librarians. Configuration consisted of refinements, search interfaces and relevancy strategies. Basically it is “how to slice and dice a catalog.” What are the main ways to slice and dice? – obviously there are “way too many choices.”
When you walk into a Barnes & Noble, you know what you want. “That’s what we are going to do with our catalog.” Phoenix wanted format based navigation plus wanted to divide the catalog into content-based categories. Which fields to search – what would the search interface look like? They also wanted to incorporate relevancy. The final interface also integrated other library data with information on library programs (story hour, readers advisory, etc.) plus staff picks, most borrowed titles, and a TomatoMeter (boos and yeas)
Endeca does not come out of the box - It can be self-styled in a “relatively” short time. It is keyword based (as opposed to LC subject headings). Development was further refined to include authority files.
Phoenix was aware that the browsing function was going to be a challenge. Librarians “squawked” about using BISAC subject headings. Then one Phoenix librarian had a revelation. Book Industry Standards and Communications (BISAC) using Endeca for browsing was going to be a challenge. Used BISAC subject headings. “Its not about us, it’s about them” It’s people speak not catalog speak.
Please note that quotation marks are both the blogger's (Doris Madsen, Springfield City Library) and the presenters from Phoenix, AZ.