Better node pages

Nothing is perfect! This is where you can post your ideas and wishes for functions you'd like to see in Help & Manual. Current version only please (H&M7).

Moderators: Alexander Halser, Tim Green

Post Reply
hmotulsky
Posts: 33
Joined: Tue Oct 21, 2003 2:10 am
Contact:

Better node pages

Unread post by hmotulsky »

I define a "node page" as a topic in the navigator that has subtopics. A folder name, essentially. I've been using H and M happily for over a decade, but the handling of node pages is a continual annoyance.

Now, H and M offers two ways to handle node pages. [I compile to the web, so that is what my comments below pertain to.]

1. Manual. The H and M user can include whatever they want. This requires lots of fussing with node pages. We can copy the subtopics in the navigator and paste into the node page to create a list of links. But two problems with this: A. The links are correct at the time of pasting, but won't update if the subtopic titles are later edited or new subtopics are added. B. If there are sub-sub-topics, all are pasted with no indenting. So it takes manual fussing to make it look nice (either get rid of the subsubtopics, or indent them).

2. No node page. But this is implemented in a strange way, I think. If the end user clicks on the node page in the navigator, that node page (folder name) is highlighted in the navigator, but the prior page remains in the main part of the window. So the highlighted item in the navigator does not correspond to the page you see. One use of the navigator is to see where you are, but in this case the navigator provides incorrect information.

I'd like two more options:

3. Automatic. Base on a template that the user can configure. The default would be the topic title and the list of first level subtopics as links. This list of links would be regenerated when the help is recompiled Set this choice once, and never have to think about node pages again!

4A. A better no node page design. If the end user clicks on the node page in the navigator, open that folder (if it is not already open) and move the highlight to the first item within. If that is a folder, open it and move highlight to the first item.. So the first actual page (not a node page) is selected in the navigator, and that is the page that is seen in the main part of the window. [I would pick this, as node pages seem way more trouble than they are worth, but the current "no node page" design is too confusing for the end user.]

4B. (If 4A is not doable, this should be easy.) When the end user clicks on a folder name, expand that folder (or close it if it is open). Leave the highlight in the navigator where it was and leave the visible page as it is. No mismatch. Basically clicking on a folder name is the same as clicking on the + in front of the folder name. It opens the folder but doesn't navigate anywhere.
Harvey Motulsky
Tobias Escher
Posts: 202
Joined: Mon Dec 28, 2015 7:32 pm

Re: Better node pages

Unread post by Tobias Escher »

Just adding my voice to this.
I also compile extensively for web, so some auto-generating overview page would be perfect.
User avatar
Tim Green
Site Admin
Posts: 23157
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Better node pages

Unread post by Tim Green »

Hi Harvey,

Thanks for your detailed comments on this. First let me respond on the subject of "empty nodes":
If the end user clicks on the node page in the navigator, open that folder (if it is not already open) and move the highlight to the first item within.
This is already available. That is exactly how I have implemented it in the new V3 Responsive skins in Premium Pack 3. If you click on an empty node (a "chapter without text" in Help & Manual parlance) the chapter will open and the first genuine topic with its own content in the chapter will be opened and highlighted.

On the subject of link lists for the sub-topics and chapters inside the node:

That is much trickier than you might imagine at first, because we would need to plan ahead and cater to all possible wishes for such a feature. You know exactly what you want here, but there will be a large number of other authors who, in the words of Monty Python, will want something completely different. For example, how deep should the link list go if the chapter contains additional sub-chapters? You might say that it should obviously only be the current level. Other authors will be equally adamant that it should include all levels, or just two levels, or just three. So then you have to provide configuration options for that, and already you have the monsters of complexity and featuritis raising their shaggy heads.

And what about the formatting? This would also require a complex configuration tool comparable to the heading configuration options in Manual Designer for PDF layout, with different formatting, spacing and indenting options for all the different levels. I'm not saying that it's impossible or something we wouldn't do, but it is very difficult to do in a way that makes it accessible and un-confusing.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Post Reply