#What should HELP do?
27 messages in this thread
Don,
Then we have absolutely no common ground for discussion. What I am proposing
is something I have seen, and liked a lot, so much so that I rave about it, in
spite of the fact that it is on a machine I don;t care for in almost all other
respects.
If most Amiga users feel the way you do about it, there isn't much sense in
changing the way it's done right now.
-larry
Both you and Don seem to agree that context sensitive help is desirable. The
issue you part on is how to determine context. It's certainly tough when you
have a) two primary input devices, the mouse and keyboard, and b) multiple
programs running on the same screen.
Any scheme you come up with is necessarily frought with compromises[sp?]. While
I agree the Help key should have system wide meaning I come down more on Don's
side of context detection. What is the probability the user will want help on
something he or she isn't currently using (i.e. not the active window)? Low
enough, I think.
System help for sizing gadgets, scroll bars, etc. is too trivial to warrant
storage space, IMHO.
Menu Help? How about a pointer in the HELP IDCMP message to another message,
in this case MENUPICK? Replying to the HELP message would also constitute a
reply to the linked message(s). — Art
Art,
I think it is entirely up to the user as to what he wants help with, whether
in or out of the particular application he is interacting with. The 'mouse
pointer' context solution is a far more general solution, and allows for many
special cases.
As an example, you might have a program that monitors its active/inactive
window state, and changes behaviour in the two states. Clicking to activate
another application may or may not be appropriate at the time. It really is a
matter of allowing for the most flexibility, and for future flexibility.
I would like to see, as part of this HELP thing, the ability to place the
mouse pointer over an icon for an application and to get a description of the
purpose and use of the program or data file, to whatever degree the author saw
fit to document it via this facility.
As for HELP for scroll bars, sizing gadgets, and so on, I vehemently disagree
with the thought that they are too trivial to warrant storage space. Consider
the novice as well as the pro. How much easier it is for the novice to remember
one simple rule: Place the mouse pointer over anything, hit the HELP key, and
get more information. Granted, the novice would not get help for the system
gadgets for long, but the mindset created by the facility, and the degree of
comfort provided by it, would go far in alleviating the sense of being lost,
especially if most application programmers took advantage of an easy to
implement HELP feature.
Don seems to want a single generic help file, with perhaps menus to select
the appropriate topic. Note that this _can_ be done under either scheme, but
that under his scheme, there is no provision for getting help more directly,
more visually, and more quickly.
-larry
Art:
Now maybe I am the only idiot on the forum that brings up a program to modify
data and then does not remember everything that I need to know about the
program that I am modifying the data FOR. If so then I suppose this is a
wasted discussion but I really believe that having the help key respond to the
location of the mouse pointer regardless of active status is far more
'intuitive' than have a window selected when it is pushed into the background
using the back gadget. As to confusion, I recommend that the help function
alway indicate the program/function.
=>73<=, bill (KB7LX)
Larry,
While I see Don's point, and agree with it to a degree, there IS a reason
for changing the way it's done right now. I don't know of any programs now
that will give context sensitive help dependent upon mouse position (that
doesn't mean none exist, I just don't know about them). By not supporting the
Help key as you propose, things will remain as they are. How many applications
offer context sensitive help now? How many would if the Help key were a system
function? I'd say almost all — if from competitive pressure alone or from
user pressure (what's this? No help? An incomplete program, I wonder what
else is missing — maybe I should look for spelling errors too <grin>).
-sja
Steve,
My sentiments exactly. While I cherish and fight to protect the flexibility
of the Amiga as compared with other systems, I do see the value in maintaining
consistency with the implementation of built-in functions, especially if they
can be made to be user definable/replacable, and easily implemented by the
programmer.
I agree fully that pressure by the customers would virtually ensure that
virtually all commercial programs would offer some degree of context sensitive
help, were the facility to exist.
Of course I would definitely caution the help file authors to carefully check
their spelling. 🙂
-larry
How do you offer contex-sensitive help in a compiler environment? Aside from
help on the editor's functions, I don't see much else. Maybe also the
possiblity to get extensive descriptions of all compiler errors with examples
of code that can cause an error.
Martin,
Perhaps you don't offer context sensitive help with such things as compilers.
You can, however, offer a menu driven, generic help for virtually all programs.
While context sensitive help, driven by the position of the mouse is not
necessarily useful for all applications, there is nothing in what I propose to
stop anyone from writing any sort of help file they see fit.
-larry
No, I wasn't commenting that you can't do context sensitive help for a
compiler. It was an honest question: "What help *can* I offer?" That's one of
the features I'd like to add for the next release.
Martin,
That's a good question. Perhaps a menu with selections for compiler, editor,
linker, etc., with subheadings under those for the various options and so on.
-larry
Larry,
What you're looking for is a form of HyperText…hit the button and
expand the subject.
I believe in hand-holding, but only to a degree, beyond that, the
manual, instruction or a different program is what's needed. I believe that a
good manual, with a proper tutorial along with general help in the program (and
that can also point to specific pages in the manual) is far better than
essentialy coding the manual into the program.
I really hope you're not saying that either the system ROM, or the
program should contain text such as "To select a menu item, press the left
mouse button, move the mouse to the menu bar and proper dropdown menu and then
release the mouse button. For multiple selects, follow the above but instead
of releasing the right mouse button, press the left mouse button for each item
you'd like to select."
Don
Don,
The hypertextual aspects of what I am proposing are definitely a detail, and
not an essential part of the implementation, nice though it may be.
One need not provide a full hypertext implementation in order to link a
generic help file with more specific help files, or to link a quick hint with a
more specific explanation.
I find your use of the term 'hand-holding' to be interesting. I see HELP as
an online reference, not necessarily as a substitute for a manual. It is
entirely up to the author of an application as to how much detail should be in
a help file as supplied with the program, under the current, or under my
proposed scheme. I would hope that the help files provided would be extensible
_by the user_, so that he can put his own notes in there should he desire. I
also feel that should the user decide he doesn't need help, or doesn't want to
use the disk or memory space for it, that it could be completely disabled, or
only those help files he has need of could be placed in the appropriate
directory.
I am definitely not saying that the help text should be in system ROM. It
should always be in the same place as any other help text, probably an assigned
logical directory is the best place. I mean how much would it add to the system
cost to provide an extra floppy? Given a format for help files that is easy to
edit, a user could modify them to say whatever they wanted them to say. Help
files for new users might look very different from those for advanced users,
your HELP: directory might contain very different files than mine.
The important thing, in my opinion, is to provide a system-wide facility to
allow the easy implementation of any sort of help a programmer cares to
provide, while allowing the maximum flexibility for the user to configure their
help files.
-larry
Implementing a HyperText reader is trivial. The hard part is the tool to create
the HyperText document.
Perhaps that's true Martin, but as I pointed out in another message, all that
is really needed in a HELP scheme is that help files be available, and that
anything that provides a linkage between documents is gravy. Simple links are
all that are required to make things very nice indeed, and thos can be provided
by straight ASCII text files using a few special commands (a la the old style
dot-commands in word processors). Creating a document is fairly trivial for
this example.
-larry
I agree, in this particular case, it is trivial. The scope of the database is
restricted to programming stuff, and it doesn't have to provide multiple links
and backtracing, etc…
Larry,
Just the logic alone would take up about 20K of code, and that would
have to be in the program itself…and thus not removeable by the user to save
space or memory.
It's not as simple as:
if last_key was equal to HELP
which screen am I on
which window am I in
where am I on window
open text file
if no text file
display generic help
else
look for context item in text file
display text file item
close text file
end
(continued…)
(continuation…)
what you're saying is:
SYSTEM:
if last key was help
save system state
stop current task
locate mouse
activate mouse screen/window
send message to now active program
PROGRAM:
get system message
stop current processing
locate object mouse is on
open text file
<as original example>
signal system "done"
resume processing
SYSTEM:
restore old active screen/window
restart old current task
re-set system state
end
When I say stop and restart the current task, I'm not saying stop all
processing for that task, just 'pull' the input from it for the time
being…the task itself can continue to run as long as it doesn't require user
input. However, the task I call PROGRAM would have to stop it's current
operation and then handle the HELP operation.
continued…
Continuation…
None of that is 'cheap' code, nor is it necessairly efficient, and most
of all…I don't think it's what the average user wants. In my experience,
what the users want is a 'quick reference card' with the heavy details left to
the manual.
We just went thru this at work, the system provides us with the ability
to add a help message for each field on the screen the user can get to. We
asked the users what they wanted in the help fields (that get displayed if you
hit the HELP key) and without exception, they wanted nothing there. They
didn't want context sensitive help, they were able to figure out if the field
was labeled "Street: ____________" then the name of the street went into that
field. What they did want was a quick reference card form of help for the
F-Keys and special keystrokes (ESC + key).
We had to put something into the help string for each field to prevent
the system from putting up a nonsense help screen for each field (the system
would display field characteristics such as CHAR data type, 4 wide and Database
table and column name). The few users that looked at the field level help
thought it was silly and a waste of time.
Don
Don,
Well, I have to disagree with your assesment of what I'm saying, as well as
your assesment of what has to happen when the HELP key is depressed.
First of all, why do you have to save system sate, stop current task, locate
mouse, etc.? The system does the processing for all input events now. When a
key is depressed, it does what is necessary to analyze what it needs to do with
the event, whether it be a mouse click or a keypress. The logic is built-in for
that, and all that need be done is to decide if it should send the resultant
message to the help-handler directly or to an application, or perhaps to
completely ignore it, if the user has turned off that particular feature
(reverting to making the HELP key a normal keypress, as it is now).
Yes, the program must be activated, but only if it is in a Wait(). There is
no need to activate any windows the application has up. After all, the program
is not inactive just because its window is inactive.
The application, if it is Wait()ing, and has that mask set up, certainly
would not mind receiving the event, or it wouldn't have flagged it as a
condition of awakening. If it is not waiting, but is processing, the event is
no different than any other event that the user might send, and I'm sure you
can visualize ways for a program to check for events during processing.
Basically, it's up to the programmer to decide whether he wants to implement
help. It would certainly be a lot cheaper in terms of programmer effort to
implement it if the facility were provided by the system.
Continued…
Continued…
Under 'PROGRAM', you have listed a few steps that show me that you have not
read the messages wherein I proposed how HELp was handled from an application
point of view. Yes, it would have to determine which object the mouse was on,
which could be easily enough done, considering that gadgets, requesters, and so
on are system supported already.
The application, however, need not open a file. The application would decide
what help filke was appropriate, and would send that information to the
help-handler, whose sole job would be to determine if that file exists, and to
present the data if it does, or to put up an indication that no help is
available for that selection.
'signal system "done"? "resume processing"? No… it is done when it replies
(or perhaps better, when the help-handler replies to the input event).
Back to the system…. no need to restore active state to any window or
screen, since there was no need to inactivate it in the first place. Restart
old current task? That happened as soon as the HELP message was sent, either to
an application or to the help-handler.
'Pulling input' in the context of 'active window gets the input' is not
germaine to the discussion if we are to consider the HELP key to be a special
key, and not part of the set of keys that sends an ASCII code in the normal
manner of input.
Cont….
Continued…
In your paragraph on 'who would want it', you sound like Steve Jobs. You tell
us that your users don't want it, and judging from the implementation you
describe, it isn't surprising at all. In the first place, it is obviously an
application oriented help, and not a system-wide one. In the second place, it
sounds like it is not optional, cannot be disabled, and provides too much help
for obvious things.
I can assure you that there are thousands of folks who would welcome a HELP
facility for many programs. I doubt many of them would ask for help with a
field that you describe, but if they wanted it, why pull a 'Jobs' on them by
denying them that wish, just because _you_ prefer a generic help facility,
application oriented, for the particular types of programs you use the most?
Again I am fascinated by opposition to an idea that will help many, and is
not mandatory for anyone. Don't want HELP? Turn it off. The help-handler will
never get loaded, and you can look things up in manuals to your hearts content.
-larry
Larry,
I've got two windows open, one a text editor, the other a ray tracing
program. I'm working on the text editor, but the mouse is in the ray tracing
window. I hit the help key.
The system gets awakened, says, "Ah ha…he's hit the help key, let's
find out where his mouse is…why it's in the inactive window!"
Whether it goes thru a help handler, or the program…it's got to
attempt to open the text file…if for no other reason than to see that one
exists. It also has to activate the ray tracing window so that it can now
receive my key/mouse events. It has to withhold those events from the text
editing window. So far, not much different than if I had clicked on the mouse
and made the ray tracing window active.
But now, the ray tracing window has to stop it's calculations and/or
spawn a new task to handle my request for help. The window has to be brought
to the front so I find the object I want help with. Since that object was
hidden originaly, I'm left with generic help. If I exit that, the system would
either revert to what I was doing (restore state) or would leave the ray
tracing window to the front…so I could get help with what I really wanted in
he first place…but was hidden.
Either event is absurd to me….if I wanted help with the ray tracing
window…I should have brought it to the front in the first place, thus
eliminating the need for the system to handle swapping windows. If the system,
after giving help on the first event (mouse just sitting on window)…then I
could get help on the ray tracing gadgets anyway because as soon as I quit the
generic help…I'd be popped back into the text editor.
I don't have a major problem with context sensitive help, althou I
don't see the need for it for myself, but I do have a major problem with the
help key being tied to anything other than the current window. continued…
continuation….
If the mouse is outside the current window…you get generic help with
the program in the current window. If the mouse is on an object in the current
window…fine, if you want…give them context sensitive help with that.
If you've got a stack of reports on your desk and are working on
them…where is the report you're working on? I ceratinly hope it's on top
where you can see what you're doing. If you suddenly decide you want help on a
report in the middle…don't you think you should at least pull that report out
and put it on top so you can see what you're doing?
If you're in an office taking to Joe, and suddenly want to talk to
Bill…do you yell across the room, or do you go over to Bill's workspace and
talk to him?
I realize that the above aren't exact examples, because I know of no
exact examples of mouse position vs keyboard key similarities in real
life…but the above are close.
Don
Gee, Don, we agree! Think it's the altitude? 🙂
…BobR
Bob,
It must be the altitude. 🙂
– Dave (another Denverite)
Bob,
Either that or the snow yesterday!
Don
Larry,
Do you realize that all we're arguing about is a simple mouse click?
Both of us have 2 programs running…A is the active window, B is the
inactive window. We both want help with program B.
your method….you must move the mouse to program B's window
my method…I must move the mouse to program B's window
your method…hit help key
my method…hit mouse button and then help key.
Second scenario…same as above, but both of us have moved the mouse
out of the current window for one reason or another; however, we now want help
with Program A.
your method…move mouse back into program A's window
my method…do nothing
your method…hit help key
my method…hit help key
Third scenario…novice user is comparing two word processors. He has
word processor A active, word processor B inactive. The mouse is outside the
active window for whatever reason…novice user wants help with his current
program. User sees help key and hits it:
your method…help for word processor B pops up giving user wrong
generic help
my method…help for word processor A pops up giving user help for
program he's running.
You require me to make sure the mouse is properly positioned every time
I want help…current window or not. I don't. Under my method, the only time
I have to move the mouse is if I want help with the inactive window (and in
that case…you also require me to move the mouse to the inactive window). I
think we both agree that wanting help with the inactive window is going to
comprise the vast minority of instances.
My method is consistent with the current interface, keyboard strokes go
to the active window…your method makes keystrokes go to the current mouse
position, which is inconsistent with everything else. You say we should forget
the physical position of the help key…pretend it's really a special key on
the mouse. I say pretending is not reality.
Don