[Evergreen-general] Planning the next EG Offline Interface

[Terran McCanna]

I love the idea of it being able to pull updates, especially the blocked
patron list, automatically in the background. Ideally, the interface should
show the date/time of the last update as well. Back in XUL when we were
able to do the blocked list download, staff didn't like having to remember
to do it manually, so the more automated it could be, the better.

(Noting that very few of our libraries use Hatch because it requires so
much configuration and it's difficult for them to troubleshoot issues.)



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

http://help.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 11:28 AM Bill Erickson <berickxx at gmail.com> wrote:

> Thanks, Terran.  Comments inline below.
>
> On Fri, Mar 11, 2022 at 10:47 AM Terran McCanna <
> tmccanna at georgialibraries.org> wrote:
> <snip>
>
>>
>> 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.)
>>
>
> The workstation can either be entered/registered in the standalone
> application directly or, if Hatch is running, it could pull the workstation
> info from Hatch or directly from the disk.
>
>
>>  - 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.)
>>
>
> The standalone app will have to communicate to the EG server to pull down
> some data (as Jason mentioned in his email).  That opens the door to
> expanding communication and streamlining.  For example, once the network is
> restored, the standalone app could post the pending transactions directly
> to the EG server where they are kept in a staging area awaiting
> processing.  Or it could post a simple "you have X pending transactions" to
> the server in a place the browser client knows to check at login time.
>
> Alternatively, if Hatch is involved, it could be informed of the pending
> transactions and communicate that to the browser client.
>
> There are probably other options.
>
>
>>  - 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.)
>>
>
> Yes, I would expect this to be resolved.
>
> I imagine the standalone app could run as a background / startup service
> that pulls data (new org units, noncat types, blocked patrons, etc.) at
> regular intervals without any staff intervention.  I also like the idea of
> a "force refresh" option built into the standalone app.
>
> -b
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20220311/4ddddcbf/attachment.htm>