Thank you all for working on this! Front line staff will really appreciate it.
Diane Disbro Pronouns: she/her Circulation Coordinator Scenic Regional Library 251 Union Plaza Drive Union, MO 63084 (636) 583-0652 ext 110 [email protected] On Mon, Mar 14, 2022 at 12:17 PM Morgan, Michele via Evergreen-general < [email protected]> wrote: > Since it's Pi Day, I'm just tossing out a pie in the sky idea about this. > > It would be great if offline circulation could be seamless, or nearly so. > Many selfcheck kiosks have this feature. They continue to record > transactions when the ILS goes offline, and automatically send them when > connectivity restores. > > I can't offer any suggestions as to how to accomplish this, but it would > be awesome! > > But given Bill's original question, there are merits to an installed > application, a few that come to mind are: > > - Better control over where it's installed. > - The ability to install it when a workstation is offline. > - Easier to train staff since it can be invoked at any time. > > Still hoping for Pi in the sky, though. > > Michele > > -- > Michele M. Morgan, Technical Support Analyst > North of Boston Library Exchange, Danvers Massachusetts > [email protected] > > > > On Mon, Mar 14, 2022 at 1:04 PM Bill Erickson via Evergreen-general < > [email protected]> wrote: > >> Thanks for all the input, everyone. >> >> JFYI, I chose JavaFX for my experiments because: >> >> 1. Hatch uses it, duh, specifically for HTML rendering of print content. >> 2. It's cross-platform >> 3. JavaFX has its own markup language (FXML), which comes with a handy >> "scene builder" for quickly creating/editing UI's. >> 4. Companies outside of Oracle, like Microsoft [1] and Amazon [2], are >> now creating open source builds of OpenJDK. >> >> I'm open to other technologies, though. >> >> [1] https://docs.microsoft.com/en-us/java/openjdk/download >> [2] https://aws.amazon.com/corretto/ >> >> -b >> >> >> On Mon, Mar 14, 2022 at 12:18 PM Jason Boyer via Evergreen-general < >> [email protected]> wrote: >> >>> I do like the idea of an installed application. If there is any issue >>> getting the offline webapp to work staff generally use Excel or Notepad >>> anyway, so something purpose built would be a big step up from that. These >>> (tried and true, long-term battle tested, heh) alternatives show that a >>> dedicated offline utility wouldn’t be required to use Evergreen, just a >>> major UI / UX improvement over some of the alternatives. >>> >>> The main issue with the existing offline interface is that if anything >>> answers on port 80 at all you can’t get into it. So if you have an >>> ldirectord fallback (for a maintenance page, for instance) the only way to >>> get into offline is basically to unplug the cable from the staff machine >>> and try again. The background download of block lists and other assorted >>> settings is also a great idea. Saving things to a system-wide location >>> (like %APPDATA% on Windows) will also prevent libraries with per-user OS >>> accounts from accidentally finding and uploading old transactions long >>> after they were saved. >>> >>> Making it safer for staff to wipe out their Chrome history is also a >>> good benefit. (Hopefully they don’t often need to anyway, but making it >>> impossible to lose pending circs this way is an unqualified improvement.) >>> >>> Searching around a bit for other systems shows a variety of options: >>> Alma, Atriuum, and Sierra use a locally installed utility. >>> Aleph, and Symphony still use locally installed clients that also handle >>> offline circ. >>> FOLIO doesn’t handle it. >>> Polaris has a browser offline client. >>> >>> Koha can use a browser offline client, FF plugin, or locally installed >>> utility. I haven’t done a deep dive, but I’ve been given the impression >>> from some email list postings that the local util is generally preferred. I >>> don’t know the current status of the plugin, but requiring a specific >>> browser definitely limits its appeal. >>> >>> As for specific technologies, I’m like Jeff; we don’t want another Dojo >>> situation, but am otherwise fairly open. I haven’t messed with Java much >>> since college but if we want something that’s cross platform that’s pretty >>> much the choice. I’m not familiar enough with JavaFX to know what additions >>> the FX brings and so don’t have an opinion on that yet. >>> >>> Jason >>> >>> -- >>> Jason Boyer >>> Senior System Administrator >>> Equinox Open Library Initiative >>> [email protected] >>> +1 (877) Open-ILS (673-6457) >>> https://equinoxOLI.org/ >>> >>> On Mar 11, 2022, at 12:23 PM, Jeff Davis via Evergreen-general < >>> [email protected]> wrote: >>> >>> My other concern about a standalone app would be picking a tool that >>> won't become obsolete in a few years (XUL, old Dojo) and doesn't require a >>> ton of work to stay up-to-date (Angular). I have no opinion on JavaFX >>> specifically, but we are already using Java for Hatch, so maybe there is >>> precedent? >>> >>> I personally like the idea of a standalone app if it's easy to manage >>> and use. I think our staff have found the current offline UI to be >>> unintuitive and kind of finicky. >>> >>> Does anyone know offhand how other ILS products deal with offline? >>> >>> Jeff >>> >>> >>> On 3/11/22 7:46 AM, Terran McCanna via Evergreen-general wrote: >>> >>> My initial thoughts on a separate app: >>> Advantages: >>> - A lot of staff tend to be confused by the concept of an offline web >>> app and find it easier to understand an installed program. >>> - It would get around the need to load pages into cache before using it >>> for the first time, which staff don't usually understand. >>> - It could potentially be installed from a flash drive to a computer >>> that is not connected to the internet. >>> Disadvantages: >>> - Staff would need to install it and do upgrades on every machine. >>> - It would be more difficult to locally customize and it would create a >>> separate product for the developers to maintain. >>> Questions: >>> - How would it handle the workstation name? Would staff need to set it >>> up at first use? (Note that it would be useful for it to have a workstation >>> name that indicated that the offline app was used for each transaction so >>> we could identify offline transactions in reports/logs.) >>> - Would the staff client still be able to tell if there were pending >>> offline transactions to upload? (Note that it would be nice to see this >>> alert once logged into the staff client as well as on the login page.) >>> - Would this resolve the problem of not being able to download large >>> patron block lists? (PINES hasn't been able to download block lists at all >>> since moving to the web client.) >>> >>> Terran McCanna, PINES Program Manager >>> ------------------------------------------------------------------------ >>> Georgia Public Library Service | University System of Georgia >>> 2872 Woodcock Blvd, Suite 250 l Atlanta, GA 30341 >>> (404) 235-7138| [email protected] < >>> mailto:[email protected] <[email protected]>> >>> http://help.georgialibraries.org <http://help.georgialibraries.org> | >>> [email protected]<mailto:[email protected] >>> <[email protected]>> >>> <https://www.facebook.com/georgialibraries>< >>> https://www.twitter.com/georgialibs>< >>> https://www.instagram.com/georgialibraries/>< >>> https://www.twitter.com/georgialibs> >>> Join our email list <http://georgialibraries.org>for stories of Georgia >>> libraries making an impact in our communities. >>> On Fri, Mar 11, 2022 at 10:28 AM Bill Erickson via Evergreen-general < >>> [email protected]< >>> mailto:[email protected] >>> <[email protected]>>> wrote: >>> Hi All, >>> I'm thinking of turning my attention to porting the Evergreen >>> Offline interface as we continue our march away from AngularJS. >>> Unlike other interfaces, where the end goal is pretty >>> straightforward -- just migrate it to Angular -- I think the Offline >>> UI would benefit from some discussion. >>> I've long been a proponent of not requiring external software to use >>> the browser client. Once an EG server is up, just open your >>> browser, and you're good to go. >>> Hatch is obviously external software, but I don't consider it a >>> requirement to use the client. It smooths over some aspects of the >>> workflow, but it does not provide functionality that can only be >>> done with Hatch. >>> However, I have also heard some comments in IRC to the effect that >>> having a purely web-based offline interface may be causing some >>> consternation / complications. I don't recall the context or the >>> specific concerns, only the seed stuck in my mind. >>> Because of these conflicting ideas, I thought it best to get some >>> feedback. >>> Here I propose two options to consider that I think cover the >>> extreme ends of the spectrum. There may be middle ground or other >>> options entirely. >>> 1. Create a progress web app in Angular that performs exactly as the >>> AngularJS version. There will be slight style variations and some >>> differences to how the offline code is managed (Angular has a nice >>> set of tools for progress web apps) as with the other Angular pages, >>> but it would essentially be a direct port. >>> 2. Create a standalone application that's just an offline >>> interface. It would be a separate program you run on your PC. >>> Because I don't like showing up empty handed, I've created a proof >>> of concept JavaFX app at https://github.com/berick/eg-offline-jfx >>> <https://github.com/berick/eg-offline-jfx> complete with screen >>> shots. (I can explain the choice of JavaFX later as needed). >>> Both have pluses and minuses. Before we get too into the weeds, >>> though, I'm curious if there is an obvious direction people feel we >>> should take, specific technology notwithstanding. (Also, by all >>> means, let's get into the weeds :) >>> I welcome your questions and feedback! >>> -b >>> _______________________________________________ >>> Evergreen-general mailing list >>> [email protected] >>> <mailto:[email protected] >>> <[email protected]>> >>> >>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general >>> < >>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general >>> > >>> _______________________________________________ >>> Evergreen-general mailing list >>> [email protected] >>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general >>> >>> _______________________________________________ >>> Evergreen-general mailing list >>> [email protected] >>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general >>> >>> >>> _______________________________________________ >>> Evergreen-general mailing list >>> [email protected] >>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general >>> >> _______________________________________________ >> Evergreen-general mailing list >> [email protected] >> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general >> > _______________________________________________ > Evergreen-general mailing list > [email protected] > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general >
_______________________________________________ Evergreen-general mailing list [email protected] http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
