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

Navigate directly to created change requests #4114

Open
rolodato opened this issue Jun 5, 2024 · 2 comments
Open

Navigate directly to created change requests #4114

rolodato opened this issue Jun 5, 2024 · 2 comments
Assignees
Labels
improvement Improvement to the existing platform

Comments

@rolodato
Copy link
Member

rolodato commented Jun 5, 2024

Is your feature request related to a problem? Please describe.

When a change request is created, a toast notification showing "Created Change Request" is shown. However, there is no link to such change request, and users need to manually navigate to Change Requests to find it. This can leave users wondering if they actually created the change request correctly, especially if they don't notice the notification before it disappears.

Describe the solution you'd like.

I see two possible solutions:

  1. Directly navigate to the change request. For example, this matches GitHub's UX when creating issues or pull requests
  2. Add a link to view the change request in the toast notification. The only app I can think of that behaves this way is Gmail when sending a message:

image

I believe option 1 makes more sense for several reasons:

  • Change requests can potentially break an application, so it's good to get the requested changes directly in front of users even if they were confident about what they requested
  • Change requests usually require approval from other people - navigating directly to the created change makes it easier to copy/paste this link and share it with other people. Copying a link from a toast message requires users to act quickly before it disappears
  • Directly showing to the change request allows users to directly assign people to it, which is presumably a very common task
  • Change requests are presumably created much less often than emails, which is why the UX should be optimised for user confidence and not volume of requests. Creating more change requests is just a "Back" away if needed
  • It's more consistent with the UX of directly updating features, which is to stay on the same feature modal (i.e. displaying the changes that were just made)

Describe alternatives you've considered

🤷

Additional context

change.request.mov
@kyle-ssg
Copy link
Member

kyle-ssg commented Jun 6, 2024

I think instead of those suggestions we should just add the link to the existing change request alert, if a user is modifying multiple features navigating to a change request would be jarring and links shouldn't really be in toast messages that disappear.

Maybe this should be an info style rather than warning.

image

@rolodato
Copy link
Member Author

rolodato commented Jun 6, 2024

we should just add the link to the existing change request alert

That was next on my list of feedback :) I agree adding the link(s) to change requests from the feature modal would help. Haven't thought about how we would handle multiple change requests for the same feature since AFAIK we can't filter change requests by target feature. Maybe we could inline each change request IDs/titles/target dates/authors/links.

if a user is modifying multiple features navigating to a change request would be jarring

I don't think this is a common scenario, especially when creating change requests that others will need to review. If an environment requires change requests to begin with, it's likely because it's sensitive and users need to tread carefully when making changes - to me this is a sign that this workflow should be optimised for confidence (i.e. immediately show the created change request for validation) rather than speed. To me, this is a similar reason why we keep the Feature modal open when directly saving changes instead of closing it - we give users confidence by staying on the page to give them a chance to re-read what they just changed.

Browsing directly to the change request makes it faster for users to share the link to the change request to others for approval, instead of needing to find where the link is on the page, or manually browsing to it and then copying it from the address bar or using a Share button.

Imagine if you're a junior developer making your first ever change request on a Flagsmith production environment - I'm fairly sure the first thing you would do after creating the change would be to browse to it, to be 100% sure that your changes are correct. Browsing directly to the change request is more reassuring and not as scary as popping up a warning box saying that there are open change requests. We know this warning box exists ahead of time, but to unfamiliar users it's not far from being a jump scare (it would still be jarring if it's an info box IMO)

I was going to suggest that another way of making changes to multiple features quickly would be to CMD+click or middle-click each feature to open them in their own tab, but this isn't actually possible - each feature in the Features list is a div and not an a so they can't be middle-clicked or CMD+clicked.

Maybe this should be an info style rather than warning

I can see the argument for either - what I like about the warning is that it warns users that any changes they make might get overwritten by existing change requests. This might not catch their attention so much if it's an info box. The same reasoning as above applies - environments that require change requests are sensitive, so I would err on the side of caution (warning).

links shouldn't really be in toast messages that disappear.

Agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Improvement to the existing platform
Projects
None yet
Development

No branches or pull requests

3 participants