[OPEN-ILS-GENERAL] TODAY: IRC practice time on Friday, April 4 at 2PM EST
Hello, Here is a last minute reminder that today I will again be hosting an IRC practice time. The first practice time went well, and I am looking forward to todays second practice time. Like I said during the recent conference id you… 1) have ever sent a text message 2) have a web browser … you can pull off giving IRC a try for yourself. Here is a presentation with information of how to just use a web browser to use IRC… http://goo.gl/w3zml2 This will be an hour long session for newcomers to practice using IRC to be held on TODAY Friday, April 4 at 2PM EST. This will be a designated practice time, so no one feels like they are interrupting others. Thanks in advance, Yamil
[OPEN-ILS-GENERAL] TODAY: IRC practice time on Friday, April 4 at 2PM EST
Hello, Here is a last minute reminder that today I will again be hosting an IRC practice time. The first practice time went well, and I am looking forward to todays second practice time. Like I said during the recent conference id you… 1) have ever sent a text message 2) have a web browser … you can pull off giving IRC a try for yourself. Here is a presentation with information of how to just use a web browser to use IRC… http://goo.gl/w3zml2 This will be an hour long session for newcomers to practice using IRC to be held on TODAY Friday, April 4 at 2PM EST. This will be a designated practice time, so no one feels like they are interrupting others. Thanks in advance, Yamil
[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 -- Bill Erickson | Senior Software Developer | phone: 877-OPEN-ILS (673-6457) | email: ber...@esilibrary.com | web: http://esilibrary.com | Equinox Software, Inc. / The Open Source Experts
Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
On Fri, Apr 04, 2014 at 10:25:56AM -0400, McCanna, Terran wrote: 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. +1 to what Terran says. Let's forgo the complications of trying to force new-style development into an aging security / performance / functionality-impaired container and instead focus on fleshing out the browser-based modules on a workflow-by-workflow basis as much as possible, so that some staff (as Terran says) can benefit ASAP and help us find where we can optimize workflows or where we've missed yet another piece of existing functionality that most sites don't use but that is critical to another site's workflow.
Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
At the Hack-A-Way we discussed the piecemeal method of integrating the new staff client into the XUL app as a way of easing people into it. I've always been OK with that approach but I don't prefer it. I think we would waste precious resources trying to frankenstein them. On Fri, Apr 4, 2014 at 10:32 AM, Dan Scott d...@coffeecode.net wrote: On Fri, Apr 04, 2014 at 10:25:56AM -0400, McCanna, Terran wrote: 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. +1 to what Terran says. Let's forgo the complications of trying to force new-style development into an aging security / performance / functionality-impaired container and instead focus on fleshing out the browser-based modules on a workflow-by-workflow basis as much as possible, so that some staff (as Terran says) can benefit ASAP and help us find where we can optimize workflows or where we've missed yet another piece of existing functionality that most sites don't use but that is critical to another site's workflow. -- Rogan Hamby, MLS, CCNP, MIA Managers Headquarters Library and Reference Services, York County Library System You don't have to burn books to destroy a culture. Just get people to stop reading them. -- Ray Bradbury https://www.goodreads.com/author/show/1630.Ray_Bradbury You can never get a cup of tea large enough or a book long enough to suit me. -- C.S. Lewis http://www.goodreads.com/author/show/1069006.C_S_Lewis
Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
On Fri, Apr 4, 2014 at 10:39 AM, Rogan Hamby rogan.ha...@yclibrary.net wrote: At the Hack-A-Way we discussed the piecemeal method of integrating the new staff client into the XUL app as a way of easing people into it. I've always been OK with that approach but I don't prefer it. I think we would waste precious resources trying to frankenstein them. I agree with this. The staff client quickly became a frankenstein, and not without some dissonance and pain. If we were to simply link to the newer interfaces within the portal page, and not try to otherwise integrate it, that would be okay. If were to disable the spawn foreign links in an external browser functionality, then we'd essentially be using HTTP, etc. on what amounts to an older version of Firefox within a browser element. -- Jason Etheridge | Support Manager | Equinox Software, Inc. / The Open Source Experts | phone: 1-877-OPEN-ILS (673-6457) | email: ja...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
Another +1 to Terran's thoughts. From my perspective, as the one who has to train the staff, being able to move certain functions entirely out of the staff client will be easier to explain to them than letting them stick with the client with these new interfaces. It's going to be painful for them regardless, but I'd rather rip off the bandaid than slowly peel it back. Kate Butler Technology Librarian Rodgers Memorial Library (Hudson, NH) http://www.rodgerslibrary.org/ From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Rogan Hamby Sent: Friday, April 04, 2014 10:40 AM To: Evergreen Discussion Group Cc: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration At the Hack-A-Way we discussed the piecemeal method of integrating the new staff client into the XUL app as a way of easing people into it. I've always been OK with that approach but I don't prefer it. I think we would waste precious resources trying to frankenstein them. On Fri, Apr 4, 2014 at 10:32 AM, Dan Scott d...@coffeecode.netmailto:d...@coffeecode.net wrote: On Fri, Apr 04, 2014 at 10:25:56AM -0400, McCanna, Terran wrote: 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. +1 to what Terran says. Let's forgo the complications of trying to force new-style development into an aging security / performance / functionality-impaired container and instead focus on fleshing out the browser-based modules on a workflow-by-workflow basis as much as possible, so that some staff (as Terran says) can benefit ASAP and help us find where we can optimize workflows or where we've missed yet another piece of existing functionality that most sites don't use but that is critical to another site's workflow. -- Rogan Hamby, MLS, CCNP, MIA Managers Headquarters Library and Reference Services, York County Library System You don't have to burn books to destroy a culture. Just get people to stop reading them. ― Ray Bradburyhttps://www.goodreads.com/author/show/1630.Ray_Bradbury You can never get a cup of tea large enough or a book long enough to suit me. ― C.S. Lewishttp://www.goodreads.com/author/show/1069006.C_S_Lewis
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-...@list.georgialibraries.org, Evergreen Discussion Group open-ils-general@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 -- Bill Erickson | Senior Software Developer | phone: 877-OPEN-ILS (673-6457) | email: ber...@esilibrary.com | web: http://esilibrary.com | Equinox Software, Inc. / The Open Source Experts
Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
Hi, On Fri, Apr 4, 2014 at 7:25 AM, McCanna, Terran tmcca...@georgialibraries.org wrote: 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. +1 for the reasons that folks have already mentioned. My main caveat is to try to anticipate and avoid situations where folks would not only have to switch from browser to XUL often, but would also need to maintain a lot of context while doing so. As a contrived example, if v1 of the web-based circulation interface let you do everything except register patrons, switching to the staff client to add a new patron, then switching back to the browser to scan their barcode and check out their first items wouldn't be ideal, but it wouldn't be difficult or slow to make the transition. This is because the only thing needed to maintain the context during the transition is scanning a patron barcode. Conversely, as another contrived example, if v1 of web-based circ required that you jump to the XUL staff client during a checkout session to add a pre-cat, that would be more disruptive, as it scatters the overall workflow of check out a bunch of items across two interfaces, and raises questions like whether the patron would end up with two checkout receipts. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: g...@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web:http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org http://evergreen-ils.org
Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] browser staff feedback request / integration
Conversely, as another contrived example, if v1 of web-based circ required that you jump to the XUL staff client during a checkout session to add a pre-cat, that would be more disruptive, as it scatters the overall workflow of check out a bunch of items across two interfaces, and raises questions like whether the patron would end up with two checkout receipts. Yes, Galen's point is a good one. The frequency of this kind of thing happening will probably vary significantly from consortium to consortium depending on their policies, and some places might find it's too much of a hassle and opt to continue to work just in the client and not in the web version at all until they have to. That would be unfortunate for the project from a testing and adoption perspective, but I would expect that most places would at least be willing to try it and some places would really run with it. And, I'd rather support staff who are grumble about switching back and forth between two clients than staff who panic because something was accidentally broken in a Frankensteined merge. Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org
Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
+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-...@list.georgialibraries.org, Evergreen Discussion Group open-ils-general@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 -- Bill Erickson | Senior Software Developer | phone: 877-OPEN-ILS (673-6457) | email: ber...@esilibrary.com | web: http://esilibrary.com | Equinox Software, Inc. / The Open Source Experts
Re: [OPEN-ILS-GENERAL] browser staff feedback request / integration
+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-...@list.georgialibraries.org, Evergreen Discussion Group open-ils-general@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
Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] browser staff feedback request / integration
On 2014-04-04 09:37AM, Galen Charlton wrote: +1 for the reasons that folks have already mentioned. My main caveat is to try to anticipate and avoid situations where folks would not only have to switch from browser to XUL often, but would also need to maintain a lot of context while doing so. As a contrived example, if v1 of the web-based circulation interface let you do everything except register patrons, switching to the staff client to add a new patron, then switching back to the browser to scan their barcode and check out their first items wouldn't be ideal, but it wouldn't be difficult or slow to make the transition. This is because the only thing needed to maintain the context during the transition is scanning a patron barcode. Conversely, as another contrived example, if v1 of web-based circ required that you jump to the XUL staff client during a checkout session to add a pre-cat, that would be more disruptive, as it scatters the overall workflow of check out a bunch of items across two interfaces, and raises questions like whether the patron would end up with two checkout receipts. I think this caveat is pretty important. Ideally, no individual workflow would require switching between the XUL client and the browser. In Galen's first example, switching isn't too much of a problem because you are also switching between conceptually distinct workflows (and indeed between different interfaces within the existing XUL client). As Dan suggested earlier, if development focuses on fleshing out modules on a workflow-by-workflow basis as much as possible, we'll mitigate a lot of the pain in having multiple clients. Jeff
