With an automatic “seamless” sort of solution, I would want the ability to 
exercise some control over it.

Just because it can manage to talk to the server for a moment, doesn’t 
necessarily mean it should be considered up and ready to start accepting 
inbound offline transactions.

Generally speaking, once a system is back up I want to do a little bit of 
testing first to be sure of the complete status of everything, before telling 
staff to go ahead.  Wouldn’t want clients auto-dumping transactions at it 
before I’ve confirmed we’re ready for that.  (Thinking about upgrade-related 
outages, mostly.)

Perhaps something as simple as “this file with these contents must be found 
present on server before sending transactions” would take care of that.  (On my 
end, the file would be renamed/unavailable to the clients, or have negative 
contents, until deemed ready to go.)

Also… I’d prefer the current mechanisms for managing them to be retained, as 
the ability to control what is going on there is useful.  Rather than just send 
transactions (the way a selfcheck queues up sip requests when offline, to later 
send them when back on)… just automate the upload of transaction files into 
queue(s) for processing.  Basically the same thing that happens now, only 
removing the need for staff (or visit by admin) to upload them.   I agree, 
that’d be great.  While retaining the ability to reject (or modify) them, if 
necessary for some reason.  Or even to just verify that yes, these are legit 
transactions that happened while offline for x amount of time on this day at 
this location, and to look them over, before automatically accepting a load of 
data for import as transactions.  Would just need a standardized organization & 
naming scheme for auto-uploads & their queues to follow.

I love automatic stuff, as long as there are some reins or gates available for 
managing it.

Summarizing the logic..


  1.  If running in offline mode, check every x amount of time for return of 
connectivity.
  2.  Once connectivity has returned, check every x amount of time for presence 
of “ok to proceed” on server.
  3.  Once presence of “ok to proceed” found on server, check for presence of 
“auto upload queue” for correct org unit and date (something like that).
  4.  If found, use it… if not found, create it then use it.
  5.  Upload offline transaction file to that queue, inform the user that it 
has successfully done so.  Maybe notify a designated user that there are 
offline transactions awaiting review/processing.

At least that’s how I’m currently picturing such a thing in my head.  Might be 
workable whether a completely transparent thing in the web client, or an 
independent/local offline app.  (I have a slight preference in that direction.  
Maybe it could inform you when “your system is back online, click here when 
you’re ready to upload your transactions and return to the web client”.)


--------------------------------------
Jeremiah Miller  | 503-507-9258 (cell)
Sysadmin | Albany Public Library
--------------------------------------




From: Evergreen-general <[email protected]> On 
Behalf Of Joe Knueven via Evergreen-general
Sent: Monday, March 14, 2022 11:02 AM
To: Evergreen Discussion Group <[email protected]>
Cc: Joe Knueven <[email protected]>
Subject: Re: [Evergreen-general] Planning the next EG Offline Interface


[External Email Notice:  Avoid unknown attachments or links, especially from 
unexpected mail.]
I think I would side towards staff either needing to click through a warning 
that they are entering offline mode or having to open a separate program, as I 
basically agree with what Michele Morgan said earlier.  I think either would be 
a useful reminder that this isn't something that should be done because their 
connection timed out once.

I would also add a +1 to Michele's suggestion of it being seamless.  (ie the 
interface uploads transactions when a connection is available without human 
assistance)  I would rather the system upload the transactions that work and 
then dump a report to the local admin about transactions that failed.  For 
security, such notice could be generic ("some offline transactions from station 
[EG WORKSTATION NAME] failed to load at [TIMESTAMP]") and the detailed info 
kept inside EG, but accessible in such a way that the local admin could sit at 
their computer and make those manual corrections rather than going around to 
every workstation.

In addition to making it easier for the local/consortium admins to manage these 
situations, I think this would be useful for all staff/improve customer service 
since I've seen where in the stress of dealing with an ILS down/internet 
down/power outage that staff who do not know how to load offline transactions 
will not remember to tell anyone that they used the interface and the 
transactions get found (hopefully) the next day by someone who know what to do 
with them.

Have a good day.

Joe

Joe Knueven, Director
Wilmington Public Library
268 N South Street
Wilmington, OH 45177
937-382-6165 x101 (direct)
937-382-2417 (public)




---- On Mon, 14 Mar 2022 13:37:32 -0400 Bill Erickson via Evergreen-general 
<[email protected]<mailto:[email protected]>>
 wrote ----

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 
<[email protected]<mailto:[email protected]>>
 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
[email protected]<mailto:[email protected]>



On Mon, Mar 14, 2022 at 12:17 PM Morgan, Michele via Evergreen-general 
<[email protected]<mailto:[email protected]>>
 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
[email protected]<mailto:[email protected]>



On Mon, Mar 14, 2022 at 1:04 PM Bill Erickson via Evergreen-general 
<[email protected]<mailto:[email protected]>>
 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/<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2faws.amazon.com%2fcorretto%2f&c=E,1,SbW6VQy3AyAKjN2zmRiJkKAyjI4xjN8T-lR7JsuNAgfcz56tB84L-V0jVoBVgOTFAQGbUrWDJca1UqRTDCnKBcrRdHY3V1TtYeruo04aEyx7Ww,,&typo=1>

-b


On Mon, Mar 14, 2022 at 12:18 PM Jason Boyer via Evergreen-general 
<[email protected]<mailto:[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]<mailto:[email protected]>
+1 (877) Open-ILS (673-6457)
https://equinoxOLI.org/<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fequinoxOLI.org%2f&c=E,1,FB73AQIwxo3n7LZjcN3xcpeYsD9ib7GKwHn3HbvbxP4gbESCzifMjZHniZngIzEU2RpIowxzC1U_dj04n4Mf5UPwBuTBvAtdfA-1KLav--lrw1dyfoExRXI,&typo=1>

On Mar 11, 2022, at 12:23 PM, Jeff Davis via Evergreen-general 
<[email protected]<mailto:[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]> 
<mailto:[email protected]>
http://help.georgialibraries.org<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fhelp.georgialibraries.org%2f&c=E,1,HAxBLP8ykapRPqOa68N14mT9hQaqXccnyjRGi3im5_arvEIDyQXIzz7HVjyfFk1KNDEk_hc1s0d9LLYZ1EaIqbHus4v6l6LVsd-Ye4NeT2Bn8PI4P2Nl&typo=1>
 
<http://help.georgialibraries.org<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fhelp.georgialibraries.org%2f&c=E,1,dunD0LpVawID7Iz5m21FlwYcT7PUkDCkIRlKhu3K0jcycT9gfUJ9WDEoKTfcQQLtr3ZV-30s3CpmGFyUUE7C7eA8lfSyiwgk8iz-ISsLjQ7MSvidL2Ny6qsXEQ,,&typo=1>>
 | 
[email protected]<mailto:[email protected]><mailto:[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<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fgeorgialibraries.org%2f&c=E,1,OrN6xEuRF5wsBcY3qR6U0HE02gZunxFBuBmzJFIj6tKAwGjZbOeFbT6zos--UAuI_9AoIhWjT2bDu_xIJfvovvKk2stvY8CN-eO0h-BxU89fqXI,&typo=1>>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]><mailto:[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]>
   <mailto:[email protected]>
   
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,-kRnn1pDa2V6ndqFiHthCDhsLNTH1SYj9KHVDs2AqkAtU8tx0CNjn7FZdAD87fEMQPjxx0obEc2RIXxTDmkevqQMrBsw2QYJmnOv4PqW1cbp6Uo,&typo=1>
   
<http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,mQpjp0wNT7ygJiM7TjBMPJTJTzE04pcZNtsJgYWw6DoFcPpyGSTLsWrws9ToGRFmoFweHbH6B39fQx9B_H_jmhZlNnLH50xgtqc6-rRksX8rKk0P7mE,&typo=1>>
_______________________________________________
Evergreen-general mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,OsfFaPm0d-w_7aVfW8yjhg_85yllD49EErt4IrsVXpalV1XtkIdpeg0zxklH7BLlzvHwGCZtWJjjYZAaj3ybQLb-SbCLrV7ZC7AjMqgoi3wNVuz7IbPw3w,,&typo=1>
_______________________________________________
Evergreen-general mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,_UElfaHKj8WkcP7OpBs_OODaRSiupE7qKRVrCsOpJqkSrDZQchcLhjox5D5e-q_tdgXuMgY0G2Zv6w5vmsuYxf7wQbU4z5NAG9md-6Iq5DZ_YOuWPLidb5BByQ,,&typo=1>

_______________________________________________
Evergreen-general mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,X2_mwJb9WjrUOSYXg2X6vRnci7t5kEzqwh1-ni7cUD7BRUVG9wOPz9noe9WXFfbTSm7QMABRymFG4yA2fwFz0k2AlO66SCzuNJw_3ddQk2pC4ZdPnw,,&typo=1>
_______________________________________________
Evergreen-general mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,YW3hNJhtsQxV5mnPHaqsJ8TF_RiKxE4ZZF6R1QkH9gskCpuf1-kFfi4GctRImOFyWG7Tmlj68PUT10DmXlnjlYKHz3OcS3EA14gv8W-MpzE,&typo=1>
_______________________________________________
Evergreen-general mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,XtJJJx8xn6XnzvPhJMwHwJri0JbAJyLQeYzs3nowrLVJFSdRrHF_hKXPBxwroa7FyzguIMko0YbC3kVLOl_THhYzNcrzSxsNQwBRxfsnI1-W9eSjQ4SaYA,,&typo=1>
_______________________________________________
Evergreen-general mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,PVcHM5XEozVRIVFrSr1KNIsx40b7pG4_mulp54HN6xyv4-DzgKrdGi-dPQGVYhR5dX02Y3gsinzJnmWe1dGi7SGhodWRf6nYBRxJ4w5zBCLTOvE5&typo=1>
_______________________________________________
Evergreen-general mailing list
[email protected]<mailto:[email protected]>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flist.evergreen-ils.org%2fcgi-bin%2fmailman%2flistinfo%2fevergreen-general&c=E,1,Hxtik6B7xvJVMpNhp4j6RBEhb0jWqgVmgMYcu9HOt4FW9dh_30kJ9OO-qjqmhdQkPf93UDeheiNFE61D81bwyihSxXQFdZswLQRJewjScBxf&typo=1>





______________
DISCLAIMER: This email may be considered a public record of the City of Albany 
and subject to the State of Oregon Retention Schedule. This email also may be 
subject to public disclosure under the Oregon Public Records Law. This email, 
including any attachments, is for the sole use of the intended recipient(s) and 
may contain confidential and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you have received this 
communication in error, please notify the sender immediately and destroy all 
copies of the original message.
_______________________________________________
Evergreen-general mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Reply via email to