Please revert decision to remove library update notifications

Hey @Alamaki - appreciate the feedback on this. Aside from reverting back, do you have feedback/suggestions on your ideal way to get updates communicated to those working with your library?

I’ll make sure to pass it onward internally on the Figma end.

I’ll say this: the old “component updates available” prompt wasn’t effective. It was a buzzing fly that designers would wave away without even seeing it. Sometimes at the end of a call where someone had screenshared their designs I would ask “Did you notice that prompt to update some components?” and they wouldn’t even remember clicking it away; hitting dismiss had become a reflex.

With this new thing - the blue dot - I think designers will not only (still) not care about updating components, but now they won’t even know there are updates to get. The blue dot is ignorable to the point of being invisible. So I don’t know the solution here, but if designers having up-to-date components is important (I think it is, but that’s because I maintain the library, ha) then something better’s got to be figured out.

Idea: When I create a new component to replace an old one I deprecate the old one, and I make it really obvious - pink background, warning icons in the name, it’s really obnoxious - I want them to know, “stop using this, it’s old and there’s a newer one.” What if you did that for un-updated components? What if you could indicate, as part of the component’s appearance, that it’s out of date? You’d have to do it nondestructively - no risks of breaking changes, just put a different color border around it or something, and a link or button that lets them quickly update it, or open the “review updates” panel (which is brilliant, by the way 🥰). Something like this:

Oooh a dif. color border is a good one for outdated components – I wonder if having a quick ability to duplicate and ‘detach’ from the updated component would be useful to have as well 🤔

ty for this!

I wonder if having a quick ability to duplicate and ‘detach’ from the updated component would be useful to have as well 🤔

I like that. And hey, if Figma’s smart enough it might even be able to suggest to the designer, under the right circumstances and without needing the designer to look at the side-by-side view, “This update is safe for you, nothing will break.” Because that’s the biggest hindrance to getting people to accept updates - they’ve been burned in the past by accepting some update that erased all their form labels or something. But if you can indicate right there that there aren’t any risks, that would go a long way toward fixing the issue. (Of course for this to work you have to be right about it - the first time Figma tells someone an update is safe and then it breaks, all confidence is lost, lol - good luck! 😀)

An instance not being up do date should be treated as an error state user is supposed to solve.

There are two different cases to consider:

• “External libraries” (e.g. design system library) where auhor of the changes can’t be responsible for keeping the library using files from breaking.
• “Internal libraries” (e.g. project’s design-molecule library) where author of the changes should be responsible for fixing every instance in every file as needed.

In both cases it should be obvious from the file list view and from file’s page list that they contain instances that are not up to date. Instances that are not up to date should also have a distictive visual marker like Travis2 suggests.

It should be possible to go through updates instance by instance project wide to check that nothing gets broken when updates are accepted. It should also be possible to accept updates so that they get immediately applied everywhere in the project.