WebHelp - after linking to anchor, return to same place?

[Dave Gehman]

Scenario:
WebHelp user clicks a link ("place of departure") that takes the user to an anchored section of another topic. I'd like to provide a way for the user to return to the place of departure -- not just to the original topic, but exactly to the link that was clicked.

Not sure this is possible without coding, since the place of departure is always going to be dynamic...

[Martin Wynne]

Hi Dave,

The Back arrow/button in the browser bar should do that. Nothing to do with H&M. Certainly works in Firefox.

However, if the "place of departure" was inside an expanded toggle, you are likely to find it collapsed when you get back, and needing to be expanded again.

Martin.

[Dave Gehman]

Ah - not in Chrome. Chrome takes me back to the top of the topic that contains the point of departure.

I'll have to check the other contender browers.

[Martin Wynne]

Hi Dave,

Working for me in Google Chrome on Windows10. Just tested on: https://www.helpandmanual.com/help/

Maybe not on tablets?

Martin.

[Dave Gehman]

I'm also Chrome on Windows 10, on a desktop. I'll run through Chrome's settings to see if there's a switch I've missed.

[Dave Gehman]

Yes, it also works for me in the online H+M help file - excluding toggles, as you say. But not in WebHelp via the V3 skin I'm using.

So perhaps this is a switch or option in the skins?

[Tim Green]

Hi Dave,

Because of the way WebHelp must work, a number of things that are possible in "normal" web pages are not possible in WebHelp. Returning to the scroll position with the Back/Forward browser buttons is one of those things. A normal web page is a single static page that is managed entirely by the browser. Its scroll position is the normal position of that page, and only that page, in the browser window. This is always stored by the browser, so returning to it with the Back button is trivial.

A WebHelp page needs to handle a truly huge amount of data compared to a normal static web page and you need to use a lot of trickery to make it behave itself with reasonable performance: You have a table of contents and index, which can both have thousands of entries, a search page that needs to update with many pages of possible hits, and all the content of the current page as well. The user expects to be able to change the content of the current page immediately when they want to switch to another page, without having to reload all that additional material, which they also want to be updated accordingly. If all this was done in a single static page, browsing between topics in WebHelp would take several seconds (and it does on some systems).

What scrolls in a WebHelp page is not the entire page, which is the only thing the browser would keep track of. Instead, only the actual topic content within the page scrolls. Returning to that position would require additional scripting that would have to maintain a separate list of the current scroll positions of all the pages that have been visited, restoring the scroll position dynamically every time the user returns to the same page. This would be possible but a potential source of errors and would also add additional processing overheads to every page load, and would require a constantly-running polling loop to monitor the scroll position. That is not really a problem on desktop browsers, although I'm not a friend of constant polling if it can ever be avoided. However, on mobile browsers it can be a problem, among other things increasing battery consumption.

So far I've decided not to do this because I feel the disadvantages outweigh the benefits by a considerable margin.

[Martin Wynne]

Hi Tim,

Surely you are referring there only to the V3 Webhelp, not Webhelp generally?

I hear what you say about speed, but I have never found it a problem. For example H&M's own non-V3 Webhelp works just fine, including the Back button: https://www.helpandmanual.com/help/

Those topic pages load instantly for me. A human eye couldn't blink any faster.

However, the Index and Search icons don't work, unless I right-click on them and open in a new tab.

Which skin is that? Using Firefox / Windows 10.

p.s. working ok in Edge (and just as fast).

cheers,

Martin.

[Tim Green]

Hi Martin,

Surely you are referring there only to the V3 Webhelp, not Webhelp generally?

I was referring to WebHelp generally. I had always assumed it never returned to the previous scroll position with the browser Back button in iFrames, but apparently it does (but not in toggles), which I find surprising, since users have been complaining for years that it doesn't work.

Your Firefox problems have something to do with the (very) new version, which seems to be badly broken. It's not just the tabs, it's pretty much everything that has to do with clicks that execute script functions. There are no errors in the console. I'll look into it, but it's basically just a broken browser at the moment.

[Martin Wynne]

Your Firefox problems have something to do with the (very) new version, which seems to be badly broken. It's not just the tabs, it's pretty much everything that has to do with clicks that execute script functions.

Hi Tim,

I'm a bit surprised to hear you say that, because my Firefox seems to be working fine on all other websites. Including executing scripts from clicks, including on my own site, e.g.

Code: Select all

 onclick="javascript:document.getElementById('video_week').style.display='block'; document.getElementById('video1').src='https://www.youtube-nocookie.com/embed/afvGStYT9xI?rel=0';"

p.s. I've been using the Back button to get back to the original link position for years. Equally surprised to hear that it doesn't work for others.

regards,

Martin.

[Tim Green]

Hi Martin,

Update on the new Firefox: It has to do with the generic click/touch event definer from the Premium Pack that is also used in Help+Manual's responsive scripts. It defines a generic event called touchstart based on the current browser's capabilities and that is failing in the new FireFox. I'll check into it.

[Dave Gehman]

Thanks, Tim. I figured the issue would require a lot of dynamic code to make happen, and understand.

[Martin Wynne]

Hi Tim,

Just tried touching the icons instead of clicking them, and they work.

cheers,

Martin.

[Tim Green]

Just tried touching the icons instead of clicking them, and they work.

Yes, the problem is only on Windows touch devices. On normal desktop browsers without touch and on iOS and Android mobile devices it's fine. Should be an easy fix.