It’s not easy to get the information architecture right when designing a web interface. What might appear to be a workable solution in the pre-production planning phases does not always come together in production, and we all know how clients like to pitch those curve-balls at us, mid-development. The result can often be an excess of interface elements, or even orphaned functionality that has nowhere to live.
This situation can be hard to solve. Once you’re in production it can be expensive to go back and refactor the IA to take account of your predicament. It may seem like there is no good solution and besides, you can’t backtrack as the project deadline cannot be allowed to slip. In these circumstances it’s easy to see why so many web developers play their joker. They resort to the get-out-of-jail-free card that they’ve been holding to their chest the whole time. They put the functionality in a pop-up window.
It seems like a logical choice though, doesn’t it? All you need is somewhere for the user to click, and you can launch a new, bright clean canvas on which to weave your evil ways. The pop-up needs no context within the site, and therefore doesn’t have to fit into the IA. So it’s the perfect solution, right? No. You’re bad and wrong, and very naughty. On your rug.
By putting pointy-cornered functionality into pop-up windows, you simply address one small problem by introducing another problem of such magnitude that the fixes to all your other problems become nicetohaves at the bottom of your project manager’s wish list. It’s the start of a very slippery slope. Once you’ve use a pop-up within the interface, it becomes a precedent that is very easy to follow. Suddenly, the answer to every interface challenge is a pop-up window. It’s not long before you create a situation where a pop-up needs to launch another pop-up and it’s Geri Halliwell all over again.
So here’s the bit to print out and pin to your wall: by putting awkward functionality in a pop-up window you’re either creating a) and interface inconsistency, or b) a precedent you’ll wish you’d never set. Pop-up windows are not a get-out-of-jail-free card, they’re a dig-a-tunnel-and-escape-from-jail card that leaves you forever looking over your shoulder and living life on the run. They will catch up with you, and this time, it’s personal.
Comments
I think the same is true no matter what web project you are on. Once you set a precedent by using a certain feature in a site design, it can explode… a uni web environment is the worst for this.
I know this, but answering it in your post makes it more credible.
Just my 2 cents.
I feel like I’m not adding much value with that explanation, but there you have it.
The other day I suggested to Drew that we should do a ‘change password’ function on a current project inside a pop-up… oops. :)
You can still go ahead and do it if you like ;-)
Out of natural, misguided, curiosity I clicked on the Geri link. Heavens preserve us. What were they thinking?
Anyway, having just added a pop-up form to my site (where, I tentatively suggest) it is perhaps okay (it’s a largely flash based site with just the one page of HTML – so, the ‘precedent’ risk is minimized nor can it be used ‘everywhere’ because there isn’t an ‘anywhere else’), I will now have nightmares about Geri Halliwell and my web based connection to her.
Jeepers.
There are a few cases when popups can be used effectively (for instance, exit popups that you show only once to let people know about a subscription offer—that works well and users don’t mind) but those are quite rare. Most features and content belong within the main site, within the chrome.