I totally agree about the URLs. We decided not to launch with human readable URLs since we didn't want to deal with the namespacing issues right away. i.e. /user/post vs /collection/post vs just /post. I'm a huge fan of URLs as part of the interface, so I'm sure its something we'll implement.

Just seconding Dan's answer here, I'm a big fan of human readable URLs as well. They are on our roadmap but we didn't include them in this initial release for reasons including but limited to the namespace issues Dan mentioned.

As Ev said in his post this release is a preview and we're not done by any stretch of the imagination.

Glad to hear it! Like I said, just a small thing. I'm really excited to see where you guys go with the platform.

Understandable. Any idea when you'll be opening up the platform beyond family and friends by the way?

http://www.w3.org/Provider/Style/URI should be required reading for every designer, developer, and stakeholder who is involved in building any kind of product on the web.

For sure. And it's funny coming from Obvious. Twitter's traditionally one of the best examples of real-world cool URIs.

Hopefully it's just a prototype thing, but you'd think they'd want even these early URLs to be shared with love.

"Twitter's traditionally one of the best examples of real-world cool URIs."

Do you mind expanding on this? I thought hashbangs were a rape and pillage of URI convention.

I wasn't thinking of hashbangs, which will ultimately be noise in the history of Twitter. (I could get into a debate about why they weren't that bad, but it's all (HTML5) history now, so I'll move on.)

I was thinking mostly about the clean, namespaced, REST scheme for their API, which you can see at https://dev.twitter.com/docs/api. And it's not just a separate API, as it corresponds closely to the website URLs too.

Generally, Twitter and Digg were the best examples of real-world REST implementations around that time. That people like Oatmeal are making fun of the crazy-long Plus URIs [1] shows it's not just RFC longbeards pontificating about The Right way to build web apps. At least some end-users notice and care about this stuff too.

1. http://techcrunch.com/2012/08/12/google-plus-the-oatmeal/

This is really interesting. I don't do as much REST API work as I'd like to, and I assumed twitter's scheme was standard rather than a shining exception. Thanks for teaching me something new :)

Hashbangs existed for a very short period of Twitter's life. They were a mistake. They're gone now.

And Twitter is even slower...

Seriously? I found it unbearably slow until the big update a few months ago. I simply couldn't use the website. Now it's fine again.

If they're smart, they'll HTTP 301 redirect these old URLs to new ones, if they ever decide to change them.

URI design is hard, especially when you're dealing with a single namespace on a site with massive scale like Twitter. But if everyone has their own namespace (it seems Medium is a good candidate for this), then you could as well use a human-readable timestamp in UTC (yyyy/mm/dd/hh-mm-ss), but they might be an eyesore for some.

The fashion these days tends to be short, mixed-case, untypable URIs that don't look like they'll stand the test of time.

Not quite as bad as the internal links: https://medium.com/r/?url=https%3A%2F%2Fmedium.com%2Fr%2F%3F...

But I actually really like the look and feel, so I've signed up. I'm sure they'll hammer the issues out.

It's not a small thing: the web is made of links.

So I know this will probably be an unpopular opinion, but I think W3's strict URIs are only a few years from being less important for web applications and only being important for TLDs and web "sites." Reasoning: Chrome's web store and the rise of single page applications that rely on things other than URIs.

Don't really care what they look like. Not very memorable though.