[Evergreen-general] Planning the next EG Offline Interface
Bill Erickson
berickxx at gmail.com
Mon Mar 14 13:37:32 EDT 2022
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 <
evergreen-general at list.evergreen-ils.org> 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
> 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
>>
> _______________________________________________
> 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/69f76a7b/attachment-0001.htm>
More information about the Evergreen-general
mailing list