Creating a new workspace should also switch to it

Extended the patch with changes in tests which made all tests pass for me locally (didn't run functional JS tests though). From my point of view this is RTBC, as there's no benefit in remaining inside the live workspace when creating a new workspace, or at least it's more beneficial to switch to the created workspace in most scenarios.

hm i am not sure. leaving the user the option might be a good choice. an easy way might be to add a checkbox to the add workspace page. that could be set per default to something like "switch to the new workspace" (not the suggested wording). so the default behavior would be like what the patch is introducing but still there would be the option for the user to uncheck and remain in the current workspace?

Uploading the right patch...

Fixed failed commands on #8

Not sure, but I think it's enough if tests pass on 10.1.x to get this in, right?

Hi,

I'm afraid this feature as it is in patch #9 is definitely a no-go. There a couple of major issues here that fail Nielsen's #1 usability heurestic:
Visibility of system status: "Communicate clearly to users what the system’s state is — no action with consequences to users should be taken without informing them."

1) The same action "Save" should always render the same result: save. If the button does something else, it should be indicated by the button. This relates also to "recognition rather than recall" principle as there is no information given that a switch would happen.

Possible solution: Add another button saying "Save and switch" but keep the option for user to only "Save" as well

2) Saving and switching does not sufficiently inform the user about switching workspace. When user switches a workspace one of the two status messages is displayed (I don't really understand why the difference between the messages for Live and others):

Status message
Third is now the active workspace.

Status message
You are now viewing the live version of the site.

but neither of these messages are displayed when user creates a new workspace while on Live workspace. In that case the message is same with "normal" save action:

Status message
Workspace Fourth has been created.

Possible solution: display both the creation message and the switching message if user clicks "Save and switch".

3) If user switches workspace there is dialogue confirming that user wants to switch to another workspace. There is no confirmation when user saves a new workspace and is switched automatically. This is inconsistent behaviour and especially important as there is no indication in advance that the workspace would be switched. If there is a separate action button for the double action, then this is mitigated.

(Also there is a technical possibility to create workspaces named "Live" where the only change in UI would be the change of background colour in the workspace indicator - but this is not a real problem, only a theoretical case. Could be an April fools joke but not a real use case...)

thanks for implementing the suggestions! i've manually tested, overall it looks good, there is only one small detail i've noticed. The newly added button Save and activate is using the verb "activate" while on the workspaces overview page Switch to... is used on the buttons with "switch" as the verb. Technically if you click the Switch to... button on the overview page you get "Activate the ... workspace" on the confirmation page step. For the Save and activate button that confirmation page step is not necessary and the workspace is directly activated which is a good thing. But still that inconsistency of the used verb might be potentially confusing to users and being consistent here might help?

thanks for the fast turn around! yep i agree technically both variants work and as you said save and activate "slightly" sounds better but in regards of consistency Save and switch is the preferable choice imho. plus i've just noticed back then in the ux review we've also agreed on Save and switch (ref #15). So this issue looks good to go from a manual testing perspective, but not sure if i am eligible to rtbc it or if still someone has to take another look at the code?

Applied some small suggestions to the MR. Will mark after the tests run.

All green!

Not entirely convinced by the ::create trick but it does remove a tonne of boilerplate and it's very easily reversible if we want to override the constructor again.

Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!

I’ve seen it a few times in contrib modules nothing breaks but phpstorm complains about the typehint