The UX of Hyperlinks—Taking it all a step further.
The other day on everybody’s favorite daily newsletter, I spotted an awesome article by Nash Vail in which he brought up a really great point that had also been on my mind for a while.
Online anchor links suck.
To save you the time of having to read his entire article, the gist was this: links are simply not prescriptive enough. Meaning that when a user clicks on a link within any given website, there is always a level of uncertainty about where it’s going to open the link. Same tab? New tab? New window?
The user has no idea.
He brought up a really great point about control. I, like him, often find myself using the addition of Command key with a link click to make sure that I know where the link will open in my browser. It seems to me, that the control has always been skewed to the side of the developer. The developer gets the luxury of discerning the experience for the user. It’s always been a siloed decision. Even from the user.
So how do we fix it? How do we show the user and kill that uncertainty? How do we make clicking less of a commitment?
If you have the time, definitely give Vail’s article a read—it’s pretty quick. He goes through his process in which he designs out some icons and comes up with an interaction model in which, upon hover, the icons would appear giving the user a choice of where to open said link.
I love it. I think it’s an excellent idea and a great first stab at solving a pretty annoying problem.
Fixing the Fix to Fix the Problem
The problems I saw in his approach were these: 1) How would this work on mobile? 2) How do we make the decision of where to open a link amicable between the user and the designer (or developer)? 3) How do you train the meaning of the icons, or the behavior itself, to the end user?
Number 1 was easy. Number 2, not as simple. Number 3 is a complicated one, but could also be overcome.
I decided to start by taking his idea of icons a bit further and envisioned a world where this might one day become a powerful default browser function instead of just a neat one-off plugin.
I took the approach of thinking for both the dev and the user at the same time. What if this was a css rule that we could one day write in? Still have our decision making on the product side, but make it very clear for the user where the window would open, and then allow them to either go for the default, or choose their own path? Have some sort of element—always present—that would clearly delineate to the end user where the developer or designer wants the window to open, and then let them decide to follow their rules or not?
Hmmm….
As you can see above, I ended up taking the same icons he designed and just applied them a bit differently to solve for the issue. In his model, one would hover and then see where the link would open, or choose. I just thought up a new element that would be a part of any anchor tag, that was ever present and stylable to reduce the latency in the discovery process.
What if these icons were just a part of any link that one could style and give an open rule to?
It would give the end-user an exact idea of what will happen when they click on the link and, essentially, reduce the need for the Command + Click method! Brilliant!
But wait, what if I don’t agree with the decision made by the designer/dev and just want to open it my way?
Well, here’s where I ended up solving the two problems I mentioned earlier.
I still liked the idea of some sort of hover event for the decision, but I didn’t want to let it get in the way of any regular click. If every click has to have a hover -> click process, it felt like it would become an even bigger process for someone to commit to the click. So I figured, kill half the median and you’ve solved have the problem.
As you can see above, I ended up solving this by using a hover event on the new anchor element. I added a hover/tap zone on the element itself and also envisioned this as a default anchor behavior. Hover/tap for the context, then choose your method. Hold the hover or press for some detail.
Boom. Solved 1 through 3 in a single punch.
Injecting UX Into Browser Design?
As you can see, this was a pretty simple solve (on a conceptual level anyway). However, the real reason that I was so excited about this topic and approach for the fix was this:
What if one day browser manufacturers and web standards peeps were taking their methods further and, instead of introducing new elements and css rules into the develop-o-sphere for the sake of making dev’s lives easier, they started thinking about how to make the end user’s (and by extension, the developer’s and designer’s) lives easier?
Of course, this is through the lens of someone who’s ignorant in what goes into the process of introducing such things, but to me this all seems like a pretty simple addition into the lexicon of the web and has a huge level of added impact into the interface for the user by default. Isn’t it about time that the default rules of the web were also—by default—the best experience for the user?
And also, of course, I’m not blind to the fact that certain affordances like the ever present default text-decoration: underline exist, but shouldn’t we start thinking of introducing web elements that directly help the user and not just the person in charge of helping the user?
What do you guys think? Am I totally off base? Am I missing something? Just want to assert a gutsy knee jerk reaction/opinion? Please share any and all thoughts!!
Published in #SWLH (Startups, Wanderlust, and Life Hacking)
