buckyschwarz.net

Should links open in new windows?

Smashing Magazine answered that question succinctly and correctly (back in July of 2008, I might add): No. They shouldn’t. It’s as simple as that*. You should let your uses decide how to handle their links. When you force users to open a link in a new window against their will, it destroys their web experience for a few reasons:

• It removes control from the user in favor of control of the developer, and users should always be in control of their experience
• It forces the user to use the site in a way you’re dictating, which is usually not the way the user wants to use the site
• It removes use of the back button, an integral part of the web experience, even today with all of our AJAXy goodness
• To novice users, it’s confusing: where did my back button go, what just happened?
• To experienced users, it’s downright enraging: thank you, I know how to open links in a new tab or window, I don’t need your help telling me how to browse the web. In fact, I’m going to close your stupid site right now, just to spite you and your stupid ideas.
  
• It doesn’t do what it’s supposed to (keep users on your site): If a user wants to leave, opening a link in a new window won’t get them to stay. Giving them what they want (good content, good user experience) will, however.
• It destroys the very thin veneer that we’re in control of at least something in our existence, often leading to very severe existential crises in which a person’s entire reality might be shattered, leading to unintended consequences including but not limited to: psychosis, rage, murderous rampages, and losing touch with reality

*Of course, there are caveats. I would say that you should force the link to open in a new window or tab only when opening the link in the current window will interrupt the flow of the user experience. What does that even mean? I don’t know. Nah, but seriously, for example: let’s say a user is using your site to buy a vintage harpsichord, and he’s on the last step of the buying process: checking out. He’s found the perfect harpsichord to put in his basement, he’s entered his shipping and payment information, but he has a question about shipping. So he clicks the link that looks like it can answer his questions, and he’s taken away from his shopping cart. Crap, he’s thinking, now what? Do I have to re enter all my information? Do I have to start the whole process over? This is a perfect opportunity to open the link in a new, small window positioned right next to the link.

Smashing and webcredible provide a good cross section of times when you should open links in a new window:

• The link provides assistance, as in the example above
• The link will interrupt an ongoing process, again, see example above
• The link leads to a non-html document, like a PDF, mp3, or movie file
• The link leads to content that will take a long time to load, like a large image, or javascript heavy web page
• The link leads to a printable version of the current web page, although this can be mitigated by using a print stylesheet

Keep in mind however, that even if you do have a situation where it is appropriate to open a link in a new window, you should always inform the user that the link opens in a new window, either via the title attribute of the anchor element, or by specifying in the link text that the link opens in a new window. Similarly, if you’re in a situation where you’re forced to open links in a new window, like say if you work under someone who is convinced he is a usability expert and also makes the decisions and one of those decisions is deciding that all outgoing links will open in a new window, you should try as hard as you can to inform the users that their usability experience is about to be disrupted.

Remember: it’s not 1999, web usability has grown by leaps and bounds over the past decade, and one of the things we’ve learned is that you should trust the user to be in control of their user experience.

I’m a bit mad with myself. I’ve been using the Syntax Highlighter Evolved plugin on my WordPress blog to highlight my code. Well, I would have been using it to highlight my code if it had been working as advertised. There wasn’t any kind of highlighting happening – the code inside the generated pre tags looked the same as the rest of the text on the page.

I’ve hacked together my own WordPress template for fun and posterity to integrate into my site. See, I’m a pretty big newbie to all of this, and it didn’t help that the /blog directory under my main site actually pulls from a separate blog directory one level up (don’t ask me why I did this, I was probably drunk – in hindsight it’s pretty obviously boneheaded). Regardless, I had a suspicion that this had something to do with why the syntax highlighting wasn’t working. I did searches and couldn’t really turn up many good results. It seemed pretty obvious that most people with normal working blogs weren’t having issues.

I ended up looking at the plugin code in the WordPress plugins editor to see if there was something obvious causing it. I spent about 15 minutes looking through it when I figured that there was some kind of issue resolving the directory/URL structure between where the blog was being included and where it was actually located. I found the following code:

// Initalize the plugin by registering the hooks
 function __construct() {
 // Check WordPress version
 if ( !function_exists( 'plugins_url' ) ) return;

 // Load localization domain
 load_plugin_textdomain( 'syntaxhighlighter', false, '/syntaxhighlighter/localization' );

 // Register brush scripts
 wp_register_script( 'syntaxhighlighter-core',             plugins_url('syntaxhighlighter/syntaxhighlighter/scripts/shCore.js'),            array(),                         $this->agshver );
 wp_register_script( 'syntaxhighlighter-brush-as3',        plugins_url('syntaxhighlighter/syntaxhighlighter/scripts/shBrushAS3.js'),        array('syntaxhighlighter-core'), $this->agshver );

I figured it had something to do with the function

plugins_url()

not returning the correct location of the plugins directory where Syntax Highlighter is located. I figured it couldn’t resolve the location of the plugins directory and therefore couldn’t find the JavaScripts that color the code. I spent about an hour tooling around with

plugins_url()

trying to get it to work in various ways and permutations, all to no avail.

I was starting to get frustrated when I noticed, for the first time, right next to the code editor a list of plugin files to edit. One of them was titled ReadMe.txt. “What the hell,” I figured, it can’t hurt to take a look at it. I scrolled down about half way until I saw a FAQ. Right there, in the middle of the page, like a veritable bullhorn shouting, “You freaking moron!!!” at me, was my solution.

The code is just being displayed raw. It isn’t being converted into a code box or anything. What’s wrong?

The answer, of course, was to call the

wp_footer()

function in the blog’s footer. Man, did I feel like a jackass. Here I was, making things difficult, wearing my Big Boy Coder’s™ pants, trying to hack up functions and make things more complicated than they are, when all I had to do was RTFM like the noob that I am and find the function to include.

So naturally, the first thing I had to do (after fixing it) was write a post about it rife with Syntax Highlighting. Thanks, Alex Gorbatchev.

At work, I’ve been working with a user who needs a few certain pages on the site I’m developing to be printer friendly. These pages are usually ones that display data in tables with a dark blue/light blue zebra stripes. All the pages of the application (these table pages included) have a two-column fluid layout with the site navigation occupying the left column. Obviously, for printing tabular data, the navigation need not be displayed, nor do any kind of form controls that might be used for searching for particular data in that table, so obviously, those should be disabled in the print stylesheet.

So, for the first time ever, I wrote up a stylesheet with the media type set to print. I’ve just never needed to print anything from a website before. So I wrote up a stylesheet with the media type set to print. I just set the display properties of elements I didn’t want to show to none and went about testing it. During testing, I kept running into a problem where the left column, which should have been hidden, would still be causing the center content column to float right. The navigation menu wouldn’t be there, but the container the navigation menu lived in was still there, even though its border and content were hidden. This stumped me for a good day and a half, and after hitting my head against my cubicle wall I finally decided to try setting the media type of the main stylesheet of the app to screen. This solved every problem I had and now the tables are printing beautifully.

The moral of the story: Always set the media types of your stylesheets. It’s a good idea and a good way to add semantic meaning to your header files, and also, all the cool kids are doing it these days.