CDPT-1939: Splash page

[EmilyHazlehurst]

• Redirect users to a simplified version of the agency switcher when they don't have a cookie set.
• Allow users access to the accessibility and privacy policy pages before setting a cookie, but use the simplified header

[EarthlingDavey]

This works really nicely locally, I've added a few comments.

In addition to those, do you think it would be worth bringing an extra feature into the scope of the ticket? ...

The user could be redirected to their page after selecting an agency on their first visit.

This could be useful if a link to a specific intranet page is circulated via email. Otherwise, after opening a link, a new intranet user will always land on the homepage.

---

It could work similarly to what happens when a specific admin page is accessed by a logged out user.

e.g.

http://intranet.docker/wp/wp-admin/edit.php?post_type=page

redirects to

http://intranet.docker/wp/wp-login.php?redirect_to=http%3A%2F%2Fintranet.docker%2Fwp%2Fwp-admin%2Fedit.php%3Fpost_type%3Dpage&reauth=1

and after a successful login, the user is redirected to their original page.

[EmilyHazlehurst]

This works really nicely locally, I've added a few comments.

In addition to those, do you think it would be worth bringing an extra feature into the scope of the ticket? ...

The user could be redirected to their page after selecting an agency on their first visit.

This could be useful if a link to a specific intranet page is circulated via email. Otherwise, after opening a link, a new intranet user will always land on the homepage.

It could work similarly to what happens when a specific admin page is accessed by a logged out user.

e.g.

http://intranet.docker/wp/wp-admin/edit.php?post_type=page

redirects to

http://intranet.docker/wp/wp-login.php?redirect_to=http%3A%2F%2Fintranet.docker%2Fwp%2Fwp-admin%2Fedit.php%3Fpost_type%3Dpage&reauth=1

and after a successful login, the user is redirected to their original page.

Thanks for reviewing @EarthlingDavey!

I did consider this. The reason I decided against it in the end was because of the way agency branding works on the intranet.

Just as an example, I'm a new hire who hasn't accessed the intranet before:

• I get a link to a generic HR page on the HQ intranet but I'm in HMCTS.
• When I click that link, select my agency then get sent back to the link I see the HQ page with the HMCTS branding at the top.
• I then click HR and can't find that page anymore because it's not part of the HMCTS intranet.

I suppose they're going to have that confusion anyway though once they go back to the link that was shared originally...

Maybe this can stay as is for now, but I'll make an improvement ticket? There might be a bigger discussion to be had around how shared content is handled on the intranet.

[EarthlingDavey]

Hey @EmilyHazlehurst , I see that there probably isn't a perfect solution to this - especially while there is the underlying issue/feature of an agency's page being branded as whichever one has been selected in the agency picker.

I do think that we should be cautious that, while aiming to improve the UX, we in fact degrade it for a subset of users.

---

In terms of new users clicking a link in Slack or an email:

Currently:

Pro: they will get to the correct page
Con: it will always have the default agency of HQ.

With this PR:

Pro: the user will pick an agency
Con: but they will land on the homepage.

This could be confusing to the user, best case scenario they will re-click the link, worst-case scenario they assume that the link is broken.

With a redirect:

Pro: the user will pick an agency and land on the correct page
Con: In cases where the picked agency is not the same as the agency that published the content, we could see the issue that you described, i.e. navigation will not make sense.

I feel like the downside in this case is the lesser of all 3. As the end result is that the user finds the content that was linked.

[wilson1000]

This works really nicely locally, I've added a few comments.
In addition to those, do you think it would be worth bringing an extra feature into the scope of the ticket? ...
The user could be redirected to their page after selecting an agency on their first visit.
This could be useful if a link to a specific intranet page is circulated via email. Otherwise, after opening a link, a new intranet user will always land on the homepage.
It could work similarly to what happens when a specific admin page is accessed by a logged out user.
e.g.
http://intranet.docker/wp/wp-admin/edit.php?post_type=page
redirects to
http://intranet.docker/wp/wp-login.php?redirect_to=http%3A%2F%2Fintranet.docker%2Fwp%2Fwp-admin%2Fedit.php%3Fpost_type%3Dpage&reauth=1
and after a successful login, the user is redirected to their original page.

Thanks for reviewing @EarthlingDavey!

I did consider this. The reason I decided against it in the end was because of the way agency branding works on the intranet.

Just as an example, I'm a new hire who hasn't accessed the intranet before:

• I get a link to a generic HR page on the HQ intranet but I'm in HMCTS.
• When I click that link, select my agency then get sent back to the link I see the HQ page with the HMCTS branding at the top.
• I then click HR and can't find that page anymore because it's not part of the HMCTS intranet.

I suppose they're going to have that confusion anyway though once they go back to the link that was shared originally...

Maybe this can stay as is for now, but I'll make an improvement ticket? There might be a bigger discussion to be had around how shared content is handled on the intranet.

Hey @EmilyHazlehurst @EarthlingDavey

Thank you both for the wonderful discussions here!

There is a bigger discussion to be had around the working of links clicked.

Davey's suggestion sits best, as we know at the point of click where the user wants to be. We shouldn't be creating additional clicks for them, especially if they have been given a link (as a new starter) that is HQ content. Lots of HQ content is still relevant in the HMCTS context so again, we should allow the user to navigate to the content they are trying to view, under the banner of the intranet they are expecting.

Please also bear in mind that heavy user research has been applied in this very area. The intranet is operating as it does today as a result of this user research.

With that said, I am very open to a discussion about best practices here, we may indeed be limiting the user experience. If we decide that usability is degraded as a result of the current working, we should make moves to engage our User Research colleagues to determine the best and most up-to-date ways of operation.

[EarthlingDavey]

Hey @EmilyHazlehurst , I've seen a couple of minor snags when testing the changes locally.

1. I think we need to exclude /agency-switcher/ from nginx's cache - as the content depends on the user's state.
   This can be set in deploy/config/local/nginx/server.conf and deploy/config/nginx.conf.
   To test your config changes you'll need to restart the nginx container.
2. It looks like the cookie wasn't setting for me. For example if I clicked an internal agency, it would show that agency but a cookie wasn't set, and navigating around the site would send me back to the agency switcher page.

Would it be possible for you to check those points, and then I'll re-review?

[EmilyHazlehurst]

Hey @EmilyHazlehurst , I've seen a couple of minor snags when testing the changes locally.

1. I think we need to exclude /agency-switcher/ from nginx's cache - as the content depends on the user's state.
   This can be set in deploy/config/local/nginx/server.conf and deploy/config/nginx.conf.
   To test your config changes you'll need to restart the nginx container.
2. It looks like the cookie wasn't setting for me. For example if I clicked an internal agency, it would show that agency but a cookie wasn't set, and navigating around the site would send me back to the agency switcher page.

Would it be possible for you to check those points, and then I'll re-review?

Thanks @EarthlingDavey, that's odd it was working for me 🤔 I'll take a look and get back to you 🙂

[EarthlingDavey]

Potentially you were not getting cached pages for a different reason, like having a WordPress login cookie.

[EmilyHazlehurst]

Hey @EmilyHazlehurst , I've seen a couple of minor snags when testing the changes locally.

1. I think we need to exclude /agency-switcher/ from nginx's cache - as the content depends on the user's state.
   This can be set in deploy/config/local/nginx/server.conf and deploy/config/nginx.conf.
   To test your config changes you'll need to restart the nginx container.
2. It looks like the cookie wasn't setting for me. For example if I clicked an internal agency, it would show that agency but a cookie wasn't set, and navigating around the site would send me back to the agency switcher page.

Would it be possible for you to check those points, and then I'll re-review?

Thanks @EarthlingDavey, that's odd it was working for me 🤔 I'll take a look and get back to you 🙂

@EarthlingDavey I'm still not able to replicate this locally. It works correctly for me even after rebuilding everything and accessing the site in private browsing mode.

Please could you describe the steps you're taking? Are you logged in/out?

[EarthlingDavey]

Hey @EmilyHazlehurst , thanks for confirming and sorry for the bad advise!

The problem was with my local setup, having previously used https locally, and now http, the agency cookie was not being set.

This is now sorted and the functionality looks like it's working! I'll review then code now and feedback ASAP.

[EarthlingDavey]

Looks good, just a few comments, with the send_back one requiring a change.

[EarthlingDavey]

LGTM :)