Task list component

[frankieroberto]

This adds a new component for the existing Task list pattern, which is widely in use by services. (At the moment, this requires custom code, such as is included in the GOV.UK Prototyping Kit).

The component can be used to create a single task list. Multiple task lists can be added, with headings, to create a task list page, where there are groups of related tasks.

This component was developed collaboratively by the cross-government Task list group, based upon the research and experience of teams using the pattern in live services.

Some changes were made based upon feedback from service teams:

• the whole 'row' of the task is clickable, as in research some users have been observed clicking the status text
• the status tag was redesigned to no longer user uppercase text, and to use lighter colours - this was done separately in PR #3502
• there is an option to use plain text instead of a tag component for a task status - this is intended for 'completed' tasks, as they don't need as much attention drawn to them
• tasks can be made non-clickable – this is intended for tasks with a status of 'Cannot start yet'.

Thanks to

@ImranH-GDS @owenatgov @MK-NG @steve-oconnor @Dawdre @lfdebrux @frankieroberto @christopherthomasdesign @calvin-lau-sig7 @36degrees @timpaul @paulrobertlloyd and many others!

[frankieroberto]

One of the questions for this component is what do we call the param that holds the array of things with statuses?

Our initial instinct was to use rows to match Summary List and because they look like rows (horizontally divided).

However I've done a quick check of what existing components use:

Accordion: items
Breadcrumbs: items
Checkboxes: items
Error summary: errorList
Footer: items, navigation
Header: navigation
Radios: items
Summary List: rows, actions
Table: rows, head
Tabs: items

Based on this, I wonder whether it would be more consistent to use items instead? That would also not tie us to a particular visual style, should the component evolve in future to render differently.

[frankieroberto]

GDS wrote a summary back in 2017 of some of the pros and cons of using Tables, Definition lists and Lists.

[frankieroberto]

We might want to add role=list to the <ul>, see alphagov/govuk-prototype-kit#1009 cc: @edwardhorsford

[frankieroberto]

Here’s the original PR which added the task list to the Prototyping Kit.

[frankieroberto]

One of the questions for this component is what do we call the param that holds the array of things with statuses?
[...]
Based on this, I wonder whether it would be more consistent to use items instead? That would also not tie us to a particular visual style, should the component evolve in future to render differently.

I've switched to items as the param name in 181273d, based on the following rationale:

• 6 components use items vs 2 that use rows
• Consistency with the HTML tag name (<li> - "list item") and CSS class name (govuk-task-list__item)
• More generic, not tied to visual appearance

[frankieroberto]

@36degrees I think I’ve made all the changes - thanks for spotting them all! 👏

Would you mind approving the test workflows, and checking and re-reviewing the code? Thanks!

[36degrees]

This looks good – thanks for all your hard work on this @frankieroberto 🙌🏻

A few final things to sort:

• We need to add a changelog entry to tell users know about this exciting new component!
• Ideally we'd improve the commit structure, ideally reducing to a small number of meaningful commits and removing the merges. Is that something you'd be comfortable doing? I'm happy to do this for you if you'd prefer.
• It'd be good to add some more tests to cover the various different macro options to ensure they're working as intended. This is a little laborious, so I'm happy to create an issue for our team to do this in a follow up PR unless you're particularly keen to be involved?

[36degrees]

It'd be good to add some more tests to cover the various different macro options to ensure they're working as intended. This is a little laborious, so I'm happy to create an issue for our team to do this in a follow up PR unless you're particularly keen to be involved?

Discussed this with @frankieroberto and have raised an issue for us to do this (#3828).

I believe the other points have been addressed. This just needs a second review and then we can get it merged – @owenatgov would you be happy to take another look?

[owenatgov]

My final extremely pedantic review comment is that the hint param still needs a description. Once that's done then I'm more than happy to approve this.

[frankieroberto]

@owenatgov:

My final extremely pedantic review comment is that the hint param still needs a description. Once that's done then I'm more than happy to approve this.

Fixed (squashed the commit and force-pushed) - thanks for spotting.

[owenatgov]

Well done everyone 🎉