Before I start, let me be very clear; your blog = your rules. If you want to write your URLs as a series of Emoji or in Klingon - go right ahead. There really is no such thing as "best practice" - only personal preference and observed behaviour.

That said...

Here's my case for keeping dates in URLs.

URLs are designed to provide information to humans and computers. That's why we don't just use IP addresses and binary representation of paths.

• The "scheme" (http, https, ftp, etc) tells me whether my connection is secure, and what program is likely to try to open the link.
• The domain "example.com" tells me the destination. I can decide whether I consider it to be trustworthy or not.
• The path "/2015/blog-urls-explained.pdf" gives me further semantic information about the destination. Is it recent information? what's the page about? Is it a web page or a file?

All of which lead to my decision as to whether I visit the link or not.

Matt's arguments are mostly aesthetic.

They’re visually ugly. Strings of numbers aren’t nice to look at. They look like they’re made for machines.

Well, that's a matter of opinion. I can't find any evidence that people are somehow offended or alienated by numbers. The semantic information is useful for humans - people can quickly see that a post about the iPhone is from 2011 and is probably obsolete.

They’re unnecessarily lengthy. They’re exactly eleven characters too long, in fact.

Personally, I prefer Year/Month format - but I rarely write each day. For a site which has to publish multiple times per day, it may make sense to give the reader some pre-warning as to how fresh the content is.

Why is brevity a virtue? What is the perfect length? What are the consequences of being unnecessarily verbose? The only explanation is the next point:

They push the post’s title off to the right, maybe partially obscuring it in the address bar of the visitor’s browser (or their bookmarks menu, or history list).

That's stretching it a bit! If you're truly worried that obscuring the address is a concern, get a shorter domain! The argument here is that the last few characters of a URL have much greater semantic importance than the date of publication. I can't agree. In the future we might be browsing on augmented reality goggles which give us a 360° field of view. Complaining that small phones might be slightly disadvantaged seems like the sort of "pixel perfect" design the web is meant to eschew.

Worrying about the length of the URL just leads you to waste time crafting a URL which is exactly the right length for one particular device. Or should you worry about how the URL will display on a Smart Watch?

The page itself has the date of the post on it anyway. In the few cases where it doesn’t, that’s a deliberate design choice, and you’re not meant to be focusing on it.

I agree, your posts should probably have a date on them. But they also have a title, so why not remove that from the URL as well?

If your posts really are designed to stand the test of time and remain an immutable opinion - you may be confusing yourself with an infallible deity. For most bloggers, posts are a product of their time. Users probably do care that your opinions have evolved. IF I write about the War in Afghanistan, I want it to be fairly obvious which of the many wars I am talking about. I think the URL helps - as does the date on the page.

In most cases, you don’t care about the date. Right now, a tiny subset of humans (technical people, who think of code examples or software tutorials when they read the phrase “blog post”) are going to argue that the date does matter. They are wrong. Any article with time-sensitive information will either mention its vintage explicitly, or is by definition poorly constructed.

Hurrah! I'm in a subset of geeks! Luckily, I am right.

Humans are notoriously bad at thinking in advance. Most of us have neither the time nor the inclination to make our text adhere to the Platonic Ideal of a blog post. Should I mention that my review of a book is the 2013 edition? Probably. But if I forget, or simply don't consider the consequences, there's a handy guide for the next human in the shape of the URL data.

Dates in URLs help save us from our human failings.

Next Steps

Taken to its logical conclusion, Matt's idea (human-readable semantic information is ugly and redundant) ends with the proposal put forward by my friend Tom Morris whose posts URLs are in the format "/post/1234".

not every post can be adequately summarised with a bunch of ASCII characters with hyphens between them. What about just a photo post, without a title? Even my “formatted titles” are a bit of a bad hack I might turn off.

Other than SEO, there’s no particularly good reason why people should prefer a long URL with the title in than one that just has a unique identifier. The title is also not immutable on posts. That is, I can change a title, or even remove a title, after publication. Should I change the URLs? Well, no. URLs, once announced, should stay the same. Okay then, I’ll have URLs that are inaccurate.

Just say no to URL stubs

A plague on both your houses!

Humans are fragile and fallible. We need every bit of help we can to navigate our way through life. A fashionable choice now can have unintended consequences in the future. We should design all aspects of our sites - from URL to content - to withstand changes in devices, formats, browsers, and people.

Would a URL with a date in have helped prevent confusion over Tony Hart's date of death?

Probably not. We're all just monkeys letting squiggles of black and white emotionally manipulate our brains. Or, to put it crudely :

Katie

@KatieOldham

Ever realised how fucking surreal reading a book actually is? You stare at marked slices of tree for hours on end, hallucinating vividly

---

One of the most requested features in QRpedia is to have custom URLs.

For example, the British Museum may want a URL of "bm.qrwp.org". This has two main advantages.

1. Better analytics. Although the British Museum is the only place likely to have the Rosetta Stone, many museums will have exhibits about "Ancient Egypt" or "Gold". By differentiating museums, their statistics are easier to view.
2. Branding opportunities. A user will know that they've scanned a code belong to a specific museum.

From a technical perspective, this is fairly easy to implement. Assuming that a museum is only generating codes in one language, we simply map $museum.qrwp to $language.qrwp - and record in the logging database as per usual.

However, there are a number of challenges around the naming of museums which means considerable thought is needed before we implement this.

Length

QR codes work best when the URL inside them is as short as possible.

This means, we don't want a URL like "BritishMuseum.qrwp.org" or even "PrestongrangeIndustrialHeritageMuseum.qrwp.org".

So, we need to choose suitable abbreviations.

Language Clashes

We could create a custom URL for the British Museum of "bm". However, that's also the same language code as the Bambara language.

There are several Language Codes in use - covering two and three letter combinations. There are currently 282 different language versions of Wikipedia.

Those mostly use two or three letters to distinguish between languages - but there are the occasional surprise like "bat-smg"

Abbreviation Clashes

Suppose that the British Museum wanted a custom URL of "brit.qrwp.org" - that may clash with the (fictitious) Brazilian Institute for Technology.

We Need...

We need to meet these aims for custom URLs:

1. Short
2. Unique
3. Recognisable
4. Fairly distributed

How on Earth do we do that?

On your marks... Get set... Discuss!

Twitter's way of linking URLs is broken. It's annoying to users, and a pain in the arse to developers. This quick post talks about the problem and offers a solution.

I've raised a bug with Twitter and I hope you'll star it as important to you.

Preamble

A common trope in programming classes is "how do you detect valid email address?"

It should be obvious, right? A string of text, an @, a domain - probably ending in .com. As it turns out, it's not that simple. "who+o'toole@invalid.museum" is a potentially valid address, for example. There are literally thousands of ways to detect the potentially infinite variety of email addresses.

The same is true for URLs - and slavish adherence to guidelines is killing Twitter's usefulness.

The URL Matching Problem

Which of these strings should be turned into hyperlinks?

www.bbc.co.uk

example.com

http://test

https://test.test

ftp://news.com

As it happens, Twitter only matches "https://test.test" and none of the others.

Twitter's matching regex is, as far as I can tell, this

If it starts with http:// or https:// and has a dot in it - it's a URL

I think this is a serious weakness. Twitter users are sharing URLs which their followers can't click on - Twitter is also linking to URLs which don't exist.

I've picked these examples more or less at random.

Solution?

Much like the email regexes, I would take a much more lax approach. Essentially, if it looks vaguely like a URL - link to it.

I would suggest the following rules:

• If it starts with a protocol - http:// ftp:// tel: etc - create a hyperlink.
• If it starts with www. - create a hyperlink.
• If it ends . then a valid TLD - create a hyperlink.
• If it contains a valid TLD followed by a slash then some other characters - create a hyperlink.

The "correct" method would then be for Twitter to perform an HTTP HEAD request to see if the URL is potentially valid. There are three drawbacks to this.

1. It may place excessive load on Twitter's servers to process and cache these requests.
2. The URL may be that of an Intranet site - and thus inaccessible to Twitter.
3. The URL may be valid but temporarily inaccessible.

Regardless of the method, surely it's inexcusable that "www.example.com" isn't detected as a URL whereas "http://bork.bork.bork" is?

ACTION!

If you think Twitter's approach to hyperlinks is wrong - please make your voice heard at the bug report.

One of the advantages of the text processing is that it will recognise that www.example.com is a URL and automatically create a hyperlink. Considering that dropping the "http://" represents 5% saving on Twitter's 140 character limit for messages, this is great.

So, I was mightily surprised to get this bug report from user "schmmuck"

Dabr rendering error

How very odd... This is how it looks on m.twitter.com.

m.twitter rendering error

Twitter also use mobile.twitter.com for smartphones. Here's how that site renders the text.

mobile.twitter rendering error

Finally, let's take a look at the "canonical" rendering at Twitter.com

Twitter rendering error

The Problem(s)

The first issue is inconsistency.  Twitter ought to be using the same regex for each of its sites.  It doesn't.  This means that different developers will get divergent experiences.  This leads to confusion, which leads to fear, which, as we all know, leads to anger.... and so forth.

Secondly, and more importantly, parsing is hard.  There are so many edge cases that errors inevitably creep in.  My post about hashtags explains the problems in defining what should be recognised.

So, based on what we've seen, should Twitter recognise any of the following as URLs?

news.bbc.co.uk - no www there.

invalid.name - a silly URL, but a valid one.

खोज.com - International domains contain more than just ASCII

All the above are valid - yet they're not recognised by Twitter.

A (Simple) Solution?

There is a canonical list of TLDs which is also available as a plain text list.

Any string containing a "." followed by a valid TLD, then followed by a space or "/" should be treated as a URL.

Your thoughts?