Hackpads are smart collaborative documents. .

Michael Thomas

576 days ago
Unfiled. Edited by Michael Thomas 576 days ago
Sjors T
 
 
 
245 days ago
Unfiled. Edited by Alex Nolan 245 days ago
Kellie M
  • I understand that if I have given false information or I do not provide further evidence if requested, my application may be rejected and the full fee will be payable."
Alex N
  • Doesn't feel like the right page for this, but just a thought about the process in the comment directly above: If you ask people to commit to honesty before the form, rather than after, it makes their responses more honest. I don't know if your service suffers from many fraudulent claims, but you might want to consider this if so. If the next action after that confirmation is to close the page and exit, it's a lot easier to do that than go back and correct any dishonesty. 
 
337 days ago
Unfiled. Edited by Sanjay Poyzer 337 days ago
Register a physical item or activity
 
May or may not involve getting a license.
 
e.g Apply for alcohol license, Apply for flood license, Apply to be a foster parent, Register to vote
 
Sanjay P Register yourself (or someone you represent)
Telling government you exists and getting a certificate to prove it.
A certificate does not give you permission to do something (like a license), but it can prove things about you which allow you to do things.
 
e.g Register a birth, register a death, apply for a gender recognition certificate, Register self-employment, Change your name by Deed Poll
 
e.g Apply for research funding, Apply for business funding, Apply for flood defence funding, Apply for student loan
 
e.g Housing benefits, Tax Credits, Jobseeker's Allowance, Carer's Allowance, refugee integration loan, budgeting loan, sanction loan
 
 
e.g Appeal refused immigration permission, Appeal benefits sanction, Appeal school placement sanction
 
e.g Do my taxes for me, Lasting Power of Attorney, Get a defence lawyer
 
Check private data about someone else
Ask government to check that someone is allowed to do something.
 
e.g Check criminal records (DBS), Check a driving license, Check tenant's right to rent
 
Pay to use a public asset
 
e.g Pay road tax, Pay canal boat tax, Pay to search Land Registry
 
 
Booking a time
 
Report a concern or possible crime
 
e.g Report a food premises, Report illegal fishing, Report an estate agent, Report a patent infringement, Report benefit fraud
 
345 days ago
Unfiled. Edited by Michael Thomas 345 days ago
Michael T Character validation for users' names
 
  • The problem
Many users of services of GOV.UK will have characters in their names that do not fall within the A-Z latin alphabet. Examples have arisen whereby users have been unable to use a service as their name, containing either diacritics/accents, failed validation and prevented them from continuing.
 
Tim P
  • Guidance
 
Michael T Accept whatever characters the user inputs
Ideally we would accept whatever characters the user puts in, since by definition the name I give you is the name it's OK to use.
 
Or, request they match the name on an existing document
 If you need a name that's used somewhere else, e.g. for identity matching services, be transparent and explicit about that (e.g. "Name, as given on your passport / We need this so we can check your application against our records)
 
 If all else fails, anglicise names but be clear that this is whats happening
 If you're dealing with a legacy system, anglicise names where possible without throwing up an error - e.g. "Björk" becomes "Bjork" (obviously some people are going to - justifiably - get annoyed about that, but might be the least bad option).
If we have a system that cannot accept certain characters - like the British Passport system - then we can do the hard work to convert the character to its transliteration and notify the user that that is what we are doing. They shouldn't have to do any extra work.
For instance, the International Civil Aviation Organisation (ICAO) have an internationally agreed list of transliterations (converting certain accents/diacritics into their closest A-Z equivalents) in the 'Numbers, Symbols and Punctuation Marks' section of HMPO's Names and changes of name document. It should be noted however that this is not an exhaustive list of all accents and different languages may transliterate characters differently. But should we consider building up a list of known diacritical/accent characters along with appropriate transliterations? 
 
Further considerations
You may not be able to change what someone types in:
a) for legal reasons (non-repudiation)
b) because you may not know what caused the error, just that it was triggered 
– Because of b, one team wrote an error that began "First name must only include letters a to z..." that explained what characters and symbols you could include. It tested OK but some people treat 'è' as 'e' so the error does not help them.
 
Tim P
  • Use this section to draft guidance for the pattern. This will become the first draft of the pattern page when it's added to the Service manual, at which point it will be removed from this page. It's quite common for a single pattern page to describe a number of different approaches. We're using the following structure to document each approach:
  •  
  • Example: 1 line intro plus screenshot or HTML
  • Pros: What this pattern is good at and when to use it
  • Cons: What this pattern is less good at and when not to use it
  • Guidance: General guidance on implementing this pattern
 
  • Discussion
 
  •  A place to have a more general conversation about the pattern.
 
  • Examples on GOV.UK
 
  • Post images and links to examples on GOV.UK or prototypes
  •  
  • Research
 
  •  A section to talk more generally about research relating to this pattern
  •  
  • Further reading
  • Names and changes of name – The 'Numbers, Symbols and Punctuation Marks (Diacritical characters and accent characters)' describes the internationally agreed specifications for transliteration.
  •   
Tim P
  •  Links out to related articles, blog posts etc.
 
548 days ago
Unfiled. Edited by Michael Thomas , Caroline Jarrett 548 days ago
Michael T Documenting changes to content
 
Showing users how page content has changed over time.
 
  • Example: Service manual
 
Understanding when and why updates are made
Users are building their services to the specification of the guidance that the service manual provides. It is therefore important that when this guidance is changed or updated we clearly explain what has been changed, and why.
 
Research has shown that users have varying levels of interest in the updates to guidance, often depending on their role within the service team or the kind of guidance in question. We show two levels of detail:
  • a brief summary of the updates, including a one line description of the change (in the metadata at the footer of the guidance.) 
  • an in depth view of the specific changes made with more background information (on a separate 'page update'  page.)
Caroline J
  • "Research has shown": what research and where is it published? Plus: passive voice. Plus: tried to identify the two levels of detail and couldn't quite do that - hence odd bullet points
Michael T
  • Thanks Caroline. I've just fiddled with that wording to improve clarity. A blog post will be along shortly to explain the user research in more detail
 
In-guide summary of updates
We have adapted one of the 'last updated' patterns from GOV.UK to into our page footer. As well as showing a list of the updates with their timestamp, the update summary has also been included. 
Caroline J
  • Not sure what the 'have adapated' sentence means. Second sentence: passive voice
 
This gives users enough information to make a discussion to either interrogate the update further and link though to the page update or be satisfied with the information in the description and continue browsing.
 
Michael T A page-per-update
The more engaged users can then find out more detail in the 'Page update' page.
 
 
 
These pages document the state of the guidance on the date of the update, including a summary of the change, a detailed description of the reasons for the change and a preview of the actual changes from the previous version.
 
This stand alone page approach was taken as it allow us to easily surface more contextual information about the change. It should also be more clear to the user that they are not looking at the latest version of the guidance due to the considerably different page layout.
The method of displaying the diffs has so far tested well with users showing a strong understanding of the changes being displayed. We are still working on creating a rational for how to write the detail for the change logs.
 
Having explored a wide range of approaches to showing diffs (GitHub, Wikipedia, Google, etc.) and experimented with existing service manual content and updates, we are confident that the in-body comparison is more readable with our style of content and thus more effective than the side-by-side approach.
These update pages will only appear for non-minor (e.g. spelling errors, broken links etc.) updates which will be specified as such in the publishing process.
Caroline J
  • This is good stuff - I'd like to see it as a blog post
 
Michael T Still to do
What exactly should be included in the explanation and descriptions of the updated still need to be nailed down. We hope to develop a clear rational for anyone publishing updates to the guidance to ensure the change log is filled out effectively as possible.
 
 

Contact Support



Please check out our How-to Guide and FAQ first to see if your question is already answered! :)

If you have a feature request, please add it to this pad. Thanks!


Log in / Sign up