-
Notifications
You must be signed in to change notification settings - Fork 4
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
Timeline #167
Comments
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. |
Thanks Tim, that is much better. 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" :) |
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 |
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 hmrc/design-system#161 |
Currently the Name used on macro params is |
Hi @NikhilNanjappa, thanks for raising. Do you mean the example at https://design.tax.service.gov.uk/hmrc-design-patterns/timeline/ has |
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
The text was updated successfully, but these errors were encountered: