Summary list

[GrilloPress]

What

Use this issue to discuss the summary list component in the NHS digital service manual

---

The Summary list component is an established GOV.UK component in use in various GOV services as well as live in the National data opt-out service service.

It is also in use in an alpha service for the "Check your personal details" part of the audit and transparency foundation service/s.

The summary list component is a key element of the GDS pattern to help users to "check answers".

Why

Many transactional services need to have users check data before submission, or check data against a question or criteria, and the summary list is an established component for doing this.

Having the summary list component and related macro would:

• speed up development
• ensure services don't have to recreate their own versions/interpretations of this component
• make it easier for services to build key/value <dl> lists
• make it easier to make <dl> lists accessible and well structured

Where has this been tested

Across gov. This component has been tested across numerous GOV services and internal case working systems.

In the NHS this has been tested in the national data opt-out service:

• with 20+ users in various labs
• as part of remote unmoderated A/B testing with 50 users
• as part of the live service since October 2018 (thousands of users etc.)
• as part of three accessibility audits (with 15 people)

It has also been tested in the new frontend in the "Check your personal details" service:

• with 2 users in a pop-up
• 5 users in a lab

Issues reported: None

Other links

For the audit and transparency set of services I have created a proof of concept fork of the GDS component:

• scss for the component
• macro for the component
• list in example page
• list in alpha service

[GrilloPress]

Recreated issue from nhsuk/nhsuk-frontend#384

[ShaneHudson]

We use a custom version of this exact component on 111.nhs.uk in production as of last week. As a “confirm your details” screen for booking a call.

[LydiaTeebay]

We use this in the NHS login Delegated Access prototype for a summary page before a primary user sends their invite to the delegate. The width of the first column feels squashed but UR has found that we can't put it into one word such as "delegate name".

[GrilloPress]

One of the things I've done with other teams is add a few adjustment classes.

Things like making keys a full block if the question is really long, so the question sits on top of the answer.

Similarly, if you have lots of complex, policy-driven questions... you can't always get the word count down or use a placeholder phrase. So I have adjusted the size of the key.

[devansXD]

I would like to see a version of this which helps users scan services selected. On eRS ive gone with a simple list, but having service details next to it would be helpful. I havent gone down the table route as I thought this was overkill for a simple check/review page.

[devansXD]

Similarly, I think a version which has inline / page editing would be useful. I'm struggling to find examples of inline editing anywhere, especially one thats accessible out of the box.

[theonlymojo]

We've published guidance about the summary list in the service manual - https://service-manual.nhs.uk/design-system/components/summary-list

We've labelled it as experimental as we want more research to prove it works well in a health context.

Moving this issue to published but please do keep contributing within this thread as and when you have evidence of using the summary list component.

[samanthasaw]

Hi on the NHS App we are now using the summary list component for the users' personal details on the home screen.
The 'out of the box' code means there's quite a big gap between the key and the value on desktop:

In the prototype we'd added some custom classes to make this gap smaller.

Is there a reason there is a big gap? We feel that it risks making the key and value look unrelated?

[davidhunter08]

Hey @samanthasaw, I did a quick comparison of your App 'out the box' example and a prototype kit example and there looks to be a big difference in spacing between the key and value. Can you confirm if the summary list component in your example is within a full-width or two-thirds sized column?

It looks like the spacing is well worth reviewing. I'm thinking we'd need consider how reducing the spacing would affect longer key terms such as "Offered a free flu jab" or "Asthma that is difficult to control". Does the App have any examples of a summary list using longer key terms than "Date of birth"?

[samanthasaw]

Hi @davidhunter08

Here's the mark up if that's helpful, it's in 2 thirds

[samanthasaw]

@davidhunter08
On this:

Does the App have any examples of a summary list using longer key terms than "Date of birth"?

The only other example I've got is checking the prescription items selected before ordering. This has not been built yet so this is a screenshot from the prototype. There's no custom classes on this. So 'Notes for your GP surgery' is longer than 'Date of birth'

[samanthasaw]

@davidhunter08
And actually (forgot this one!) our latest check your appointment details design (also not yet built in live) features a summary list, again no custom classes, with some longer keys than 'Date of birth'

[davidhunter08]

Hi @davidhunter08

Here's the mark up if that's helpful, it's in 2 thirds

Thanks @samanthasaw, could you share a link to this page?

[samanthasaw]

@davidhunter08 I don't think I can send you a link as it's only on our preview environment. We would need to whitelist your IP address for you to access, let me check with the team and get back to you

[danjohnstonUX]

We've had a query regarding the spacing of the summary list from one of our testers. Is there a 'correct' column layout to use this component within, or is it flexible based upon the context in which it's being used? I can see that two-thirds columns have been mentioned here, but the example at https://service-manual.nhs.uk/design-example/summary-list?fullpage=undefined uses the full width.

For context, we currently have it set to occupy the full width of the parent container:

[samanthasaw]

On the NHS App our testers found an issue with visually hidden text.
They found that the hidden text wasn’t reliable on Android (including on the example NHS page https://service-manual.nhs.uk/design-system/components/summary-list) in that it would sometimes read out the visible part separately from the invisible part.
They've used an aria-label instead which they confirmed works as expected.
Video shows the problem, it was reading out the first Change link incorrectly but the second one correctly. But on iOS and jaws it worked fine.
https://user-images.githubusercontent.com/38656667/108178567-7ca21a80-70fc-11eb-9b28-e7153ac469b2.mov

[Spencerooni]

Here is a clearer example of the visually hidden text from the summary list not being very useful when read out on an Android tablet with talkback enabled.

video-1613563729.mp4

[chrimesdev]

Hi @samanthasaw & @Spencerooni thanks for raising this, I've opened a issue on the NHS.UK frontend library; if you want to add any more information nhsuk/nhsuk-frontend#704

[Fenwick17]

The profile manager will be doing some user research around the Govuk Summary Card component https://design-system.service.gov.uk/components/summary-list/#summary-cards

This is a slightly different design to the usual summary list component and is designed for when you need to display multiple summaries on a page.

There has been a lot of discussion in the govuk design system backlog around this prior to their merge, including feedback from their working group alphagov/govuk-design-system-backlog#210

[sarawilcox]

Here's an example from the Profiles team. See comment above.

[wellhairy]

Hi. I've been working on making the summary list more uniform. I ended up re-writing a lot of css using grid. I'm not sure how we plan to implement this so i've left it as a modifier with a prototyping prefix. This is a link to the scss. Some of this works by moving the border to the row and creating a layout through the use of css grid. This implementation addresses three main points:

• Removing the border from __key, __value and action (DTs and DDs) and setting on the __row means the border maintains a consistent width regardless of every item needing an action.
• This implementation allows the use of multiple values (DDs).
• and sets a fixed width on __keys and __actions so items are a consistent length across multiple Summary lists (DLs) on a page.

You can see a live version of these modified summary lists working in our prototyping toolkit or in the screenshots below
user: prototype
pass: prototype

Current implementation

Example from prototyping toolkit at desktop

[Fenwick17]

In our next round of UR within the Profile Manager are testing a variation of the summary list which govuk-frontend has. We are looking at their Summary Card variation.

This can be used when you have numerous summary lists relating to different pieces of information to potentially make it easier to understand.

Feedback will be provided after we do our testing.

[nir-github]

Are there any examples with multiple actions on summary list? Just wanted to know is there a way to customise the pipe (|) separator in multiple actions.

[wellhairy]

@Fenwick17 Just a small comment on your design above. The gov.uk summary list uses a H2 to title their summary lists and encapsulates it's content visually. I wonder if the content under "Services in this clinic" needs a summary title of "services" if it's being titled by the heading. I've attached a couple of examples of what i mean.

I think it's also possible that the content in "services in this clinic could be presented as a UL or OL in the same container. I dont have the full context of your work so please take this with a pinch of salt.

It'll be interesting to hear your feedback after testing. It'd be great to have more ways to present definition list content consistently.

Not that similar to this but we did some work that presented a user with multiple groups of definition lists

There wasn't any follow up after our first round of testing but it was clear that this visual separation helped user to quickly identify different areas of information.

[mapi2]

Following on from the recent comments from @Fenwick17, the Profiles team tested the design with 5 pharmacy profile managers. We tested it within our set up journey as part of the Service opening times feature for the NHS Profile Manager, and then also asked users to compare the design side by side with the current/live implementation of the summary list.

Feedback summary:

Set up journey
The design tested received very similar and positive feedback to the current version of the page in previous testing

• All participants understood that this page provides a summary of the information you have selected, and understood they could edit any information by selecting change.
• Participants viewed this positively and saw the value in being able to make any amendments before confirming.
• All participants navigated to and from this page with ease.

Side by side comparison

• Recognition - Half of participants correctly identified which confirmation page they did see in the set up journey. Knowing this did not impact their preferences, with most users who thought they saw the existing version favouring the new version. Only 1 user recognised the current version as the version that is currently used in PM.
• 3 participants preferred the new design, 1 preferred the current design. (one session ran out of time to test these side by side)
• All acknowledged there is not a great deal of difference between them which means decisions were often based on a version one element being preferred to the other.
• All were aware that both versions have the same functionality

Reasons participants preferred current version:

• clearer list of services with more spacing (especially in our example with long service names). However, it's worth noting that our prototyped new design wasn't as refined so the spacing didn't align directly with the GOV design. In the real thing we’d ensure we’re using the accurate amount of spacing.
• Initially didn't see the headings on new version (a bit smaller?)
• Change options more readable
• 'Quick, easy, punchier' headings compared to question-based headings in new version.

Reasons participants preferred new version:

• White and grey backgrounds make the presentation of info cleaner/clearer
• Box structure helps to break out each info type
• Question-based headings are simple and easy to understand.

[steph-w-nhs]

Following a few conversations with other designers, we have decided to follow the behaviour that when a user changes their answer from a summary page, on pressing 'continue' they will be taken back to the summary page -- as opposed to progressing through the form again.

This follows gov guidance: https://design-system.service.gov.uk/patterns/check-answers/
"When they’ve finished, the ‘Continue’ button should return them to the check answers page. They should not need to go through the rest of the transaction again."

We will do this for future releases of NHS health assessment tools (https://www.nhs.uk/health-assessment-tools/)

Example screenshot from the Heart age calculator (which has many inputs).