Browser searching suggestion

While I'm thinking of UI stuff, here's a suggestion that might be simple for a Morphite to try out -
For the class category and message protocol lists, add a 'spotlight' morph. The class category 'find class' menu entry work ok on a fast machine but is very slow on smaller machines at least in part because of building a large list and a full window in which to show them. If the top of the browser list were to be a typeable morph attached to a very lightweight drop-down list (a menu in essence) of matches for what was typed… so instead of doing

menu or cmd-f,
opening a somewhat complicated dialogue/window showing all classes,
typing the pattern,
selecting a matching one

we might have -

type into pattern field
fast, simple list displayed containing only matching entries
select choice

I'm thinking of this as both a lighter weight bit of work for the system (since the full list of all classes need not be built and formatted and displayed) and a slightly lower friction UI for the user (since the UI is right there in front of you). The same widget targeted at all messages of a class could be nice. I wonder if it might be even more effective if nothing were displayed until at least 'n' characters were entered, where 'n' is probably 2-4. Is it actually useful to see  a list of all classes containing a single typed letter? Could we sensibly link the pattern to regexp code, or at least basic matching with wildcards?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: WDS: Warp Drive, Scotty!

Tim, I assume you're using the new list-filtering feature I put in
last year?  Just give any list of classes, categories, methods, etc.
focus and then start typing.  Is there something that could be done to
improve that function that would satisfy you?

Also, have you considered setting the "alternativeBrowseIt"
preference?  Thanks to that preference, I haven't needed "find
class..." in a decade.

Whereever I'm typing or, sometimes even in the Annotation pane, I'll
type a partial-match name of any class, press Command+B and the system
quickly(?) presents a list of matching classes (substring matching).
Even better, I'm now browsing the *code* model rather than the package
model, which is a much rarer need.

HTH.

On Fri, May 24, 2013 at 4:47 PM, tim Rowledge <[hidden email]> wrote:

The cause of the slowdown is the lack of name cache in Environment.
Class, global and trait names were cached in SystemDictionary, so asking
for #classAndTraitNames was cheap.
If you try it with a 4.4 image (or any image which doesn't use
Enviroments), then you'll find that it's it about 15 times faster there,
which is probably sufficient on a slower machines.

Starting with an empty list might make the UI more responsive, but as soon
as you start typing, it will be just as slow as before.


Levente

On Fri, 24 May 2013, tim Rowledge wrote:

And this is also the reason why syntax highlighting might be too slow on a
slower machine, because #hasBindingThatBeginsWith: uses a linear search
instead of a binary search in Enviroments.


Levente

On Sat, 25 May 2013, Levente Uzonyi wrote:

On 24-05-2013, at 3:39 PM, Chris Muller <[hidden email]> wrote:

> Tim, I assume you're using the new list-filtering feature I put in
> last year?  Just give any list of classes, categories, methods, etc.
> focus and then start typing.

Nope, because I had never heard of that and there isn't anything immediately cluing me in about it. That's a common issue with UI stuff - how to make it easy to use once you know of it whilst making it easy to find when you don't. Even though a visible search field would strictly speaking add clutter, it also adds that vital affordance.

>  Is there something that could be done to
> improve that function that would satisfy you?

As a general idea for lists it's quite interesting and effective. I'm not sure the balance of when to stop adding new typing to the pattern or when to start a new pattern is worked out well enough; I found it a bit disconcerting that if I hesitated a fraction it started a new search. The background colour change as an indicator is nice.

The real problem is that the list I want to search in this scenario is one that doesn't strictly exist within the browser, so your code can't get me the answer I need.

Whilst that is very useful it still has a problem on a slow-ish machine in that it opens another browser window. This both takes time and continues to steal time later due to good ol'Morphic and it's anti-social habits. I don't recall if you said you have Pi to play with but it's always a good thing to have a 'different' machine to try stuff out on occasionally. Over the decades it's constantly surprised me how tricky is can be to make UIs work well across even a mere 2-3x speed factor, let alone 10-20x. And everyone ought to have a little experience of a notably different OS (for example RISC OS) just as a reminder that not everything can be fudged to be POSIX complaint. (sic)


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- LE ROI EST MORT. JIVE LE ROI - The King is dead.  No kidding.

On 24-05-2013, at 5:27 PM, Levente Uzonyi <[hidden email]> wrote:

> And this is also the reason why syntax highlighting might be too slow on a slower machine, because #hasBindingThatBeginsWith: uses a linear search instead of a binary search in Enviroments.

I'm running a 4.4-12550 image so I'm not at all sure what state Environments may be in. Interesting point though.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- A one-bit brain with a parity error.

On Fri, 24 May 2013, tim Rowledge wrote:

>
> On 24-05-2013, at 5:27 PM, Levente Uzonyi <[hidden email]> wrote:
>
>> And this is also the reason why syntax highlighting might be too slow on a slower machine, because #hasBindingThatBeginsWith: uses a linear search instead of a binary search in Enviroments.
>
> I'm running a 4.4-12550 image so I'm not at all sure what state Environments may be in. Interesting point though.

That is a Trunk image (4.5). 4.4 was released with version 12327.
The Environments package was added to the Trunk soon after 4.4 was
released (it was added once before, but then got removed).

Can you please try it with a 4.4 image, and tell us how it works? It's
available here: http://ftp.squeak.org/4.4/


Levente.

Thanks for the feedback!  Some (hopefully) helpful responses, below.

>> Tim, I assume you're using the new list-filtering feature I put in
>> last year?  Just give any list of classes, categories, methods, etc.
>> focus and then start typing.
>
> Nope, because I had never heard of that and there isn't anything immediately cluing me in about it. That's a common issue with UI stuff - how to make it easy to use once you know of it whilst making it easy to find when you don't. Even though a visible search field would strictly speaking add clutter, it also adds that vital affordance.

Very true.  OTOH, typing in a list is something that is pretty much
universal in Windows, Ubuntu, very early Squeak and possibly other
environments.

You can see it was handled for the World Menu was the little balloon
that tells you you can do that.  Don't know how well that would work
for a list widget that newly gets focus (perhaps the balloon could
appear just for a few seconds and then disappear.. hm..).

>>  Is there something that could be done to
>> improve that function that would satisfy you?
>
> As a general idea for lists it's quite interesting and effective. I'm not sure the balance of when to stop adding new typing to the pattern or when to start a new pattern is worked out well enough; I found it a bit disconcerting that if I hesitated a fraction it started a new search. The background colour change as an indicator is nice.

Yes, for this function it's best know all of what you want to find
before starting to type it.  Usually 3 or 4 chars is enough and
Backspace takes you back to your prior place if it was a dead end
Might be nice if the delay could be dynamically adjusted based
TextEditor's notion of the typing-speed of the last user.

One thing I do like about it is the "direct control" feel; I don't
have to explicitly enter a "find mode"; nor any need to "Escape" out
of said mode.  Instead, I can just type something and, by no more than
the brief time elapsed (probably while I was consuming the results of
my typing), it's ready once again to navigate to next destination.

Ok, I didn't know whether the delay would be avoided by virtue of
opening Hierarchy browsers instead of full PackagePane browsers.  I
don't have a Pi.