[OPEN-ILS-GENERAL] [OPEN-ILS-DEV] browser staff feedback request / integration

[Ruth Frasur]

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 <berick at esilibrary.com> wrote:

>
> On Fri, Apr 4, 2014 at 2:11 PM, Jeff Davis <jdavis at 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: berick at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140407/0afdeb25/attachment.htm>