Well, I don't know if some spaces got lost concerning the illustration I added to my previous post. 
The Prev but. Up but. etc on the bottom should be placed much more to the right, situated directly 
below the help document window. Also the Contents/Glossary and Help page separation seemed to 
be gotten mangled by the bug post system. 
 
Thanks. 
Beat 

Small correction, point (4): The focus of the user is usually on the currently displayed help 
document and therefore during document navigation one has to switch focus to the right to activate 
the backward or forward buttons and then focus back to the document window. 
  
 
The focus of the user is usually on the currently displayed help document and therefore during 
document navigation one has to switch focus to the _left_ to activate the backward or forward 
buttons and then focus back to the document window. 
 
Sorry about that, 
Beat 
 
... one has to switch focus to the right... should be: ... one has to switch focus focus to the left 

It would be very much easier to comment on these if you filed them separately. 
 
In any case: 
 
1, pressing space in the page navigates to the end, then follows the 'next' link.  Most of the 
pages are fairly short, leaving the beginning or end of them not so far away if you want to use 
the mouse, and they're certainly never more than a 'Home' or 'End' key away.  If we get the 
accesskeys support in Konqueror, there are keybindings built in to the documents already to 
immediately go to the 'Next' or 'Previous' links.   
Implementing things as you suggest seems at first glance to require frames (virtually 
impossible, will never happen) or implementing the entire back/forward setup in the app 
rather than in the document.  That would leave the documents unsuitable for use on websites 
- to keep that functionality would require maintaining twice as many stylesheets as now. 
Much work for little gain, IMO.  
 
2, This one is a possibility.  It's been considered before.  The main problem is that icons small 
enough to fit sensibly in the default layout look terrible when users increase and decrease 
their fonts, and finding a set of icons that looks ok against any background is also difficult. 
 
3, Web users seem to have no trouble with the concept 'Home' within a website returning 
them to the 'front page' of that website.  There's never been a single complaint from a user 
that it confused them (unless it confused you, in which case, the count is '1') There are also 
implementation difficulties (the generated text comes from files not maintained by KDE, they 
are external.)  I'm tempted to leave this alone too.   
 
4, While I can see some benefit in such a layout, it would be wildly against all KDE Style 
Guidelines, and inconsistent with every other KDE application.  I can't see this happening 
either. 
 
Summary, I'd say it's WONTFIX, maybe, WONTFIX and WONTFIX respectively from me.  
Leaving this unclosed for the benefit of the 'maybe' one. 

First of all, it's IMHO perfectly okay to have this file as a single bug report.

Regarding the issues which were pointed out:

1.) I think the idea of having dedicated navigation elements is nice. The 
problem I can see is that the HTML pages generated from the DocBook files are 
used in multiple places - in KHelpCenter, and on docs.kde.org for instance. 
Now, on docs.kde.org you want links at the top and at the bottom as they are I 
think, since you do not have a real user interface. In KHelpCenter, you don'T 
want these navigation elements in the main HTML view. That means we would have 
to use different stylesheets, which might be a maintenance problem (since I 
personally have only limited knowledge on CSS stylesheets, but I bet there are 
many people who can do that).
The other approach would be to put the dedicated navigation interface directly 
into the HTML manual, but keeping it permanently visible by using HTML frames. 
A problem with this which might come up (I don't know yet, I did not actually 
try this, just brainstorming) is that you need some tricky JavaScript or such 
to keep the navigation bar always in sync with what's visible in the main view 
showing the document (for example, on the first page there shouldn't be 
a "Prev" link).

2.) Is nice, I like it and I do not think that will be a big problem. I cannot 
think of any other issues as those pointed out by Lauri right now, and those 
are not big problems.

3.) Right now, I doubt that is going to happen. Cornelius, what do you think 
about this? The problem is that it's very "non-standard" (read: not styleguide-
compilant) to have toolbar buttons not aligned at the left side. Or did I just 
misunderstand you, and you have something else in mind?

4.) That sounds similar to 3) somehow, you mean having the History toolbar 
buttons somewhere else, no? That would be a styleguide problem as well I think 
but I'm not entirely sure. And I cannot find screenshots of OpenOffice's help 
system right now, but I will look.

Ok, on number 3 again:  
 
It seems to me that the Home icon on the toolbar is more or less pointless at the present.  It would be 
easier and more consistent to change the icon to do the same as 'Home' in the document, that is, go to 
the first page of the currently open document.  The location it currently goes to is the default help center 
page, which is still available in the left hand menu pane. 

1.) We could implement that by adding a box with additional navigation widgets  
below the HTML view which is shown when a docbook document is displayed. This  
would have to be interfaced with the HTML navigation somehow, but I think that  
would be possible. The HTML links in the document would still be there, so no  
different style sheet would be needed.  
  
2.) If we have separate widgets for navigation we can add icons there.  
  
3.) If we don't have the style sheets under control which generate the navigation 
links, I would just leave it as it is. The "Home" action in the toolbar is useful when a 
special start/overview page is configured for khelpcenter. Showing the default help 
center page doesn't make too much sense, that's true. In the future I would like to 
show an automatically generated overview of the top categories (and maybe also 
one or even more levels below) as "home" page. 
 
4.) We could put the icons in a separate toolbar, so that the user can arrange it  
independently, but this still will not allow to align the toolbar with the right frame.  
The only real solution would be to move the controls from the toolbar to an own  
widget above the HTML view. I' not sure that this would be an improvement as it  
wouldn't be very consistent with other KDE programs.  
  

>  1, pressing space in the page navigates to the end, then follows the 'next' link. Most of the  
>  pages are fairly short, leaving the beginning or end of them not so far away if you want to use  
>  the mouse, and they're certainly never more than a 'Home' or 'End' key away. If we get the  
>  accesskeys support in Konqueror, there are keybindings built in to the documents already to  
>  immediately go to the 'Next' or 'Previous' links. 
Well, I think that keybindings that allow for faster navigation is a plus, however, I guess that the 
minority of users (1) knows about them, (2) is willing to find about them and learn them by heart 
and (3), for certain tasks like navigation, I guess that pure mousing action should be given priority. 
Most people are uses to browsers (e.g. browsing the internet) without using keybindings. 
 
But of course I understand that the help pages are already in a given format and used elsewhere 
too. With regard to point 1), I very much like the idea of Cornelius about adding a box with 
additional navigation widgets interfaced with the HTML navigation ,without needing a different style 
sheet. 
 
Point 4), I understand also concerns about the consistency with other KDE programs. And I agree 
also that embedding the navigation controls in a standard toolbar might not lead to a satisfying 
result. Finally, I see also own widgets above the HTML view as a promising solution. 
 
Thanks for all the comments on my report! 
Beat 
 

Regarding 3.), the misleading Home button - how about opening 
KHelpCenter with a given manual (which is what happens when you select 
Help->Manual in any KDE application) makes pressing the Home button 
bring up the table of contents for the application KHelpCenter was started 
with? 
 
To me, "Home" means "Point of origin" in this respect and right now the 
Home button only does what I expect when I start KHelpCenter without any 
arguments, so that it show the "Welcome to KDE" page. When KHelpCenter 
gets started, showing an application's manual though, I would say pressing 
Home should give me the table of contents for the application's manual, 
since that table of contents seems to be the "Point of origin" to me. 
 

regarding (1): the help documents already contain the LINK information,
e.g. http://docs.kde.org/en/3.1/kdebase/konqueror/tabbrowse.html
<link rel="home" href="index.html" title="The Konqueror Handbook">
<link rel="up" href="browser.html" title="Chapter 4. Konqueror the Web Browser">
<link rel="previous" href="surf.html" title="Surfing and Searching">
<link rel="next" href="enhanced-browsing.html" title="Web Shortcuts">

unfortunately khtml doesnt support the link tag yet (bug 58689)

With KDE 3.2.2, the KDE helpcenter still lacks improved navigation support.
Thanks for your hard work!
Beat