[OPEN-ILS-DEV] Revisiting web client catalog integration

[Mike Rylander]

Dan,

I should also clarify that Bill has already attempted to inject the
"missing" history elements (the reverse of what that linked code does, but
conceptually similar), and it doesn't work in Chrome, unfortunately. That's
described at the wiki link I had in my last email on this thread.

Sorry for leaving that background out of my last response to you.


--
Mike Rylander
 | President
 | Equinox Software, Inc. / The Open Source Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com


On Thu, Apr 23, 2015 at 5:40 PM, Mike Rylander <mrylander at gmail.com> wrote:

> Dan,
>
> IIUC, we want the Firefox behaviour, not the Chrome behaviour.  The
> latter, I believe, is what Kathy showed.  Unless I'm misunderstanding, the
> code you link to is forcing the Chrome behaviour, which is the opposite of
> what we want.
>
> Am I missing something?
>
> Thanks,
>
>
> --
> Mike Rylander
>  | President
>  | Equinox Software, Inc. / The Open Source Experts
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  miker at esilibrary.com
>  | web:  http://www.esilibrary.com
>
>
> On Thu, Apr 23, 2015 at 3:38 PM, Daniel Pearl <dpearl at cwmars.org> wrote:
>
>>  A couple of days ago on IRC, I wrote:
>>
>> I understand that use of iframes in the web client for inclusion of the
>> catalog is problematic.  I stumbled across this page
>> http://www.webdeveasy.com/back-butto​n-behavior-on-a-page-with-an-iframe/
>> which describes some JS code that edits the history stack of a browser to
>> make the browser BACK button do the right thing when iframes are present.
>> Has anyone looked into this sort of thing?
>>
>> While the solution presented doesn’t seem to map totally to the behavior
>> in the Screencast (which, frankly, puzzles me), it is suggestive that
>> judicious display history stack editing (now exposed in HTML5) could
>> produce better results.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Open-ils-dev [mailto:open-ils-dev-bounces at list.georgialibraries.org
>> <open-ils-dev-bounces at list.georgialibraries.org>] On Behalf Of Kathy
>> Lussier
>> Sent: Thursday, April 23, 2015 3:27 PM
>> To: open-ils-dev at list.georgialibraries.org
>> Subject: [OPEN-ILS-DEV] Revisiting web client catalog integration
>>
>> Hi all,
>>
>> After considerable testing of the web client and some follow-up
>> discussions with Equinox, I would like to revisit a discussion we had last
>> year regarding catalog integration in the web client -
>> http://markmail.org/message/zicsno2i7jlshpdb.
>>
>> I think the use of iframes will be problematic for our users. When
>> testing, I've found that if I click to view holds for a bib record, if I
>> then click the browser's back button, I don't return to the record.
>> Instead, I go back to a different holds view and then back to the
>> advanced search screen. See the screencast at
>> https://drive.google.com/open?id=0B74gDMUDwDXqMXhBMlBmQUI3Uk0&authuser=0.
>>
>> There are navigational elements in the UI to bring users back to the
>> record or to the search results. However, if there is a browser back
>> button, people will use it despite those navigational elements. This is
>> what makes the iframe issue distinct from what we currently have available
>> in the xul client. There is no standard back button in the xul client, so
>> people are forced to use the other navigational elements available in the
>> UI. We don't have that level of control in the web client.
>>
>> I am sending this e-mail to see if the collective wisdom of the developer
>> community may be able to come up with a solution that will work well for
>> our users. My preference is to not use iframes at all, but my primary
>> concern is getting the browser navigational tools to work correctly.
>>
>> Any thoughts?
>>
>> Thanks!
>> Kathy
>>
>> --
>> Kathy Lussier
>> Project Coordinator
>> Massachusetts Library Network Cooperative
>> (508) 343-0128
>> klussier at masslnc.org
>> Twitter: http://www.twitter.com/kmlussier
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20150423/55735acf/attachment.html>