“Google Wants to Kill the URL”
The team is mulling its most controversial initiative yet: fundamentally rethinking URLs across the web.
This isn’t the first time they’ve tried to figure out ways to remove URLs from the web experience. The last time they tried, in 2014, they faced a lot of opposition
Adrian Roselli covered a lot of the discussion that took place at the time: “On Hiding URLs in the Browser”
The gist of it is that we’ve already trained regular web users to use URLs for a variety of things and the solution Chrome floated at the time only covers a small part of what they’re for. This is still a problem that Chrome needs to figure out if they want to replace URLs with something else.
Jake Archibald highlighted some of the reasons why Chrome wanted to go this route in 2014, all of which are still applicable: “ Improving the URL bar”
He highlights phishing and security as big issues.
Jeremy Keith at the time wrote an excellent post that highlighted the value of seams like the URL. Seams are how casual users grow to understand how the system works. It’s an important pathway into expertise: “Seams”
The points made by these three guys are still true. So why is the Chrome team revisiting the URL issue, four years later?
Missing from all of this is the fact that making URLs an explicit part of the user interface and a core part of the user-facing browser experience has always been controversial. The URL’s visibility has always been seen by some as a user experience wart and by many in Hypertext academia and theory as a major flaw in the Web as a system.
Here’s what George P. Landow had to say in the book Hypertext 3.0 when talking about various tactics for orienting readers in a hypertext system:
The graphic representation of information embodied in the useful, if limited, desktop metaphor proves an especially effective means of reader orientation in the systems that use them, but World Wide Web browsers, in which the risks of disorientation are particularly grave, do not. Of course, the “Show Location” window in IE, Firefox, Safari, Netscape, and other HTML browsers does provide the exact address of a lexia, and as I write today, following a link to one student’s essay on Patchwork Girl, say, Lars Hubrich’s “Stiched Identity,” would produce the following information in the location window: www.cyberspaceweb.org/ht/pd/lhp… Such information not only apperas in a form daunting to most readers, it fails to be very helpful on two counts: first, the need to create economically bried directory names often renders the file incomprehensible to all but the person who maintains a website and, second, it provides very little information of this particular lexia to the information space it inhabits. (2006: p. 154)
It’s the second problem that is the root of all of the security issues and UX problems caused by URLs. Like ISBNs, URLs provide you with very little in terms of reliable context but provide us with a unique identifier we can use to discover its context.
That isn’t to say that Chrome can come up with an adequate replacement. Just that URLs have been controversial from the start and have, for good reason, been seen as a core flaw in the web browser user experience for many, many years, with many of the arguments in the hypertext community actually pre-dating the birth of the web.