Security in a way. The issue is that there’s no way for the properties UI to display those types of items even if the Attribute storage itself can store them. It’s not just a question of implementation work either, we couldn’t arrive at a UX we were happy with for dealing with them so excluded them from the first version of Attributes rather than making people wait even longer for them.
TL;DR: Having people able to pack hidden data into an instance that you can’t find out is there without scripting is not ideal. We did it with Tags, but didn’t want to repeat the same mistake with Attributes.
Is there anything complicating the issue of showing tags in the properties widget? Or is this just a matter of prioritization? It’s funny that both the properties widget was revamped and attributes were released while tags are still completely invisible.
I mean, if it were just showing Tags in the properties widget then that would be easy enough, but that’s not an acceptable Tags UX. The whole idea of tags is that you can identify things with a given Tag, so you’d want some viewport visualization / way to hide things with a given tag, etc… so it’s a much bigger can of worms to deal with.
That sounds very cool if those are the features Roblox would like for working with tags in Studio, but I really think something like this needs to be handled in “levels of quality”.
Even if Roblox has a whole awesome feature spec designed for this already, that is meaningless to users because in the meantime, they’re waiting 2+ years with no functionality whatsoever while Roblox shuffles around priorities. Completely leaving out this functionality for years is worse UX than providing super basic controls, because out of touch developers won’t know about CollectionService, or third party plugins, and other developers now have to juggle more screen clutter and spend more mental effort to work with tags.
The code for this in the properties widget would also most likely be independent from the other tooling, and could likely be reused or expanded upon later.
It seems wrong to put off something like this just because plans for the feature are huge and the roadmap doesn’t have space for it.
Yes, for some further context, the fact that there’s already a very good Tag editor community plugin at this point does play into this. Even if we make a stopgap solution (which is something that we try to avoid doing if at all possible), if it isn’t better than the readily available community tag editor then it wouldn’t accomplish much.
I would argue that simply by it being built into studio, in a place where people look to see instance properties, it’s already valuable enough because it is much more convenient for a quick glance, and many people don’t even know CollectionService exists, especially since its name isn’t obviously affiliated with tags. I wouldn’t call it stopgap either if the properties widget side of implementation can be easily iterated on.
Truth be told, I do not use most of the advanced features of the tag editor plugin. I only use it to add, remove, and see what tags are available, the last of which is not strictly necessary for my workflow.