Jesse, I changed the subject because I think this is not specific to
your package...

It is a pity that people so often put up a package in SM and then the
package doesn't get used.

I think there is something that can make an SM entry much more
attractive, so people are likelier to try out the package, and also
makes it more likely that people will suceed in using the package, and
that most people don't do.

*Write down completely explicit instructions on how to use the package*.

And yes, I really mean *completely explicit*. For the package we're
talking about, I'd recommend the following additional text.

*******
For example, if you installed this package (with prerequisites) and you
want to learn how the Worlds menu is invoked:
* Create a EventInterceptorMorph using the "new object" option in the
world menu.
* A blue "click to arm" button should appear. Click it. Tracing has been
armed.
* Now cause the event you want to trace. Click the background to invoke
the world menu.
* The tree that results allows you to explore what methods were invoked
to process this event.

If you want to change the type of event to be used as trigger, and other
paramters, bring up the arming buttons halo, and play with the various
options in the menu.
*******

After reading something like this in the SM entry, one has no doubt that
he will begin to understand what the package does in 5 minutes, with no
annoying exploration.

BTW, I think this package would be wonderful if it displayed the time
distribution and source code as the current UI for TimeProfileBrowser
does. The fact that it uses a tree widget instread of a list is a good
thing. I think the package should also allow one to debug the event
handling process, instead of tracing it. If this is possible with the
package, I haven't found how to.

Daniel

Jesse Welton <jwelton at pacific.mps.ohio-state.edu> wrote:
> Daniel Vainsencher wrote:
> > 
> > A menu that offers some event types would be simple to program and
> > effective.
> 
> Yes, this has always been my plan.
> 
> > I think keyStroke and mouseUp are the most important, since
> > they would cover most of the conventional UI stuff.
> 
> There's alot that happens in response to mouseDown, too.  But those
> three definitely cover the vast majority of cases.
> 
> > BTW, a very accessible way to expose the UI itself is that it register
> > itself in the open menu.
> 
> Yes, once the interface is sophisticated enough to be usable when
> opened in this way, I'll definitely do that.
> 
> As for instructions, I've updated the SM entry with some of the text
> from the changeset preamble.  Does it require further explanation?
> 
> -Jesse