How to make a great government website

I thought this was an interesting read. There's certainly a lot of room for improvement for websites that allow you to sign up for government benefits (although i suspect in some cases the friction is intentional).

My biggest gripe with govenrnment websites is not the parts where they're taking in user data, but the parts where they silo their public data. In my experience this is the worst at the local and federal level. Infuriatingly, my local city council does not OCR their most recent minutes, but they do OCR their archived minutes. So you can search their minutes, just as long as they aren't relevant anymore. Another thing is using javascript buttons to serve PDF files, and filenames have no refeence point with their titles. So if you need a few at once you've gotta stop and manually change the filename from 123455325.pdf to something intelligible.

It's 2024. We've got to stop making everything turing complete.

I would somewhat strongly disagree . Using JavaScript allows for a more interactive interface, where cause and effect are more clearly visible, and where the relationship between answers and further questions is more obvious.

For example, it's common for govt forms to have sections like "fill this part in if you're a resident" and "fill this part in if you're a visitor".

Elsewhere in this thread, auto-saving is mentioned, trivial to do with javascript, (and more privacy respecting to do if using local storage.) The alternative is "one page per question" - which is the slowest way possible to fill out a form (and not inconsequentially puts the highest load on the server.)

JavaScript is part of the web, and offers significant UI and work-flow advantages. Govt (or indeed any site) that eschews it is unnecessarily degrading the experience for the vast majority because some sliver of the audience don't like it.

I disagree. Most content on government sites is static content, you could fairly easily deliver much of that to a large population with relatively little hardware, assuming the software is developed such that static delivery is possible.

There are "processes" that people need to complete, but these are typically life-changing processes, things you do once in your life, or maybe once a year at most. Even if those are clustered in time as you say, and most aren't, it doesn't take a lot of hardware to run most of those processes, especially if again the software is designed well and to pull things off the critical path that don't need to be.

The healthcare.gov rollout is often pointed to as an example of these things going wrong, the site crashed, and it would be easy to say it needed more hardware, but actually the core issue was that it was "enterprise software" – it was software built by people used to building software for small numbers of expert users in a company who might go through training, who might be using on-prem servers, who might have a lot of complex business requirements. The big improvement came when a bunch of producty-UXy sorts of people came along and scrapped most of the system, made a simple piece of user-facing software that did the minimum necessary, and built it with modern (at the time) web technologies, not from throwing hardware at it.

gov.uk is pretty good, and their forms are quite good. But there are definitely still places where this design is worse than one using JavaScript.

For example when paying for tax free childcare you have to enter a date for when you want the payment to go out. Not only is the date picker just three edit boxes (no "tomorrow" button for example), but it isn't validated at all so if you put in today's date (quite reasonable) and click next it will only tell you on the next page that you can't use today.

It would be much better if a tiny bit of JavaScript told you as soon as you put the date in, and if it had a "tomorrow" button, which would also require some JavaScript.

JavaScript was invented for a reason!