I'm going to be honest: I spun up the UI, and I don't fully understand how to use it, or how to evaluate whether the user flows make sense.

I'm just going to be writing questions/comments that come to mind while I'm testing things out. Feel free to pick and choose which feedback actually makes sense:

• I have no idea what a "Sync Field" does, and the documentation linked on the page doesn't mention those words once
• The "organization sync field" input mentions "If empty, organization sync is deactivated". I don't know if that means that the entire form should be disabled while the field is empty, or not. Right now, all the main inputs are still interactive
  • As in, if the point of the page is syncing organizations, and the UI tells me "organization sync is deactivated", but it's not really, that feels like communication broke down
• I don't know if the UI around the switch is clear.
  • It's not clear from looking at the switch that clicking it immediately makes a POST request, especially when there's a separate Save button right next to it
  • I feel like the label text would be more clear if it said something like "Give all users default organization". I know that "Assign" is also a verb, but something with the current phrasing makes it less clear to me for some reason
• Maybe the word "Save" could be renamed to "Sync" to make it more clear that the button is only relevant to the sync field?
• There's no easy way to add a new Coder org to an existing IDP org. You have to add a new IDP org with the same name, and manually re-add all the Coder orgs (with the risk of forgetting one if the list is long enough)
• On the flip side, it's not easy to remove a Coder org from an IDP org
• I don't know if it makes sense to display the table when there are no IDP orgs. It makes the UI show two extra headers that just add visual noise/confusion, because there's nothing for them to apply to. I'd rather just display the call-to-action outside the table
• It'd be nice if the Delete icons had a tooltip
• When I'm in the empty state and have no groups, it's not clear what the UI wants me to look at first. The Call to Action is drawing my attention a lot more because it's larger and has more relative brightness. But the only action there is looking at the docs

The documentation hasn't been created yet and some of the things you are mentioning, especially editing rows in the table are intended to be updated in a future PR. I also wanted to leave the table as is, since this would get replaced with a non-MUI table in the future with the work for IDP group and role sync.

When clicking the switch, a toast does appear telling the user the settings have been updated.

So my thinking with UI is that it should be as obvious to the user before they even interact with it. As in, it should set relatively firm expectations on what something does, so that the user can confidently decide if the element is even relevant to them

If the user has to interact with the element once to know exactly what it does, I feel like there's something that can be done to make the UI more clear. UI engineering wants to minimize surprises

@Parkreiner I think this may be a good discussion for FE Variety. Right now, the assumption is that a user would probably not interact with this page without reading the docs first. Historically, I believe these kings of settings would be handled with an onboarding call. Of course its a great goal for a user to intuitively understand everything about a page just by looking at it but there will be tradeoffs in usability and design esthetics. For example, the atomic saving of each element of the form was a tradeoff, the alternative design with a single save button for the entire form, considered that if the table had many rows, the save button for the entire form would be pushed below the fold, so that an indicator would be needed to let the user know the form is dirty. Is possible this is a better design, but doing the work iteratively will allow more people to use it and to get some feedback about what works and doesn't work.