Should URLs Be Human Readable?
In developing a comprehensive web application, a broad range of decisions must be made. One key element of any web-oriented presentation is the URL… uniform resource locator… the unique web address that is the precise destination of any given hyperlink. How a web app constructs that URL can make a difference.
In the past, significance has been placed on the link itself and making it human-readable. Here are two examples:
You can “READ” the URL and gain some sense of its target… picking out the “url” or “Semantic_URL” at the end.
Here are some examples of NON-human readable links (that work):
The first, natural, human response to any question about favoring human-ANYTHING should be YES.
As a power-browser user (and human), I admit that readable URLs are handy… you can take manual control and type in a URL or just visually scan a list of URLs to get a sense of what might lurk on the other end. MY personal preference would be to have a readable URL.
But, there is the real world…
… which is increasingly “MOBILE”, which really means MOSTLY presented on a wide variety of devices, from phones to tablets,… things that can be moved. As a web app technician, what that infers is a broad range of browser screens with various WIDTHS and HEIGHTS… viewports… and the challenges of simply presenting the exact same data well in all those dimensions.
What does that have to do with URL?
While you can view the URL in a mobile browser, it usually requires extra effort to expose the hidden part of the window so you can see the URL in the address bar… but, even then, most URLs are too long to be easily seen on many devices (yes, you can but it is very clunky). URLs in a mobile world are mostly hidden. That’s the browser.
Plus TODAY, most mobile apps are not web apps, they are “native” apps. Generally, native apps do not expose URLs at all.
URLs have become more complex as database-driven, dynamic applications gain acceptance… all resulting in LESS readable URLs. Fact.
There is also a case to be made that URLs should NOT be human readable… but I think that has more to do with domain names, not what comes after them (but it would still apply!).
From a practical perspective, URL readability by humans is declining and NOT really a battle worth fighting.
It seems most objections to NON-human-readable URLs are either purely emotional OR come from the community focused on search engine optimization (SEO) of web pages. In other words, those trying to promote websites and the ecosystem that has evolved. The thinking is the link gains higher visibility in search engines by having keywords in the URL. I’m sure that was true years ago but suspect the search engine algorithms of TODAY care little about the construction of the URL; that almost all keyword value gains are through interpretation of actual page contents.
Note that the resistance is not technical. If a link WORKS, that part is complete. It takes you to the page intended.
Create a standard that adds a human readability component to HTML.
I picture it as a built-in function that could be referenced on any link… which does an ajax query to the link itself, and returns a json package that forms a popup tooltip-style response on the rendered page… giving an even more complete, human-readable description of the link. We’ve seen widgets like this in the past but I’m visualizing a more modern, mobile variation of the idea (and remember, mobile has no hover; requires a visual/manual prompt!).
The concept is just an extension of the “rel=help” attribute of “<a href> tags. Something like this:
- Typical non-human-readable URL:
- Used within a standard HTML tag:
<a href=”https://example.com/?hash=cbec85f8–5de6–902b-a8ba-a5ac9a7676e4”>text inside the link</a>
- Additional tag attribute, much like you can with DIVs:
<a href=”https://example.com/?hash=cbec85f8–5de6–902b-a8ba-a5ac9a7676e4” data-helptext=”Help text here, or URL to HTML snippet for popup” data-helpicon=”https://example.com/images/icon-inlineHelp.png”>text inside the link</a>
- Even better, do not use an actual graphic in #3 but reference an icon font?
- Best, have all the above automatic (even if attributes above are undefined).
The result would be a hyperlink immediately followed by a tiny icon automatically inserted after the link text. Upon hover or touch of the icon, a popup tooltip gives more details about the link. Any touch closes the popup.
Perhaps approved by standards organization for widespread acceptance?
It is a simple, logical idea that should be universally applied… not proprietary (widgets ARE available)… but a standard.
OH, about SEO visibility? Such a standard would enhance it.
Back to work.