----- Original Message -----
From: Francisco J Vives <vives_francisco at jpmorgan.com>
To: <Squeak at Cs.Uiuc.Edu>
Sent: Wednesday, April 14, 1999 10:12 AM
Subject: Re: Thinking about a better UI


I feel the same problem as you.
I want to navigate easily and quickly and I can't.

I've been developing a dynamic context menu for browsers.
Where the context depends on the kind of browser and the "kind" of selected
object.
In hierarchy browsers, the method and class panes have a fix contextual
menu; they are ok. But I want a similar behavior in the text part.
In a text pane, the kind of selected objects could be a method, a class,
etc.
The different occurrences of text panes are in inspectors, workspaces and
hierarchy browsers. In each of them you want some special behavior on the
selected objects.

For example, in the text pane of a hierarchy browser, if you paint (select)
a word that the user knows is a selector, a popup could let you copy,
paste, see its implementors, senders; I mean things related with the method
on that area.


I agree.  Perhaps Bob could incorporate this into his browser.  Bob?

In the same way, painting an object or a class, you open a popup, it could
let you scan the references of the class, you can browse it in a new
window, you can see what messages the class define, you can see the
different versions of a class (if you are using ENVY for example).
Painting an object in an inspector, the options presented in a menu could
be scan its referenced objects, browse its class.


Right; I've thought about similar things, many times, as have others reading
this.  I can't believe this sort of hypertextual Smalltalk environment
hasn't evolved earlier.  Bob's Browser is headed in the right direction.  We
just need to manage window proliferation by reusing common viewing panes for
the same kinds of data: classes (most recent plus a search field for new
ones), references to those classes, methods (again, most recent plus a
search field for new ones, plus a search-as-you-type for local methods),
implementors of methods, senders of methods, all instances of a specific
class taken from a user-specified scope (object or set of objects comprising
an app or subsystem).  The view for instances could also be taylored to
filter for ones whose instance variables are thus and so and fall into
specific ranges, so that you can see/confirm that a specific situation is
developing (or not) as your app runs and creates, changes, and destroys
instances.  Debugging, instead of being a separate mode, could be just
another pane:  alway there, hidden if you want, dynamic inspection running
collaterally with the app's normal surface (visual, audible) behavior.
But...at this point we're quickly running out of screen area and need to
sagittally stack some of this stuff.




The idea is to interpret the objects hidden in the text. To release the
user from the responsibility of knowing what kind of things he could do
with the object.

Exactly.



 Showing objects allows to reflect the selected object
behavior in the context of the workbench that you are using.

I didn?t implemented it in Squeak, I don?t have much time to do it. If
someone is interested in implementing it in Squeak, I?m willing to help.

I'll be in touch.  Talk to Bob Arning, too.


Best,

S