Tag: nakug15

Coverflow in the OPAC: Making your catalog more dynamic

Chris Brannon, IT Coordinator, Couer D’Alene Public Library

His slides will be on the wiki

CIN’s catalog

Kyle’s coverflow instructions [back-end setup need in webserver, Apache]

4 coverflow widgets, based on reports for new Adult materials, new childrens materials, recently checked out materials, recently returned materials reports

Hasn’t seen many performance issues with this set up; report doesn’t reload/rerun unless you refresh your page; doesn’t have many people landing on catalog homepage — could be an issue if you have lots of computers that land on the catalog homepage

Dynamic content for the catalog

  • install the coverlow plugin (may need assistance from support vendor)
  • Configure the plugin in the Tool Plugins
  • Place your elements somewhere in the catalog page 
    • <span id='coverlow'>=Loading </span>

Instructions walk you through the necessary steps; to

4 coverflows set up with unique span id and unique report id

will be also sharing the SQL on the reports used to build the coverflows — reports need to be public in order for this to work.

Plugin does the heavy lifting for CoverFlow — javscript code, etc., more, built through plugin, and is added to your opacuserjs sys pref. Can tweak/manipulate the js code then.

One tweak: added canned searches link to the new items cover flows to find more materials.

Some reports are load slower than others.

Suggestions for improvement

  • Reports that are run once a day or on a schedule, and the results stored where Coverflow can utilize those results, resulting in faster loading <– should be be available in a future version of Koha, thanks to Bug #13578
  • Working on applying the results in Digital Displays around the library that can be automatically rotated thru.

Could you pull the data from a list? Write a report that pulls data from a static list

Patron Import and LDAP Authentication

Steve Weber, Systems Admin, Mercyhurst University

What is LDAP? Lightweight Directory Access Protocol – Software protocol that allows an application to authenticate a database of users or resources (LDAP, port 389; LDAPS, port 636)

Simplified — using your work username to log into Koha

4 requirements for LDAP

  • Network communication
  • An application (Koha’s config file)
  • A binding user (the bridge)
  • A Database of Authenticating Using (Active Directory)

Network communication

  • network ports open:
    • server firewall
    • network firewall
  • 3rd party Koha providers should be secured by IP address

Koha’s LDAP config file

  • A Koha file that supplies the mappings to fields/info in Active Directory
  • Located: /etc/koha/koha-conf-site.xml.in

The binding user (bridge)

  • The user in Active Directory that is authenticated against Koha in order to securely allow Koha to search Active Directory for users, allowing logins to be successful

Active Directory

  • A group of users that are able to log into Koha using their current usernames and passwords
    • No need for duplicate users
    • Search DN (limit which users can access Koha)

Patron import tool — add/update patrons

  • used to add and update user information
  • Tools > Patrons and Circulation > Import Patrons
  • Format of .csv

CSV File formatting for import, very specific — documentation in the Koha community in the manual for the data needed. Couple of requirements for matching: cardnumber

Record matching

  • branchcode and {patron} categorycode
  • date format must match sys pref
  • replace/overwrite option important;

Custom attributes

  • csv header must by titled by “patron_attributes”
  • Attribute is listed with CODE, followed by a colon and then the value
  • Separate attributes with a comma [Ex. CLASS:Senior, GRAD: 2015]

This and that

  • Excel and leading 0s — import, not directly open files!
  • Staff accounts — exclude users with special permissions
  • Expired — account cleanup — ByWater deletes

Question raised about multiple LDAP server configuration for a consortia. Has anyone done that? Config file speaker has seen, only lists one config file. Not sure if that’s possible or not.

Which patron attribute is being sent to LDAP for authentication? cardnumber in Mercyhurst’s configuration.

LDAP information on ByWater Solutions blog

Transport Cost Matrix

Christopher Brannon, IT Coordinator, Couer D’Alene Library (ID); also works with the CIN network, that his library is a part of (27 libraries)

Transport Cost Matrix has really helped his consortia. (600,00 items; 135,000 patrons); Couer D’Alene Library (88,000 items; 34,000 patrons; 3600 holds in July; 2500 items that his library borrowed from other libraries; loaned 2600 items to other libraries in the consortia). A lot of materials moving around.

Two other libraries in the room using the transport cost matrix.

How Koha fills hold requests:

  • first, check check for items locally
  • sys pref, StaticHoldsQueueWeight —
    • if left at default (0), will go thru branches alphabetically (will not randomize);
    • If branches are specified, it will only use branches specified; branches listed can be checked in the order listed or randomized
  • PROS – easy to use
  • CONS – many factors can delay transport; may not be the most efficient in cost and speed, may overwhelm some libraries
  • Other option, use Transport Cost Matrix – must set the UseTransportCostMatrix sys pref

Matrix setup

  • Sources (From), left-hand side
  • Destinations (To), horizontal across
  • Rank the Sources (From down the column)

At first, did ranking based on mileage alone. Worked at first.

Factors to consider for cost

  • Miles/distance
  • The same post office/courier
    • going thru more handlers could cause delays
    • going thru more couriers could increase costs
  • Frequency of routes
    • some libraries may be open only a few days a week, or have less pickup/delivery times

To create his rankings, recreated the matrix in Excel. First sheet is mileage, from library A to B; also includes Zones and Frequencies. Outlying libraries depend on secondary courier (Zones 1 (main courier), 2, 3, 4, 5, 6); a few libraries act as hubs, too, for some of the outlying zones. Frequency also a factor; only 4 libraries are only 5 times a week; several are 1 time a week, a few are three times a week.

  1. First sheet: Library data, mileage, zones, and frequency
  2. Zone Calculator – Formula details
    • If the cell is blank, keep it blank; if libraries are in the same zone, don’t change the value; if either zone is zone 1 (but not both), add 10000 to the value
    • Otherwise, add 20000 to the value (neither are in the primary courier, and not in the same zone)
  3. Frequency Calculator
    • If the cell is blank, keep it blank
    • The libraries with the highest frequency (5) don’t change; all others, 4 adds 1000; 3 adds 2000; 2 adds 3000; and 1 adds 4000; (the less frequent the pickup, the more it is dinged)
  4. Rank the values for the simpler input — Excel feature
    • If the cell is blank, keep it blank
    • Rank that cell against the rest of the cells in that column in single steps (simple numbers)
  5. Final rankings to put into Koha:

Slides and Calculator will be on the Wiki.

Smaller libraries aren’t getting hammered as much under this model. It’s been a more efficient method. Has worked well for his consortia. Important piece of puzzle.

Randomization doesn’t take into account closed libraries. Just mileage alone, is a good first step. Library took it a step further.

Question about StaticHoldsQueueWeight sys pref and how that’s set up: branchcodes entered and choose either in random order or specific order, for holds to be pulled.

Question, If you use the transport cost matrix, how can exclude libraries from being a source? Disabling doesn’t seem to work. For school library, added default policy of no holds allowed for the summer.

Question, do you have stats on hold this change affected holds? Not at this time. Based decision on how libraries were getting hammered in holds queues.

Accounts Development Update

Kyle Hall, Development Support Specialist, ByWater Solutions

Rewrite of accounts management. Payments and fees now in separate tables; a third table tracks the interaction between the two. Can’t tell in current Koha what payment affected a given fee.

A lot more data now available and displayed; print receipt for individual fee or payment. Payments can be viewed separately; fees can be viewed separately. Description now links to the item data, not just barcode and title.

By default, can hide fees and payments that have no balance.

Can now see each and every fee paid.

OPAC view is similar, so patrons will also be able to see their fees and payment history — very similar to staff side view.

Development is still under progress.

Write now, credits sit there forever, fees and credits added together to give a balance. Now, credits automatically pay off fines and fees until outstanding balance reaches zero. Tracks what fees were paid with that credit.

Biggest thing from doing this development? Kyle admits he made a huge mistake. Much better to do small, incremental changes in the community, rather than a big, huge change.

It’s gone to the signed off stage, and no one has dived into QA’ing yet. May need to redo the entire development and do it piece by piece until it resembles the development where it stands today.

Testing a large change at once, takes time. Fear you can miss something. Double-QA suggested for this. No one in QA has stepped up to do this. Different approaches to QA, based on background: Developer QA will look at code in patch and suggest code rewrites; most systems librarians are just trying to break the feature. But at the end, the QA process has same end goal: try to make sure feature/patch works and that it doesn’t break anything else in Koha.

Part of this process is that Koha is constantly changing as things are developed — coding changes, new features added simultaneously, etc., so your code/patch may need to be redone to reflect those changes.

Koha is a gift with expectations. 

Questions about QA process, too stringent? Discussion around how Koha used to be before stringent QA process put into place — wild west. Pretty stable now; developments may take longer to get in, but system is more stable, as a result.

Koha works in many different ways, for many different libraries, don’t trample over all types of libraries workflows.

Suggestion made, could part of a development contract, include paying for for someone’s QA time? Hot issue, you don’t want to necessarily pay someone for a rubber stamp; Horowhenua Koha community foundation hiring for community QA and signoffs.

Kyle is working on larger developments now, breaking it down into pieces, his biggest lesson learned from the accounts rewrite.

Will he truly start over? Not sure yet; if he does take it apart and start over, algorithms can be reused, his knowledge on how this feature all works. May piece out into individual bugs. Can’t easily and quickly take what he’s done immediately into pieces, but won’t take nearly as long to write.

The cataloging module feature, doesn’t touch most of Koha. Almost completely independent. It’s huge, but isn’t affecting most of existing Koha, like the fines module does.

 

Talk from Ed Veal on Open Source Community

Ed Veal, ByWater Solutions

Switching from Proprietary software to Open Source Software

Differences

  • Administrative
  • Mind set
  • Development
  • Resources

Front line staff don’t care as much about the switch; still have to learn new system. Get support from the same sources on staff.

Biggest difference? The community behind a a piece of open source software. Bug reported; community fixes; community pushes new releases. Things get developed because members of the community want things to be developed, funded, etc. The community drives, instead of the business plan; there is no business plan behind Koha. Proprietary focus on what business can sell.

Koha — open source — together because of community.

Question – if a lot of IT staff are Windows/proprietary supporters, and the staff who supports open source leave an organization and things go wrong, how do you keep open source packages in place? 

Need a plan to put together those transitions.

Concern of someone about to move to Koha: current cost for library is only Sirsi hosting [but LOTS of money goes to that]; will it require more staff time and talented staff? 1) If you go your own way, you can self-host — have to have knowledge, resources. 2) Can choose support company vendor to support, hosting, do migration. There are ways around this more easily.

Another library moving from III to Koha, biggest issue, cultural shift from proprietary to open source, switch in nomenclature — really an ILS issue, not open source. The cultural change is in administration; by using an open source product, especially one like Koha that is so community-focused, that’s where the transition will have to happen. Koha grows as you, the community, wants it to go.

Community to rely on for answers to questions. IRC channel; listservs; bugzilla.

Frontline staff at a library on Koha for awhile, they now ask if things can be done differently. They raise issues and make suggestions.

No matter what change/development you make to a system, someone has to sit behind a keyboard and write the code. Whoever is writing the code, developers whether they be in-house for a self-hosted library or through your support company, there are costs in doing that. That’s where the development costs come from. There is a shift from paying from software licensing to helping make the software better.

A lot of people are paying for the flashy, big developments but there are behind the scenes developments that are also needed.

Development process in Koha: someone finds a bug, wants an enhancement, report is placed on the community Bugzilla site. A developer (someone who writes code) writes a patch. Once that’s written, it’s added to Bugzilla. Community starts testing, it’s signed off on. Then it goes off to the Quality Assurance (QA) folks, who do a second layer of testing. Then the Release Manager (RM) checks it again, and decides if it’s going into master/next release. Everyone in the Koha community is volunteering to test.

One good way to give back to the community? Start testing patches in Bugzilla. The nos are more important than the yeses. Anyone can sign off on a patch; QA folks are checking other parts of Koha as well, to make sure it didn’t break anything; RM is checking to see if patch works; checking to make sure it doesn’t break Koha in other places and meticulously checks the code.

Need more Americans on Signoffs/QA team, especially QA team. Can volunteer to be on QA team. Say, “I would like to help.” And people want to help you!