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
