Usability and Design of WiFi Interstitial Pages

You’re out somewhere, maybe a coffee shop or an airport.  Suddenly, a man falls to the floor – you need to know – what’s the antidote for tricyclic antidepressants*?  You grab your laptop or mobile and use the local WiFi to look up the answer –

Only to be annoyed and inconvenienced by the interstitial “terms and conditions” page that the coffee shop and/or airport redirects your browser to.  Time is of the essence!  Why do they need a 2-minute flash animation to load an “I agree” button?

Thus ends my attempt to make a relatively boring subject seem interesting.  In any event, I can’t be the only person who’s noticed that WiFi login or “terms and conditions” pages are often way more complicated and annoying than they need to be.

In the hope that someone, somewhere will do a quick search before implementing one and come across this blog, here are some guidelines.  These all follow logically from supporting the user’s goal, which is to get info quickly, and the business’ goal, which is to attract and keep customers.

Do not require Flash, ActiveX, or god forbid Silverlight.  Nothing you could want to do here could possibly require it, and there are lots of WiFi-enabled mobile devices that don’t have it.  Do you really want to poke a finger in the eye of every customer with an iPhone?  If we’ve already bought iPhones,  we obviously like spending money!

Make the checkboxes / buttons large enough to click on a small device.  So that people with touchscreen PDAs, Blackberries, iPhones and G1’s will be able to touch it on their screens.

Make the page and any server-side code fast.  Stay out of the user’s way as much as possible.  If your code can’t accept a form and do some logging without dragging a user’s browsing session to a crawl, you need to go yell at your devs.

Once users agree to terms, save it in a cookie for a reasonable amount of time. Many mobile devices don’t allow programs to run in the background, which means session cookies can expire every time the device dozes off.

Once users agree, redirect them back to where they were trying to go.  And use a real, server-side http redirect too, not a fragile javascript redirect.  Many people set up their browsers to ignore those.

Make the legal terms and conditions as readable as possible.  Readability is an interesting topic, with lots of research into measurement formulas and the like.  I think we can all agree that an iframe with 1700 words of legalease is not readable or useful.  And while we’re at it, why not add some actually useful information, like bandwidth limits, disabled protocols, etc.  If you are blocking POP and IMAP, let me know so I don’t waste time trying to check my email.

While the crazy scenario at the beginning of the post isn’t very likely, this isn’t just a list of gripes.  Why are you providing WiFi if not as a service to customers or a way to differentiate?  Well, coffee shops with WiFi aren’t very unusual anymore, so you should look at it as part of the who customer experience.

* Why did I pick tricyclic antidepressants?  I did a Google search for poison antidotes and picked the first one with an antidote I thought you might be able to find, in a mad rush to save a beloved minor character’s life, like in a TV show.

EDIT:  thanks to Wysz for pointing out the massive numbers of typos.

2 thoughts on “Usability and Design of WiFi Interstitial Pages

  1. I need a wifi LAN based reminder pager for disabled clients, very simple to use, controlled by an existing reminder calendar on the family’s home computer.. Any ideas?

  2. It’d be nice if networks would let you know whether they actually are ‘free’ or not. If I log on to a public hotspot and I need a login, then really it’s not much better than a secure hotspot is it?

Comments are closed.