Just to clarify one point, staff can access the current Evergreen offline interface at any time. The PC does not have to be offline. Just go to Circulation => Offline Interface and select one of the action tabs (Checkout, Renew, etc.). They work fine.
-b On Mon, Mar 14, 2022 at 1:31 PM Diane Disbro via Evergreen-general < [email protected]> wrote: > 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 >
_______________________________________________ Evergreen-general mailing list [email protected] http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
