[Evergreen-general] Planning the next EG Offline Interface
Diane Disbro
ddisbro at scenicregional.org
Mon Mar 14 13:22:25 EDT 2022
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
ddisbro at scenicregional.org
On Mon, Mar 14, 2022 at 12:17 PM Morgan, Michele via Evergreen-general <
evergreen-general at list.evergreen-ils.org> 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
> mmorgan at noblenet.org
>
>
>
> On Mon, Mar 14, 2022 at 1:04 PM Bill Erickson via Evergreen-general <
> evergreen-general at list.evergreen-ils.org> 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 <
>> evergreen-general at list.evergreen-ils.org> 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
>>> 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 <tmccanna at georgialibraries.org>>
>>> http://help.georgialibraries.org <http://help.georgialibraries.org> |
>>> help at georgialibraries.org<mailto:help at georgialibraries.org
>>> <help at georgialibraries.org>>
>>> <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 <
>>> evergreen-general at list.evergreen-ils.org<
>>> mailto:evergreen-general at list.evergreen-ils.org
>>> <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> 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
>>> <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
>>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>>>
>>> _______________________________________________
>>> Evergreen-general mailing list
>>> Evergreen-general at list.evergreen-ils.org
>>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>>>
>>>
>>> _______________________________________________
>>> Evergreen-general mailing list
>>> Evergreen-general at list.evergreen-ils.org
>>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>>>
>> _______________________________________________
>> Evergreen-general mailing list
>> Evergreen-general at list.evergreen-ils.org
>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>>
> _______________________________________________
> Evergreen-general mailing list
> Evergreen-general at list.evergreen-ils.org
> 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/5a9532c9/attachment-0001.htm>
More information about the Evergreen-general
mailing list