Open roobottom opened 3 years ago
This seems like a good addition to the library. Well done.
However, the styling of this components should be considered in scenarios where it appears alongside other components on the page and not just by itself. As it is at the moment it is out of kilter with other likely "companion" components/patterns -- inset text, warning text, bulleted lists, error message.
Placed together with other most likely patterns:
As a suggestion, by aligning measurements to other existing elements:
We would get:
Which I think it produces a more integrated and unified page.
Hi Asier, Thanks for the comment. I've changed the margin so that the pattern text lines up with the bullet points:
I've left the border width as is at the moment as I think there's enough difference between this pattern and the inset/error border width that it doesn't look like a mistake. We'll be releasing this pattern as experimental so we'd welcome any research that suggests changing the pattern. The border is a visual change as well which will make it easy to change in the future.
Thanks Tim, that is much better. However the horizontal extension of the blue line is now too close to the title. Its proportions seem arbitrary. Wouldn't the line achieve the same affect by being sorter and in line with other elements? Also the thickness of the blue line seems arbitrary. Was it designed in isolation or another context?
Regarding experimentation -- The thing with design decisions like this is that the will never cause a noticeable problem to the user. They are micro-design decisions, to small to detect with experimentation. They will not reach statistical significance. We are talking visual "aerodynamics" :) But if every new pattern introduced is considered in isolation and introduces new measurements our pages will not come together as a single unit. Lets imagine a letter that changes fonts throughout, for no meaningful reason.
Yes, you're right about the distance to the title. I did change that at one point but must have pulled it out at some point. I'll get that changed.
As for the thickness, my thoughts (for whatever it's worth) were that there are a number of different border thicknesses in govuk-frontend that don't have any specific meaning. So it doesn't really matter which thickness we pick. I can see though that 5px seems to be the most used as it's used on error messages, error summary, details and maybe others. @roobottom Do you have any thoughts on the border thickness? Is bumping up to 5px ok or do you have a reason for picking 3px?
For the research, totally get that there may not be any percievable difference in behaviour and that this topic is more about consistency and building up a visual language. I wasn't really talking about testing in a quant (a/b test or whatever) way but more about user testing sessions. I don't know if we'd get any useful feedback as we're talking about a few pixels. I guess yourself or URs would be better placed to answer that!
Yes I agree, it is one for UR sessions. It is a tough one to gather evidence for, because this "pixel" matters are so small and perceived unconsciously. Drawing attention to them distorts their significance perception. Something I will consult URs about.
But in general I'd say that pursuing consistency, unity, seamlessness, economy etc ...of all patterns and its elements should be a necessary rule for all new design. Once a pattern it is out there it is very difficult justify a revision.
I wholeheartedly agree that we should go for consistency. Thanks for contributing @asier-hmrc the spacing looks way better now.
As for the border thickness, I'm not sure that UR will tell us anything - rather we should go for whatever works best in the context of other elements in the design system. So agree that 5px
is the best choice.
The Track service are using a horizontal timeline pattern. They seem to have a distinct number of 4 steps:
On smaller width devices they collapse to a vertical layout and remove the progress bar. There are some issues with the numbering at this level:
It's potentially a bit misleading to suggest step-by-step navigation as an alternative to use for orientating users in a service, because it's not a service pattern.
See https://design-system.service.gov.uk/patterns/step-by-step-navigation/ - 'GDS works with departments to build step by step navigation journeys on GOV.UK. You will not be able to publish step by step navigation you’ve created yourself' / 'Do not use the step by step pattern inside a transactional service – use the task list pattern instead'
@andyk77 Thanks for that. This has been updated in the Design System in the PR https://github.com/hmrc/design-system/pull/161
Currently the headingLevel
macro option does not seem to work due to variable name mismatch.
Name used on macro params is headinglevel
and name used within macro code itself is headingLevel
Hi @NikhilNanjappa, thanks for raising. Do you mean the example at https://design.tax.service.gov.uk/hmrc-design-patterns/timeline/ has headinglevel
but the code params are using headingLevel
?
Hi @timsb, Correct. As most of the users would refer to the example as the source of truth.
So, seems like just a typo on the example then ?
Thanks @NikhilNanjappa I'll update the code to fix!
Thanks @timsb
Timeline
Service: Track your VAT repayments (VRT)
Overview
The timeline component is in the GDS backlog, but there isn't any standard implementation across departments. We recently used a timeline in the Track your VAT Repayments service.
It helps users to quickly understand their progress through a process.
I'd like to propose adding it to the HMRC patterns so it's quickly accessible to other designers and developers—ahead of it being potentially added to GDS patterns.
Research on this pattern
We tested this component as part of testing on VRT with 7 users across 3 rounds. We found that:
Accessibility
We did some internal accessibility testing with screen zoom and Voice Over on Mac, but more formal testing of this component needs to be done.
We also found in testing that some users didn't notice the date when it was in "hint text" style, so we updated this to be standard body text.
Originally we tried using a
<time datetime="…">
element for compatibility with microformats and microformat-like event readers. However, we found that Voice Over would read the date out twice.I also wrote an article about the timeline pattern.
Code
I created a Nunjucks macro for this component.
HTML
Use with other components
This component is design to play well with any other component, these can be wrapped in:
*[VRT]: Vat Repayments Tracker