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.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 > > -- 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 Reading<http://pinterest.com/hjtplibrary/ruth-reads/>