Kansas HB2719 post-hearing reflections

TL;DR :

  1. Legislative Update HB2719 from Kansas Library Association
  2. Storify of yesterday’s social media posts and news coverage [because, what do librarians do along with everything else that we provide to our communities through our services? We curate and repackage information for public consumption]

Personal reflections follow (and it gets lengthy…I captured these for my own thoughts and archive; if anyone else is interested, that’s great; if not, I completely understand if you don’t make it all the way through!).

Note: those foam fingers have been around for months. They were not created or designed for Monday’s advocacy efforts. 

Continue reading “Kansas HB2719 post-hearing reflections”

Mobile Strategies Best Practices

Tony Medrano, President & Megan Vizzini, VP of Sales, Boopsie

People Spend Most Time on Mobile Devices: 2010, 1/2 hr/day, 2015, 2.8 hrs/day

90% of users’ mobile device time spent “in apps”: native apps vs mobile websites.

  • Using whatever works better on the situation at hand.
  • Apps can be configured to meet needs; website harder.
  • Apps are targeted toward specific purpose (quick)

Are apps a trend, monthly usage? — large growth Continue reading “Mobile Strategies Best Practices”

Let’s Make a Game Out of It: Building Connections, Constructing Community, Thinking Strategically

Lauren Hays, @Lib_Lauren, Instructional and Research Librarian, Mid-America Nazarene University

Mark Hayse, PhD, Director, Honors Program, Mid-America Nazarene University

Center for Games & Learning” at Mid-America Nazarene University

Faculty and Librarian Collaboration, Relationships

IMLS Sparks Ignite Grant

Continue reading “Let’s Make a Game Out of It: Building Connections, Constructing Community, Thinking Strategically”

LibKi Integration

Kyle Hall, ByWater Solutions

LibKi website

Kyle tried many, many different options that were available at the time his library (Meadville) was looking for a time management software package, and eventually developed his own, to meet his library’s needs — LibKi.

Staff interface, now shows live data (didn’t in the past). Simple interface (users; clients)

Koha works very well with LibKi. Version 2, now has support for SIP.

Does the client lock down the patron computer — can’t be bypassed? Kyle says yes. Auto-hot-key used for restrictions.

Can customize the banners on the client screen, with images and/or custom HTML.

Persistent user creation (if you don’t use SIP)

Guest pass creation

Goal: Librarian shouldn’t have to interact with system — self-sustaining.

Settings — pretty simple: default time allowance/day; default time allowance per session; client registration update delay limit — if computer is down/network issues, etc.

Client Behavior option — First come, first serve; reservations only; or combo of these two.

Automatic time extension: length; when to kick it in; exception to extensions.

Third party integration (like with Koha, to create a link to a patron in Koha).

Closing hours (not complete yet): 

Bare-bones statistics module; daily usage counts, date range, who logged on and when; can implement cron job to delete user history.

When using the client, gives time left messages, every five minutes.

Age limits now available, using Koha date of birth field. {Wonder if this could be extended to having a flag on if person has signed patron Internet use policy agreement}

Software gives options for what happens after patron logs off/time runs out: nothing; restart computer (DeepFreeze); log out of account (Cleansweep); works with Linux client, too.

Will there ever be a print feature, integration? Kyle would like this to happen, but it doesn’t have that right now.

Open Source at Meadville Public Library

John Brice, Meadville Public Library Director

Meadvillelibrary.org/os
–33 separate FOSS (free and open source software) packages being used
–1000 sq miles
–175 plus clients
–3.5 FTE IT dept

Instead of spending money in packaged software license, we use FOSS and invest the savings in staff training and higher quality equipment.

Participation Strategy: we want to be a big fish in a small pond

  • we have limited resources
  • Every FOSS project deserves support
  • Active involvement is in two projects: Koha & LibKi

Development of MPL FOSS guidelines

  • We have small budgets: select FOSS if available (it’s cheap); host the software ourselves (reduces costs)
  • Test drive everything first through a proof concept (old hardware first)
  • DIY Library (we like to tinker) — build own furniture, lay own carpet, renovate building themselves
  • Leverage our knowledge of FOSS

Selection of OSS criteria

  • Technical details: programming language; packages used; what license does it use?
  • What is the community like? Single developer in mom’s basement vs Multiple developers for the Fortune 500

Passive Participation in FOSS

  • Do nothing (or small, donations)
  • Contribute to the project along prescribed guidelines

Active participation

  • develop documentation
  • answer support questions
  • sign off on quality assurance
  • submit bug fixes
  • finding bugs and reporting them
  • participate in development
  • participate in community discussions
  • submit new features

Active Participation — Financial

  • Attend community meetings/hackfests (travel around the world!)
  • Hire a developer/company to add a feature

FOSS Community members

  • lead programmer
  • independent developers
  • library developers
  • hosting companies
  • library management types
  • librarians

Community influence

  • influence in FOSS community is based on participation and supported development
  • You do not have to do both
  • The more you work with a FOSS community the more the community will listen to your needs

Active participation staff requirements

  • a good communicator
  • or good writer
  • or good administrator
  • or good IT support person
  • or good programmer

All can contribute to a FOSS community — all types are needed. You don’t have to be technical and know code to participate in the community.

Where to implement FOSS in a library?

  • Hire a host company
  • Support the software yourself <– Meadville’s approach
  • Self support and hire a company

MPL FOSS Development routine

  • Proof of concept — IT Plays
  • Alpha version — IT modifies/demos/approvals
  • Purchase hardware — best available and overspec, because not also paying for licenses and software. Investment goes into redundancy and specs. Pays off in liability down the road
  • Beta version — installed software/staff tests
  • production — go live with use
  • Debugging

Own FOSS customized version of Koha (starting 2007)

  • needed features: fines; clubs and services; rotating collection; different page layouts

Custom software disadvantages

Difficult to upgrade (missed the rest of his points)

Now, community Koha version for last three years, easier to manage

Expect the unexpected

  • no matter how much you test production setting can produce unexpected results
  • Need feedback system for staff (Mantis)
  • Need support of management when things go wrong

Support issues

Many channels of support available

  • Start with the idea: you’re probably not first one with the problem; search available FAQs/past questions
  • Community channels — usually responsive for help

Courage is being scared to death but saddling up anyway. –John Wayne — Meadville’s mantra

Library isn’t using the proven method that is taught in library school. But from John’s experience it is possible to do it, possible to succeed, and is possible to do it yourself, and have the courage to do it yourself.

Your mileage may vary

  • No hard and fast rules
  • Be flexible
  • Being stubborn also helps :)