Workflow Improvements - "Searcher" feedback

Look like this is really helpfull! do it!

 

All in favour, that looks great!

Could you perhaps coordinate some tech with the Quick Search team? All the features there, like better text matching, prefixes to specify where to search, settings for how the thing behaves, would be great to have in all the searches we do in Unity.

 

That looks great!

I really hope you will implement fuzzy search (maybe you did already, but it's not shown in the video). I often open files in VSCode like this:



Then I switch to Unity and try to do the same in "Add component" menu. Alas...

One other rarely used place comes to mind - adding scripts in Project Settings -> Script execution order. The ability to choose a script from a dropdown is effectively useless, because it can't be scrolled with a mouse wheel. Other dropdowns (like public enum fields) suffer from the same problem.

 

@Cardinal90 That's what the QuickSearch package provides right now. That's what @Baste was talking about.

In this video it looks like every right click menu got replaced by this popup. Maybe it doens't make sense to have it open for just up to 5 total items as it would take longer to type than clicking on it directly.

The create menu is definitely a keeper, too many hours wasted searching.

 

I'd prefer if the fuzzy search weren't quite so fuzzy. The examples you've included here are actually frustrating to me, as that feels too inclusive to actually be useful. I like fuzzy search where the letters entered map to the first letters in a camel-cased class name. Like typing "FPCC" and having that show "FirstPersonCharacterController". So, I support the concept, as long as it's not too inclusive.

For an example of what not to emulate, take a look at this abomination of a fuzzy search I get to see every time I try to find my "changelog" in Visual Studio



As for @willgoldstone's question of where this should be prioritized, I'm not sure the following are used enough to qualify, but extremely long dropdowns are good candidates. For example, the dropdown for picking scripts in the Script Execution Order window is incredibly long, and moving through it is very slow.

 

I love this and I want it to protect me

 

I think that this should probably really just fully replace the old GenericMenu basically everywhere. One search bar doesn't add that much clutter, it can allow for faster user input even when there are only a couple of options, and it would be more consistent than having very different looking menus pop up everywhere depending on the context.

The only place I can think of offhand where using the Searcher might feel a bit weird would be with the main menu (top-most toolbar in the editor). You kind of just expect this to have a certain type of look due to how it works across all software. But even here the search functionality itself could actually be useful in some cases (say if you have a hundred menu items nested under Tools).

I guess one could also do what Windows 10 has done with the start menu, and hide the search box and only have it show up if letters are pressed on the keyboard. It's kind of weird when there's no visual indicator for the search box at all, not even a small icon, but it does get rid of the visual overhead when you don't need the search box. Something like this could be worth considering for things like enum popups and such where sometimes there are only two or three entries and sometimes dozens.

I'm not sure if like the fact that search results are shown with their full path as the main visual element. In the rig import settings example of the video you can't initially see the most meaningful part of any of the search results at all, because the long category paths ("Reference/Hips/...") occupy almost all of the space.

With the Add Component menu in particular I much prefer that the name of the class is shown as the main element, instead of being preceded by the full namespace. I just find that this improves at-a-glance readability a lot.

I do like the general approach of how Visual Studio / VSCode display the full paths in the pictures posted above, as auxiliary text with a smaller font and grayer coloring. That way this additional information is still accessible in the rare cases where you need it, but the name of the element is still clearly the dominant GUI element so you don't need to do a lot of scanning with your eyes to find it.

Also I just don't really like horizontal scrollbars at all. They are clunky to scroll both with the keyboard arrow keys and the mousewheel (and not all mouses even have this functionality), and I don't like the fact that you need use the mouse cursor to drag things things around. This is much slower than just typing some letters and hitting return. If the item name doesn't fit fully inside the confines of the search box, I would prefer it if the search box widened dynamically when possible. With auxiliary text it could perhaps just be cut off and displayed in full in a popup on mouseover or when an item is selected with the keyboard.


As for fuzzy searching, the best example I have seen is Launchy. It remembers what choice you've made in the past and prioritizes options you've selected often and recently above ones you've never picked. This works great and helps a lot when trying to find something among tens of thousands of files on your computers. Not sure if something like this would be useful or not with popups containing only a handful of entries though, so perhaps this feature should be configurable on a case-by-case basis if implemented - or be intelligent enough to automatically change its behavior depending on the number of entries there are in a given menu.

Also all exact matches should always be listed in my opinion - even if there are a hundred of them. It is very frustrating if you search for something common like "readme" and can only see the first ten results or something.


On the coding side, one big limitation with the old GenericMenu data structure has been that you can't read what menu items already exist inside it nor modify them in any way. So you e.g. can't check if the previous item is a separator or not. You can't search for an existing item named "Copy" and then insert a "Paste Special" item below that index. It would be great if these kinds of things would be possible with Searcher. It would help a lot with things like the EditorApplication.contextualPropertyMenu callback if you could get an idea what items already exist a menu that is being opened.

Also it would sometimes be useful if at least the data structure holding the menu items would not be editor only. If you want to write GUI code that works both in the editor and at runtime, you can't currently use the GenericMenu directly but have to write some kind of a wrapper class. This wouldn't be that bad if you could easily convert data to GenericMenu and back, but because GenericMenu is such a unidirectional blackbox your possibilities are very limited in this regard.

 

Agree with everything except;

I don't like this at all. It gets put into a lot of search boxes, and I find it ends up slowing me down a lot.

If the search algorithm is fixed, it means that the results for the same inputs are the same every time, which means that I can learn what exact keypresses does what. So if there's something I use often that's two spots down with a certain search, I can blindly do search+down+down+enter without looking at the search bar.

If the search is "smart" and changes based on what I've selected before, the result moves around, so I can't learn it. I have to wait for the gui to draw, spot the search result I'm looking for, and then select it. So that ends up being a lot slower.

 

I can certainly imagine the feature being more irritating than helpful if it is not implemented well. In practice though, at least in the case of using Launchy for searching through many files on one's computer, I have found this to be extremely useful and to have exactly the opposite effect of what you're describing.

I think that where the feature shines the most is in intelligently sorting multiple search results in situations where there's not necessarily any one great match based on using pure approximate string matching.

I love it that I can just type "c" and press enter and be certain that it always opens chrome, even if I install some new programs that also start with the same letter. I love that "n" does the same for notepad. I love that I can just type "ga" and the suggestion to open one specific folder named Games (probably among dozens of other identically named folders) is always the first result suggested to me.

The feature saves me a lot of time 99% of the time, speeding up my everyday workflow considerably, and only slows me down a little bit that 1% of the time where I have to type in some additional letters or scroll through one or more additional suggestions to find that one newly installed program or something.

 

I've got "z" installed in bash/zsh which is for jumping around folders on the system and they use a ranking called "frecency", here's how they describe it:

Frecency is a portmanteau of 'recent' and 'frequency'. It is a weighted
rank that depends on how often and how recently something occurred. As
far as I know, Mozilla came up with the term.

To z, a directory that has low ranking but has been accessed recently
will quickly have higher rank than a directory accessed frequently a
long time ago.
​

(from https://github.com/rupa/z/)

 

Ship it

 

Feels like it should be a global configurable preference in the editor. I think you mentioned the same thing with QuickSearch?


But yes, I also strongly agree with everything else @SisusCo said.

 

Can you share some insight about this Editor Query Framework? It sounds interesting.
As for the searcher itself, I agree with everything @SisusCo said, except the part about hiding the textbox until somthing's been typed. It just doesn't feel very Unity I guesss.

 

This sounds great!

My priority list:

• Create asset menu (its’s gotten pretty large)
• Rig bones dropdowns
• Animation clip dropdowns

But I agree that I think this could be used to replace GenericMenu across the board.

I also think the search should optionally be fuzzy, but not too predictive smart, because I also like to memorize item locations.

 

In the Shaders dropdown, for anything ranging from ShaderVariantCollections to Materials.

In this list, LITERALLY only one entry is the one everyone in the team cares about. So the searcher not only needs to allow you to find your stuff, it needs to allow you to hide / lock away stuff that's wrong to use.

 

This looks great! The Create menu, would for sure be top priority for me, it is getting so massive. especial with multiple Assetstore assets, and packages.

I agree with what others have said. Having the path be smaller, and off to the side, or bellow the actual name would be very nice. And would improve readability and easy of use greatly to quickly find something.

For me having the search bar, and header there feels like it makes it bulkier, and more cumbersome to use. And my eyes have to go further to get to the info I want. Though truthfully I am not sure how to best fix this.

It is looking great though, can wait to get to use it. Maybe a pipe dream, but if you could hide items, that would be amazing.

 

That is great!
In addition, when searching for adding components, the script names under different namespaces are the same and cannot be distinguished.

 

does it exist?
it's nice if we can quickly specify components we created

 

Holy crap, PLEASE add this to **everything**, it's beautiful

 

no that's not what we're talking about here, we're talking about prefix, aka wildcard notation to tell the search go find all plugins with this name, go find me all of my scripts, go find all packages with this name
kinda like the current search field in hierarchy, in this format:

scene: sta

returning all scenes that have

sta

in the name

!scene: sta

returns everything with sta in the name except scene files

currently in a menu, requiring clicks, losing benefit of search shortcut

 

@willgoldstone, is this going to be implemented everywhere anytime soon? Would really help with all the menu bloating the editor is getting as features are introduced. Although I'd also really like something like a general Menu Manager for that (which could also very well be a place where to override whether to use a regular dropdown thing or the beauty of Searcher)

The context menu from the Project Window and assets in it are where I think this would be welcome asap, although pretty much anywhere with a dropdown is a prime candidate for that. In particular Timeline's Signal Asset dropdown, which currently makes the entire workflow pretty much unusable in any relevant scale.

 

I agree, I think especially the create menu has gotten beyond out of hand (it's now taller than the screen!), and this will aid in making it more manageable. Although naturally putting everything into categories would work too but it seems no one at unity is interested in that. Same for the menu used in script order.

I really like the idea of the searcher being unified, it's a really cool way to do it

 

Tried using it for some stuff this week and quickly realized it's looking very different from the version show in this thread:



And I couldn't find many options on how it looks by messing around the examples and source code.

Are there plans to make it look like this or is it locked into this current TreeView? I very much prefer the panning navigation of the original UX. Using a regular treeview serves only to waste horizontal space and visually overwhelm the user, impacting discoverability. The panning navigation has none of these flaws and allows for a consistent experience regardless of the depth of the tree.

Also, much more glaringly: is there a clean way to remove this entire preview/description panel? Most places wouldn't need that, I think. My usecase certainly doesn't. It's not even strictly necessary in Visual Scripting, although very useful.

 

I too don't understand why the Searcher Package doesn't seem to at all add support for the "Enable Custom Popup" option like what is shown in the video, which of course is the whole purpose of the Searcher Package for most people.

 

I'd say it's because it's a kinda big/not very small UX decision, but again, it's opt-in, so... Yeah, kinda makes no sense that they had the thing working, made it stop working for what they first showed it would be used for and then released it for us to toy around? And, somehow in the process of (I assume) reworking it to use UI Elements/Toolkit instead of IMGUI, made the UX worse? I assume that last part is because ListView is already a thing in UI Elements, so less work, I guess. That and the panning motion makes a little less sense with the description panel to the right, which is good for Visual Scripting Nodes.

Really trying to explain it to myself here, I might be completely wrong. Because I do want this asap. Of all the things still in my ~wishlist~ of (feasible) features for Unity, this one looks like the lowest hanging fruit.

 

Is it possible to use it somehow in 2019.x ?
I would be happy to see it as we have localization keys stored in constants and then use custom property drawer which show drop down box instead of string input field based on the static constants from single class.

 

These last posts by Flow-Fire-Games seem to be an offtopic, so...

Bump again, I guess? @willgoldstone, any updates regarding my questions? These ones, in particular?

 

As presented, where it's a complete replacement, I hate it: it massively slows down a lot of use cases: it forces me to stop using the mouse, move to the keyboard, type some stuff, move back to the mouse ... for things that currently are "click .. move, move .. click".

e.g. on the Create menu: Good packages already organize their elements well. It's the bad pacakges (And especailly: Unity's own pacakges! That have never been well organized on that menu!) that are the problem. "fixing" the bad packages by making the good packages harder to use is the opposite of what I'd want to see.

If it were only used for bad packages, and Unity's internal components/objects, then: great.

HOWEVER: it would be much more useful to fix the whole Create menu itself, which still has an undocumented API, which still breaks frequently (and has a secret cache, so that to debug the [MenuItem] attributes you have to keep restarting the editor every 5 seconds .... argh!), and is missing core features people have had to hack-in over the years (e.g. "put a separator in this menu", or "order these items on a menu" -- both those things have different bugs in differnet editor versions, don't work consistently even across minor point releases, and randomly break, because neither of them has a public, tested, working API).

TL;DR: don't make the common UX mistake of picking one use-case that's poor and then breaking everyone else's usecases just to fix that one. UX is hard because you have to keep all use-cases in mind when creating new / modifying old UX.

 

All that you described is still perfectly doable using the Searcher. You don't need to type, you can navigate the whole thing using the mouse. As shown by the video, It's exactly the same as the AddComponent menu (which isn't the case if you download their example package, but it's still good).




In this UI, clicking the bottom "Reference" slides the entire list to the left, revealing all the children of it. This is way better than the context menu hell of deep hierarchies, where you have to engage you FPS skills not to missclick and lose the entire menu.



In this most recent UI, they use TreeView instead. Solves the same problem also very well.