More Link Treatments

One point of discussion I had with J5 today around Fedora Community and links is how should you distinguish, in a web application, between links that take you elsewhere within the web application and links that take you “offsite” or outside of the web application. They’re both links, in most cases are full-page load links in both cases… is it *really* that bad to use target="_blank" links to handle offsite links within a web application?

I think our conclusion was yes, even then it is bad form to use target="_blank" links to open a new window on users. As was pointed out in the comments of my first post on this topic, browsers give users sufficient controls to open links up in new tabs or windows as they so desire. (Of course, middle-clicks are thwarted by javascript links, although the middle clicks can be captured and handled differently using JS, and should be.)

Still, there may be some cases where distinguishing between application links vs. off-site links is useful. One example I can think of – if the web application vendor decides to not ship documentation with the app but instead provide links to the documentation on their corporate website (so within the UI, users always get the latest version of the docs for their product), then the documentation becomes an off-site link. If you’re using the web application in an environment where there is no external internet connection, it might be nice to know which links will be dead and which won’t before you click on them.

Okay, okay. Maybe that’s a contrived example. Well, a more practical scenario: Links that keep you within the application will have the same look and feel as the application by definition. When you click a link that goes offsite, more likely than not you’ll start seeing a different look and feel. That could be confusing to your users. If the offsite link looks too dissimilar to your app and they are expecting to remain within your app, they may think something is broken or they may not understand how they arrived there. If the offsite link looks too similar to your app, they might think they are still in your app but are actually on a site or web application you have no control over and then start filing bugs against your app!

The way I decided to treat offsite links for now (and we don’t do this consistently in Fedora Community yet, let me know how you feel about it and based on that I may expand our usage of this pattern or stop using it), is to add a little icon. For example, in the screenshot above. What do you think?

9 Comments

  1. Indicating external links with an icon is a web design pattern, although not used very widely.
    I'm curious about your assertion about users getting confused when they accidentally navigate away and don't notice it. Do you have any experimental or anecdotal data to support this? Am I too optimistic in assuming that in this century users have generally heard about this "Internet" thing and know that it has more than one website on it?

    1. @Marius, I don't know if you've ever had the experience of watching a usability test. But it's quite eye-opening. You'd be quite surprised not at just how very knowledgable and experienced people run into issues you'd think a person who knew all about "this internet thing" would have no problems with, but also how they run into situations in basic mouse, keyboard, and navigation within and between applications. (Avoiding the topic of digital divide here as well.)
      Anyhow, I have quite a bit of anecdotal evidence towards this point. The problem is not the difference between say amazon.com and google.com and users not understanding they are in a different app. The problem is the difference between say Yahoo Mail and Yahoo Calendar, or between say the Red Hat Support Center vs Red Hat Network. It's the sites that are part of the same family of websites but are actually separate applications that run into this situation. Sometimes, you don't even want your customer to think they are on a different application/site but under the covers they really are using multiple different applications written and maintained by different teams. Other times, you want the customers to understand, oh, I'm at Yahoo.com, but I'm using the Calendar vs Mail vs My Yahoo.
      Having worked on Red Hat Network as an interaction designer for a number of years, I can say that a lot of folks would identify web applications on redhat.com as being part of Red Hat Network when they were only remotely related and neither part of RHN or branded Red Hat Network. (eg http://www.redhat.com/docs). The redhat.com branding across these apps was consistent enough that it introduced confusion.

  2. This is a perennial problem and one which I don't think has a very good answer. All lot of the choices that you'll make will depend on how experienced you think your users are. Using the icons for external links is fairly common and sounds like a reasonable idea – but has many issues.
    Most users will not even notice that they exist. I'm constantly amazed by things like this, but a lot of people will just not even see them, at all. Even those that do will almost certainly not know what they mean and will just ignore them either way. People who are switched on enough to notice the icons, remember seeing them before elsewhere and be aware of what they mean – don't need them anyway. They'll hover the link and look at the status bar, or just middle click.
    Also, target="_blank" is deprecated and isn't valid for XHTML strict; this is a behavior, so you're 'supposed' to use JS for this.
    Having said all that, I mostly do what you're proposing – I use the icons on my site, but without target="_blank" – so the links that go to external sites get an icon and people can choose whether to middle click them or not.

    1. @dflock:

      People who are switched on enough to notice the icons, remember seeing them before elsewhere and be aware of what they mean – don’t need them anyway. They’ll hover the link and look at the status bar, or just middle click.

      I think "switched on" people do know they can do this and do it sometimes, but I've gotten feedback on other posts from these type of users saying most times they just fire a click off and don't even bother to check the status bar because they are too lazy.

  3. The external link icon is reminiscent of what MediaWiki does, which I find effective. It *is* useful to know when the link is external. For example, in a wiki you know it is an external source of information, not part of the central repository you are browsing through.
    Would there be any advantage to having three icon states? One is no icon (in-app link), second is a Fedora-specific icon (new web app is a Fedora Project tool), third is true external link (fully external web site).

    1. @quaid hey! 🙂 Thanks for the comment! I'm not sure if it's the most effective way to go, but the way you propose is exactly what we're going to try to do in Fedora Community:
      no icon or anything – in-app link
      application icon (eg bodhi icon, pkgdb icon) – link to a Fedora infrastructure app
      generic link-out icon – link to an external site
      So far in the Fedora Community pages we've tried this on it feels pretty natural so it may be the right way to go.

  4. Swivelling their eyeball is too much effort? Were these people… American?

  5. @dflock, quite a few Europeans actually. For what it's worth, I too have been guilty of this. I just don't think to look until I already clicked. When I'm opening links in new tabs, it's because I'm too engrossed in the current content I'm reading to leave it, so if a link embedded in the content looks like something I want to read I'll open it in the tab for later. Now if I am so engrossed that I'm queueing up additional content to read *afteR* I'm done with the current content, scrolling my eyes down to the status bar I think could be reasonably disruptive to me.

  6. […] more paintain. Posted in Uncategorized by mairin on June 11, 2009 As I’ve blogged about before, in the past few months I’ve been working a lot on Fedora Community with John […]

Leave a Reply to dflockCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.