Re: [lmi] LMI Help Proposal

[Greg Chicares]

On 2006-5-18 13:30 UTC, Vadim Zeitlin wrote:
> On Thu, 18 May 2006 01:50:17 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> > "What's This?" Help
> GC> >     A yellow box with text that appears in the vicinity of the control.
> GC> >   How is it invoked ?
> GC> >     1) By Clicking on the "?" button [i.e. activating the "? Cursor"]
[...]
>  Note that from personal experience I'd say that more users use "?" button
> (because it's visible) than right click menu. So while I do agree that for
> advanced users the context menu is more convenient, I still think that the
> "?" should also be available and I even believe it's useful for the
> advanced users as well because it indicates that the context-sensitive help
> is available for the current window.

There are circumstances in which the '?' button provides help but
"What's This?" is unavailable, in ms applications. I hesitate to
rob others of the joy of discovering what those circumstances are.

When some user notices this, we should be able to say "it's normal,
it's right, here's why, and, BTW, look at this popular application
on the same platform that intentionally works the same way".

> GC> >     Always, whether or not the control is. If there is no useful
> GC> >     statement about a control, "What's This?" will evoke "Sorry Not
> GC> >     Available..." or something like that.
> GC> 
> GC> Do we ever need such a message at all?

There are circumstances in which clicking somewhere after clicking
'?' does nothing, and "What's This?" is unavailable. Again, this
is standard behavior on the msw platform.

>  Probably yes, it would be confusing if nothing happened when you selected
> an item from the menu.

Agreed. However, is such a message ever needed when a modal dialog
is shown? In ms excel-97, when I do
  Format | Cells
  Shift-F1
I see
  "No Help topic is associated with this item."
I wonder whether this is deliberate. Perhaps they added that message
as a matter of "defensive programming" and would regard it as a
defect that a user can ever see it.

At any rate, '?', "What's This?", and Shift-F1 have similar but not
uniformly identical behaviors, and at least some of the differences
are deliberate. I don't suggest that we adjust our design to be
"better" than generally-accepted practice. I do however think it's
important that we understand the differences so that we can explain
them to users who might perceive them as defects at first glance.
If we don't remedy such incorrect perceptions immediately, then
they tend to become immutable.

[What does F1 do if the help controller is open but not active?]
> 
>  It will just bring the existing help window in front if it's already
> active.

Okay. I think we're trying to consider a way to position the help
controller at a topic that's appropriate to the "context", which
I write in quotes because I don't clearly see how to define it. In
that case, F1 would presumably need to bring the help controller
to the top *and* display a potentially-different topic.

> GC> >   Where is it appropriate ?
> GC> >     Lower-level controls [data entry, selection etc.] same as "What's
> GC> >     This?"
> GC> >   When is it available ?
> GC> >     Always, whether or not the control is.
> GC> 
> GC> Are the specified conditions for appropriateness and availability
> GC> consonant?
> 
>  I really think it's going to be unworkable to have a separate help page
> for each control. Just how much can you say about the "Ok" button, anyhow?
> I strongly suggest that we should open the help page for the entire panel
> or dialog instead of habing per-control pages.

That approach is usually ideal. But lmi is unusual in that its
main data-entry dialog is "skinnable". Now, "skinnable" might
suggest what I think msw calls "theming", which merely changes
the generic appearance of widgets--but we actually vary the
entire contents of the dialog by switching among different
'.xrc' files, each considered to represent a different "skin".

Thus, one skin might have
  name of insured person
  name of employer
  name of insurance agent (salesperson)
all on one notebook tab (dialog), while another skin might
have the agent's name on an "agent" tab--and might not
represent an employer in any way, e.g., for an insurance
policy that is always bought by individuals outside of any
employment relationship.

If we "skin" the help files, then anything is possible, but
it could be a lot of work. If we don't, then "agent" doesn't
belong to any particular notebook tab, and offering help on
"employer" to users who never work with insurance policies
sold through an employer may seem...well, worse than odd.
We support many groups of users with very different needs,
and the union of all the features that any group needs is
too broad, because each needs a handful of arcane features
that are incomprehensible to other groups. That's why we
were led to skin the input dialog in the first place.
"Employer" is a generally-understood concept, but what
about "Experience rating initial k factor"? Skinning hides
that from the great majority of users who don't want to
know what it means--hides it on the dialog, that is; the
question we must now grapple with is what to do about that
in interactive help.