Re: What should the user see? (Was: ANNOUNCE : HelpViewer 0.1)

[Andreas Heppel]

This should have gone to the list, too...

On 2003-01-22 17:05:21 +0100 Richard Frith-Macdonald 
<richard@brainstorm.co.uk> wrote:

> On Wednesday, January 22, 2003, at 03:42  pm, Jonathan Gapen wrote:
<snip>
> >            The context help is set by the NSHelpManager method
> > -setContextHelp:withObject:.  It's an NSAttributedString that appears in a
> > yellow rectangle with a drop shadow when the user 'help-clicks' an object,
> > and disappears upon the next click.
>
> I have nothing particular against tooltips, but I do very much dislike the
> replacement of the very good help panel context sensitive help by this
> tooltip-like help in NSHelpManager.
I think, noone wants to replace a help panel by tooltips. They are just an 
additionalpart of the help system. The problem maybe is that many ppl abuse 
them to display lots of text on the screen which is not what they are for. 
They are rather small reminders of what this particular UI elemnt was for, 
but not huge explanations on how to use the app.

> > > I'd put the main part of the help display code in NSHelpPanel, and have
> > > the helpviewer app add the capability to show/search help from
> > > multiple applications.
> >
> >            I agree.  As you said, a help panel keeps its state 
> > per-application.
> >            Using the existing API, a helpviewer app could fill up its own 
> > help
> > panel with other apps' help files (ab)using the -addSupplement:inPath:
> > method, but a more general method which could prove useful is adding a
> > method to allow apps to generate help items at run-time.
> >                                       ----
> >            Perhaps it would help (ha! ha!) in this discussion to put aside
> > issues of external apps vs. panels, DO APIs, file formats and other
> > implementation issues to focus on the question:  What should the user see?
> >            In some cases, that's pretty clear:  When using GNUstep as a
> > cross-platform compatibility layer, the user should see the native help
> > system.  That's why NeXT invented the NSHelpManager class.
>
> I think you are probably right ... NSHelpManager does seem to be a kind
> of lowest common denominator help system.  IMO NeXT lost their way when
> they decided to port to windows and began to modify the API to blend in
> with the native systems rather than to be good.
>
> >         But in a
> > native GNUstep environment, what?
>
> I know I'm repeating myself ... but I'd like a help panel  similar to the 
> NeXTstep one -
It seems that we are repeating ourselves all the time. All of us. To me it 
looks like we all kind of agree on what the help system should have:
tooltips and a help panel for both, context help and application help. The 
only question is how the help panel should be implemented, right?

> Fast, context sensitive, searchable, hypertext links, back/forward buttons,
> an index of topics, hidden when the app is inactive.  The only thing I'd 
> change really
> would be to make it support xhtml rather than just rtfd.  Perhaps it could 
> invoke an
> external viewer application to follow links to remote systems.
That's perfectly ok with me. To repeat myself one last time ;-) I would like 
this panel to have all above mentioned features, but I have no preference 
about whether the panel to be an external app or something inside the 
GNUstep libs. Whatever makes it easier to implement/use and faster to pop up 
on user's request. MAybe also a combination of both.

Cheers,
Andreas


--
Andreas Heppel

Mail: aheppel at web dot de
Home: http://www.andreasheppel.de

Check out GSburn.app - the CD burning frontend for GNUstep
http://gsburn.sourceforge.net