How to build the world’s best captive portal.
So, you’ve been offering public Wi-Fi for some time and you’ve seen some of your competitors use it as a mechanism for collecting customer information (80% of all data collected by hospitality comes from public Wi-Fi) and you may be thinking, “that looks easy!” or “its just a web form…”
If only it were that simple. The best-case scenario for most captive portal self-builds is something that just about works and only slightly annoys customers.
In the worst-case scenario, you’ve just put a massive barrier up to your clients being able to get online. Connectivity is now considered more essential than toilet paper according to a consumer poll of what UK citizens would prefer to live without. As such, any action that blocks customers from Wi-fi could severely damage their experience and your reputation.
Considerations
It needs to be quick and easy for users to get online. The walled garden is the first hurdle, and if it doesn’t go smoothly, where many users give up. The walled garden is essentially a webpage which appears to be online. However, it’s actually the only bit of the internet you can see until you’ve logged into the captive portal.
Your customer only has access to a single domain that in most cases will be propped up by a sub-standard DNS service so will also probably need a static IP.
It is important to make setup as straight forward as possible and to minimise the number of IP’s/Hostnames you use. The best way to achieve this is by running traffic through a proxy with SSL.
“Let’s enable log in by social, isn’t that what everyone does?” — No. This just isn't a good idea. You may have been told it is the future because you can link into a users ‘social graph #2020’ to profile which football team your customers support. However, the way this works on the web isn't the way it works behind a walled garden, because the walled garden has no way of speaking with social apps natively and because the browser sessions in the walled garden are cookie-free, the user will be taken to a mobile version of the social site. You’ll also need all their endpoints in your walled garden, to put in their username and password, fun fact! 95% of social network users don't know their username and password combination. Unless you can have native SDK access (Apple Sign In) this is an utter waste of time and will do more harm than good.
Page load
Dos & Don’ts
Do — MAKE EVERY KB COUNT: Your client has no guaranteed level of connectivity and might be connecting to a capped Wi-Fi network.
Do — Every item on your page should defer from loading unless it is absolutely critical to the user getting online. If you are using modern dev tools you should be using some form of an analyzer and making anything/everything outside your core-bundle asynchronous so it doesn't impact your time to interaction and transfer size.
Don’t — import complete font sets, your user doesn't care about loading 500 beautiful SVG icons Font Awesome when they only see 1.
Don’t — import design libraries. Figure out which elements you need and just import those. If you have a 100kb+ sized CSS file you’ve likely tripped up somewhere.
Do — Compress and rescale images, you may upload several 5MB images to make the page look beautiful and that's fine… but if your client is using a 375x812 do you really need to load the full thing for it then to be downscaled by the client? no. Use the attributes you know about the device to serve an image that's exactly the right size for the device. This will reduce your image size by ~95% in most cases.
Gzip + WebP + CDN Cache, cache and compress everything aggressively. Every KB counts.
Once you’ve reviewed the steps above run it past Google’s lighthouse tool to check that you are on the right track. If you’re scoring below 80 go back to the drawing board.
Compatibility
Think IE10 (a browser released in 2012 that supports 0% of the modern web standards) doesn’t get used any more? Think again. You’re dealing with 99% of the public, not just the device you are building on.
Use a tool like BrowserStack to run your creation through every browser under the sun.
When you are compiling your code be sure to use EcmaScript modules (ESM) builds. This effectively means you’ll end up with two versions, one that will work on legacy devices and one that will work on new shiny devices without taking a performance hit on backwards compatibility.
Accessibility
Your client is quite literally anyone with a Wi-Fi enabled device that has a browser.
When looking at things like inputs make sure they are at least the size of someone's thumb (sounds obvious). Think about what happens if your client is using a screen reader. Test that you can fully navigate the page without using a touch or cursor input.
While you may have perfect vision and fine motor skills, many of your clients will not. For more information, Stanford University has written a great tips post on web accessibility here.
Locale
If you expect customers from around the world you’ll need to make sure all the above is true for currencies, formatting, time and language.
If you have to ask them which is their preferred language, you a probably starting off on the back foot when that information exists within the user's device.
Experience
If you know who your clients are, for god sake please don’t keep asking them for their details. You’ll annoy them, and it’s a missed opportunity for you. Instead, show them a welcoming screen, or promote something you think they’ll like “Check out our new candyfloss cocktail” + video.
Be clear about what data is being collected and why. There is also the GDPR to consider, which makes it illegal to unknowingly exchange personal data for a free service. You must always give people the option to skip the whole thing, NOT BY OPTING OUTING OUT AFTER THE FACT!!
This is a golden opportunity to connect and engage, remove the friction make your clients feel known by giving them a dynamite experience. This isn’t an opportunity for someone to tell you everything about themselves to get online. If you want to know more ask them in small chunks (and give them the option to not tell you).
Validation
It’s good to validate inputs on the fly. No one likes being told they have to go back and submit a form. Using Regex is a great start on inputs but there will be some fields that need server-side validation eg. email and phone numbers.
Don’t try and validate a clients email by sending them an email to confirm before they are online. To expand on this a little. If your guest is trying to access your Wi-Fi to get online because they don't have the internet. It is going to be rather tricky for them to get online to check their email to confirm their identity. So while this is a common pattern for authentication within web apps, it won't work here.
Hardware Vendor support
There is no one prominent vendor of WiFi access points. If you want your captive portal to work, you’ll need to support the majority (not just your favourite).
Every vendor has its own take on authentication, and unfortunately documentation is often lacking. The best way around this is to get your hands on some hardware.
Integration
Companies rarely use just a single product, so having a solution that integrates seamlessly with everything makes for a much better experience across the board.
Take a common scenario of booking a table online. In an ideal world, as soon as you walk through the door you get a confirmation popup on your phone, telling you when your table is ready and what number it is. Integrations should allow for this sort of capability.
If your integration method is sending personal registration data over FTP or by email this is not an integration. This is dangerous. The reason why this is bad practice is that if your guest requires their data to be removed from your system, their data actually exists in a file, not on a database which means you have made their right to be forgotten extremely difficult for anyone other than the system admin. Also imagine for a second, an entire database of personal information being sent over the open internet in a file… pretty scary stuff.
Why do captive portals still suck?
Bad captive portals should no longer be an issue. However, I think I am closer to understanding why the experience of captive portals is generally so awful.
- The techies of the world feel like this problem has been solved
- The customers don’t know any different
- The end client pays the price
In reality, this is a user experience problem and it is extremely hard to get right. So when someone says ‘we built a solution for that’ have they actually?
Upon closer examination, I would expect many captive portal self-builds to fall short in some (or all) of the areas outlined above. I see businesses make the same mistakes over and over again. The simple truth is that it’s a hard problem to solve. It isn’t “just a webform”, it’s so much more.
