Uploading is a challenging interaction for many users, particularly on desktop devices. It's somewhat easier on mobile devices, but still presents challenges. Users lower on the digital literacy scale will struggle and may not be able to use a service if they need to upload as part of it.
The most basic upload mechanism is the file picker. This can be difficult to use on desktop devices, but works well on mobile devices. You should support using a file picker as a minimum before adding alternatives.
Drag and drop
Proficient computer users may prefer to drag and drop from their file system onto the browser.
Always use another upload method alongside drag and drop.
Drag and drop only works in modern browsers
Users with dexterity problems such as tremor may have difficulty dragging a file.
You may want to support drag and drop to support users who attempt to drag a file, and would otherwise lose their progress in the service.
Joe LanmanHarry Trimble I don't think 'Organising long tasks' and 'save and return' should be the same page. They're not the same thing and have different needs. They're definitely related and should cross link though. Thoughts?
Joe Lanman yes we've seen this on production for QAE, we had to implement single sessions to avoid people overwriting their saved data by having two tabs open (we used websockets to detect multiple sessions, then disabled autosaving on the other tabs)
I'm not sure this is as cut and dry as the heading suggests. Is it always good to save all input without explicit action (save and return later) from the user? Saving when there are validation errors also may present a big tech headache. Whilst we aim for 'do the hard thing', communicating these validation errors when the user returns may make for a more confusing and worse journey than simply warning on save that incomplete bits can't be saved. Anyone done any research on this?
Ed Horsford I do agree, it was a lot of work to get this right technically on QAE, for some services perhaps auto saving is not needed. For QAE there is a submission stage after completing the form, where we then do validation and the users will potentially have to go back to past sections to correct the errors (which cannot be validated during input). It tested ok, however there were some instances on the submission deadline of users frantically trying to correct errors as they had left submission very close to the deadline (or some users did not complete the submission).
For some data we are, but other data might not be possible as it relies on future data. A good example is that financial figures must not have a 'dip' where we will only know once all figures are entered. Also actually there is another reason, the form is nonlinear - so when skipping a section, this results in a sea of red errors which confuses/scares the users.
I see... I think. I think it's a difference of terminology - I wouldn't call what you describe in the first bit 'validation' - it's some kind of uber-check that happens later - like eligibility that throws you out after answering several questions. The latter bit sounds like something is wrong - agreed users shouldn't see loads of errored fields, but we'd normally not show conditional questions until we know the user needs to answer them. Sounds like you have a complex service though!
The difference with eligibility is that, well in the case of QAE it can change - people typically submit 'estimated' figures so they might be eligible at the start of submitting, but not at the time of submission when they use updated figures (also the eligibility checker is more of a yes/no check rather than checking the actual figures). And yes it's quite complex - it does not follow the one question per page pattern.
To solve this problem, label the button with 'Save and continue', as tested by the Visas service and by the Queen's Awards for Enterprise.
Is there any guidance / research around the most appropriate labels to use when asking for telephone numbers? Very conscious that the labels - Mobile / Home / Work will not be relevant for everyone ... we are also looking to test with Main phone + other phone
alex jaques We recommend you ask "How do you want to be contacted?" with checkboxes for home phone / mobile / text message, etc. See gif below. An advantage of this is a user who can't speak on the phone because is given an alternate contact method. For your service, how will deaf people use it?
This doesn't really help for contacting primary vs secondary numbers though. Lets see what others think. I wonder how relevant secondary phones are these days - my reckon is many will just give mobile.
Over here at HMRC we've been having a problem with the example NINO that's given in the Service Manual (QQ 12 34 56 C). In particular, we've been trying to use it as an example NINO for use in our APIs, on the grounds that it is guaranteed to be fictitious. The trouble is, it fails validation within the API because "QQ" is not a valid prefix for a NINO. I was wondering whether there are any "reserved" NINOs that are guaranteed to be fictitious but will also pass validation. Any thoughts?
On the positive side, we do have valid test IDs for UTRs - for example, I am told that 1111111111, 2222222222, 3333333333 etc. are valid UTRs (as per check digit validation) but are guaranteed not to belong to anyone. I believe this applies both to CT UTRs and SA UTRs
Ed HIf your service collects personal or sensitive information, you will need to 'timeout' users' sessions after a period of inactivity. On public computers this would prevent a subsequent user from seeing the first user's information, and also prevent new applications accidentally appending to an abandoned application.
Timeouts work on a per page or per activity basis, and are not a time limit on the total time to complete an application.
The timeout you choose will want to balance security with the need to give users enough time to complete a single page of the transaction. The 'page per thing' pattern means that users only need to provide one thing per page, so should be less likely to cause a timeout.
In practice, most services use timeouts are between 15 - 60 minutes. Services should do user research to find out what an acceptable minimum is, and use analytics to measure the volume of timeouts.
If services expect users are likely to timeout or may need longer periods of time to complete a task, they should investigate save and return functionality.
It shouldn't be necessary to tell the user the timeout before they start. If you do this, many users will think that it represents the total time they have to complete the application.
How to time out the user
One minute before a timeout is due to occur, display a warning to the user that it will happen.
This warning should let the user extend the timeout.
If the user does nothing, after one minute, timeout the user.
Redirect the user to a page explaining that the service has timed out, and advising the user what what they can do next.