zerosleeps

There’s this road junction here in Melbourne where Montague Street crosses Lorimer Street/Convention Centre Place:

It’s a miracle this junction works at all during peak times (zoom out when viewing it on a map to see the whole terrifying thing) but it mostly does, except for one scenario which I wanted to report to VicRoads. The feedback form I found wants words and there’s no way I could explain the issue without pictures, so here I am describing it in full colour for all to see.

When travelling through the junction northbound on State Route 30/55/Montague Street, and sitting at the lights waiting to cross Lorimer Street, there are five lanes. Traffic in the two right-hand lanes must turn right into Convention Centre Place, and the other three lanes continue on the north side of the junction.

So for traffic passing through the junction it’s three lanes in, three lanes out. Here’s how it should work:

But for some reason this is what actually happens:

I try to position myself in the left lane in preparation for the next turn I usually take, and about 75% of the time I use this junction I end up having to take some sort of action to avoid being sideswiped by cars in the middle lane.

I’ve noticed that if traffic is light and does not have to stop at the lights, everyone goes where they’re supposed to. It’s only when traffic is setting off from a red light that this happens. And of course once the first car in the middle lane takes the wrong path, all the cars behind do the same thing.

I suspect it’s because the middle of the junction is also the middle of the “turn” - the middle of the curve the road is taking - and drivers assume the junction is straight-and-true so take the lane directly in front of them.

Road markings are an obvious solution to a layman like me, but that would presumably cause other problems given the markings already on the road surface.

Anyway, I’ll send my feedback off to the relevant authority. What else can I do?

From the Django 4.1 release notes:

In order to aid users with screen readers, and other assistive technology, new <div> based form templates are available from this release. These provide more accessible navigation than the older templates, and are able to correctly group related controls, such as radio-lists, into fieldsets.

The new templates are recommended, and will become the default form rendering style when outputting a form, like {% raw %}{{ form }}{% endraw %} in a template, from Django 5.0.

This is excellent news. Django form rendering has annoyed me for years because of the (subjectively) old-fashioned HTML tags and structures it uses by default. It’s always been close to “just working”, but simultaneously useless because the output is cumbersome to tweak, meaning I end up using my own templates anyway.

Fingers crossed these changes make it easier to stick to the defaults.

This blog post from the GOV.UK Design System team has been doing the rounds this week. I’ve been aware of this department of the UK government for a while, but having read through some of their well researched and reasoned recommendations I must say I’m a big fan of their work.

The industry I work in - Australian education - sorely needs to wake up to a lot of this. Unfortunately education providers are required to collect a lot of questionable data for statutory reporting purposes, and often in a very rigid format. It’s a system which was designed about 30 years ago by people who had no idea that not everyone has a name, and not every address has 4 lines and a postcode, to name but a couple of my irritations.

Here are a couple of my favourites from the GOV.UK Design System team.

Gender or sex:

You should only ask users about gender or sex if you genuinely cannot provide your service without this information.

Compare this with the latest requirements from the Australian Government, which doesn’t even provide “declined to answer” or “we don’t ask our students for this data” option.

Passwords:

Overly strict or confusing constraints can make it harder for people to create memorable passwords.

And:

You should only force a password change if you suspect an account may be compromised.

Names:

Use single or multiple fields depending on your user’s needs. Not everyone’s name fits the first-name, last-name format. Using multiple name fields mean there’s more risk that a person’s name will not fit the format you’ve chosen and that it is entered incorrectly.

You’d think this would all be common sense, no?

Patrick Smith at askthepilot.com on MH370:

Consider this: We’ve all watched airplanes high in the sky. A plane flying 12,000 feet above you (that’s the average depth of the Indian Ocean) appears as just the smallest gray speck, its profile visible but indistinct. Now, imagine you’re looking down at that same plane. Except, you’re looking down not through clear sky, but through 12,000 feet of murky seawater. Indeed, for most of that depth you’re staring into aphotic blackness. And the airplane you’re looking for is, in all likelihood, no longer in the shape of an airplane; it’s in thousands of fragments scattered across miles of rugged seabed.

Reading log summary for 2021: 30 books completed, down on 39 from 2020. I abandoned an additional four.

4×2-stars, 11×3-stars, and 9×4-stars.

Six 5-stars, but spread across just four books as I read Andy Weir’s “The Martian” and “Project Hail Mary” twice in 2021.