This feature request is pretty self-explanatory. Archivable is extremely useful for plugins, but it’s easy for developers to accidentally set Archivable to false while building or scripting and have their instances not save. I haven’t had any problems with this before, but communicating Archivable-ness through explorer icons seems like an intuitive feature.
Implementation ideas:
A small symbol in the corner of the icon.
A slash or X over the icon.
A grayed out icon, although this behavior may be more appropriate for communicating enabled-ness on scripts, lights, guis, etc.
Name of instance is grayed out, although this is less useful if the name is short or just whitespace.
In the past I have participated in discussions about even outright hiding the property in studio so that it’s only accessible via scripting. Both of these ideas seem very important. This property should not be surfaced and should be explicitly communicated when its enabled because it can lead to data loss.
Honestly I feel like we need to seriously limit the amount of overlays we put on the explorer icons themselves - they’re a key part of identifying and distinguishing different class types, and they’re already pretty overburdened with visual details. This is especially true with the new icon set.
I’d feel better about putting some extra icons in all this unused space to the right of the icon to communicate warnings about instances not being archived:
100% agree, I’ve multiple times thought about the it.
They could take the system programs like blender have where certain children or properties display extra icons.
A warning icon with a tooltip to the right could work, but I don’t want the space for this extra icon to cut off the names of instances or make it feel cramped. It’s uncommon for an instance to be non-Archivable, so I don’t think it should take up horizontal space by default.
Some people need a small explorer view, so lots of icons to the right could get in the way. Non-archivable instances risk confusion and lost work if the user isn’t aware of the behavior. Even if the ‘Archivable’ property were to be hidden or have a warning, it’s possible a developer may try to insert something into an instance created by a plugin, not knowing that it will be gone when they load their save.
This could be implemented as an overlay so new icons don’t need to be made.
I would think that uncommon badges would be perfectly suited to take up that space, as opposed to badges that take up space all the time.
It’s worth noting Roblox has well in excess of 600 class types at this point (ask me how I know that :p) and in both the old and new icon set, existing badges (such as the link badge used by packages) already do obstruct important parts of some class icons which place distinguishing details in the corner. This is much more prevalent in the new icon set, and even occurs pretty often in Vanilla despite my best efforts to avoid it. These badges can take up to a quarter of the available pixels by area and destroy icon recognisability if used without care.
This is before we even consider legibility concerns. How do you ensure icon badges sufficiently stand out from their background, and don’t just blend into the rest of the icon to result in a visual soup of shapes?
And then, on top of all of that, what if you need to show more than one badge? What if you have an unarchivable package? Or even worse, an unarchivable disabled script package? Are you willing to chop an icon in half or even into quarters to show every badge? It does not scale.
Finally, each icon need not take up more space than a 16x16 image, with perhaps a tooltip for extra context of what the icon means. You can even put it before the name if you’re concerned with horizontal overflow pushing the icons off screen for people with narrow explorer windows. Space is not a concern, and certainly does not justify ruining functionality or readability.
