Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] browser staff feedback request / integration
On Mon, Apr 7, 2014 at 6:30 PM, Tim Spindler tjspind...@gmail.com wrote: Maybe this was said but if the web interface is not incorporated in the xulrunner client, would the old screens continue to be available in the xulrunner client? Yes, the XUL app will continue to operate as-is while the browser client is developed. I also expect the XUL client will be available for some amount of time after the browser client is ready to ease migration, though the details are yet to be ironed out. -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] [OPEN-ILS-DEV] browser staff feedback request / integration
On Fri, Apr 4, 2014 at 2:11 PM, Jeff Davis jda...@sitka.bclibraries.cawrote: 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. Agreed on fleshing out modules on a workflow-by-workflow basis as much as possible. This is one area where user testing early in the process can really pay off. So, I think it's safe to say we have a consensus on avoiding the XUL/mixed integration path entirely. From a development perspective, this is certainly a relief. -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] [OPEN-ILS-DEV] browser staff feedback request / integration
Late weighing in, and weighing in with little technical know-how. It's my feelings that any kind of in-between product is really just going to waste time and resources that could be going into building the web client. I suspect that's already been said, but here's another +1 On Mon, Apr 7, 2014 at 1:19 PM, Bill Erickson ber...@esilibrary.com wrote: On Fri, Apr 4, 2014 at 2:11 PM, Jeff Davis jda...@sitka.bclibraries.cawrote: 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. Agreed on fleshing out modules on a workflow-by-workflow basis as much as possible. This is one area where user testing early in the process can really pay off. So, I think it's safe to say we have a consensus on avoiding the XUL/mixed integration path entirely. From a development perspective, this is certainly a relief. -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 -- Ruth Frasur Director of the Historic(ally Awesome) Hagerstown - Jefferson Township Library 10 W. College Street in Hagerstown, Indiana (47346) p (765) 489-5632; f (765) 489-5808 Our Kickin' Website http://hagerstownlibrary.org Our Rockin' Facebook Page http://facebook.com/hjtplibrary and Stuff I'm Readinghttp://pinterest.com/hjtplibrary/ruth-reads/
Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] browser staff feedback request / integration
I'm fine with the decision and consensus, but want to add one thing. I've met a fair number of users who have a difficult time managing multiple windows in an ongoing way (call them the closers). We obviously don't have any such folks responding to this thread, but I think we should be open to such feedback (should it come) and possibly reconsider this decision if necessary. Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133 From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Bill Erickson Sent: Monday, April 07, 2014 1:20 PM To: Evergreen Discussion Group Cc: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] browser staff feedback request / integration Agreed on fleshing out modules on a workflow-by-workflow basis as much as possible. This is one area where user testing early in the process can really pay off. So, I think it's safe to say we have a consensus on avoiding the XUL/mixed integration path entirely. From a development perspective, this is certainly a relief. -b -- Bill Erickson | Senior Software Developer | phone: 877-OPEN-ILS (673-6457) | email: ber...@esilibrary.commailto:ber...@esilibrary.com | web: http://esilibrary.com | Equinox Software, Inc. / The Open Source Experts
Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] browser staff feedback request / integration
Hi, On Mon, Apr 7, 2014 at 2:32 PM, Dan Wells d...@calvin.edu wrote: I'm fine with the decision and consensus, but want to add one thing. I've met a fair number of users who have a difficult time managing multiple windows in an ongoing way (call them the closers). To clarify, are you talking about computer users in general, or folks you've met who are already using the Evergreen staff client but who you believe would not be able to adapt to switching contexts at all? 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
Every system has a few. The Closers is fantastic. For our users, I plan on recommending that the staff members that have trouble switching back and forth and that are intimidated by the new interface should just stick with the existing staff client when they are busy and practice using the web interface when they are not so busy until they get used to it. Any sort of change is going to require a certain amount of training, and I feel that this approach gives libraries more control over how and when they get their staff up to speed. And, depending on how workflow is set up at a branch, sometimes you will find yourself doing a simple repeated task over and over a hundred times and there won't be a lot of switching back and forth (checking in books from a holiday weekend, routing holds, etc.) 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: Dan Wells d...@calvin.edu To: Evergreen Development Discussion List open-ils-...@list.georgialibraries.org, Evergreen Discussion Group open-ils-general@list.georgialibraries.org Sent: Monday, April 7, 2014 5:32:12 PM Subject: Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] browser staff feedback request / integration I’m fine with the decision and consensus, but want to add one thing. I’ve met a fair number of users who have a difficult time managing multiple windows in an ongoing way (call them “the closers”). We obviously don’t have any such folks responding to this thread, but I think we should be open to such feedback (should it come) and possibly reconsider this decision if necessary. Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133 From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Bill Erickson Sent: Monday, April 07, 2014 1:20 PM To: Evergreen Discussion Group Cc: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] browser staff feedback request / integration Agreed on fleshing out modules on a workflow-by-workflow basis as much as possible. This is one area where user testing early in the process can really pay off. So, I think it's safe to say we have a consensus on avoiding the XUL/mixed integration path entirely. From a development perspective, this is certainly a relief. -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] [OPEN-ILS-DEV] browser staff feedback request / integration
Maybe this was said but if the web interface is not incorporated in the xulrunner client, would the old screens continue to be available in the xulrunner client? Tim Spindler C/W MARS On Mon, Apr 7, 2014 at 6:12 PM, McCanna, Terran tmcca...@georgialibraries.org wrote: Every system has a few. The Closers is fantastic. For our users, I plan on recommending that the staff members that have trouble switching back and forth and that are intimidated by the new interface should just stick with the existing staff client when they are busy and practice using the web interface when they are not so busy until they get used to it. Any sort of change is going to require a certain amount of training, and I feel that this approach gives libraries more control over how and when they get their staff up to speed. And, depending on how workflow is set up at a branch, sometimes you will find yourself doing a simple repeated task over and over a hundred times and there won't be a lot of switching back and forth (checking in books from a holiday weekend, routing holds, etc.) 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: Dan Wells d...@calvin.edu To: Evergreen Development Discussion List open-ils-...@list.georgialibraries.org, Evergreen Discussion Group open-ils-general@list.georgialibraries.org Sent: Monday, April 7, 2014 5:32:12 PM Subject: Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] browser staff feedback request / integration I'm fine with the decision and consensus, but want to add one thing. I've met a fair number of users who have a difficult time managing multiple windows in an ongoing way (call them the closers). We obviously don't have any such folks responding to this thread, but I think we should be open to such feedback (should it come) and possibly reconsider this decision if necessary. Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133 From: open-ils-dev-boun...@list.georgialibraries.org [mailto: open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Bill Erickson Sent: Monday, April 07, 2014 1:20 PM To: Evergreen Discussion Group Cc: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] browser staff feedback request / integration Agreed on fleshing out modules on a workflow-by-workflow basis as much as possible. This is one area where user testing early in the process can really pay off. So, I think it's safe to say we have a consensus on avoiding the XUL/mixed integration path entirely. From a development perspective, this is certainly a relief. -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 -- Tim Spindler tjspind...@gmail.com *P** Go Green - **Save a tree! Please don't print this e-mail unless it's really necessary.*
Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] browser staff feedback request / integration
Galen, I was deliberately vague in my earlier email, and hope you will understand if I continue to be :) I think it is fine to proceed with a separation mindset and see how it turns out. Thanks, Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133 -Original Message- From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Galen Charlton Sent: Monday, April 07, 2014 5:52 PM To: Evergreen Development Discussion List Cc: Evergreen Discussion Group Subject: Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] browser staff feedback request / integration To clarify, are you talking about computer users in general, or folks you've met who are already using the Evergreen staff client but who you believe would not be able to adapt to switching contexts at all? Regards, Galen
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] [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
