Skip to main content

Tagged “govuk”

Choosing a date - we want to know your use cases (a discussion re. gov.uk design system)

We want to find out if adding a 'date picker' component to the Design System is a good idea.

We're currently looking for: examples of date pickers in services: screenshots, prototypes, links to live services; use cases: explanations of why a 'date picker' was used in a service instead of a 'date input', or something else; research: how well 'date pickers' tested with users to complete different tasks.

This discussion thread will be really helpful for everyone attempting to create an accessible Date Picker.

GOV.UK visitor stats for January 2022

Thanks once again to Matt Hobbs and GOV.UK for sharing their website visitor stats publicly so that we can learn from them. As ever, lots of juicy detail in Matt’s thread.

GOV.UK stats for January (1-31):

- Chrome - 45.08%

- Safari - 36.82%

- Edge - 7.38%

- Samsung Internet - 7.08%

- Firefox - 1.35%

- Android Webview - 0.72%

- Safari (in-app) - 0.61%

- Internet Explorer - 0.5%

100% = 187,969,863

#browserstats

—Matt Hobbs, @TheRealNooshu

In particular, their “usage by device type” stats see mobile at ~67%, Desktop at ~30.5%, Tablet at ~2.5%.

In terms of comparative traffic, according to Simliar Web’s Top 10 most visited UK websites list they’re hovering around #10.

Building a resilient frontend using progressive enhancement (on GOV.UK)

GOV.UK’s guidance on developing using progressive enhancement is pretty great in all departments. It begins with this solid advice:

you should start by making your page work with just HTML, before adding anything else like Cascading Style Sheets (CSS) and JavaScript. This is because HTML is the most resilient layer. If the HTML fails there’s no web page. Should the CSS or JavaScript fail, the HTML will still render correctly.

I particularly like the section where they address the misconception that a resilient baseline is only required in places where the user has explicitly disabled JavaScript and therefore not worth worrying about.

You should not assume the reason for designing a service that works without CSS or JavaScript is because a user chooses to switch these off. There are many situations when extra layers can fail to load or are filtered.

As their subsequent list of scenarios illustrates, a user turning JavaScript off is probably the least likely of a range of reasons why extra layers on top of HTML can fail.

Relatedly, I’ve often found that Everyone has JavaScript, right? serves as a great go-to reference for these sorts of conversations around resilience.

See all tags.

External Link Bookmark Note Entry Search