[frontend] Improve ShareOpenDevin User Experience

[xingyaoww]

What problem or use case are you trying to solve?

• Right now, when the user clicks thumbs up / thumbs down on the OpenDevin interface, it asks the user to enter an email every time the button is clicked.
• It also asks the user to select whether the feedback is public/private - it is a dropdown menu instead of two radio selectors, which is a bit slow for me, IMO.
• There is a toast popping up after the button is clicked, showing the feedback/share URL where you can access the shared interaction - but the delay is too short for people to see (1 second?). And it is also hard to copy the URL.
• There needs to be a way to track what chat histories I've shared.

Describe the UX of the solution you'd like

• [x] Allow the user to set a default sharing configuration in the setting modal, allowing user to set default "email". If the user inputs their email first when submitting an update, it should also be updated in the settings modal.
• [x] Change the dropdown menu of Share OpenDevin to two radio selector
• [x] Increase the display time of the "feedback URL" toast: https://github.com/OpenDevin/OpenDevin/blob/ff6ddc831f0e5b4038a233702d3399eb78ce74fd/frontend/src/components/modals/feedback/FeedbackModal.tsx#L36-L37
• [x] Add a copy button next to the feedback/share URL when it poped up in the toast.
• [ ] Allow a way to track interactions the user has shared - e.g., a small button on the bottom right near the setting; when clicked, it will pop up a small window showing what interaction the user has shared yet (and their URLs).

Optional

• [ ] Maybe we could figure out a way to highlight the thumbs-up/down button on the bottom left (e.g., adding keywords like "Share Interaction") so that user knows they can share trajectories with friends that way.
• [ ] Make it even easier for a user to remove their own interactions - instead of providing a password with the URL, maybe the user only needs to provide their email on the website and receive an email authentication or something - and the user can modify visibility/remove their shared trajectory (though this need to happen on the share-opendevin website - which i can do it next).

These are just my quick thoughts -- let me know what y'all think!

Do you have thoughts on the technical implementation?

Relevant file to change: https://github.com/OpenDevin/OpenDevin/tree/main/frontend/src/components/modals/feedback

Describe alternatives you've considered

Additional context

[tobitege]

We really could use a "Notifications" sidebar where this info could be shown to the user. How/where to store is another question.

[tobitege]

@amanape is there a way to display slightly differently in that the toast stays and has an extra "cross" close button? That way the user can take their time to copy the info and the close button cannot be ignored then.

[amanape]

These are good changes, some comments:

There needs to be a way to track what chat histories I've shared.

Since we don't have any form of permanent persistence like a database, I think the best way would be storing it in local storage. This has the downside of clearing if the user changes browser or resets cache. Did you have something else in mind?

instead of providing a password with the URL, maybe the user only needs to provide their email on the website and receive an email authentication or something

Good idea, but keep in mind some extra effort (e.g., also setting up some form of persistence to retrieve the currently stored code to verify it is the same that was entered, setting up and verifying a sender email, etc...)

@tobitege Yes I am pretty sure the library we are using supports this to some extent. If not, I know of other libraries that do.

I just so happen to be updating tests and refactoring some things related to feedback #2997, so I should be able to tick off a few boxes here at the same time.

[xingyaoww]

Since we don't have any form of permanent persistence like a database, I think the best way would be storing it in local storage. This has the downside of clearing if the user changes browser or resets cache. Did you have something else in mind?

I think in the simplest form, we can just make these info stored in the current browser session (like what we are doing with the API key - I think that just gets stored in my browser?) WDYT?

[amanape]

I think in the simplest form, we can just make these info stored in the current browser session (like what we are doing with the API key - I think that just gets stored in my browser?) WDYT?

Yes exactly

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[xingyaoww]

This should mostly been resolved a while ago - i think we can close this for now and create new issue if we want more feature here