<div dir="ltr"><div dir="ltr">Hi Tim, Craig, and all,</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > It's all a bit of a mess right now and this may be a perfect excuse<br>
> > for you to improve it ;-)<br>
> <br>
>     I've come to prefer local search engines like Spotlight to both menubars and pop-up menus.<br>
<br>
I love Spotlight. Our dock search does a pretty good job of providing that within Squeak, though I'm sure we could do more (one example - I hate how it takes an exact match as a reason to open a message list on only that match instead of the list of matches).<br></blockquote><div><br></div><div>The difference being, I believe what Craig is talking about is that the *menu commands* should be part of the search.  The Search field in the DockingBar only searches for objects within the system, not menu commands.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But a counter to search-as-interface is that we don't always know a priori what is available, and a well done menu type UI can provide that info. I want both. It's kind of what I was thinking of when I mentioned expanding the menuitem search to work down menu trees (I did mention that, right?)<br>
<br>
Also, *having* to type anything is not always convenient. There's a lot of UI that simply doesn't involve keyboards.<br></blockquote><div><br></div><div><div>My dream solution addresses that counter.  For years, I've wanted the docking bar search field to be replaced with a tiny button ["?"], and make the Control+0 hot-key activate an "assistant" balloon, <u>at the hand</u>, that instantly has keyboard focus which:</div><div><br></div><div>  1) provides all the search functions of the current DockingBar search and, </div><div>  2) serves as a multi-line scratch pad for transient "notes", or quick calculations or one-line workspaces, <u>that persist across activations</u> and, now,</div><div>  3) adding in the search-engine style menu for commands that Craig refers to.  For discovery, there should be a compact button that would allow the user to expand to the full, traditional menu.  Also, the search finds any function, regardless of its menu depth.</div><div><br></div><div>The balloon should be the newer rectangular shape, not the old round comic book ones (which by their shape should be read-only).</div><div><br></div><div>"Assistant" might not be the best nomenclature, I don't care about that, the point is that it's something to minimize the transient break in one's thought (to do the search) until the search results are provided allowing the user's thought process to continue.  This UI design optimizes for that, and serves a few extra use cases besides search and activation.</div><div><br></div><div>Because we already have all the widgets, I would think it would also give a good ROI of the implementation effort.  What do you think?</div><div></div></div><div><br></div><div>Best,</div><div>  Chris</div></div></div>