Besides the hierarchical information, a good slug can already tell you a lot about a page without the need to open it at all. I'd argue that

https://sive.rs/short-urls-why-and-how

would be much more valuable than

https://sive.rs/su

I suppose a middle ground is something like https://siv.rs/short_urls

I do this on my own blog. e.g. a post titled "Mr. Robot Hides Data on Audio Disks, And So Can You! (Season 3 Spoilers)" has the URL https://jszym.com/blog/mr_robot_steganography/ and not the WordPress style https://jszym.com/blog/mr_robot_hides_data_audio_disks_so_ca...

I love that on mobile they all show up as "https://www.kozubik.com/it.."

You can't win, haha

I think I prefer a middleground. I like Sivers' short URLs but I'd go with a word rather than just letters. Letters seems like a step too far for my preferences, looks untidy.

In real reality I'd probably use both methods. Long SEO-delicious URL for the actual article, short redirect to it, best of both worlds. Use whichever is appropriate for the medium (preferring to link online to the non-redirect for less future hassle)

Your hierarchy won't necessarily help others. For URIs that leak into the UI/UX to be short is almost certainly good advice. You can always have them be redirects to the hierarchical names you would prefer.

Don't believe me? Twitter, for example, has short, meaningful URIs for user's status pages, and long, meaningless-to-users URIs for tweets. And in the sea of tweets there is no hierarchy in their naming.

How does Twitter's lack of hierarchy demonstrate that hierarchy doesn't help anyone?

Me: Your hierarchy won't necessarily help others.

You: How does Twitter's lack of hierarchy demonstrate that hierarchy doesn't help anyone?

How did you read into my comment that I said that "hierarchy doesn't help anyone"?

I think it comes down to a mix of (a) how people (and robots) organize and find information (b) tool limitations and genericity.

Regarding (a),I personally like the view that the content lives in a "flat world" on top of which we collate different structures to organize/filter a same set of contents. In that worldview, web users entry-points can be more than directory-listings. A great inspiration is how Wikipedia offers a way to find which articles use a given picture: each picture acts like a "category", the same way that "recent-changes" is another filter on the same "flat world" of articles.

However, what is immensely difficult is to standardize these in a world where de-facto implementations burgeon, flourish, and eventually becoming out of touch (e.g., site-maps, RSS, OpenGraph). Hence we are stuck with very limited but very generic tools (b) for which rules like "directory-listing on the slash-separator" or "generate a JSON of the whole site connections to display as an interactive graph" (which I do on my personal blog) merely are local work around which require a bit of duck-tape to work.

"items" isn't very useful.

Have either:

example.com/<article_title>

or, if categories exist:

example.com/<category_name>/<article_name>

A poor exemple doesn't make for a poor argument. I like hierarchical URLs because they allow me to try and find more content by stripping the end of the URL fo see what is up the hierarchy.

This sounds more like a workaround to a website with poor navigation and UX, but ultimately you are still at the mercy of the website, eg if they have /articles/<title> links but throw 404 when you try to access /articles directly. It's up to the website to choose how navigation works, and I don't think we should constrain the structure of website urls just to support these hacky workarounds.

Now there are other reasons for hierarchal urls mentioned in the thread, like providing better semantic meaning when representing content that is already hierarchal. Though I find that that is rarely the case. For example, you might think to represent blog posts like myblog.com/articles/<title>. But you could also do it like myblog.com/<article year>/title (eg myblog.com/2017/why-choose-short-urls). I've seen both formats, and both are valid to a certain degree. So choosing one is a bit arbitrary. But if you allow both formats, that just pushes the ambiguity onto the user. For example if the user wants to bookmark the article, which url do they bookmark?

From my experience, data follows graph structures, so trying to force a hierarchal structure and doing things like encoding paths in urls, feels too arbitrary and adds unnecessary ambiguity.

> It's up to the website to choose how navigation works

Yes, and they should live by their choice and implement whatever is implied by their semantics.

URLs also have their own affordances and I expect to be able to act upon them.

Url hacking is a clunky and extremely uncommon method of navigation. It should be the least of the website's concern. We don't design our doors based around the 0.01% of people that get in by kicking them down.

I agree. Also, images that are meant to be included in your articles can still have long urls if you want. Unless those images are urls you want to share, of course; it's about sharing urls, and that's much easier to do when they're short.

If you've got a CMS, I suppose you could do both: store each article in its hierarchical place, but also give each article (or each article you consider important enough to share, but I would hope that's all of them) a short name through which it can easily be remembered and shared.

agree, I often edit url directly in the browser

agree, about to say this...