[Koha] Possible APP development

Fri Apr 18 08:09:46 NZST 2014

That loan period is a really good idea, Viktor- it's like Bookmobile loans but with carry-out!
If we could figure out a way to automatically set up this kind of alternative loan period based on the patron's address (e.g. longer loans for people living 20+ miles away), that'd be brilliant. Our staff already often make this type of exception to folks who live prohibitively far away, so it'd be better to have it as an actual policy and coded into Koha.
But I'm not sure I am comfortable with 'as long as you like'... maybe two/three x's the normal loan period or equal to the max renewal period. In my experience, no due date = lost under the sofa/pile of dirty laundry. ;o)

Tim Miller
Library Technician
College of the Redwoods Library
7351 Tompkins Hill Rd.
Eureka, CA 95501-9300
(707) 476-4256

-----Original Message-----
From: Koha [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of HOWES, Steve
Sent: Thursday, April 17, 2014 6:05 AM
To: 'koha at lists.katipo.co.nz'
Subject: Re: [Koha] Possible APP development

* Create new rules that guarantees a patron a certain loan period but allows them to keep the book for as long as they like as long as no reserves are made. Contact the patron when somebody places a hold on the title with a ”Others have requested the book, and you now have X days to return it”.

This functionality is something our senior management are interested in regardless of an app :-)

Best Wishes,
Steve

-----Original Message-----
From: Koha [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Viktor.Sarge at regionhalland.se
Sent: 17 April 2014 11:47
To: koha at lists.katipo.co.nz
Subject: Re: [Koha] Possible APP development

Great input Tim! An app that can’t talk to the server for ages do provide some challenges and I like how you work around them.

I’ll just throw some other ideas in the mix to make shure we look at the problem at hand from all perspectives:

Problem to solve: provide library service where there are no internet connection and/or phone.

Ideas:
* Automatically renew loans serverside when possible. Contact the patron through snailmail, e-mail or SMS when renewals are no longer possible and set a few days as grace period.
* Create new rules that guarantees a patron a certain loan period but allows them to keep the book for as long as they like as long as no reserves are made. Contact the patron when somebody places a hold on the title with a ”Others have requested the book, and you now have X days to return it”.
* Set up at phone based service with speech synthesis for those who have 2G connections or landline.
* Allow renewals after the book is already late (if it isn’t already possible. A quick peek in system preferences points at ”no”)

That said I have WiFi/3G/4G everywhere I go and I do love my apps :)

Kind regards/Viktor Sarge

Viktor Sarge
Utvecklingsledare
Regionbibliotek Halland
Kultur i Halland

TFN: 035-17 98 73
E-POST: Viktor.Sarge at regionhalland.se<mailto:Viktor.Sarge at regionhalland.se>
BESÖKSADRESS: Södra vägen 9, 30180 Halmstad
WEBB: www.regionhalland.se/regionbibliotek<http://www.regionhalland.se/regionbibliotek>

15 apr 2014 kl. 23:50 skrev Miller, Tim <Tim-Miller at Redwoods.edu<mailto:Tim-Miller at Redwoods.edu>>:

That's interesting, Susan- I have a different take on the usefulness of apps in areas with poor connectivity. Though I'm definitely not saying it won't work.

I'd argue that patchy internet access is the main issue to resolve when creating and promoting a native app that patrons will rely on to complete important transactions. I see very few problems with native app functionality in areas with adequate internet/cell service- most of the usability issues arise when service is poor. Perhaps the area where I live has worse access to internet and cell service than your community, but my library is also in a rural area and includes communities with no service at all (cell or internet). The infrastructure is limited.
However, many of our patrons simply cannot afford internet service at
home- even if it is available (the economy here is quite depressed).
Since a native app would still need to communicate with the library's ILS to complete any transactions (which requires connecting to the internet), there are some major problems that I see. Examples: if a patron renews in the app while offline, but the app can't communicate with the library's server; if a patron's app cannot be updated about a hold that has become available, they won't receive the push notification.

To the average patron, it is not clear how such apps work and how they need to connect to the ILS to ensure that the transaction is completed.
A patron may be able to renew an item in the app, but the app won't necessarily be able to communicate that renewal to the ILS. As the circulation coordinator, this is one of the major problems that I see.
Who is at fault? What is the library's accountability for an app that is misunderstood by the patrons?

This is not to say that native apps cannot be useful in areas where connectivity is spotty- but certain issues unique to such areas need to be considered. I should clarify that I'm certainly not arguing that a web-based app would work in these conditions (it clearly would not), but these confusions would not come up, either. Regardless, it is certainly possible to build a good native app to provide offline services to patrons, they simply require a few considerations not only in the design of the app itself but also in the policies and procedures of the library. For an area similar to where I live, I think that having a notification system using SMS would be best- it's easier for texts to get through in areas with spotty/slow cell service. Native apps can use SMS to send push notifications, but the patrons need to be made aware that they can be charged for those by their cell phone company.

My suggestions for creating an app with the intent to provide offline
services:
*Use SMS to send notifications (not necessarily all data needs to be updated with SMS, only the time-sensitive data) *Do not show items as renewed (don't update due dates) until the data has made it to the server- display due dates based on the ILS database, not based on local storage (pull the due date data from the ILS, don't use the data typed into the device).
*When renewals aren't completed immediately, use pop-up alerts to notify patrons that the item cannot be renewed until data is sent (when there is no current internet connection).
*Educate users on the importance of setting up the push notifications
appropriately- the device won't need to look for updates constantly and drain the battery (which can be magnified when the device is having a hard time finding a signal to begin with), but it will need to update at least daily (which will help ensure that hold notifications don't get missed).
*Educate users on the use of the app when disconnected from service for extended periods of time- use a pop-up alert to notify offline patrons that transactions made will not be completed until they connect (e.g.
patrons who live in a pocket with no service and will be home for days in a row cannot expect to receive notifications or complete transactions). Perhaps create a notification that tells the user when the app has not gotten an update in the last x number of hours) *Within the ILS, be sure to use a different set of criteria for data sent from an app- e.g. if a user renews an item at 11:58pm on their app and it doesn't update the server until 12:01am the next day, be sure to not allow that to generate overdue fines (use a timestamp to determine the time of renewal and apply it retroactively?).
*If using SMS to send notifications, be sure to allow the patron to determine what types of notifications they want/don't want to receive.
Be sure to notify them that they may be charged for such notifications.

Another tangential issue (which is fairly germane to this conversation) which enters my mind when developing new electronic services (and in this case, native apps specifically) is the creation of library services targeted at select brands of devices and operating systems. If the library creates iPhone and Android apps, is it in keeping with the library's mission to devote resources that will not be available to Windows, Blackberry and Symbian users? Does the library need to ensure that the same services are available across all apps? Will the limitations of one OS/device determine the limitations of the other OS/devices? Perhaps only certain types of services (renewals, holds) are important enough to be considered in this type of discussion. Perhaps your library decides these are non-issues. Perhaps user surveys demonstrate that Blackberry and Symbian users do not use library services (yet). But it's something to think about.

Good luck with the app! I look forward to seeing it.

Tim Miller
Library Technician
College of the Redwoods Library
7351 Tompkins Hill Rd.
Eureka, CA 95501-9300
(707) 476-4256

-----Original Message-----
From: Koha [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Sue McMillan
Sent: Monday, April 14, 2014 1:24 PM
To: koha at lists.katipo.co.nz<mailto:koha at lists.katipo.co.nz>
Subject: Re: [Koha] Possible APP development

Thanks for everyone's input. The different views are interesting.

I see one of the major advantages of having an app that uses push notifications is that here in NZ internet access for people outside of the major centres is patchy at best.  Connecting to a webpage over a cell phone network or even a landline is near impossible in rural areas as the connection is weak and/or drops out continuously.  High speed broadband is limited to major cities.  Towns outside of these areas have broadband but at very low speeds.  Some (un)lucky places still have dial up.

Most rural cell phone connections get enough signal send and receive texts but not phone calls, and definitely not enough to load a webpage.

Personally I would much rather have an app that sends me notifications alerting me to the need to renew books or that a held item is ready for collection than remember to login to a webpage.

Regards
Susan McMillan
Cataloguing and Systems Administrator| South Taranaki District Council
105-111 Albion St, Hawera 4610 | Private Bag 902, Hawera 4640, NZ
Phone: +64 6 278 0555 | Cell: | www.southtaranaki.com<http://www.southtaranaki.com>

This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorised and may be illegal. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
_______________________________________________
Koha mailing list  http://koha-community.org Koha at lists.katipo.co.nz<mailto:Koha at lists.katipo.co.nz>
http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________
Koha mailing list  http://koha-community.org Koha at lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

_______________________________________________
Koha mailing list  http://koha-community.org Koha at lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-
‘In the top 5 in the Green League Table; committed to sustainability’
This email is confidential to the intended recipient. If you have received it in error please notify the sender and delete it from your computer.
The University of Gloucestershire is a company limited by guarantee registered in England and Wales.  Registered number: 06023243.  Registered office: The Park, Cheltenham, GL50 2RH Please consider the environment before printing this email.
-
_______________________________________________
Koha mailing list  http://koha-community.org Koha at lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha