Dates are one of the most important bits of information a person uses in the product.
We use a lot of tables to show different user groups information about the project they're working on and the work their team is doing.
That information often contains the conversion or transfer date.
Dates used
Users need to enter, check and update several dates when they manage a conversion or transfer.
They need to use dates that show when:
- an advisory board meeting was held
- a school wants to open as an academy
- an academy wants to transfer to different trust
- a school will actually open as an academy
- an academy will actually transfer to a different trust
- a project is completed
Not all users need those dates but our primary users (caseworkers and delivery officers) will use most of them.
Styling dates
Generally we follow the GDS guidance on how to write dates and how to show date ranges.
But we needed to adapt that for dates in tables.
Struggling for space in tables
When we show conversion or transfer dates in the tables we use to summarise project progress to users, space is at a bit of a premium.
We have used a 1200px wrapper to widen the tables as much as possible, but we still need to maximise the use of space and use abbreviations, acronyms, contractions and shortened versions of information where we can.
This helps us make sure we communicate the relevant information to a user effectively. We want to avoid our tables becoming a hard to read, overwhelming, off-putting wall of text.
Shortening dates in tables
Typically, if we're writing a date in a sentence, we would write it in full with no ordinals (leaving off the st, nd, rd or th after the number).
Something like:
You should do the thing by the 1 October 2024.
When we show a conversion or transfer date in a table, writing it out in full like that takes up a lot of space and can be harder for a user to read, so we've shortened it.
First we tried just shortening the month.
1 Oct 2024
We then realised that because all schools convert or transfer on the first day of the month, we'd just have a big long list of 1's in the table.
All those 1's felt pointless. Users would soon learn to ignore the 1's becuase they never change, making it a totally redundant bit of content.
There was also another slight problem with all the 1's.
Always the first of the month, except when it isn't
When a user creates a project they only need to enter the month and year. The system assumes that the date is always the first of the month because that is what the real world process is.
However, this is not exactly right. The conversion or transfer actually happens on the first working day of the month.
Often this is the first day of the month too, but sometimes the month starts on a weekend and the first working day is the second or third day of the month.
When the first of the month is not a working day
Just having 1 Jun 2024 would not always be right. While it said 1 Jun 2024, it might actually be 3 Jun 2024 when the conversion or transfer happens.
Including the 1 in the date information felt unnecessarily inaccurate and a needless use of space.
So we have decided to drop that altogether.
Just show the shortened month and the year
Conversion and transfer dates in tables will just use the shortened version of the month and the full year.
Jun 2024
That will save us a good chunk of space from the original style: 1 June 2024.
Six characters might not seem like a lot, but it will helped us add more white space to the tables so they're less compact and easier to read.
It also gives us some more space to add other information as and when research shows us that it'd be helpful to our users.
Exceptions to the rule
It wouldn't be a content update without there being some exceptions.
We do show the full date in some tables, such as the table that shows all completed projects.
This is because a project is not complete when a conversion or transfer happens. There are still things for the caseworker or delivery officer to do at that point.
A project can be completed at any time, so it is important that that table shows the number in the date.
Right now, it's also not necessary to shorten the month as there is plenty of room in the table for the information the user needs.
What we'll do next
As always, we'll continue to monitor how users find this way of styling dates and react to that with new iterations.
We'll also need to adapt the style if there is a policy or process change that means conversions and transfers officially happen on more than just the first working day of the month.