Links to popups inside popups - can 1st pop be persistent?

[Dave Gehman]

My company keeps finding ways to complicate the operation of a help authoring tool...

A higher-up in the company wants links, links, links.

This includes links inside popups. So far, all of our popups are definitions of terms in the help text. The links inside a given popup are to term definitions used in the first popup's definition.

For example, in the following popup text, the underlined words are all supposed to link to a popup that includes each respective word's definition:
"The World Parent is a hidden Instance of a System Design (the "World" design) that contains the definition of the Child Rule for the Root Model, including its Design. Top Level Parameters are stored here and saved when the Root Model is saved."

Testing it out, when the "World Parent" definition pops up and, while reading along, I click on "System Design", the "World Parent" definition disappears and "System Design" pops up.

Is there a way to keep both the World Parent definition popup AND the System Design definition popup visible at the same time? As it is, I have to go back and click on "World Parent" to open that term's popup again.

[Tim Green]

Hi Dave,

Is there a way to keep both the World Parent definition popup AND the System Design definition popup visible at the same time?

No. That is not possible now and will not be possible in the future either. Not ever.

[Dave Gehman]

*gulp* Asked and answered...

Looks as though I'll have to play with alternatives (such as re-creating all the definitions in a glossary topic in the main help TOC and linking to those)...

[Martin Wynne]

Is there a way to keep both the World Parent definition popup AND the System Design definition popup visible at the same time? As it is, I have to go back and click on "World Parent" to open that term's popup again.

Hi Dave,

What's wrong with the more conventional solution of using anchors to jump about between definitions on a glossary page? To go backwards you simply click the Back button in the browser.

You seem to be trying to reinvent existing wheels.

p.s. your bosses seem to have got the wrong end of the stick. The idea is that YOU tell them what they can and can't have.

cheers,

Martin.

[Dave Gehman]

What's wrong with the more conventional solution of using anchors to jump about between definitions on a glossary page? To go backwards you simply click the Back button in the browser.

My current quest began because linking to an anchor resulted in a switch to the page with the anchor, which is the behavior around that type of link... but then, in our experience in Chrome, on using the back arrow to return, the viewer returns to the top of the original page containing the link, not to the specific location of the original link. If the viewer clicked the link after scrolling well down the page, the viewer had to once again scroll well down to where the viewer left off reading the original page.

The behavior of a popup (or tooltip) enables the viewer to remain right where the reading of the main text was happening.

I'm aware that your setup behaves differently with a link to a separate glossary page, but it's the behavior we get with Chrome. It doesn't work for us.

We have a tenuous hold on our viewers because (a) they are mechanical engineers and do not have advanced reading skills, (b) the material is difficult, and (c) our technology is only now beginning to enter the mainstream, so 90% of engineering practitioners don't know a thing about it -- and we feel that any extra effort will compound a viewer's frustration to the point that that viewer may well chuck it all out.

The back-button behavior we're getting may be skin-related, but until this last December, we didn't have the expertise to find out exactly why, or the cash flow to hire freelance expertise. Right now, our new resources are 100% focused on improving the visual and informational design of our program, which is cloud-based. It will be a long time (at least until the end of next summer) before they are available to me -- 'me' in this case being a really old person who is a writer, not a coder, and who doesn't have time to learn JavaScript, JSON, or XML.

[Martin Wynne]

but then, in our experience in Chrome, on using the back arrow to return, the viewer returns to the top of the original page containing the link, not to the specific location of the original link. If the viewer clicked the link after scrolling well down the page, the viewer had to once again scroll well down to where the viewer left off reading the original page.

Hi Dave,

This question has been bugging me so much, because it is definitely NOT my experience, that I have spent some time setting up a dummy H&M project to test it.

The answer is that there is a problem in the skin you are using (I tested the Premium Pack 3.46 / V2 WebHelp+Ewriter Skins / WebHelp SlateGrey skin).

Using that skin, the browser Back button seems to work ok between pages, but NOT for anchors on the same page. After jumping to an anchor on the same page, using the browser Back button jumps to a previous page, not to the link location on the same page from which you jumped. This applies to both Firefox and Chrome (I didn't test any others). Over to Tim on that, see: https://helpman.it-authoring.com/viewto ... 074#p65074

I don't know which other skins it applies to, if any, it would take too long to test them all (edit -- see below).

However, it all works correctly if you don't use a skin.

Here is a native H&M project without a skin, created from scratch using all the defaults in a new empty project (H&M 7.4.1.4615).

I created 2 pages with several anchors and links to the same page and across the pages. Make your browser window narrow to create a long page, so you can better see the destination of the jumps. After clicking a link, use the BROWSER BACK BUTTON, and you will see that it jumps back to the clicked link every time, on the same page or the other page. Don't change pages in the TOC, because that will always go to the top of the page. Don't use the Next/Previous topic links because that does the same. Use the BROWSER BACK BUTTON. You will probably need to tell this to your users 3 times. Here is the project:

http://85a.uk/HTML/

Go slowly when testing it and make notes, otherwise you will get in a muddle, like I did.

(The actual content is just some dummy text.)
___________________

Edit -- a bit more testing.

The same problem applies to the V3 responsive skins, and also to some of the non-Premium skins (e.g. the Two-Frames Classic Skins).

But not to all of them -- for example, the Back button is working fine on same-page anchors in this non-Premium skin: Webhelp, iFrames Responsive, White-Grey, see:

http://85a.uk/skin/HTML/

and probably the other colours in the same range.

cheers,

Martin.

[Dave Gehman]

Martin -
Your experimentation and effort are much appreciated. You are a mentor among mentors.

Right now, that is, over the next 5 days, I need to push my way through what I have, since as much as I can finish (of a very problematic update) has to be finished (a) for early topics by the time the sun rises in the UK tomorrow and (b) later, advanced topics by Thursday. We have a UK training session beginning about 22 hours from now.

As soon as all this is settled, I'll be able to tackle your suggestions and follow your pointers. I had begun to wonder if our issues were skin-based. When choosing a skn, I went for "responsiveness," simple and easily customized design, and V3 skins for the latest and greatest...

It turns out that our software is impossible to use on phones, so full responsiveness is not needed. But we definitely need tablet and desktop/laptop, so we'll have to find how to develop a skin of our own (or modify an earlier,less complex H+M skin) that will work in both environments.

Again, thanks. I'm eager to begin delving into this.

Dave

[Tim Green]

Hi Martin,

The issue with going to anchors on the same page in these skins is that this is not part of the browser history at all. You can see this if you start on a page where there are one or more anchors for navigating within the page. You will start with the Next/Previous buttons blank/disabled, so you will be able to see directly whether anything is added to the normal browser history. All navigation operations within the page using anchors will leave the Next and Previous buttons unaffected. This is because browser history doesn't apply to scrolling inside block elements -- and particularly not when that scrolling is scripted, only to the scrolling of the main page in the current window. In the V3 skins the main page in the current window is the entire user interface, so you're definitely not going to get that. In the V2 skins you do have a topic window inside an iFrame, but you also have containers for the tabs inside that iFrame, and the scrolling is happening there, so you have exactly the same issue -- nothing in the browser history.

Now, theoretically it would be possible to script this so that every anchor operation pushed an event to the history object and every history.back() event popped a routine that would return to the last anchor. However, that would add a lot of overhead and since there is already a lot going on it would be a major potential source of errors and unintended consequences.

Really, the only way to get this is to use the bare-bones templates generated with every project, without using any skin at all. This applies particularly to skins like the Premium Pack V2 and V3 skins, where the content is dynamic and the HTML5 history object is used to provide a continuous URL display of where you are in the Address: bar.

[Martin Wynne]

Thanks Tim.

I understand the difficulty. But it does seem to be a drawback with these skins. There are some types of long page where the ability to jump to and fro among several anchors is definitely needed -- a glossary for example.

I can see the difficulty in using the browser's history stack, but it might not be too difficult for the page script to keep its own position history stack, and provide separate forward/back jump buttons on the page?

Given that we have a WYSIWYG editor available, it has often seemed to me that it would be useful to be able to create stand-alone HTML pages which are not part of the skin/TOC system. Which could open (and remain open) in a separate browser tab as conventional web pages. A glossary would be a classic example of that. At present we can edit html and php Baggage files at the code level, but not in WYSIWYG using the project styles, images, etc. That has to be done from scratch in some other web editor program. H&M can be used for that, but only for those able to dive into the files and extract chunks of code (unless I'm missing something?).

Really, the only way to get this is to use the bare-bones templates generated with every project, without using any skin at all.

Some of the skins do work ok, for example the Webhelp, iFrames Responsive skins, so it's not necessary to go right back to the native H&M output and lose all responsive functions.

cheers,

Martin.