Add task list component and pattern

[edwardhorsford]

Description

Adds the task list component and pattern. These are largely copied verbatim from the GOV.UK Design System, though I have made updates to refer to NHS, make the examples more relevant, or where our colour scheme differs.

As the NHS Frontend component PR hasn't been merged, this PR targets that pr in package.json. This should be removed prior to this PR being merged. For testing, you can pull this branch and run npm install and it should pick up the other work.

It's possible the component / pattern should be mentioned / listed in other bits of the app - I tried to insert it in all the places by checking where another pattern was mentioned, but it's possible I've missed places.

Component guidance

Pattern guidance

Updated tag colour examples

The tag component shows some example statuses - but these don't align with what the task list pattern uses. I've updated the two conflicting ones to align with what we and GOV.UK have.

Before	After

Related issue

This wants to be merged alongside the companion nhsuk-frontend pr adding the task list component.

Checklist

• Tested against the NHS.UK frontend testing policy (Resolution, Browser & Accessibility)
• Code follows the NHS.UK frontend coding standards
• Version number has been increased in package.json (using SEMVER)
• CHANGELOG entry
• Whats new page entry

[anandamaryon1]

A bit off-topic for this PR maybe but, I notice we have two example of an 'Active' tag, one with the default dark blue and one with nhsuk-tag--aqua-green. The task list should see more usage of these status tags so perhaps we should fix them?

[cjforms]

The task list guidance is awash with 'should' - a word that is ambiguous and does not clearly say what the reader must or must not do.

I'm happy to try to provide a version without 'should' in it but could someone give me a hand about how to do that?

Here's a specific example:
"In a task list, the user should be able to choose to complete tasks in any order that works for them."

This is somewhat incorrect, as typically users can choose some tasks straight away but others may not be available yet.

Solved by changing it to:
"In a task list, the user can see which tasks they have to do and can choose tasks that are available in any order that words for them".

[cjforms]

The guidance says "Do not use the task list for a long service that needs to be completed in a specific order. If it needs to be completed over multiple sessions, consider allowing users to save their progress, and then to continue where they left off when they return. Use the start page to explain what users will be expected to do during the service."

This is not correct. With appropriate content design, a task list will give users a sense of their overall progress in long services, irrespective of whether the service needs to be completed in a particular order. I've seen testing where the report has been 'the task list did not help here' where in fact the problem was that the content design was poor.

My suggestion is to remove this paragraph.

[edwardhorsford]

The guidance says "Do not use the task list for a long service that needs to be completed in a specific order. If it needs to be completed over multiple sessions, consider allowing users to save their progress, and then to continue where they left off when they return. Use the start page to explain what users will be expected to do during the service."

This is not correct. With appropriate content design, a task list will give users a sense of their overall progress in long services, irrespective of whether the service needs to be completed in a particular order. I've seen testing where the report has been 'the task list did not help here' where in fact the problem was that the content design was poor.

My suggestion is to remove this paragraph.

Strong agreement on this. Task list is the ideal thing to help navigate things that need to happen in a specific order.

[anandamaryon1]

Myself and @sarawilcox made some content changes in this commit: fdf75cb

In summary:

• Loosen the wording around only using the task list for multi-session transactions, thinking that one user's 'single sitting' is another's multiple sittings.
• Loosen the wording around choosing the order, to include "where possible", as sometimes a certain order is needed, which was already hinted at with the 'cannot start yet' status, and mentioned in the pattern but not task list.
• Removed the GOV research on this component and linked to theirs instead.

Feedback welcomed.

[sarawilcox]

Released today:

• task list component
• complete multiple tasks pattern

[anandamaryon1]

Released via another branch and PR in release 7.2.0