URLs are UI
What a great title. "URLs are UI." Pithy, clear, crisp. Very true. I've been saying it for years. Someone on Twitter said "this is the professional quote of 2017" because they agreed with it.
Except Jakob Nielsen said it in 1999. And Tim Berners-Lee said "Cool URIs don't change" in 1998.
So many folks spend time on their CSS and their UX/UI but still come up with URLs that are at best, comically long, and at worst, user hostile.
Search Results that aren't GETs - Make it easy to share
Even non-technical parent or partner things URLs are UI? How do I know? How many times has a relative emailed you something like this:
"Check out this house we found!
https://www.somerealestatesite.com/
homes/for_sale/
search_results.asp"
That's not meant to tease non-technical relative! It's not their fault! The URL is the UI for them. It's totally reasonable for them to copy-paste from the box that represents where they are and give it to you so you can go there too!
Make it a priority that your website supports shareable URLs.
URLs that are easy to shorten - Can you easily shorten a URL?
I love Stack Overflow's URLs. Here's an example: https://stackoverflow.com/users/6380/scott-hanselman
The only thing that matters there is the 6380. Try it https://stackoverflow.com/users/6380 or https://stackoverflow.com/users/6380/fancy-pants also works. SO will even support this! http://stackoverflow.com/u/6380.
Genius. Why? Because they decided it matters.
Here's another https://stackoverflow.com/questions/701030/whats-the-significance-of-oct-12-1999 again, the text after the ID doesn't matter. https://stackoverflow.com/questions/701030/
This is a great model for URLs where you want a to use a unique ID but the text/title in the URL may change. I use this for my podcasts so https://hanselminutes.com/587/brandon-bouier-on-the-defense-digital-service-and-deploying-code-in-a-war-zone is the same as https://hanselminutes.com/587.
Unnecessarily long or unintuitive URLs - Human Readable and Human Guessable
Sometimes if you want context to be carried in the URL you have to, well, carry it along. There was a little debate on Twitter recently about URLs like this https://fabrikam.visualstudio.com/_projects. What's wrong with it? The _ is not intuitive at all. Why not https://fabrikam.visualstudio.com/projects? Because obscure technical reason. In fact, all the top level menu items for doing stuff in VSTS start with _. Not /menu/ or /action or whatever. My code is https://fabrikam.visualstudio.com/_git/FabrikamVSO and I clone from here https://fabrikam.visualstudio.com/DefaultCollection/_git/FabrikamVSO. That's weird. Where did Default Collection come from? Why can't I just add a ".git" extension to my project's URL and clone that? Well, maybe they want the paths to be nice in the URL.
Nope. https://fabrikam.visualstudio.com/_git/FabrikamVSO?path=%2Fsrc%2Fsetup%2Fcleanup.local.ps1&version=GBmaster&_a=contents is a file. Compare that to https://github.com/shanselman/TinyOS/blob/master/readme.md at GitHub. Again, I am sure there is a good, and perhaps very valid technical reason. But another valid reason is very frank. URLs weren't a UX priority.
Same with OneDrive https://onedrive.live.com/?id=CD0633A7367371152C%21172&cid=CD06A73371152C vs. DropBox https://www.dropbox.com/home/Games
As a programmer, I am sympathetic. As a user, I have zero sympathy. Now I have to remember that there is a _ and it's a thing.
I proposed this. URLs are rarely a tech problem They are an organizational willpower problem. You care a lot about the evocative 2meg jpg hero image on your website. You change fonts, move CSS around ad infinitum, and agonize over single pixels. You should also care about your URLs.
SIDE NOTE: Yes, I am fully aware of my own hypocrisy with this issue. My blog software was written by a bunch of us in 2002 and our URLs are close to OK, but their age is showing. I need to find a balance between "Cool URLs don't change" and "should I change totally uncool URLs." Ideally I'd change my blog's URLs to be all lowercase, use hyphens for spaces instead of CamelCase, and I'd hide the technology. No need (other than 17 year old historical technical ones) to have .aspx or .php at the end of your URL. It's on my list.
What is your advice, Dear Reader for good URLs?
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test, build and debug ASP.NET, .NET Framework, .NET Core, or Unity applications. Learn more and get access to early builds!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Like you Scott, I have a Synology NAS that I love. Almost everything about it is great, but there is one thing that has always bugged me. The Photo Station application has terrible URLs. I use Photo Station as my family picture site and have a custom domain pointing to it. But I really wish I could more easily share links to specific albums with sane URLs.
If anyone from Synology happens to come across this post, hopefully they can raise the issue internally to get that fixed. :-)
People who are fed up with the "hashbang fiasco" must not appreciate how a framework (AngularJS for example) can dramatically speed up dev time while easily facilitate desirable UI/UX.
What's next? 'View source' must yield a Magic Eye of the Statue of Liberty?
Later that year, I created an editing tool called {{Section link}} that inserted links to desired parts of articles but used the academy-standard section link (§) in its display text. Fellow Wikipedians later developed the {{format link}} tool that accepted a raw link and formatted its display text to contain §. This was after the introduction of the Lua programming to Wikipedia.
Slightly off topic...but the URLs for charity fundraising pages are also crazy.
http://main.diabetes.org/site/TR/TourdeCure/TourAdmin?px=3992664&pg=personal&fr_id=11747
After my first year of sending this out, hoping for donations - I bought a domain name. And since we need four links, each member of the family gets a subdomain.
<a herf="http://brian.teamtegan.com>http://brian.teamtegan.com<\a>
This is much easier for the user. Since the URLs change each year, I simply update the domains when a new event comes around.
So - a permanent URL for a sorta permanent page.
http://main.diabetes.org/site/TR/TourdeCure/TourAdmin?px=3992664&pg=personal&fr_id=11747
vs
http://brian.teamtegan.com
It's definitely not hypocrisy to point out the situation or URLs and your opinion of them. Specially since your opinion in this case, is almaost objectively the right thing to do. And your URL does seem simple to me, at least on this page.
While Dropbox and others do it right, I'm a big fan of the SO model, specially with it's compacting and shortening. In fact, just like some sites have sitemaps, I'd go so far as to say that each site publish a URL navigation guide- in their own interest. If I'm more likely to remember your URL pattern, I'm more likely to find something when I want to come back.
Personally I'm not a fan of user ids as a login-device so only use gmail but when there is content that has to be attributed to users, user-ids are the way to go but I don't like that people squat on them and leave them unused.
It totally misses any argumentation regarding SEO/SEM.
Yes, human-readable URLs are very good for search engines too ... so whats my point?!
My point is that in this article there are example URLs written to be "good" because the latter part of the URL doesnt matter.
Well ... and that' not true if it becomes to be relevant to SEO/SEM.
Because, it results in multiple URLs returning the same content - the so called "double content" in SEO terms ...and you guess it, this is BAD.
For sure this only matters if we talsk about any web content that needs or wants very good rankings in search results, or pays for search engines advertisings (because than it gets an price issue).
This way 404's are impossible, and there's always a 'non-breaking URL' reflecting the actual content.
So the current 'valid' URL is specified as the canonical one:
<link rel="canonical" href="https://stackoverflow.com/questions/701030/whats-the-significance-of-oct-12-1999" />
And any request with another slug (or without one), gets a 301:
| =› curl -I https://stackoverflow.com/questions/701030/
HTTP/1.1 301 Moved Permanently
Location: /questions/701030/whats-the-significance-of-oct-12-1999
...
I recently had a non-technical relative try to send me a link to a wonderful graduation video they made on YouTube for a family member. The URL was to their account's admin page, so there was no way to actually see the video. How do you explain that to them?
One shout out to smugmug.com for doing this right for photos. Has saved me a lot of time sharing photos.
Thanks, Scott.
There is no question here - of course short URL are easier but as every site / app has a simple share button - is it really that important?
https://www.hanselman.com/blog/URLsAreUI.aspx doesn't have that ring to it,
As a user, let me make sugget: https://www.hanselman.com/urls-are-ui or https://urlsareuis.com/ would be even better.
Thanks for clarifying.
If(!) its done that way, its fine - as you describe.
Actually what you wrote should have been mentioned in the article - thats what I meant.
Users don't care about URL length or complexity. Only the domain and TLD are important for end users. As long as the website has deep-linking, copy and paste works whether the URL is 5 characters or 500 characters. You only need look at the most big websites on the internet- there's probably zero correlation between URL niceness and success or user experience ratings.
"People who are fed up with the "hashbang fiasco" must not appreciate how a framework (AngularJS for example) can dramatically speed up dev time while easily facilitate desirable UI/UX."
Well, actually Adam... They probably just don't appreciate that anything after the hash is never sent to a server, makes it impossible to pre-render the content before loading the JS, and exposes the limitations of an implementation that favours dev time over function.
Why are we discussing pre-rendering now? Is this relevant to prioritizing the URL as part of the UI?
Great points made in this post.
[let's not get blocked as spam].com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiR4J7Fw_7UAhUJL1AKHSNBBJIQFggkMAA&url=http%3A%2F%2Fwww.dictionary.com%2Fbrowse%2Fsomething&usg=AFQjCNEbVA5JIKdRtoCynte1F48P9tT0Ow
https://hanselminutes.com/587
https://hanselminutes.com/587/i-stole-your-wallet
https://hanselminutes.com/587/scott-hanselman-hates-cats
Scott, how would you propose a OneNote web URL UI? Surely they have to use ids/numbers since names could be unwieldy? (I still hate that there is no deep-linking to notebook pages, but if there were)
^ not a great url, lol
A colleague of mine came up with https://github.com/ananthakumaran/u/ to solve the problem of long ugly URLs.
The approach is to encode the URL based on schema. The added advantage, is that as long as the schema is backward compatible, URL is also. And application gets a decent way to manage state.
Example from the repo:
Without μ:
http://app.com/url#%7B%22lookingFor%22:%22bride%22,%22age%22:%5B25,30%5D,%22religion%22:%22Hindu%22,%22motherTongue%22:%22Bengali%22,%22onlyProfileWithPhoto%22:true%7D
With μ:
http://app.com/url#bHhc9I-aqa
With variable length of the domain name itself we had to make sure to create short-cut URLs to be used in the text messages which were also still descriptive enough for people to know what they were clicking on in the message. But they had to be short enough to allow some basic text content to be included as part of the message before the link for more information.
I've worked on many web projects, often for large companies. It's disappointing to see how frequently URLs are not considered at all, or are at best peripheral to the design and build work. Playing the "SEO card" sometimes helps persuade stakeholders to care about URLs. However, it really ought to be part of the process, regardless of whether it was an explicit requirement from the client or not.
I'd especially like to see more UX and UI design folk be considerate of URLs in their work.
I even wrote a post about it on our company's blog, in the hope it might raise awareness: http://wiprodigital.com/2015/08/20/whats-your-url-strategy/
Perhas its time I wrote another one on the topic and chuck in a link to your post! :-)
Comments are closed.
Fyi, there are a couple spelling mistakes in the first few paragraphs.