[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KHelpCenter Suggestions
From:       Peter Gostelow <gostelow () global ! co ! za>
Date:       2003-12-19 5:47:20
[Download RAW message or body]

On 18 December 2003 16:01, Luke Sandell wrote:
> Hi! My name is Luke Sandell, and I am an poverty-stricken undergraduate
> student in computer science. This is my first time posting on this list
> (OK, perhaps, the poverty part was a bit of an exaggeration, but still
> feel free to send me money).
>
> This post is concerned with the usefulness of KHelpCenter. To make KDE
> Help Center a little more... helpful... I have the following suggestions:
>
> 1) Ditch the Global Help Tree on the left-hand side of the help-center.
> I'm all for having a navigation tree, but it should only concern itself
> with topics in the Current Application.   Having other KDE applications
> listed (and man pages and info pages) is overwhelming to any user,
> regardless of skill level.  The only time you should see the Global Help
> Tree is when you launch KHelpCenter from the Panel.  Perhaps it could also
> still be accessible via the "Home" button in KHelpCenter.

The listing can be improved. In fact, it should add a HOW TO and Request For 
Comment (RFC) sections. The GNU system contains vasts amount of documentation 
and KHelpCenter provides a useful way to bring them all together. I often 
need to look at related help.

I would like a setting option that allows users to add search paths (for info, 
man etc.). The default/custom $INFOPATH etc. might be incomplete. If you 
disable man/info etc. then those files won't get searched and listed. Speed 
increases.

>
> Or, take another approach:  have two separate tabs - one for Global Help
> and one for Application-specific help (perhaps on the side in Konqueror
> Navigation Pane style).  When one clicks on an application inside Global
> Help, it should automatically switch to the Application-specific help tab.

The side list provides the neccessary info hiding. Rather split the list into  

+ System help 
+ KDE help
+ Application Help
+ Custom Help
+ Glossary

Where System help expands into the man, info etc. help files, for example.

With Glossary included in the same list, we can remove the tabs, which are 
considered poor GUI practice.
>
> 2) Closely related to my previous suggestion: make the tree display all
> topics available for the Current Application.  As of now (3.1.94), it
> displays only the Table of Contents.  It seems that it would be much more
> useful for it to display the hierarchy of topics that are contained in the
> Table of Contents, seeing as it is a tree.  The same with man and info.

Perhaps I'm missing something here, but this relates to incomplete 
documentation on the developers part. The left side panel provides document 
navigation only. Each document should provide its own navigation system, 
mainly through links. man and info pages probably can't do what you want and 
aren't even KDE aware.

What is, or isn't, a topic is rather subjective. I'd rather see KHelpCenter 
allow _users_ to grow their own topic lists. KDE itself and App developers 
can provide default topics, but users should be able to edit them, similar to 
the menu/bookmark systems.

>
> 3) OK, this is one of my pet peeves, but it has more to do with
> KApplication than with KHelpCenter. If there does not yet exist a handbook
> for Application X, or if that handbook is not currently installed, then
> the "Help" menu of Application X should not have a menu entry that says
> "ApplicationX Handbook."  KApplication should automatically detect this.
> Let's not deceive users by leading them to believe there is help when
> there is not.

Good point, but it should list all the apps because every app must have help 
docs. Rather, missing help docs could have the entry followed by "no help 
available" or some similar comment.

Contact the app developers and bug them, or write it yourself:)

>
> 4) Startup times: KHelpCenter would benefit from a vast speed increase if
> it itself were eliminated.  That is, make it into a KPart and have it open
> in a special instance of Konqueror (with a radically altered interface, so
> that the user doesn't even know it's Konqueror).  Seeing as Konqueror is
> usually the fastest loading application, even without preloading, due to
> caching and other optimizations.

Yes, speed improvement is a worthy goal. However, using konqueror is, imho, 
overkill. Help is a specialised task. Unless you allow help to scan the whole 
lan for docs (slowing it down further), I don't think konqueror is a good 
design solution. It may even cause security issues.

>
> 5) The Glossary has some major issues.  There needs to be a text input box
> where the user can type in a word and get possible matches in a listbox.
> Also, the alphabetical list should be just that... an alphabetical list.
> There's no need to break it down by letter.  OK maybe keep it that way, I
> don't know.  But if we just had it set up so that the user could type in a
> proposed word into a textbox, the grand list could automatically jump to
> the right spot anyway.  In sum, there should be a text entry box and two
> list boxes: one for the jumpy alphabetical list and one for substring
> matches.
>
> The other issue with the glossary is that the definition should not take
> the place of the current document.  The purpose of a glossary is to aid
> the user in understanding a word *as they read*.  Thus, we do not want to
> replace what they are reading with the definition.  It would make more
> sense to pop it up in a separate bareboned window, which the user can
> simply close when he/she/it is finished.

Again, this is up to the doc writers. The html allows tool-tips, so when you 
point on the word/term it shows a tooltip with the definition. KHelpCenter 
can scan the doc and add these to the glossary.

You can edit the docs to add your own terms, too.

>
> ***
>
> I have never developed for KDE, but if need be I can write patches to
> implement some of these features.
>
> Actually, I have a few more ambitious ideas on how to drastically improve
> the usefulness of the Help Center, so sometime after I am done getting
> condoned/flamed for this post, be looking forward to a Part 2!

The most important feature missing is a search. htDig was used for this, but 
quickly removed because users simply could not install htDig cleanly. Find a 
simple solution and make many people very happy!

To get some idea of the complexity, take a look at, for example, BibleTime for 
topic management, accessing terms, and even managing translations.

Peter

>
> Your faithful tester,
> Luke Sandell
>
> _______________________________________________
> kde-usability mailing list
> kde-usability@mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]