lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [lmi] LMI Help Proposal


From: Vadim Zeitlin
Subject: Re[2]: [lmi] LMI Help Proposal
Date: Thu, 18 May 2006 15:30:56 +0200

On Thu, 18 May 2006 01:50:17 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2006-5-17 17:36 UTC, Ericksberg, Richard wrote:
GC> > Tooltip
GC> >     A little yellow box with text appearing over the control.
GC> [which presents]
GC> >     A brief [one or two word] explanation of "what" the control is
GC> >    [e.g. Cut, Copy, Paste.]
GC> [and which we plan to use only for]
GC> >     High-level controls [navigational] such as main window toolbar
GC> >     buttons that usually only have a picture.
GC> 
GC> In wxxrc terms, I believe the 'tooltip' tag is bound to this usage:
GC> appropriately, it's always used only for a tooltip as defined. For
GC> controls on a dialog, our current plan would be not to specify any
GC> 'tooltip' tag. I think that's a change from our original tentative
GC> discussions with Vadim; is it final, or might we ever revisit it?

 I realize that I misread/misunderstood the original proposal. I've just
seen that it called for using tooltips with the toolbar buttons (which is
already the case) but didn't realize that it seemed to exclude the tooltips
for all the other controls while I believe it could still be useful to have
tooltips in some situations. But, anyhow, who can do more, can do less so
if we decide not to use tooltips for any controls, there is still nothing
to do to allow it (except stopping working on some pending tooltip patches).

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"]
GC> >        and then clicking the control [not preferred - shifts user's
GC> >        focus away from the control in question.]
GC> 
GC> Yet I don't think you're suggesting we suppress that, right? Is it
GC> harmful to offer that for users who, however perverse it may seem,
GC> prefer it to "What's This?"?

 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.

GC> I think you're saying that
GC> 
GC>  - in the problem domain, there are a couple ways of doing this,
GC>    and you find good reason to prefer one and would like to make
GC>    sure it's available; yet
GC> 
GC>  - in the solution domain, both ways are probably already available,
GC>    and it might even require extra work to inhibit one;
GC> 
GC> and therefore solution-domain workers should be sure to implement
GC> the second, preferred way, while also implementing the first if
GC> it's essentially gratis, and certainly not inhibiting it if to
GC> do so would be costly.

 This is my interpretation as well (but also see the proposal in my message
about text control "What's this" help), please let me know if it's wrong.

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?

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

GC> Is it better to provide help text for every control just for
GC> uniformity?

 I think it is.

GC> Does wx provide a suitable default message already?

 No.

GC> Or does it already provide another behavior that we might find
GC> suitable?

 No.

GC> What do, say, ms applications do? I'm pretty sure they'll never say
GC> "Sorry"--they'll express facts instead of emotions.

 Which is a good thing, too... In fact MS applications do have help for all
controls (if they have context-sensitive help at all) AFAICS. And this
should certainly be the goal, "Sorry" is just a (hopefully never used)
fallback.

GC> > F1 Help
GC> >   How is it invoked ?
GC> >     By pressing F1 for any control that has the focus.
GC> 
GC> What behavior should Ctrl-F1 or Shift-F1 have? Does wx by default
GC> already do something appropriate for those combination keystrokes?

 No, it doesn't but, as I said in my previous reply, I think we might.

GC> >     Launches HTML Help
GC> 
GC> Launches wxBestHelpController, as we've already discussed off this
GC> mailing list.

 Ok, thanks for confirming this.

GC> > [if not already active.]

 It will just bring the existing help window in front if it's already
active.

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.

GC> >   How is it invoked ?
GC> >     1) By clicking the desired selection within the Help menu.
GC> 
GC> What selections would be added? For instance...
GC> 
GC> >     The standard Contents, Index and Search navigational facilities
GC> 
GC> ...should these be separate menuitems? Does it matter much
GC> whether they are or aren't?

 FWIW, the "Contents" and "Search" items already exist (in the patch).
"Index" should be added as soon as we have an index in the help file.

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]