Ed HThis page can be bypassed by passing a *chosen* payment provider directly to Worldpay. Not ideal (card providers can be inferred from the card number), but this gives control of the page design to us.
Some guidance on suitable formats for confirmation codes would be useful. i.e. if we send a letter/email/SMS to a user, giving them a code we want them to enter into a web application to confirm that it's them, what format should we chooseenter into a web application to confirm that it's them, what format should we choose for the code? For "Help with Fees" at MoJ, they used 6 characters from this set [ 3 4 6 7 9 A C D E F G H J K L M N P Q R T V W X Y ] to minimise ambiguity, and presented the code as XX-XX-XX to make it easy to read.
Tim PSome users enter 2 digit years in the year box. It's fine to accept this format for narrow date ranges, but don't use it for dates that could range over more than 100 years.
Always validate date ranges to make sure the end date is after the start date. If the user changes the start date to be later than the end date you can do one of these:
give an error message
set the end date to the start date
shift the end date by the same amount as the start date shifted
Which approach you take depends on the context. For example, if you change the start of a calendar appointment then typically the end will shift by the same amount, because the start time of an appointment tends to be more variable than it's duration.
Users like the look of sliders but I’ve seen many struggle; especially when any kind of accuracy is needed. On desktop their perceived benefits generally don’t outweigh the usability and accessibility flaws (Ithey may perform better on mobile though).
Only p calendar controls if they match the users likely mental model of the date they're being asked to enter. For example - a calendar control is not appropriate for date-of-birth because people know these by heart. However, if the day of the week or week of the month is relevant then a calendar control might be appropriate.
Our previous advice said "Avoid shortening month names, but if you absolutely have to, use princeton shortening." This differs from the advice in the style guide, which has a slightly different shortening. The Princeton one specifies all the months but in a confusing format; the style guide only says what to do for some of the months.
Has there been any user research in favour of native date pickers? On 'Visit someone in prison' (formally Prison Visits Booking) we used this for touch devices which support 'date' type inputs with feature detection (Modernizr).
We had some technical problems with Samsung devices which very strangely switched day and months on certain months and another bug led us to remove the native date picker.
We have since found that users are as comfortable entering memorable dates in 3 fields on a touch device as they are desktop. The pattern and number type attributes enforce the numeric virtual keyboard which aids input. The only thing that's lost - on iOS certainly - is the next field button (tab equivalent).
Also, native date pickers will suffer from the the same problems as drop downs for the year field, as they require a lot of scrolling (or even worse - tapping on Android (when the user doesn't realise they can swipe)).
For the Android Galaxy S5 in the screenshot below, the date picker obscures all the content on the screen. Starting at current year isn't helpful when entering a date of birth and will require a lot of scrolling. GOV.UK elements has removed the native date picker.
The Air Accidents Investigation Branch (AAIB) reports page has a date range filter.
This page has tested very well - but bear in mind that the users of the page are highly specialist, and would be nearly all high confidence/ high skills Internet users.
We started with a more specific date thing that wanted dd/mm/yyyy and then we noticed that that didn't really map to how people thought about dates in this context (they were more inclined to say: "reports after 2009" than "reports after 01/01/2010"). So we opened up our validation based on analytics and then wrote a test suite for all the date formats we wanted to support and then implemented date parsing to support that.
Caroline J(These numbers are from the range picker above, with a suggested input of 01/01/2013 and with users who are mostly high skills/high confidence).
01 January 2014
1 January 2014
31st august 2015
2 11 2014
Cath RIn user research on this picker, we saw people leaning towards putting the date in the suggested format - they feel like they have to even though they might prefer to enter it more loosely e.g. June or 2010. One participant put in June in the main search field (instead of the date picker) and expected it to automatically default to June 2014
A system that is used inside Government by Government staff or agencies representing Government
this doesn't mean only government employees, or agents see the system - the public/people we serve also do - for example screen sharing when citizens meet government in job centres, or contact centres (Land Registry will show citizens their screen)
These systems exist as part of the whole service - so they should be designed to help government representatives meet the needs people outside of government have of us.
Context of use of internal Government systems
Many staff spend their entire working days using internal tools, and jump between multiple systems as they have to use multiple ones simultaneous to do their job. E.g. case workers may have to consult/enter data into 3 or 4 systems to complete one case.
Note that when working between different systems, some users arrange the systems on their screen in specific ways to maximise either efficiency and utilise screen real estate, for example having one system in a window on one side of the screen and another on the other side to speed up cut and paste or cross referencing
The tool will be accessed from a variety of screen sizes and device types (mobile, tablet).
Many tools are used frequently by users who become expert in the system, but other tools are only used very occasionally, so it cannot be assumed that users are familiar with the form and function of an internal system.
Need for cohesion:
As a gov employee I need to know where I can find functionality on the internal tools I use so that I can be efficient in my job
“Where is the search box here?"
Need for recognition:
As a gov employee I need to be able to quickly identify which tool I am looking at when I glance at the page so that I am efficient and reduce mistakes
"Which tool of the tools I have open is this one?"
Need for trust and reassurance
As a gov employee I need to have trust in the internal tool that I am using, so that I can be confident using it and showing it to citizens when necessary
Types of content in current internal tool header’s:
Primary nav and Secondary nav
Navigation elements - pattern that top left includes link back to dashboard/top of the tool
Can internal tools that are not on Gov.uk be allowed to use Transport and Crest?
currently not. But we discussed the value of trust these element bring, and the assurance 'the thing' meets a certain standard (discussion about internal assessments and if/how that would be governed. Desire to have some form of assessment/governance for internal systems)
Summary of thoughts / recommendations from the day: