On Wed, 29 Dec 1999, David Cramer wrote:

> Well, the issue of emulation fidelity is an unfortunate monkey on the 
> back of anyone authoring interactive computer application end-user 
> training. Even if you largely ignore the issue, it's probably because 
> the authoring software won't give you the control you need to do it, 
> or at least do it well/economically/quickly/whatever. Perhaps I have 
> higher hopes for MetaCard in this regard than any of your other 
> customers (which I somehow find a little hard to believe).
>
> I still would like to know what, if any, messaging is provided for 
> while a stack menu is displayed in MetaCard. I can track the mouse 
> position, for instance. But when you disrecommend a script-based 
> workaround for this "problem", are the quotes to indicate it's not a 
> problem for you? If so, it won't be a problem for me, either. I'll 
> just tell my company that MetaCard is unfortunately unsatisfactory 
> for our purposes, and we'll just have to continue to use Awfulware!

But is really a problem for *your users*?  As I said before, of the
thousands of other people using MetaCard and MetaCard applications,
none have reported it as a problem.  Possibly you're the only one that
noticed it?

> And when you say my best bet is just to wait, exactly how long should I wait?

It could be a long wait if you continue to try to get it fixed by
harping to the mailing list instead of filing a bug report.  I'm still
not sure why people continue to do this because we've publicly stated
that problems and feature requests made to mailing lists get a very
low priority, if they get looked at at all.  If you want to get the
bug fixed, your best bet is to file a bug report and hope that others
do the same (a bug's priority goes way up when multiple people report
it).  Raising a stink on the mailing list is likely to be counter
productive because it biases the reporting away from what people
really think is important...

> Basically, the most desirable situation from my point of view would 
> be that MetaCard would allow the handling of mouseUp and mouseDown 
> messages to the menu heading button *somehow* while the stack menu is 
> deployed.

The problem here is that menu behavior is automatic.  So even if you
got the messages, you wouldn't be able to do anything about it.  The
only way to allow fixing it via scripts would be to require that
people use the "pulldown" command to open a menu and then add a
"closemenu" command that would have to be called to close the menu
after a selection had been made (or if they didn't).  Pretty ugly.

> Incidentally, the 99% of Windows users probably aren't 
> aware that in Word 97, for example, clicking the menu heading button 
> closes the menu and leaves the button in the up/rollover state on 
> mouseUp, while My Computer windows do it on mouseDown. At least 
> Microsoft doesn't have a monopoly on interface consistency. I would 
> be happy to correspond further on the issues of event-handling and 
> interface feedback states. (For example, guess how many button states 
> can be found in Office 97 and Office 2000 products! Prizes may be 
> awarded for the correct answer or for any reasonable justification 
> for such byzantine interface design features.)

And even the latest version versions of some Microsoft products come
with both the new and old versions of the menus (hilite with a box vs.
filled blue).  Maybe *this* is why no one has complained: they're so
used to this kind of variety in the look and feel of applications.

> To return to the value of the feature I guess I am requesting, 
> remember that in the kind of interactive training I am developing, 
> clicking in the wrong place should result in a response or error 
> message. At this point, I can't respond to clicking on the menu 
> heading button at all. If I were designing some kind of soft skills 
> course, I could care less what MetaCard provided as long as it 
> basically worked. But with closely monitored interactive stuff, I 
> can't be so blas�. Besides, incompleteness bugs me.
> 
> Speaking of bugs, should I report this as a bug? I really consider it 
> more of a feature request, but I'd be happy to go the bug report 
> route, too.

Look and feel standard deviations *are* bugs, though of course they're
class 4s (1 is crash, 2 is data loss, 3 is significant impairment of
functionality.  The priority for fixes is also a function of how
common the problem is and whether or not there is a workaround).  But
regardless of whether you think it's a bug report or a feature
request, you're better off just sending it in to [EMAIL PROTECTED]
As long as you've taken the time to make sure that it's not already
implemented, the more information we have about the problems you face,
the better MetaCard will be at solving them.
  Regards,
    Scott

> Many regards and happy millenia to all and sundry,
> 
> David (a stickler for completeness)
> -- 
> David Cramer, Process Innovation Evangelist          87-1313 Border Street
> PBSC Computer Training Centres (an IBM company)      Winnipeg MB R3H 0X4
> Corporate Office Research & Development              Canada
> 
> This is the MetaCard mailing list.
> Archives: http://www.mail-archive.com/metacard%40lists.best.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> 

********************************************************
Scott Raney  [EMAIL PROTECTED]  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...


This is the MetaCard mailing list.
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm

Reply via email to