Hi Sue, I like your ideas and think you have pin-pointed some good functionality and features that are useful and desirable to the typical library user. However, I'd encourage you to design a great mobile OPAC rather than a native app. Koha's mobile layout has already done a lot of the work for you (and my library isn't on 3.14 yet, but it sounds like the Bootstrap OPAC theme is even better). Requiring folks to download a native app often seems like a novel approach, but in many respects it is unnecessary and can be a stumbling block for users. A native app takes up space on the device, requires learning a new interface (and learning how to download an app- which isn't an easy task for every user), and app updates require user authorization. A web-based app (mobile-optimized OPAC) can offer the same functionality and provide access to the catalog without requiring new downloads or learning a new interface (when constructed well). In fact, a good web site's mobile and desktop layouts will be similar enough so that the user has very little to learn. You can figure out how to store the user's password (HTML5 localStorage?)- or even offer a video/web tutorial to teach your users about how to store passwords in browsers. This would teach users a skill that will be useful in many applications (and teach to online security, to boot). Any features already in the OPAC are available to the mobile user, so your work is almost done. Web apps can also be used across devices and operating systems- a good website already works on any device. Even the absolute best native apps require different programs for each OS and often for different devices/OS versions (e.g. a need for separate iPhone and iPad apps). The workload to develop a set of native apps (to avoid ignoring a segment of your user base) is far bigger than for developing a great web app. The most time-consuming aspect of creating a web app is in making the interface user-friendly. Since this is the most important part of developing an app (no one wants to use an unusable app!), that is a great place to put your efforts and resources- and you'll end up with a great product. Almost all of your bullet points are already available in the OPAC and those that aren't should be in the desktop website as well, anyway. All of those should be developments in Koha. One aspect that a native app can offer which a web-based app cannot is offline work. However, that would be incredibly messy with users trying to renew items and cancel holds. What if the app didn't update the ILS in time to avoid fines? Is that the fault of the library or patron? In many ways, creating an app that allows time-sensitive functions while offline is not optimal from a customer service point of view. This is, of course, all my humble opinion, but there are many great arguments about choosing which way to go- http://mashable.com/2012/09/12/web-vs-native-apps/ http://www.wired.com/2012/11/native-apps-vs-mobile-web/ http://uxmag.com/articles/native-or-web-based-selecting-the-right-approa ch-for-your-mobile-app And I'd be very interested in helping with developing a mobile web app that meets your goals! I've already worked with optimizing our library's mobile OPAC (http://sometimesmotion.wordpress.com) and am chomping at the bit to work on the Bootstrap theme :) 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@lists.katipo.co.nz] On Behalf Of Sue McMillan Sent: Wednesday, April 09, 2014 1:21 PM To: koha@lists.katipo.co.nz Subject: [Koha] Possible APP development Hello everyone, After a brainstorming session this morning I have come up with the idea of an Apple and Android app that give users the ability to manage their Koha account without signing in the library catalogue. Not knowing the limitations of apps (so I may be asking for too much!) these are the features that I feel patrons would find useful in a Koha app. There may be other crucial tasks that I haven't listed below that other libraries or patrons would find useful. 1. The app keeps the patron signed in (probably by entering their Library card number and password into the app) 2. Lists all resources currently issued to their card (or maybe the ones due in the next x number of days?) 3. Alerts patrons to resources that are coming up overdue. 4. Gives the patron the ability to renew books from the app, with a single swipe or click 5. Alerts the patron to Holds that come available for pickup 6. Gives the patron the ability to delete the hold with a single swipe or click and at the same time alerts the library via an email or something that the book is no longer needed. 7. Gives the patron the ability to contact the library via the app. 8. Gives the patron he ability to review a resource and leave a star rating (if this is enabled in the catalogue). 9. And the nice to have would be the ability to have something like amazon recommendations "Patrons who read this book also read.....) I would imagine patrons would want the ability to download the app for free from the Google play or iTunes store. Is there any library interested in such a development and a developer with the skills to undertake the project? Or possibly someone is already working on this. 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 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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Miller, Tim schreef op wo 09-04-2014 om 16:15 [-0700]:
One aspect that a native app can offer which a web-based app cannot is offline work.
One other thing that native apps can do that would be of use to library users is push notifications. I.e. your phone tells you when things are nearly overdue, reserves are waiting for you, the thing you suggested has shown up, and so on. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
My two cents: If I understand the state of things correctly offline web apps in HTML5 is already possible. Push notifications over the web isn't there yet even if OS X has it and I hope that it becomes more common. I think that the advantage of using push notifications instead of e-mail/SMS isn't big enough to motivate using the resources neded to create and maintain tablet and phone apps for Android, iOS and possible Windows devices. I do however understand if someone wants to code those apps because it's fun :) Worth investigating might also be gateway apps that receives push-notifications for you without the need for installing a native app. I cannot vouch for https://pushover.net/ but a quick search turned it up and the idea seems to be sound. Kind regards/Viktor -----Ursprungligt meddelande----- Från: Koha [mailto:koha-bounces@lists.katipo.co.nz] För Robin Sheat Skickat: den 10 april 2014 02:12 Till: koha@lists.katipo.co.nz Ämne: Re: [Koha] Possible APP development Miller, Tim schreef op wo 09-04-2014 om 16:15 [-0700]:
One aspect that a native app can offer which a web-based app cannot is offline work.
One other thing that native apps can do that would be of use to library users is push notifications. I.e. your phone tells you when things are nearly overdue, reserves are waiting for you, the thing you suggested has shown up, and so on. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
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 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.
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@lists.katipo.co.nz] On Behalf Of Sue McMillan Sent: Monday, April 14, 2014 1:24 PM To: koha@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 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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
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@regionhalland.se<mailto:Viktor.Sarge@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@Redwoods.edu<mailto:Tim-Miller@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@lists.katipo.co.nz] On Behalf Of Sue McMillan Sent: Monday, April 14, 2014 1:24 PM To: koha@lists.katipo.co.nz<mailto:koha@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@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
* 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@lists.katipo.co.nz] On Behalf Of Viktor.Sarge@regionhalland.se Sent: 17 April 2014 11:47 To: koha@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@regionhalland.se<mailto:Viktor.Sarge@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@Redwoods.edu<mailto:Tim-Miller@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@lists.katipo.co.nz] On Behalf Of Sue McMillan Sent: Monday, April 14, 2014 1:24 PM To: koha@lists.katipo.co.nz<mailto:koha@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@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@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. -
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@lists.katipo.co.nz] On Behalf Of HOWES, Steve Sent: Thursday, April 17, 2014 6:05 AM To: 'koha@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@lists.katipo.co.nz] On Behalf Of Viktor.Sarge@regionhalland.se Sent: 17 April 2014 11:47 To: koha@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@regionhalland.se<mailto:Viktor.Sarge@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@Redwoods.edu<mailto:Tim-Miller@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@lists.katipo.co.nz] On Behalf Of Sue McMillan Sent: Monday, April 14, 2014 1:24 PM To: koha@lists.katipo.co.nz<mailto:koha@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@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
I've worked at a few educational libraries that run term-length loans - the reader can keep it til the end of the term unless someone else requests it. Also, my current library defaults to a 90 day loan on the same principle, precisely because our members are rather far flung. I wouldn't go longer than that, people tend to misplace books they have on long term loan, and then think they've returned them. It might be useful to send out a monthly reminder - "you have the following items on loan, and here are their due dates. . . " On Thu, Apr 17, 2014 at 9:09 PM, Miller, Tim <Tim-Miller@redwoods.edu>wrote:
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@lists.katipo.co.nz] On Behalf Of HOWES, Steve Sent: Thursday, April 17, 2014 6:05 AM To: 'koha@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@lists.katipo.co.nz] On Behalf Of Viktor.Sarge@regionhalland.se Sent: 17 April 2014 11:47 To: koha@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@regionhalland.se<mailto:Viktor.Sarge@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@Redwoods.edu<mailto: Tim-Miller@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@lists.katipo.co.nz] On Behalf Of Sue McMillan Sent: Monday, April 14, 2014 1:24 PM To: koha@lists.katipo.co.nz<mailto:koha@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@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> http://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Elaine Bradtke Data Wrangler VWML English Folk Dance and Song Society | http://www.efdss.org Cecil Sharp House, 2 Regent's Park Road, London NW1 7AY Tel +44 (0) 20 7485 2206 (This number is for the English Folk Dance and Song Society in London, England. If you wish to phone me personally, send an e-mail first. I work off site) -------------------------------------------------------------------------- Registered Company No. 297142 Charity Registered in England and Wales No. 305999 --------------------------------------------------------------------------- "Writing about music is like dancing about architecture" --Elvis Costello (Musician magazine No. 60 (October 1983), p. 52)
Viktor Sarge wrote:
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”.
Our library also wants extended loans, that stop when a hold is placed. Not unlimited though, only up to a maximum loan period. We figured automatic renewals would do the job. I'll start writing a patch for an automatic renewal feature very soon: http://wiki.koha-community.org/wiki/Automatic_renewal_RFC Regards Holger
Hi all. Great to hear Holger! One thing I like about automatic renewals is that you can hook a cronjob into the existing rules and don’t have add any complexity to the circulation rules in the staff interface. I took a quick peek at the RFC and what I have to add is that you might want to ”allow/disallow” that the _patrons_ turn automatic renewals on/off in the opac. I think it in many cases would be more useful to let those that actually need/want the feature use it rather than all issues. At least that’s my view after pondering Tim and Elaines point about people misplacing books :) Another thing to add to the wishlist could be a message to send when an automatic renewal is made (defined in letter.pl). Something like ”Hi! The loan ’Learning Perl’ that was due today was automatically renewed and is now due date X. Kind regards/The Library” could help people remeber to keep track of their loans. I do like Tims idea about using automatic renewals for people with certain zipcodes, but I think it might be better to use it like ”Use rule X with all patrons meeting this criteria”. This could be useful for all sorts of granular permissions but seems (to me) like a quite big RFC in it’s own right. And it would create all sorts of interesting problems. Kind regards/Viktor Viktor Sarge Utvecklingsledare Regionbibliotek Halland Kultur i Halland TFN: 035-17 98 73 E-POST: Viktor.Sarge@regionhalland.se<mailto:Viktor.Sarge@regionhalland.se> BESÖKSADRESS: Södra vägen 9, 30180 Halmstad WEBB: www.regionhalland.se/regionbibliotek<http://www.regionhalland.se/regionbibliotek> 22 apr 2014 kl. 15:15 skrev Holger Meissner <Holger.Meissner@hs-gesundheit.de<mailto:Holger.Meissner@hs-gesundheit.de>>: Viktor Sarge wrote: 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”. Our library also wants extended loans, that stop when a hold is placed. Not unlimited though, only up to a maximum loan period. We figured automatic renewals would do the job. I'll start writing a patch for an automatic renewal feature very soon: http://wiki.koha-community.org/wiki/Automatic_renewal_RFC Regards Holger _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Thanks for your input, Viktor! I updated the RFC to include your suggestion. It's an interesting idea to let the patrons decide whether renewal should be automatic or not. I hadn't thought about that, but it makes sense, when they are also allowed to renew their loans. Regards Holger -----Ursprüngliche Nachricht----- Von: Koha [mailto:koha-bounces@lists.katipo.co.nz] Im Auftrag von Viktor.Sarge@regionhalland.se Gesendet: Dienstag, 22. April 2014 18:08 An: Koha@lists.katipo.co.nz Betreff: Re: [Koha] Possible APP development Hi all. Great to hear Holger! One thing I like about automatic renewals is that you can hook a cronjob into the existing rules and don't have add any complexity to the circulation rules in the staff interface. I took a quick peek at the RFC and what I have to add is that you might want to "allow/disallow" that the _patrons_ turn automatic renewals on/off in the opac. I think it in many cases would be more useful to let those that actually need/want the feature use it rather than all issues. At least that's my view after pondering Tim and Elaines point about people misplacing books :) Another thing to add to the wishlist could be a message to send when an automatic renewal is made (defined in letter.pl). Something like "Hi! The loan 'Learning Perl' that was due today was automatically renewed and is now due date X. Kind regards/The Library" could help people remeber to keep track of their loans. I do like Tims idea about using automatic renewals for people with certain zipcodes, but I think it might be better to use it like "Use rule X with all patrons meeting this criteria". This could be useful for all sorts of granular permissions but seems (to me) like a quite big RFC in it's own right. And it would create all sorts of interesting problems. Kind regards/Viktor Viktor Sarge Utvecklingsledare Regionbibliotek Halland Kultur i Halland TFN: 035-17 98 73 E-POST: Viktor.Sarge@regionhalland.se<mailto:Viktor.Sarge@regionhalland.se> BESÖKSADRESS: Södra vägen 9, 30180 Halmstad WEBB: www.regionhalland.se/regionbibliotek<http://www.regionhalland.se/regionbibliotek>
participants (7)
-
Elaine Bradtke -
Holger Meissner -
HOWES, Steve -
Miller, Tim -
Robin Sheat -
Sue McMillan -
Viktor.Sarge＠regionhalland.se