Update landing page

[matt-dray]

Use @swyatt-SU's landing-page mock-up supplied in a PowerPoint via email. Comprises of a text section and an accompanying matrix to explain the how TPMA types fall into activity type and mechanism.

As discussed, the matrix design can be tweaked but should keep its general concept. It should be generated by the code of the app (rather than a static image) so that it can respond to the browser window.

Awaiting comments/confirmation of the content before completing this task (due 1 July).

[matt-dray]

Screenshot of original mock-up from SW (click image to expand):

The text from that draft:

The Government's 10-Year Plan for Health sets an ambition to reduce reliance on hospitals and deliver care closer to where people live. But which forms of hospital care might be avoided or transferred into community settings? And how much hospital activity can be avoided?

By reviewing the evidence, talking to clinicians, and analysing data, we have identified 34 types of potentially mitigable hospital activity (TPMAs). These include care delivered in inpatient wards, outpatient clinics, and emergency departments. This activity can be mitigated through four mechanisms:

• prevention - acting upstream to improve people's health and manage their health risks
• de-adoption - stop providing treatments that are unlikely to benefit patients
• redirection/substitution - delivering care in the same or a different form in the community
• efficiency - improving the way we deliver care in hospital to reduce the time that patients spend there

This tool allows you to explore these types of potentially mitigatable hospital activity: to see the level of these activities in your area or hospital, examine trends, and geographical variation.

This app is in continuous development. Please give feedback by clicking the link in the top-right.

Updated visual by MB (not finalised) drafted for use in a web page supporting the app (click image to expand):

Notes on the visual (waiting for confirmation):

• in the mock-up that Steven sent, 'end of life care admissions' is shown under inpatients redirection/substitution, not de-adoption (Edit: turns out this was a mistake in the creation of the MB version above)
• the spreadsheet of new names from Steven includes 'ambulatory emergency care' in inpatient efficiencies, which is missing from this image (which brings the count to 35 TPMAs) (Edit: I forgot to filter out deprecated TPMAs.)

[swyatt-SU]

I think we dropped 'ambulatory emergency care' when we introduced the 'same day emergency care' TPMA.

[swyatt-SU]

@matt-dray Re Mahmoda's image. If we were to use colour to signify the setting (rather than the mechanism) then we could collapse the rows and save space. Not sure if how this would look. Worth a try?

If we did this we wouldn't need row headings, but would need a key/legend.

[matt-dray]

Ah, of course, I clearly forgot to filter out the deprecated TPMAs.

Re the image, I think we'll have to play about a bit once we get started. Icons could also help, but I don't think the categories map well to specific icons (and it might look a bit twee anyway).

[DCEW]

Just to note that for accessibility guidelines, information cannot be conveyed through colour alone, so as long as the legend is clear and obvious, that should be ok I think?

[Lextuga007]

To ensure the TPMAs are correct and up to date consider reading from the lookup that's (currently in PR) in the TPMAs repo.

[matt-dray]

To note, @Lextuga007: later today I'll be raising a new PR with the draft lookup (The-Strategy-Unit/TPMAs#11 was erroneously merged).

Edit: the new PR is The-Strategy-Unit/TPMAs#14 and the lookup is https://github.com/The-Strategy-Unit/TPMAs/blob/10-lookup-update/reference/tpma-lookup.csv

[Lextuga007]

I shared the initial mock with @swyatt-SU along with a view where Inpatient, Outpatient and A&E are along the top rather than down the side. Confirmed the requirements are that the important information is the Prevention, De-adoption... , needs to fit one page and the image can be static with no requirement for links.

Colour coding the IP, OP and A&E had been discussed in order to put all TMPAs together. This removes the white space from the original image which has issues in accessibility for screen readers, keyboard users and neurodiversity understanding/readability.

Because the use of colour to convey meaning has accessibility implications I've added text tags for the categories to the TMPAs

and published on (restricted access) Connect with the code bundle. Before adding as a PR I need to check the colours for accessibility, particularly when used together.

[matt-dray]

Thanks for thinking about this and preparing mock-ups, Zoë.

Once the style is agreed, it would be great to see how this looks in the app proper. There'll be a little less horizontal and vertical space to play with given the navbar and the need for a box containing the explanatory text that Steven provided (see first comment in this thread).

You may also find that there are {bslib}-native components (card(), value_box(), layout_columns()) to generate the TPMA 'cells' instead of bespoke CSS.

[matt-dray]

Thank you @Lextuga007 for making headway on this and for starting a branch to add this content. I had a little look and have a couple of suggestions. You may already have been thinking about some of these things!

No action required:

1. Don't worry about using {bslib}-native elements for the cells of the TPMA matrix. I suggested it so that colours, etc, could be more easily controlled with global values, but it can be left for Standardise the design/theming of the app #30.

Re design:

2. I reckon the explanatory text on the Overview page is important enough to be visible in its own card() in the main area of the page (as per Steven's diagram above), rather than in a sidebar. The matrix card can get a full-screen button so it can be expanded by the user.
3. I set up a global sidebar for the app that auto-opens and closes depending on the selected page. I think the Overview page doesn't need a sidebar, but if modularised (see point 5 below) then the default sidebar will be inherited. Really, the default sidebar should just be disabled entirely on pages that don't need it, so I've created Do not show sidebar on pages that don't need it #210.
4. The new CSS interferes subtly with existing style: the sidebar accordions now have a box around them (unlike current live deployments).

Re file structure:

5. The app uses Shiny modules to keep code separated and easier to maintain. The Overview content could be in its own module, which would help leaveapp_server.R as clean as possible. Yes: the Context and Information pages are pure UI and don't have their own modules, but the Overview page has server code, so should probably be in its own module.
6. The CSS is perhaps better in its own CSS file so it isn't taking up space in the app_ui.R script.

Might be easier to chat if you have any questions.