On Fri, Apr 4, 2014 at 2:11 PM, Jeff Davis <jda...@sitka.bclibraries.ca>wrote:
> 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