+1 to the conversation so far. The focus should be on the development
of the browser client, not the extra code required to integrate. I
would think that the added layer could have a major impact when
troubleshooting bugs: Is this an issue with the new interface, XUL, or
the glue?
I do see the logic in easing folks into new interfaces, but I think
that for every person who has difficulty with the new interface there
is one who, as Terran mentioned, is perhaps using old hardware and
having difficulty with the current staff client. We were just dealing
with just such an issue this morning and had commented that we can't
wait for the browser based client.
Justin
On Fri Apr 4 12:23:08 2014, Forrest, Stuart wrote:
+1, good analogy Lynn
Stuart Forrest PhD
Library Systems Specialist
Beaufort County Library
843 255 6450
sforr...@bcgov.net
http://www.beaufortcountylibrary.org
For Liesure, For Learning, For Life
-----Original Message-----
From: open-ils-general-boun...@list.georgialibraries.org
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Lynn
Floyd
Sent: Friday, April 04, 2014 12:27 PM
To: 'Evergreen Discussion Group'
Cc: 'Evergreen Development Discussion List'
Subject: Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
+1 Terran. Why invest in making the changes to the current client, I am of the
let's peal the band aide off quickly approach.
Lynn Floyd
lfl...@andersonlibrary.org
Anderson County Library
864-260-4500 x181
http://www.andersonlibrary.org
-----Original Message-----
From: open-ils-general-boun...@list.georgialibraries.org
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of
McCanna, Terran
Sent: Friday, April 04, 2014 10:26 AM
To: Evergreen Discussion Group
Cc: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
My preference would be to leave the existing client as is (with the exception
of bug fixes, etc.), but to offer the browser-based modules as options once
they become available. My reasons for this are:
1) It will allow for indepth use of the new module in a production environment
to uncover any bugs or performance issues while still having a known entity as
a backup. No amount of testing is going to uncover all of the odd little
problems like working in a live environment will.
2) When moving back and forth between the two environments, staff will be more
aware of the improved user interface and performance, and I believe they will
be more eager to transition completely to the new environment.
3) The browser-based circulation module may offer some immediate relief to
those frontline circ staff who are struggling with antiquated machines and slow
networks.
4) The new modules can begin to be thoroughly tested on mobile devices that
cannot run the current client.
Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmcca...@georgialibraries.org
----- Original Message -----
From: "Bill Erickson" <ber...@esilibrary.com>
To: "Evergreen Development Discussion List" <open-ils-dev@list.georgialibraries.org>,
"Evergreen Discussion Group" <open-ils-gene...@list.georgialibraries.org>
Sent: Friday, April 4, 2014 10:09:53 AM
Subject: [OPEN-ILS-GENERAL] browser staff feedback request / integration
Hi All,
I've posted a dev log entry briefly discussing the merits/challenges of two
different integration paths for the browser client:
http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:dev_notes (see
2014-04-04)
I've focused primarily on the technical aspects, but the decision at hand is
much more than a development decision. The path we chose will affect staff,
administrators, support providers, DIG, and developers alike, so I'd like to
get everyone's thoughts on the matter. My post is brief, little more than an
introduction, so please send any questions and comments along to the lists.
Thanks,
-b
