In the last six months or so, Internet pop-up blockers have become increasingly commonplace on both personal and business computers. While pop-up blockers can improve the browsing experience by preventing unwanted advertising, they can also interfere with other, legitimate applications. Many of us in the e-Learning sector are spending an increasing amount of time dealing with this interference and the resulting impact on our courses and learning management systems.
This article sheds some light on the issue by explaining pop-ups and pop-up blockers in depth, looking at the specific problems they cause for e-Learning producers, and providing some solutions to work around the issues.
A Pop-up Primer
To understand how pop-up blockers work, we first have to understand what pop-ups are and how they’re triggered. Pop-ups, in the context of pop-up blockers, refer to new browser windows that are spawned from the main window where the user is doing their browsing. There are a variety of methods by which a pop-up window can be triggered, but the most common ones include:
- The user clicks a link that uses basic html to load a page in a new window.
- The user clicks a link, which does some kind of processing then loads a page in a new window.
- The user mouses over an object and that action launches a new window.
- The user makes a selection from a dropdown or select box and that action launches a new window.
- When the user enters or leaves the current page, it automatically spawns a new window.
<a href=”newpage.htm” target=” _blank”>click me</a>
<a href=”javascript: launchNew()” >click me</a> <script language=”Javascript”> function launchNew(){ //do some processing open(‘newpage.htm’); } </script>
<p onMouseover=”launchNew()”>
This is normal text.</p> <script language=”Javascript”> function launchNew(){ open(‘newpage.htm’); } </script>
<select onChange=”launchNew()”> <option>Item 1</option> <option>Item 2</option> </select> <script language=”Javascript”> function launchNew(){ open(‘newpage.htm’); } </script>
<body onLoad=”launchNew()”> <script language=”Javascript”> function launchNew(){ open(‘newpage.htm’); } </script>
In the first two methods, the user was required to click a link to initiate the popup. The third and fourth methods are a little more ambiguous, because the user did something to initiate the pop-up (mousing over an object, or selecting something from a select box), but they may have been unaware that they were doing it. The final method is purely automatic since no user activity was involved.
Both advertisers and legitimate sites can use all of these methods, but it’s the last method — the automatic launching of a new window when the user enters or exits the page — that most advertisers use. Sometimes it’s just one or two windows popping up; sometimes it’s a never-ending explosion all over the screen. In any case, most people get annoyed pretty quickly and start looking for ways to stop it.
Blocking 101
Pop-up blockers, at their most basic, prevent a Web page from opening a new browser window. Different blockers have different criteria for determining whether or not to block the pop-up, but they all prevent windows from opening at some point. Most blockers allow the first two methods described above and block the last one. Different blockers handle the middle two differently.
There are two main types of pop-up blocker commonly used right now:
- Blockers that the user intentionally installs as either standalone software or part of an Internet security package.
- Blockers that are built into browsers or OS updates. The user may be unaware that they have these blockers.
The standalone software packages include the browser toolbars from Google, Yahoo and MSN, as well as commercial security software such as Norton Internet Security. There are also a number of shareware pop-up blockers that are either standalone blockers, or consolidated packages with built-in blocking. A search of download.com shows 162 different applications in the category of “pop-up blocker.”
Pop-up blockers that are built into other applications include the blocker that was added to Internet Explorer (IE) by the Windows XP Service Pack 2 (XP SP2) update, and the blockers built into alternative browsers such as Firefox, Opera, Safari and others. The XP SP2 blocker appears to be the most prevalent of the built-in blockers right now.
How they work
In technical terms, the blockers monitor the Javascript window.open() command and prevent it from executing under certain conditions. Those conditions differ depending on the blocker, but most try to block “automatic” pop-ups — activities similar to the fifth example above. The specific functionality of the major blockers is outlined below.
Browser toolbars — Yahoo, Google, and MSN
All three of the major browser toolbars have pop-up blockers that show up on the main toolbar and give a visual (and/or audible) indication that they’ve blocked a pop-up. They block automatic popups but not pop-ups initiated by a user action. All three have a whitelisting function that allows you specify sites where all pop-ups should be allowed. MSN has an additional option to allow all pop-ups from intranet sites.
Shareware blockers
In contrast to the browser toolbars described above, the numerous shareware blockers tend to employ stricter popup blocking logic. In many cases, they block all pop-ups, regardless of whether the user initiated the action or not. That means that in the five examples above, most shareware blockers will block all of them by default. Some will even go so far as to stop all Javascript that runs when the page loads or unloads.
Alternative browsers
Firefox, Safari and Opera are similar to the browser toolbars in that they block pop-ups that are launched automatically but don’t block anything the user initiates. However, unlike the browser toolbars, the alternative browsers don’t all have whitelisting functionality, so users may have to turn the blockers off completely if they want to see automatic popups from specific sites.
Windows XP SP2
The XP SP2 blocker is more advanced than any of the other ones and includes some features that aren’t strictly pop-upblocking, but generally provide enhanced browser security. XP SP2 blocks automatic pop-ups and allows user-initiated pop-ups. However, by default it allows all pop-ups from sites in the Local or Trusted security zones and also provides an option to block all pop-ups (automatic or user-initiated) from selected sites. In contrast to other blockers that focus on the window.open() command, XP SP2 also looks at several IE-specific commands, including showModeless Dialog(), showModalDialog(), navigateAndFind() and showHelp().
Finally, even without the blocker active, XP SP2 imposes restrictions on browser windows and will not allow any windows to be created that are larger than, or outside of the viewable desktop area. Windows also cannot be sized or positioned such that their title bar, address bar, or status bar cannot be seen by the user.
So, what’s the problem?
While all of the blockers noted above do a solid job of preventing unwanted advertising pop-ups, they also prevent some legitimate pop-ups, which can interfere with, or completely disable, Web-based applications. For those of us that produce Web applications, it was only a minor irritant prior to the release of Windows XP SP2. Up to that point, most people using a pop-up blocker had intentionally downloaded and installed it, so they knew the ramifications and how to configure it appropriately. Even in cases where the blocker was part of another package (e.g. built into the browser or part of a larger software package) the pop-up blocking was usually listed as a major feature, so users had some idea what they were getting into. With the release of XP SP2, however, many people unknowingly installed and activated a pop-up blocker and that’s when the real problems began.
I did a quick Google search for “popup blocker XP SP2” and found numerous online support pages with information about the XP pop-up blocker and how to configure it. It’s obviously an issue affecting all kinds of Web-based applications, including distance learning, Web mail applications, online banking, and E-tail among others. With such a widespread issue, you can expect to see more articles and discussion across industry sectors in the future, but for now let’s focus on e-Learning.
To understand why pop-up blockers cause problems for e-Learning, we need to look at how pop-ups are used to launch and track courses. Pop-up window functionality is commonly used in Learning Management Systems (LMS) to launch courses, and also used by those courses to send tracking data back to the LMS. To provide the most transparent user experience, many of these activities happen automatically. This is exactly what pop-up blockers prevent.
On the LMS side, the issue is more obvious and arguably less dangerous. Many (if not most) systems launch courses in a separate window that pops up when the user navigates to a certain location within the LMS. This is pretty standard Web-application functionality and it provides numerous benefits in terms of controlling the features and functionality of the browser window where the course runs. However, depending on the specific way the LMS launches the course, the blocker may prevent it from happening at all. I say that it’s less dangerous because if the course doesn’t launch when the user expects, it’s generally more obvious that there’s a problem and the user will either start troubleshooting it or call IT for help.
Pop-ups are also commonly used as a seamless way to send tracking data back to the LMS. Typically, a pop-up (or pop-under) window is launched to pass data back to the server, and then it closes itself when the update is finished. The user can continue working through the course without being interrupted by the data housekeeping. This can be done automatically when users enter or exit certain pages in the course, which minimizes the interruption for the user, but it’s this activity that can be seriously disrupted by pop-up blockers. Since the tracking is designed to be transparent to the user, they’re usually not aware that it’s happening in the first place, so when the blocker prevents it, they often don’t notice. In fact, the user may not notice that anything is wrong until they’ve exited and re-entered the course, when they discover that their previous data wasn’t saved and they have to start all over again. I’ve seen users spend multiple hours working on a course and later discover that their results weren’t saved because a pop-up blocker prevented the course from notifying the LMS about their status.
Solving the problem
Whether the blocker is interfering with the course launch or the results tracking, we need to know about it and resolve the issue before it causes problems for the user. Now that we know how blockers work and why they cause trouble for us, there are a couple of things we can do to minimize the problems. We can 1) test for the presence of pop-up blockers before launching courses, 2) we can have our users whitelist our domains so the pop-up blockers ignore us, and 3) we can recode our applications to avoid the actions that we know cause problems.
None of these solutions is a 100% foolproof, totally transparent solution, but a combination of these three workarounds will solve the problem in the vast majority of cases.
Testing for blockers
Testing for the presence of a pop-up blocker is pretty straightforward. All you need to do is direct the user to a page that launches a new window onLoad and see if that window opens. If the window opens, there is no pop-up blocker. If it doesn’t, then there’s a blocker of some sort activated. I’ve put together a simple pop-up blocker test that does exactly this, and also reports blocker status back to the user. This is particularly helpful for those people who don’t know they have blockers activated. It’s simple and quick enough that it can be integrated directly into your application without impacting the performance or user experience.
Here’s how it works:
- The user clicks a link that launches a pop-up displaying a simple page with a “blocker turned on” message. We’ll call this window P1.
- P1 is configured to automatically launch another window (P2) that displays a page with a “blocker turned off” message.
- P2 is configured to close P1 when it opens.
Both windows are coded to open at the same size, in the same position. If the user has a blocker turned on, P2 will be prevented from opening and they’ll see the “blocker turned on” message from P1. If they don’t have a blocker, P2 will open properly, which triggers P1 to close, and the user will see the “blocker turned off” message from P2.
This simple test works quite nicely against the built-in browser blockers or the packages from the major vendors. Some of the shareware blockers that prevent any new window from opening will break the test and require special treatment. Getting around those is more work, but they tend to be rarer so you may not need to bother with it. Contact me offline if it’s a problem and I’ll give you some code to deal with those situations.
Sidebar 1 shows the code in the pop-up blocker test: openPopupCheck1() is the function you call to start the test.
Popuptest1.htm
<html>
<head>
<title>Popup Blocker Check</title>
<script language=”JavaScript” src=”popupcheck.js”></script>
</head>
<body onload=”openPopupCheck2()”>
<b>You have a pop-up blocker running.</b><br><br>
<button onclick=”window.close()”>Close</button>
</body></html>
Popuptest2.htm
<html>
<head>
<title>Popup Blocker Check</title>
</head>
<body onload=”window.opener.close()”>
You have no pop-up blocker running.<br><br>
<button onclick=”window.close()”>Close</button>
</body>
</html>
Popupcheck.js
function openPopupCheck1() {
var width = 400;
var height = 400;
var x = (screen.availWidth - width)/2;
var y = (screen.availHeight - height)/2;
var features = “width=” + width + “,height=” + height +
“,top=” + y + “,left=” + x;
window.open(“Popuptest1.htm”,”p1”,features);
}
function openPopupCheck2() {
var width = 400;
var height = 400;
var x = (screen.availWidth - width)/2;
var y = (screen.availHeight - height)/2;
var features = “width=” + width + “,height=” + height +
“,top=” + y + “,left=” + x;
window.open(“Popuptest2.htm”,”p2”,features);
}
To integrate the test right into your course, you can have your “start” link initiate the test, then have Popuptest2.htm open your course window automatically. If users don’t have a blocker, they’ll skip through the test and be taken to your course quickly and seamlessly. If they do have a blocker running, you can catch it before they go into the course, which minimizes their chances of data loss down the road.
A functional version of the pop-up test is posted at http://www.cranialexpansion.com/popup so you can see it in action. On that same page you’ll see a link to a zipped version of the files that you can download and use.
Whitelisting
I briefly mentioned whitelisting above when describing the major blockers, but I’ll provide some more detail here. Whitelisting is simply the process of telling a security application to ignore certain sites that you trust. With most pop-up blockers, you can specify white list sites and the blocker effectively turns itself off when it visits these sites. No pop-ups will be blocked, regardless of how they’re triggered. Most of the blockers listed above have very simple whitelisting functions, but I’ll go through the basic steps for the major blockers and you can copy/paste this onto your support page.
Google toolbar
Click the pop-up blocker button on the Google toolbar to allow pop-ups from the current site. Hovering over the button provides tooltips with instructions.
Yahoo toolbar
Select pop-up blocker dropdown menu, click “Always Allow Pop-ups From...” to display a list of sites where pop-ups have been blocked. Select site and click “Allow” to add site to whitelist. Note that you can’t proactively whitelist a site — Yahoo must have blocked a pop-up from that site before you can whitelist it.
MSN toolbar
Select pop-up blocker dropdown menu, click “Allow Pop-ups For This Site” to whitelist the current site. Click “Pop-up Guard Settings” to manually add URLs to the whitelist or turn on “Allow pop-ups from intranet sites.”
XP SP2
Add site to Trusted domain in IE Security settings. Select Tools | Internet Options | Security tab, then choose Trusted sites and click Sites button to add URLs.
Coding around the blockers
Since most of the pop-up blockers block the window.open() action when it’s triggered by an onLoad or onUnload event, you can get around them by recoding your application so it doesn’t use these events to open windows. Depending on how your application works, that may be a simple task or it may be extremely difficult. In many cases, you may have user-initiated actions happening elsewhere on the page and you can tie your window opening to those instead of using the page load or unload. For instance, instead of having a pop-under window automatically open when your main course menu loads, have the window open when the user clicks the links already on the page.
This solution works great if the user is going to be clicking something and you can use that click for your own processing, but if you can’t piggyback on the click, it doesn’t help. One obvious example where you can’t easily piggyback on the user interaction is the close box in the top right corner of the window. When the user clicks the close box, your options for intercepting their action and executing your own code are severely limited. You can discourage users from clicking the close box and try to direct them to an exit button somewhere on the page, but if they want to close the window, there’s not much you can do in html to stop them. Also, since users expect that they can click the “x” to end their session, disabling that doesn’t help your usability. Another option might be to use the window.opener object and pass the data to another window that’s already open. That will get your data out of the window being closed, as long as you have another window open to receive the data and process it.
What the future holds
With so many pop-up blockers available free of charge, advertisers are starting to move away from pop-ups and towards another, equally annoying, mechanism — Flash advertising. You may have seen some of these already on some entertainment sites, but if not, here’s what happens:
- The Web page loads as you expect it to.
- Once it’s finished loading, an animated Flash presentation appears on top of the content and plays an advertisement — sometimes integrating sound and video directly into the ad.
- When the ad is finished, a close box appears, allowing you to get rid of the ad.
- If you click somewhere in the ad space outside of the “close” area, you get directed to the advertiser’s Website.
In some ways, these things are even worse than pop-ups, because you can see the content that you’re after in the background, you just can’t get at it. Some of the smarter ones have the
close box appear throughout the ad, so you can get rid of it quickly, but many non-IE browsers don’t render the ads correctly and you’re often stuck with a broken page when the ad is finished.
Of course, pop-up blockers are no help in these situations because the ad didn’t appear in a pop-up window, but within the main window, in a separate layer. Some shareware pop-up blockers are starting to include a Flash ad killer that looks at the size and positioning of Flash objects and attempts to determine if they’re ads. If it thinks the Flash layer is an ad, it doesn’t get rendered.
This trend could represent additional problems for e-Learning developers down the road, since many of the interactive components in Web-based courses could easily be confused with Flash ads and not rendered properly. This trend is still in its infancy and hopefully won’t become an issue, but it’s definitely something to watch and be prepared for in the future.
Conclusion
Pop-up blockers may be a pain for e-Learning developers, but with a little proactive testing and some recoding, we can avoid the problems and provide a much better experience for our users. Internet advertisers will continue to search for new ways to get their ads in front of people, and Web developers will continue to find ways of blocking those ads. We need to be vigilant to ensure that our e-Learning doesn’t get caught in the middle.
