[Evergreen-general] Planning the next EG Offline Interface
Jason Boyer
JBoyer at equinoxOLI.org
Mon Mar 14 12:18:40 EDT 2022
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
JBoyer at equinoxOLI.org
+1 (877) Open-ILS (673-6457)
https://equinoxOLI.org/
> On Mar 11, 2022, at 12:23 PM, Jeff Davis via Evergreen-general <evergreen-general at list.evergreen-ils.org> 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| tmccanna at georgialibraries.org <mailto:tmccanna at georgialibraries.org> <mailto:tmccanna at georgialibraries.org <mailto:tmccanna at georgialibraries.org>>
>> http://help.georgialibraries.org <http://help.georgialibraries.org/> <http://help.georgialibraries.org <http://help.georgialibraries.org/>> | help at georgialibraries.org <mailto:help at georgialibraries.org><mailto:help at georgialibraries.org <mailto:help at georgialibraries.org>>
>> <https://www.facebook.com/georgialibraries <https://www.facebook.com/georgialibraries>><https://www.twitter.com/georgialibs <https://www.twitter.com/georgialibs>><https://www.instagram.com/georgialibraries/ <https://www.instagram.com/georgialibraries/>><https://www.twitter.com/georgialibs <https://www.twitter.com/georgialibs>>
>> Join our email list <http://georgialibraries.org <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 <evergreen-general at list.evergreen-ils.org <mailto:evergreen-general at list.evergreen-ils.org><mailto:evergreen-general at list.evergreen-ils.org <mailto:evergreen-general at list.evergreen-ils.org>>> 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>
>> <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
>> Evergreen-general at list.evergreen-ils.org <mailto:Evergreen-general at list.evergreen-ils.org>
>> <mailto:Evergreen-general at list.evergreen-ils.org <mailto:Evergreen-general at list.evergreen-ils.org>>
>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general <http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general>
>> <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
>> Evergreen-general at list.evergreen-ils.org <mailto:Evergreen-general at list.evergreen-ils.org>
>> 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
> Evergreen-general at list.evergreen-ils.org <mailto:Evergreen-general at list.evergreen-ils.org>
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general <http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20220314/27ecc2e4/attachment-0001.htm>
More information about the Evergreen-general
mailing list