Properties Search #71185

New Issue

William Reynish · 2019-10-29T11:21:36+01:00

William Reynish commented

2019-10-29 11:21:36 +01:00

With Blender's ever expanding feature set, it's useful to be able to search for properties, just like users can currently search for data inside the Outliner. Here's how we think it should work:

We replace the Properties header content with a search box, just like the Outliner and move the context breadcrumbs back inside the tabs at the top
When the user types in a search string, we show a list of matching properties. It searches the RNA names, but can also search for UI overriden names.
These properties have no UI layout - we just display them in a list, which fits nicely with the concept of the single column UI.
These properties use the title from RNA and not the overridden name from the UI layout script. Otherwise the name could end up being a confusing abbreviation like 'Y' instead of 'Aspect Y'
It will search across all properties tabs, but only show results for one tab at a time
We can use greying out for the properties tabs to show which other tabs may include results for the search string:
We can still display the container panel for each result, so users know where to find that property in the future:

{F7869070, size=full}

We can also support searching more dynamic content, such as modifiers:

With Blender's ever expanding feature set, it's useful to be able to search for properties, just like users can currently search for data inside the Outliner. Here's how we think it should work: - We replace the Properties header content with a search box, just like the Outliner and move the context breadcrumbs back inside the tabs at the top - When the user types in a search string, we show a list of matching properties. It searches the RNA names, but can also search for UI overriden names. - These properties have no UI layout - we just display them in a list, which fits nicely with the concept of the single column UI. - These properties use the title from RNA and not the overridden name from the UI layout script. Otherwise the name could end up being a confusing abbreviation like 'Y' instead of 'Aspect Y' - It will search across all properties tabs, but only show results for one tab at a time - We can use greying out for the properties tabs to show which other tabs may include results for the search string: ![Screenshot 2019-10-29 at 11.20.00.png](https://archive.blender.org/developer/F7869108/Screenshot_2019-10-29_at_11.20.00.png) - We can still display the container panel for each result, so users know where to find that property in the future: ![Screenshot 2019-10-29 at 11.17.57.png](https://archive.blender.org/developer/F7869106/Screenshot_2019-10-29_at_11.17.57.png) {[F7869070](https://archive.blender.org/developer/F7869070/Screenshot_2019-10-29_at_11.03.39.png), size=full} We can also support searching more dynamic content, such as modifiers: ![Screenshot 2019-10-29 at 13.54.21.png](https://archive.blender.org/developer/F7869310/Screenshot_2019-10-29_at_13.54.21.png)

William Reynish self-assigned this 2019-10-29 11:21:36 +01:00

William Reynish commented

2019-10-29 11:21:36 +01:00

Added subscribers: @WilliamReynish, @xdanic, @jc4d, @CandleComet, @RosarioRosato, @semaphore, @mendio, @0o00o0oo, @antoniov, @T.R.O.Nunes, @Ehab, @BartekMoniewski, @DuarteRamos, @MaciejJutrzenka, @Znio.G, @brecht, @Sergey, @dfelinto, @mont29, @ideasman42

William Reynish removed their assignment 2019-10-29 11:21:54 +01:00

Julian Eisel was assigned by William Reynish

2019-10-29 11:21:54 +01:00

Duarte Farrajota Ramos commented

2019-10-29 11:37:17 +01:00

This will be a very welcome addition. Will these results be limited to properties that we can find in the properties window, or will they show results from other editors?

I'd vote for the former, however one common problem of "search result" UIs is knowing where the original location for each entry is.
Some times it might be useful to know where in the properties window that property came from, so you could find them later without searching, or see related settings close by.

Not sure if it is possible to make the property name clickable when displayed in the search results so clicking it takes you to the appropriate tab and panel, or perhaps show a breadcrumb for each; though I can see how it will easily make the UI crowded.

This will be a very welcome addition. Will these results be limited to properties that we can find in the properties window, or will they show results from other editors? I'd vote for the former, however one common problem of "search result" UIs is knowing where the original location for each entry is. Some times it might be useful to know where in the properties window that property came from, so you could find them later without searching, or see related settings close by. Not sure if it is possible to make the property name clickable when displayed in the search results so clicking it takes you to the appropriate tab and panel, or perhaps show a breadcrumb for each; though I can see how it will easily make the UI crowded.

Andrei Nadin commented

2019-10-29 14:06:47 +01:00

Added subscriber: @AnadinX

Andrei Nadin commented

2019-10-29 14:06:47 +01:00

Great idea. I still think it would be useful even with changing to nodal modifiers, there will always be panels with things to find in them

Julien Kaspar commented

2019-10-29 15:08:23 +01:00

Added subscriber: @JulienKaspar

Harley Acheson commented

2019-10-29 15:11:47 +01:00

Added subscriber: @Harley

Harley Acheson commented

2019-10-29 15:11:47 +01:00

Will this work if a different Language is being displayed?

Harley Acheson commented

2019-10-29 15:48:02 +01:00

Interesting to think about reset behaviour. If we are in the state illustrated above, searching for “aspect”, which elements are active?

It could be that all tabs are inactive in that state and you are required to clear the search, by clicking the “x”, to proceed as normal.

However it might be nicer if clicking any of the tabs would immediately clear the search and open the panel. Clicking on a greyed-out tab would display as normal. But clicking on a highlighted tab would not only clear search but would open such that all sections are collapsed except for the ones containing matched items. That way you don’t need to add anything new for “go to original location” as mentioned earlier.

Interesting to think about reset behaviour. If we are in the state illustrated above, searching for “aspect”, which elements are active? It could be that all tabs are inactive in that state and you are required to clear the search, by clicking the “x”, to proceed as normal. However it might be nicer if clicking any of the tabs would immediately clear the search and open the panel. Clicking on a greyed-out tab would display as normal. But clicking on a highlighted tab would not only clear search but would open such that all sections are collapsed except for the ones containing matched items. That way you don’t need to add anything new for “go to original location” as mentioned earlier.

Duarte Farrajota Ramos commented

2019-10-29 17:43:01 +01:00

In #71185#802763, @Harley wrote:
It could be that all tabs are inactive in that state and you are required to clear the search, by clicking the “x”, to proceed as normal.

Maybe search results could be an entirely new tab that only pops up whenever there is entered text in the box.
Clearing the box "hides" the tab and entering new text switches to it again

> In #71185#802763, @Harley wrote: > It could be that all tabs are inactive in that state and you are required to clear the search, by clicking the “x”, to proceed as normal. Maybe search results could be an entirely new tab that only pops up whenever there is entered text in the box. Clearing the box "hides" the tab and entering new text switches to it again

msalv commented

2019-10-29 21:44:59 +01:00

Added subscriber: @moisessalvador

msalv commented

2019-10-29 21:44:59 +01:00

Not related to this task, but having search on the Preferences would be great too

William Reynish commented

2019-10-30 09:04:04 +01:00

@Harley apparently it’s not explained clearly enough in description, but the idea is that searching will always search across all properties tabs. You’ll only see the results from one tab at a time, and the highlighting tabs will communicate to users which other tabs also contain results.

William Reynish commented

2019-10-30 09:32:29 +01:00

@moisessalvador Yes, thet's the idea too. Once we have it working for Properties, it should be easy to do the same for Preferences.

Matt Rossman commented

2020-03-30 19:56:12 +02:00

Added subscriber: @mercyberg

Matt Rossman commented

2020-03-30 19:56:12 +02:00

@WilliamReynish Since you say we only show results from one tab at a time, presumably we have to highlight the active tab somehow. How would you display the active tab (highlighted) if it contains no results (greyed out)? It would be confusing to highlight the active tab when it doesn't contain results, but if it's not highlighted then it will be unclear which tab the user is searching through.

I like @DuarteRamos's idea of opening a designated search tab so we don't run into this ambiguity. Then there is the added benefit of being able to show an aggregation of results across tabs.

@WilliamReynish Since you say we only show results from one tab at a time, presumably we have to highlight the active tab somehow. How would you display the active tab (highlighted) if it contains no results (greyed out)? It would be confusing to highlight the active tab when it doesn't contain results, but if it's not highlighted then it will be unclear which tab the user is searching through. I like @DuarteRamos's idea of opening a designated search tab so we don't run into this ambiguity. Then there is the added benefit of being able to show an aggregation of results across tabs.

Matt Rossman commented

2020-03-30 21:23:05 +02:00

I am picturing a flow like this, which doesn't actually require a dedicated search tab, just a temporary search state:

{image uri=https:*i.imgur.com/kK5PFjL.jpg, width=100%, href=https:*i.imgur.com/kK5PFjL.jpg}

I am picturing a flow like this, which doesn't actually require a dedicated search tab, just a temporary search state: {image uri=https:*i.imgur.com/kK5PFjL.jpg, width=100%, href=https:*i.imgur.com/kK5PFjL.jpg}

Lsscpp commented

2020-05-05 10:51:51 +02:00

Added subscriber: @lsscpp

Julian Eisel was unassigned by Hans Goudey

2020-06-13 01:47:06 +02:00

Hans Goudey self-assigned this 2020-06-13 01:47:06 +02:00

Hans Goudey commented

2020-06-13 01:47:06 +02:00

Added subscriber: @JulianEisel

Antonio Vazquez commented

2020-06-13 15:35:22 +02:00

Removed subscriber: @antoniov

slowk1d commented

2020-07-08 18:33:32 +02:00

Added subscriber: @slowk1d

Chrischan commented

2020-07-15 08:02:13 +02:00

Added subscriber: @cschumann

Manuel Grad commented

2020-07-30 23:01:13 +02:00

Added subscriber: @ManuelGrad

Manuel Grad commented

2020-07-30 23:01:13 +02:00

In order to not spam the Property Search Status thread on devtalk i'll post this here, hope thats ok.

Can we please hide the the unrelevant sections? I really dislike the idea that we'd have to scroll after a search and i don't think this feature was only intended as a learning aid (as in showing the user where to find stuff) but also to boost working speed. Many users are concerned with the need to scroll too much in the properties window and it was said once the search feature is implemented it will be better – GREAT!
After seeing Pablos mock-up i feel a bit disappointed though. The mock-up feels messy and overwhelming for something that should save you time.
It for sure doesnt look like it enables fast working. For that, we would need the smallest possible travel distance for the mouse, little to no scrolling, and no useless display of information/sections the user doesnt need.

My proposal would be something like this:

hide non-relevant sections
dim more than 50%
make it more clear what the search result is; use another accent color for search, otherwise its confusing with the same blue as the sliders and checkboxes

![property_search_proposal.jpg](https://archive.blender.org/developer/F8731675/property_search_proposal.jpg) In order to not spam the Property Search Status thread on devtalk i'll post this here, hope thats ok. Can we please hide the the unrelevant sections? I really dislike the idea that we'd have to scroll after a search and i don't think this feature was only intended as a learning aid (as in showing the user where to find stuff) but also to boost working speed. Many users are concerned with the need to scroll too much in the properties window and it was said once the search feature is implemented it will be better – GREAT! After seeing Pablos mock-up i feel a bit disappointed though. The mock-up feels messy and overwhelming for something that should save you time. It for sure doesnt look like it enables fast working. For that, we would need the smallest possible travel distance for the mouse, little to no scrolling, and no useless display of information/sections the user doesnt need. My proposal would be something like this: - hide non-relevant sections - dim more than 50% - make it more clear what the search result is; use another accent color for search, otherwise its confusing with the same blue as the sliders and checkboxes

Dalai Felinto commented

2020-07-31 15:37:00 +02:00

@ManuelGrad I found your "Proposal 1" a really good compromise.

Hans Goudey commented

2020-08-03 23:05:28 +02:00

If we only display matching panels, does it really make sense to highlight their headers? It doesn't serve much of a purpose then.

For the future, some way to highlight the buttons themselves might be nice-- maybe an outline. Highlighting the labels is nice, but also a bit odd if the button itself doesn't change.

If we only display matching panels, does it really make sense to highlight their headers? It doesn't serve much of a purpose then. For the future, some way to highlight the buttons themselves might be nice-- maybe an outline. Highlighting the labels is nice, but also a bit odd if the button itself doesn't change.

Ivo van der Lans commented

2020-08-04 23:46:34 +02:00

Added subscriber: @Ivo

Ivo van der Lans commented

2020-08-04 23:46:34 +02:00

2ct: My first encounter with the mock-ups taught me that highlighting the headers makes them less recognizable (I found that it takes me quite some effort to find the highlighted headers from the proposals in the original view on the left). Otherwise, “proposal 1” worked for me. Small suggestion still: could the non-matching tabs be hidden as well?

Great initiative overall!

2ct: My first encounter with the mock-ups taught me that highlighting the headers makes them less recognizable (I found that it takes me quite some effort to find the highlighted headers from the proposals in the original view on the left). Otherwise, “proposal 1” worked for me. Small suggestion still: could the non-matching tabs be hidden as well? Great initiative overall!

Hans Goudey commented

2020-10-13 21:41:38 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Hans Goudey closed this issue

2020-10-13 21:41:38 +02:00

Hans Goudey commented

2020-10-13 21:41:38 +02:00

Since property search has been almost completely implemented, this design task isn't relevant anymore.

For the record, we decided not to use an approach where some buttons were completely hidden from the layouts because it's very hard to support that properly in the general case for every layout.
For example, when one button matches, which of the buttons around it are removed and which are kept? Beyond the most simple of cases, this is a near-impossible problem.
It also removes too much of the context from layouts. Often a button only has meaning relative to other buttons around it.

We also decided to show all panels but set expansion based on whether each panel had a search result. This ensures that users have complete context of where panels are, and easy access to other
information while the search is active.

Since property search has been almost completely implemented, this design task isn't relevant anymore. For the record, we decided not to use an approach where some buttons were completely hidden from the layouts because it's very hard to support that properly in the general case for every layout. For example, when one button matches, which of the buttons around it are removed and which are kept? Beyond the most simple of cases, this is a near-impossible problem. It also removes too much of the context from layouts. Often a button only has meaning relative to other buttons around it. We also decided to show all panels but set expansion based on whether each panel had a search result. This ensures that users have complete context of where panels are, and easy access to other information while the search is active.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Properties Search #71185