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

[Website] Rename Create a similar Playground to Edit Playground settings #1834

Closed
wants to merge 6 commits into from

Conversation

bgrgicak
Copy link
Collaborator

@bgrgicak bgrgicak commented Oct 1, 2024

Motivation for the change, related issues

@annezazu asked why we don't support changing settings on temporary Playgrounds after the redesign.
We do, but the label is called Create a similar Playground which is technically correct but might not be clear to users.
We concluded that the label should be Edit Playground settings even if it's not 100% technically correct.

Suggested improvement

For users it might not be fully expected that the site will be cloned, so I added a modal that clarifies what clone does and added support for resetting the site with new settings.

Ideally, we would only change the settings and keep the same site, but we can't do it until we implement site cloning.

Implementation details

TBD

Testing Instructions (or ideally a Blueprint)

  • CI

@bgrgicak bgrgicak requested a review from a team October 1, 2024 07:04
@bgrgicak bgrgicak self-assigned this Oct 1, 2024
@bgrgicak bgrgicak changed the title [Website] Confirm settings update before reseting a temporary site [Website] Rename Create a similar Playground to Edit Playground settings Oct 1, 2024
@brandonpayton
Copy link
Member

@bgrgicak, I think our original plan was to support both "Edit Playground settings" and "Create a similar Playground".

The reason IIUC is that we want to allow people to change their selected WordPress version without having to destroy their current Playground instance. But maybe that doesn't make sense because switching to a site with a different WP version means they have to leave the current temporary site behind, unless we do something to bring its data into the fork.

If we do this PR, maybe we should add a warning if the WordPress version is changed that it is a destructive action. What do you think?

@adamziel
Copy link
Collaborator

adamziel commented Oct 1, 2024

@brandonpayton it's not a destructive action, it just creates another Playground. The "Edit Playground Settings" label is slightly confusing, but I think that's an okay price to pay for getting the user to the modal they're looking for. I also can't think of any better alternative for now – any ideas?

@brandonpayton
Copy link
Member

@brandonpayton it's not a destructive action, it just creates another Playground. The "Edit Playground Settings" label is slightly confusing, but I think that's an okay price to pay for getting the user to the modal they're looking for. I also can't think of any better alternative for now – any ideas?

Ah, you're right. Thanks. Ultimately, maybe it would be good to keep WP source files and wp-content separate, so we could replace WP source files without affecting wp-content.

Until we are able to swap out WP versions, I wonder if we should edit site settings in place and make saving with a new WordPress version a destructive action with a warning. As a user, I might find it confusing that editing settings led to a new entry in the Playground Manager.

@adamziel
Copy link
Collaborator

adamziel commented Oct 1, 2024

Ah, you're right. Thanks. Ultimately, maybe it would be good to keep WP source files and wp-content separate, so we could replace WP source files without affecting wp-content.

Oh that sounds lovely, I like that!

Until we are able to swap out WP versions, I wonder if we should edit site settings in place and make saving with a new WordPress version a destructive action with a warning. As a user, I might find it confusing that editing settings led to a new entry in the Playground Manager.

@brandonpayton Interestingly, that's how this PR started! It went back to just changing the label upon discussing that's not actually a destructive change, but I see how actually making it destructive could, paradoxically, make for a more intuitive behavior. 🤔 Yeah, let's try that.

@brandonpayton
Copy link
Member

@brandonpayton Interestingly, that's how this PR started! It went back to just changing the label upon discussing that's not actually a destructive change, but I see how actually making it destructive could, paradoxically, make for a more intuitive behavior. 🤔 Yeah, let's try that.

Yeah, this is tricky territory whichever way we go, until we can swap WP versions in-place.

@bgrgicak
Copy link
Collaborator Author

bgrgicak commented Oct 2, 2024

I also can't think of any better alternative for now – any ideas?

What about just Settings?

@bgrgicak bgrgicak force-pushed the update/site-edit-label branch from 5acd0d7 to 5719a49 Compare October 2, 2024 11:43
@bgrgicak
Copy link
Collaborator Author

bgrgicak commented Oct 2, 2024

@brandonpayton @adamziel what do you think about this modal?

Screenshot 2024-10-02 at 17 03 38

I wanted to add a modal and implement resetting, but then realized there is a TODO to allow users to choose, so I made this. I'm not sure if it's a good flow for users and would also like to check with @jarekmorawski.

@bgrgicak
Copy link
Collaborator Author

bgrgicak commented Oct 2, 2024

TODO:

  • update tests once we decide it we want to use the modal.

@mattreport
Copy link

IMO if the user was able to click into the WordPress Version and switch, which then prompted the confirmation modal, that makes the most sense.

Though I'd also settle for calling it "Settings" as well :)

@brandonpayton
Copy link
Member

@brandonpayton @adamziel what do you think about this modal?

@bgrgicak thanks for the picture. I think that seems like a reasonable dialog to have with users. If we only show it when certain settings change, it would probably be good to mention specifically why they are being prompted.

Alternately, maybe we should invest some time into separating WordPress source files from wp-content so we can replace WP source files without affecting existing data, plugins, and themes stored in wp-content.

If we were able to do that, could we skip the prompt entirely? Any thoughts on that?

@brandonpayton
Copy link
Member

IMO if the user was able to click into the WordPress Version and switch, which then prompted the confirmation modal, that makes the most sense.

@mattreport, thanks for chiming in! I think you might be right that we could just prompt when making changes that require a reset.

Hopefully we can get to a place that doesn't require resetting site state as well.

@bgrgicak
Copy link
Collaborator Author

bgrgicak commented Oct 3, 2024

If we were able to do that, could we skip the prompt entirely? Any thoughts on that?

Alternately, maybe we should invest some time into separating WordPress source files from wp-content so we can replace WP source files without affecting existing data, plugins, and themes stored in wp-content.

If we were able to do that, could we skip the prompt entirely? Any thoughts on that?

We would need to cover the full list of settings. I don't think that we support switching language today or toggling multisites after the site is created. Alternativly we could remove some of these from editing settings and offer them only in the Add Playground modal.

@adamziel adamziel force-pushed the trunk branch 2 times, most recently from 680cd19 to 2e376d2 Compare October 4, 2024 09:24
@bgrgicak
Copy link
Collaborator Author

bgrgicak commented Oct 7, 2024

@adamziel I'm closing this one in favour of #1854

@bgrgicak bgrgicak closed this Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

4 participants