👤 Saving an Integration requires save to be set twice
Opened this issue · 13 comments
This is a...
[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ x] Bug report
[ ] Documentation issue or request
@gaughan your comment is about the UX, right?
Because it's been a deliberate decision to have the integration Saved only after the name is picked in the second screen.
This is because we don't have the inline editing of the integration name. I think it's been a deliberate choice, but I need to understand how much this matter to you.
I think what users expect to happen when clicking on the "save" button is a background save.
We do need the name/description screen when users first click "save" in the workflow because we need at least the integration name to save a draft, but the second time around, we can probably perform a background save.
I think part of the reason for not having the inline editing was because of the layout change. I'm not sure if inline edit is something easy to add? And also if we want to re-work the layout at this point to consider giving users a way to inline edit?
How often do users need to change the name and add a description? They can always do it via the integration details page. Maybe we just don't show the name/description page the second time around?
WDYT @riccardo-forina ?
Yes, this is a leftover of the early iteration of the POC, but I think there is still some value on the way it's done. As you said, there is no way to rename an integration inline, and that's for a few reasons:
- there is really no space in the already crowded header to add the inline edit widget
- even if we manage to find the space to add it back, there would be no way to change the description but exiting the editor and opening the details page
- it's not trivial to implement :P
So my reasoning was, why don't we get the user to the save page every time he wants to save? This way it would be possible to change both the name and the description at any time.
But I understand this makes quick saves more cumbersome, so we can restore the original flow if you prefer it that way. So:
- for new integrations, clicking on either save or publish will show the form page.
- for existing integrations, save and publish will act immediately, with one small gotcha: the content of the page will be replaced with a spinner while the save is in progress because we need to wait for the save result to be sure to work on the right integration object.
Hope this is clear.
My end user expectation from the first screen is that I am done, I click save so I'm done.
We could get around this in the future by automatically naming "Integration1" 2,3, etc
It's not an item we need to prioritize right now tho.
Would renaming the first "Save" button to "Review", just like the last step before confirming a purchase on Amazon, work?
Yea not a bad idea!
Which "save" are we talking about here? If it's the "Save" on "Add to Integration" page, does it mean the next page title would need to be changed to "Review integration"? And by changing it to "Review", would it imply something else to the users? What would they expect to see on a review screen?
I think the Amazon use case is for users to review items in their shopping cart? Or you're talking about AWS?
I'd love to get @TovaCohen 's opinion on changing button labeling as well.
I think that "Review" implies "Please confirm that everything is in place and you are ready to proceed and make something happen."
So I do not think that "Review" is a good option.
I think that what Ricardo describes at the end of his most recent comment is the best way to present this to users. He says:
we can restore the original flow if you prefer it that way. So:
for new integrations,
- clicking on either save or publish will show the form page.
- for existing integrations, save and publish will act immediately, with one small gotcha: the content of the page will be replaced with a spinner while the save is in progress because we need to wait for the save result to be sure to work on the right integration object.
@dongniwang the first page would change to review, the form page would still be "save".
I see where you are coming from @TovaCohen we are naming in the second screen not reviewing the details are correct.
If we stick with two separate pages, for new integrations, this wouldn't solve the double save right?
Having it on one page feels like the right option to me.
My vote goes to restore the original flow.
I agree with Dongni. I think that two Saves the first time, because you have to give the integration a name, is fine.
Do we need this for 7.4? Or we flag it as an enhancement?
Not to put my hands forward, but this is no small change.