Capturing time #334
Replies: 11 comments 8 replies
-
Multiple inputsCOP - Events and the border Asylum ops - appointment booking PPPT - LEDS Single inputCOP - OAB PPPT - MAAPPS Multiple inputs with AM/PM selectorAutocomplete with dropdown suggestions |
Beta Was this translation helpful? Give feedback.
-
|
Looks like there's an issue in the backlog that is looking into capturing date and time in code: #230 |
Beta Was this translation helpful? Give feedback.
-
|
Also, this issue has been raised to show an example of displaying time in Callisto #335 |
Beta Was this translation helpful? Give feedback.
-
|
In Callisto we add start time and finish time. That counts up their hours and attributes those hours to things they agreed in their contract. It automatically inserts a colon into the time (ie 08:00 not 8 or 8.00) if the user misses it. When users view what they've entered it appears as a range with 'to' between the times eg 08:00 to 18:00. For shifts, there is also a 'This is a X hour shift' note to confirm what will be taken off their total. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Does the 'Add another time period' cater for 2 different shifts which start on the same day? (If that takes place). |
Beta Was this translation helpful? Give feedback.
-
|
Yes they can add 2 shifts if they need to, in case they’ve done 2 nights in a row or something. |
Beta Was this translation helpful? Give feedback.
-
|
If a user enters, 1:00 in the start time, and 2:00 in the end time. How do you decide whether they're referring to 1am to 2am, or 1pm to 2pm, or 1am to 2pm? |
Beta Was this translation helpful? Give feedback.
-
|
It’s 24 hour clock so it would assume 1am. There’s going to be a “this is a XX hour” shift note underneath confirming how many hours it will deduct. And if they do a very very long shift and end up finishing 24 hours later, there’s a checkbox to indicate that that is the same time but the day after. |
Beta Was this translation helpful? Give feedback.
-
|
How did you validate that users know its the 24 hour clock, rather than the 12 hour clock? |
Beta Was this translation helpful? Give feedback.
-
|
Not got that far yet. Or at least they hadn’t when I moved on from the project. I’d be interested to hear how other folks have tackled that. I’m not sure how you’d do it. The good thing about the way the time card is designed is that it’s like a summary list, so once you save the time you see it in the timecard in 24 hour format. So there’s that opportunity to catch it, but would be great if it could be intelligent about it and catch mistakes before they make them. |
Beta Was this translation helpful? Give feedback.
-
|
Our service is a workflow tool. We are using a calendar picker that was developed by DVSA. This is what their developer has built: https://still-headland-16463.herokuapp.com/ One of our user needs was that a user may not know the exact dates but wants to search from Monday this week to Monday next week. By providing them with a date picker, they don't have to open a calendar elsewhere to check the exact dates. The DVSA team have had accessibility reviews with DAC and our team has done basic accessibility checks using screen readers, zoom colour contract etc. We've not had a chance to test with real user with access needs yet. This is what it looks like on our service.
|
Beta Was this translation helpful? Give feedback.
-
|
Adding example use case here, for visibility: "A manager wants to set up a work group where caseworkers will work on cases with the reporting date from 12 3 2022 to 12 4 2022. They would then apply that filter to the work group and all the cases that meet that filter will get allocated to the work group. The reason the standard GDS date input wouldn't work is that they may want to set up a date range that is from a Monday to the next week's Monday and seeing the calendar helps the user figure out which dates those fall on." |
Beta Was this translation helpful? Give feedback.
-
|
On AOT Appointment booking we're using a time input like this: And a variation for durations too:
Research We've not observed any usability issues with the time input so far. |
Beta Was this translation helpful? Give feedback.
-
|
Ah that looks good, and nice to hear about the research. Do you replay the time back to the user, say on a check your answers page? If so do you keep to the 24 hour clock? |
Beta Was this translation helpful? Give feedback.
-
|
Yes we do @tomyems We replay the time and date on a subsequent page like this: And then like this on the 'check your answers' style page: So yes, we keep it 24 hour across the service. |
Beta Was this translation helpful? Give feedback.
-
|
We're recently handed over a capturing time component to devs for COP. We have not been able to test it with users yet so I have added in the design rationale behind our decisions. We intend to test the assumptions in upcoming UR. For not we've went with a 24 hour time component using two text fields and hint text. |
Beta Was this translation helpful? Give feedback.
-
|
I guess you've already seen this parallel conversation, but just in case not alphagov/govuk-design-system-backlog#173 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
We are looking into better ways that we can capture time on our service. On COP we have two use cases; to capture:
We currently have a couple flavours of designs around COP and are looking to get a consistent on nailed down.
On a Figma page, I have collated a few examples found across Home Office and on other sources like the GDS GitHub backlog.
We also talked briefly about this on a Slack thread.
Beta Was this translation helpful? Give feedback.
All reactions