Present: Dalai Felinto, Hans Goudey
A quick conversation to discuss the current state of the property search implementation
Panels help to organize the properties UI, but they also makes it more overwhelming to dig through the settings. Property search does the digging for you. Even for experienced users, pressing Ctrl-F and typing the name of the property could be faster than navigating to it directly. Using the existing tabs and panels labels helps users remember where the properties are in the future so they don’t necessarily need to use search to find them again.
Search Layout Issues
The approach the design and implementation take is to change the layouts after the buttons are added. This works well in many situations, but is fundamentally a more difficult problem than just drawing a highlight for matching buttons or fading out buttons that don’t match the filter.
Dalai wondered it the shortcomings of the current implementation should be solved at the design level or as implementation details. For example, expanded enum buttons don’t show all buttons with the same property
Even though there are more issues to solve with this approach, Hans feels confident that the current goal is the better solution and that the problems are solve-able within a couple weeks. The issues mentioned above should be solved by keeping buttons aligned (stitched) to buttons that match the filter.
Searching Multiple Tabs
Although a possible simplification to the project would be only searching the current tab, mutli-tab search is one of the core principles of the project. Without it the search is almost useless, as a user would need to know where a property is before searching for it.
Building the layout to search every tab of the property editor may cause performance problems in the future. Although Hans has done some initial investigation which exposed some bottlenecks, Dalai suggested addressing performance improvements after the basic design works as expected.