Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep "Save changes" on the Replication tab #31404

Closed
nataliekwong opened this issue Oct 13, 2023 · 7 comments
Closed

Keep "Save changes" on the Replication tab #31404

nataliekwong opened this issue Oct 13, 2023 · 7 comments
Labels
area/frontend Related to the Airbyte webapp team/compose

Comments

@nataliekwong
Copy link
Contributor

On the Replication tab of a Connection, the "Save changes" button appears below the list of streams. This means that if you have many streams, you need to scroll down to the bottom of the list to see the save button.

Ideally the button is always visible so the user knows they can at any time save changes, even if they have more streams than fit the page.

@nataliekwong nataliekwong added team/compose area/frontend Related to the Airbyte webapp labels Oct 13, 2023
@teallarson
Copy link
Contributor

Refining notes:

  • related to work that @josephkmh is doing on virtualization for syncCatalog
  • @nora-airbyte will mock out some options to solve this!

@nora-airbyte
Copy link
Contributor

nora-airbyte commented Oct 16, 2023

Some options here

I'm between Option 1 & 2. Option 1 is most consistent with our save behavior throughout the UI, but the user would still have to scroll to the bottom. Option 2 is a good compromise, but fixed-height tables can be annoying.

Interested on hearing thoughts on these trade-offs...

@josephkmh
Copy link
Contributor

josephkmh commented Oct 23, 2023

Refining notes:

  • Probably a small subset of users
  • We don't feel like we have enough data, would like to watch some sessions to understand how users interact with these buttons
  • We should go with Option 2 for now, because it's the least work from the current status (move save buttons onto the card, instead of under the card)
  • Will follow up in fullstory watch party
  • In order to track this, we need to send the number of streams as a segment analytic. To do this, we can adjust the existing useTrackPage() to accept arbitrary properties, where we can send the number of streams. @timroes will make a new issue

@josephkmh
Copy link
Contributor

@nora-airbyte I took some time to implement this, and I'm now questioning whether this is the right approach.

My concerns:

  • It's hard to find a good fixed height for the table without pushing the "Save" button off-screen, which I feel is the main problem we're trying to solve here
  • Adding the "Save changes" button to the streams card makes it seem only related to that card (left a comment about this in figma)
  • The nested scrolling containers makes it hard to discover the save button at the bottom, even with a short fixed-height table

I pulled up my old PR that re-introduced a fixed bar at the bottom. The UX feels a lot better to me here, because I can always see the buttons.

Screen.Recording.2023-10-24.at.2.32.32.PM.mov

I share your hesitance about introducing new one-off patterns like this fixed footer, but this page feels like a special case to me because:

  • It's the only way I see to solve the original pain point brought up in this issue
  • This page is a unique case where a <Card> can be extremely tall
  • Form inputs in multiple cards are linked to a single resource (the connection) and the user likely wants to update connection settings in a single action.

Curious to hear your thoughts!

@josephkmh josephkmh self-assigned this Oct 24, 2023
@nora-airbyte
Copy link
Contributor

nora-airbyte commented Oct 24, 2023

To address concerns:

  • I agree, I don't think any solution besides the one you show prevents pushing the save button offscreen. I was hoping to find a solution that would still be discoverable/predictable for the user despite this.
  • Responded in Figma! I was proposing adding Save to each individual card, sorry for the confusion there.
  • Fair enough!

I think this solution does solve the immediate problem of users missing the save button the best, but I do think it might cause confusion down the line, especially with the changes we're making to replication settings. If we're ok maybe revisiting this UX in the future, I'm ok with shipping this fixed-to-bottom solution for now.

@josephkmh
Copy link
Contributor

Refining notes:

  • This is not super high priority, so moving to backlog
  • Nora may have a slightly different approach soon

@nataliekwong
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/frontend Related to the Airbyte webapp team/compose
Projects
None yet
Development

No branches or pull requests

6 participants