lmi
[Top][All Lists]
Advanced

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

RE: [lmi] LMI Help Proposal


From: Ericksberg, Richard
Subject: RE: [lmi] LMI Help Proposal
Date: Fri, 19 May 2006 07:54:16 -0400

On 2006-5-18 13:50 UTC, Greg Chicares wrote:

> In wxxrc terms, I believe the 'tooltip' tag is bound to this usage:
> appropriately, it's always used only for a tooltip as defined. For
> controls on a dialog, our current plan would be not to specify any
> 'tooltip' tag. I think that's a change from our original tentative
> discussions with Vadim; is it final, or might we ever revisit it?

As of now Tooltips are already working correctly. There are no controls
on dialogs that require them. Cannot foresee this requirement changing.
Final answer!

> I read "one or two word" as descriptive, not prescriptive. I don't
> think you'd object to the Print (Apple Color LW 12/660 PS) tooltip
> ms excel shows me, and I assume you don't mean to require changing
> lmi's current
>  Print case to spreadsheet
> tooltip. And if we ever want to enable tooltips on lmi's data-entry
> dialog, I imagine the control labeled
>  Experience-rating initial k factor
> would call for no fewer words than that.

Descriptive, as in typically. Not restricted to one or two. I would
argue that tooltips are generally for "untexted" controls like toolbar
buttons and that you would not have "Experience-rating initial k factor"
as a tooltip for a control that has "Experience-rating initial k factor"
as it's label right next to it. That is job for Superman (e.g F1 or
What's This?)

> Tooltips always shown.
> I think lmi currently does that; if so, are you just ratifying it?

Yes, ratifying. Already works correctly.

> My copy of ms 'internet explorer' doesn't work this way; I'm not
> sure that's necessarily wrong.

My IE works the other way (Tooltips always shown.) I wish Bill would
make up his mind.

> "What's This?" Help
> Yet I don't think you're suggesting we suppress that, right?

No. Keeping both. Intelligent choice is good.

> More detailed than a tooltip
> Again, I read that as a suggestion, not a requirement. Look at lmi's
> existing practice: wouldn't you agree that sometimes it appropriately
> doesn't follow this suggestion, while elsewhere it less appropriately
> follows it by introducing gratuitous differences that seem strained?

I don't follow what you're asking me to compare. In any event, it is
possible that sense can override convention.

> "Sorry Not Available..."
> Do we ever need such a message at all? Is it better to provide help
> text for every control just for uniformity?

Some kind response is a must. If nothing at all happens, the user will
wonder if there is a problem, most likely try again, get nothing again
and give up with the impression Help is not helpful.

Providing help text for every control for uniformity sounds like a neat
and clean way to solve the issue but could potentially create a
maintenance issue. If a large amount of controls have some common form
of "Unavailable" message, changing it would be tedious and error-prone.
Default behavior is preferred.

> Does wx provide a suitable default message already? Or does it already
> provide another behavior that we might find suitable? What do, say, ms
> applications do?

Current message is "Sorry, no context help available".

The newer MS Office (2003) applications generally invoke their new Help
"dialog box" (their words). Other applications (Access) have different
behaviors. On pull-downs, nothing happens. On other controls, you get a
yellow box with "No Help topic associated with this item."

> F1 Help
> What behavior should Ctrl-F1 or Shift-F1 have? Does wx by default
> already do something appropriate for those combination keystrokes?

None. To introduce yet another different key combination is unnecessary
and possibly confusing. Neither Ctrl-F1 nor Shift-F1 currently have any
functionality.

>> If no control has the focus, the user will be located at the top of
>> the HTML Help dialog.
>  Did you consider choosing a topic based on the active MDI child
>  ('.ill' vs. '.cns') and consciously dismiss that idea?

An active MDI child would have the focus and locate to the appropriate
HTML Help.

> Are the specified conditions for appropriateness and availability
> consonant?

The attributes of appropriateness and availability are independent of
each other. Not clear what begs the question.

> HTML Help (from the menu)
> What selections would be added?

Help|Contents only.

> The standard Contents, Index and Search navigational facilities
> ...should these be separate menuitems? Does it matter much whether
> they are or aren't?

Not necessary on the menu. The Help application has the necessary tabs
to navigate Contents, Index and Search. 


---------------------------------------------------------
This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 

---------------------------------------------------------





reply via email to

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