[Evergreen-general] Planning the next EG Offline Interface
Bill Erickson
berickxx at gmail.com
Mon Mar 14 13:04:24 EDT 2022
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20220314/cac6754f/attachment-0001.htm>
More information about the Evergreen-general
mailing list