-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tasklist component #1173
Add tasklist component #1173
Conversation
6ebd342
to
06f6531
Compare
06f6531
to
913ad02
Compare
913ad02
to
319cc4d
Compare
319cc4d
to
e7bbe5a
Compare
This will need a design review. |
Can you list what devices/browsers (including assistive tech) this has been tested with? |
It's gone through numerous iterations with Kate, including a couple of pairing sessions to tweak things. Mia's also seen it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This generally looks okay to me. My biggest question is: what's happening with commonisation with the accordion? We now have the same code floating about in a couple of places, and it would be good to graduate the Accordion to Static, and - if possible - even use that component as the basis for this component.
@@ -0,0 +1,3 @@ | |||
<?xml version="1.0"?> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this stuff all the same as Collections? Can you please make sure you raise a ticket to remove it from Collections (along with things like current-location.js
, history-support.js
, etc.)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Funnily enough, I've already started work on a PR in collections that removes this JS, but I've been waiting to get this all approved and merged first. Good point on the images though, hadn't thought of those.
} | ||
}; | ||
|
||
var rememberOpenSection = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I would personally find this easier to understand if it was var shouldRememberOpenSection = false
and then use the !!
operator to turn .length
into true
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion, thanks, will change.
<% if steps %> | ||
<div | ||
data-module="tasklist" | ||
class="pub-c-tasklist js-hidden <% if not small %>pub-c-tasklist--large<% end %>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please prefer !
over not
? Or better yet, prefer unless
over if !
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will change to 'unless'. I'm afraid that's my limited Ruby experience showing..
<% steps.each_with_index do |step, index| %> | ||
<% | ||
step_active = false | ||
step.each do |this_step| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you enumerate on a single step
? I find this naming confusing. Why do we have steps
-> step
-> this_step
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, if this whole loop construct exists to determine step_active
, then a more idiomatic way to achieve this is something like:
step_is_active = step.any? do |this_step|
this_step[:panel_links].to_a.any? { |s| s[:active] }
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I knew there must be a cleaner way of doing this. Thank you!
end | ||
end | ||
%> | ||
<li class="pub-c-tasklist__step <% if step_active %>pub-c-tasklist__step--active<% end %>" <% if step_active %>aria-current="step"<% end %>> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I personally prefer removing the need for end
like so: class="<%= 'pub-c-tasklist__step--active' if step_active' %>"
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, my Ruby knowledge. That's helpful, thanks. I'm definitely learning..
section_count = 0 | ||
%> | ||
<% if steps %> | ||
<div |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This whole file is hugely nested. Potentially consider breaking up into smaller partials.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a bit. I'll try some extra line spaces first to see if that helps.
e7bbe5a
to
2dfa02d
Compare
2dfa02d
to
f865ebd
Compare
Fair comment @alecgibson about the duplication of accordion code. This all relates to alphagov/govuk-rfcs#84, if we move components into static it then breaks integration tests. Basically we chose this approach (creating a new comp in static based on the accordion) because it's the quickest and easiest solution for right now. When the RFC is complete we'll hopefully have a better solution and can then rework the tasklist to fit. |
@@ -0,0 +1,333 @@ | |||
// Most of this is taken from the service manual |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this JS differ in any way to the accordion component?
Are the differences only in the class names of elements?
If so, can those class names be abstracted somehow?
Is it appropriate to avoid duplication of this JS?
If it does differ – is it possible to write this in a way that it builds on an Accordion module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is different (details below) and I think it's going to continue to get more different. In terms of avoiding duplication or building upon the existing accordion, that might be possible except we'd have to separate out the tracking, which is fairly heavily intertwined (the accordion tracks some content clicks based on an assumed content, which isn't ideal - I'm learning more about this all the time).
Differences are:
- 'remember last section opened in URL hash' functionality disabled by default
- new functionality to allow a section to be opened by default
I'm recommending that we remove the first item altogether as it's not needed when the its in the sidebar and having it on the main one only would be inconsistent.
Also, coming soon are some changes to how the GA tracking works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might update that comment to be clearer..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first point
'remember last section opened in URL hash' functionality disabled by default
That feature is still needed for users who browse from a task list to a content page and then hit "Back", the section should remain open so they can continue from where they left off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two thoughts about that.
Yes, in an ideal world. But the solution doesn't remember all the accordion sections that were opened, only the last one - so the page might look different when they click 'back' anyway.
Behavioural consistency is important, and we're not planning on having this when it's in the sidebar.
@@ -0,0 +1,20 @@ | |||
// scss-lint:disable SelectorFormat |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to upgrade the linter on static in a separate PR.
@@ -0,0 +1,358 @@ | |||
.pub-c-tasklist { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to write this in a way that shows what's copied from an accordion, and what's specific to a tasklist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment I fear it'll be difficult to make parts of this reusable, and too easy for the two patterns to grow out of sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the tasklist has already deviated significantly from the accordion that keeping them in sync is neither possible or necessarily desirable. In fact, we're currently looking at a design proposal that would make the tasklist look very different. Happy to discuss though as I feel like I'm unaware of the merits involved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I'm also worried that these two look very similar at the moment. At the very least, I'd hope that we could base both components on a "parent" component that encapsulates as much common behaviour as possible (eg expandable sections), and then make it as configurable as we need to meet the needs of both accordions and task lists. I think this is doable if we do more work with blocks, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be a good solution. Just to let you know I'm now looking at further changes to how the GA stuff works for task lists, which will further change the code involved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If tracking turns out to be a pain to commonise, a possible solution is to have no tracking by default, and people will have to implement their own tracking on a per-use basis (which could be done through JS).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be great. I think I'd have done that from the start if the tracking on the accordion hadn't been so detailed and complex.
|
||
// scss-lint:disable SelectorFormat | ||
|
||
// when js is enabled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could do .js-enabled …
rather than use the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could, yes. I wonder why it wasn't that way in the original accordion? All I'm doing is changing the class name.
height: $icon-size-large; | ||
width: $icon-size-large; | ||
margin-top: -($icon-size-large / 2) - 2; | ||
// repeating these two lines for the benefit of IE8, which doesn't support background size |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you indicate why this needs repeating?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will clarify.
@@ -0,0 +1,342 @@ | |||
name: Tasklist |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer "Task list", "tasklist" isn't a word
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Task list" and task-list
will be consistent with other list components like:
https://government-frontend.herokuapp.com/component-guide/document-list
https://govuk-collections.herokuapp.com/component-guide/taxon-list
https://govuk-collections.herokuapp.com/component-guide/topic-list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok.
name: Tasklist | ||
description: Numbered steps containing expanding/collapsing sections | ||
body: | | ||
Tasklists are designed to show a sequence of steps towards a specific goal, such as 'learning to drive'. Each step of a tasklist can contain one or more sections. Each section can contain one or more links to pages. Each section is collapsed by default so that users are not overwhelmed with information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we specifically refer to the research about why task lists are collapsed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will add.
f865ebd
to
652589f
Compare
652589f
to
5bce774
Compare
You've mentioned this has been tested with VoiceOver, since this is a navigation component that'll be used on a lot of GOV.UK's important journeys, this should be tested with the assistive technologies that are more commonly used. When will this be put in front of users? Has this been through a lab session with users of assistive tech? Again since this is a complicated piece of UI for an important journey it'd be good to have this. |
@@ -0,0 +1,84 @@ | |||
<% | |||
steps ||= false | |||
small ||= false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be 'size'? (Not a big deal)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be if there were more size alternatives than just 'small'. But at the moment it's just a flag. I think it's unlikely we'll ever have another size (the only option I think would be one bigger than the default, but that seems improbable) but if we do this can be rewritten then.
This is looking good, I agree with Alec, this feels like an uneasy amount of duplication of code. @andysellick can you record this as techincal debt alongside the static/slimmer discussion? |
Recorded - alphagov/govuk-rfcs#84 (comment) |
Spoke to @sihugh about it breaking when used in alphagov/frontend. We talked through three approaches.
Out of scope: We'd probably want to raise an issue also on static to consider removing reset.css for other components. |
Have now tested with a few more screen readers. No obvious accessibility issues, although some interesting observations. The 'just read the page' option in some of them resulted in less information being presented. JAWS didn't announce the existence of the buttons, NVDA did but didn't say they were collapsed (Voiceover had no problem). However, navigating e.g. with the tab key, no problem. Presumably most users will favour the second option so should be no problem. |
4081d9e
to
a1b16c6
Compare
a1b16c6
to
82cc67d
Compare
82cc67d
to
b76bc4c
Compare
b76bc4c
to
05d3b49
Compare
05d3b49
to
cbeb697
Compare
- don't rely on a reset being already present in the page, as in some applications it isn't
cbeb697
to
99b153c
Compare
A tasklist is meant to help users achieve a goal on GOV.UK, such as learning to drive. Links to pages of information are presented in a series of steps, each of which containing one or more expandable sections.
Large tasklist:
Small tasklist (large should also look like this on mobile):
Component guide link: https://govuk-static-pr-1173.herokuapp.com/component-guide/task_list
Related trello card: https://trello.com/c/o0BCuFub/190-rewrite-the-accordion-to-meet-our-teams-needs
Accessibility and compatibility
This work included a session with the GDS accessibility team, who made a number of recommendations which have since been implemented. It will go into public beta first, during which we'll be testing it with users with accessibility needs.
Tested with IE8 -> 11, Edge latest, Chrome latest and 54, FF latest and 48, Opera latest, Safari latest, Safari 5.1 (Windows), ipad mini 2, iphone 6s, Android Nexus 6.
Tested using Voiceover on Chrome and Safari.