Page MenuHome

User interface improvements for attribute search
Confirmed, NormalPublicTO DO

Description

Design task: T85280

This depends on T85658.



The idea is to go beyond the basic search list and indeed show:

  • Data Type
  • Category
  • Attribute
  • Domain.

Event Timeline

Dalai Felinto (dfelinto) changed the task status from Needs Triage to Confirmed.Feb 22 2021, 2:14 PM
Dalai Felinto (dfelinto) created this task.

Could a dropdown inside of the new string node be a good place to store existing attributes in a list?

Note that in D10623 I strayed from the design above in a few ways:

  1. The data types are indicated on the right side instead of the left with socket type icons.
    • Techincally, there are issues drawing the socket type icons here
    • We may not have socket types for all attribute types
    • Indicating data types with just a color is not always accessible
  2. The domain is on the left (grayed out with arrows).
    • I like the way this establishes hierarchy. e.g. "The attribute exists in the edge domain"
    • Without a cohesive set of icons for the domains, icons look weird.
  3. It does not display the "Category".
    • I think we settled on "Original Data", "Nodes", and "Built-in" as the categories, but I'm not sure because that's not in the design.
    • Personally I think some of the more specific categories (if you want to call them that) like vertex groups don't make sense to distinguish in the context of generalized attributes

One thing to keep in mind is that we can also use custom tooltips and even a right click menu for the search if it's helpful.

We may not have socket types for all attribute types

Can you give some examples?

Indicating data types with just a color is not always accessible

This is a separate issue. We can add pattern/hashes/... for the sockets as a whole to make them more accessible.

I like the way this establishes hierarchy. e.g. "The attribute exists in the edge domain"

It does indeed. However this is the same for categories. The question may then be, are users thinking in terms of (let me find the attribute X that is in the points; or let me find the attribute Y that I created as a node/builtin/...)

Personally I think some of the more specific categories (if you want to call them that) like vertex groups don't make sense to distinguish in the context of generalized attributes

We can have a generic "User/Original Data/..." however we want to call them in the spreadsheet in those cases. Though I can't see why Vertex Group wouldn't be a good category.

I think we settled on "Original Data", "Nodes", and "Built-in" as the categories, but I'm not sure because that's not in the design.

In the design we have "Nodes", "Built-in", and the Custom, the work "Custom" is never exposed to the user though, and it is actually UV Map, Vertex Group. In the documentation we can use what we plan to use for spreadsheet (User/Original Data)?

Hans Goudey (HooglyBoogly) renamed this task from Final user interface improvements for attribute search to User interface improvements for attribute search.Mon, Mar 22, 2:54 AM
Hans Goudey (HooglyBoogly) claimed this task.

@Hans Goudey (HooglyBoogly) remember in the future to add an image here of the final result.

I was testing it and have two remarks:

Test file:

  1. Data type fields gets unreadable once highlighted (gray with blue background).
  2. How are we sorting the attributes? Right now is not alphabetical, not per domain, not per data-type.

Note if we want to move this task to done I would then ask for us to have new tasks for the issues above. Also, although polishing usually can be left for the community remember that we decided on prioritize this to have this one part of the pipeline super polished. So I think it is worth to address those remaining issues.

Looks like I had an unfinished comment from a while ago here:

We may not have socket types for all attribute types

Can you give some examples?

Right now there is 2D vectors for example, I don't doubt there may be more in the future though.

Indicating data types with just a color is not always accessible

This is a separate issue. We can add pattern/hashes/... for the sockets as a whole to make them more accessible.

Anyway, I see node sockets themselves as different from attribute data types themselves anyway. After all we access attributes by name, not by plugging in sockets.

Thanks for the screenshot

  1. Data type fields gets unreadable once highlighted (gray with blue background).

I'll approach this as a bug fix, since it's the same in other menus. I agree it should change. I made a task: T87526

  1. How are we sorting the attributes? Right now is not alphabetical, not per domain, not per data-type.

This is just whatever way the search orders them, we don't really have the flexibility to change the order manually at the moment. Though this could be improved I suppose, I'm not sure exactly how at the moment.