The one thing Betterlink does really well is create custom links to the text you select.
It's no surprise linking to text is something that's been missing from the Web, and there are others who are trying to figure out what to do about it. Kevin Marks recently posted his idea on 'fragmentions'.
Fragmentions are Kevin's approach to annotating the Web by linking to specific content. An example URL might look like:
The double hash sign at the end is the signifier for a fragmention, and what follows is a case-sensitive, plus-delimited string to anchor against.
But we can do better.
The biggest issue is that the current proposal isn't a valid URL. In the specification, fragment identifiers (everything that comes after that first hash) can't contain another hash.
We can use the Hashslider homepage as an example. Hashslider is a simple jQuery image slider that saves the current image's identifier in the URL for easy hotlinking.
If I created a fragmention to the text, "link to any content", my URL would look like:
If you visit that link, you'll see the page breaks. And you can't undo the breakage by clicking around or refreshing the page.
This is another dealbreaker. To figure out the result of a fragmention, Kevin writes:
Fragmentions find the first matching word or phrase in a document and focuses its closest surrounding element.
Essentially, a browser should highlight the entire parent element that contains the requested text. Simple example: if I request a sentence, the full paragraph is highlighted.
Suppose I try something slightly more complicated. Like two sentences at the end of an article. If my selection is unfortunate enough, I may end up highlighting the entire article.
That's not useful and is suddenly impairing my experience.
Specifically, not all browsers treat whitespace the same. It's one thing to capture a sentence in the middle of a paragraph. Another to capture a fragment that spans across paragraph or break tags.
We can use another example from Kevin's blog as a test:
If you try this example in Chrome, it works fine. In Firefox or IE -- not so much.
The issue here is portability: if I create a link and share it on Facebook, you should get the expected highlights, even if you're running on a different browser or machine.
Enough about problems. The short answer is that Betterlink solves for all of the above.
Each of those links does exactly what the user expects - it brings us to the specific text that is highlighted. If those sites also included
betterlink.js, you'd be able to see them from any browser or mobile device.
In a followup post, we'll discuss how Betterlink approaches the same problems above, and our principles for creating a text-anchored solution for our users.
There are some basic principles for choosing a way to represent this feature:
In addition, we want to make sure the experience matches the user's expectations. Essentially:
Betterlink was designed specifically with these principles in mind.
Our approach is to piggy-back on a feature all browsers support today: query parameters. An example Betterlink URL looks like:
In the middle of that URL,
?bl-sid=56, is what we've added. For any site on the Web, that
bl-sid will be completely ignored. The sites don't need to use it for anything, and it won't impact the display of the webpage. In short: if Betterlink isn't turned on, nothing happens.
But if it is enabled, then we get to jump directly to the content that's requested.