Lothian Buses Wifi Is Shit
14 August 2017 12:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
digitalravenI've been cursing the Lothian Buses wifi implementation on Twitter for a while now. I've emailed this to their wifi provider (LetsJoin), and am sticking it here for posterity.
The LetsJoin portal has a number of issues:
To go into more detail, LetsJoin's captive portal uses DNS redirection. The user’s device connects to the wifi, then the user must open a browser and try to navigate to a page. At that point, the DNS redirect takes the user at the LetsJoin homepage, where they have to scroll past a number of clickbait headlines to find the “Go Online” link at the bottom.
If the wifi network is known — that is, if the user has ever connected to it — the device will connect again automatically. In the case of a phone or tablet, it presents as having a wifi connection, but until the user goes through the rigmarole of trying to load a page in the browser, it doesn’t have a connection. There is no way to tell the device “If this network is present, do not use it.” This causes many apps that users rely on to stop functioning exactly when they need to work.
For example, the Lothian Buses bus tracker app requires a network connection to show bus information. If a user has it open at a bus stop, and a bus using LetsJoin goes past, the phone automatically connects to the bus wifi. Because the captive portal uses DNS redirection, it does not give the chance to fall back to the existing mobile data connection. The app thus _loses_ the ability to connect to the tracker. At busy bus stops, where a user will most want to use the app, they have to _manually_ disable wifi in order to use it. This is not at all useful or expected behaviour from a user’s point of view. The same thing happens with the Lothian Buses M-Ticket app — the user cannot activate the ticket that they need to get on the bus at the point that their phone has connected to the bus wifi.
A more useful implementation of captive portals, as used by most wifi providers on public transportation, is via HTTP redirect. The phone connects to the wifi, makes an HTTP request, and that request is redirected via a HTTP 302 redirect to the captive portal page. On mobile devices and modern laptops, this displays as a pop-up window when the device connects to the wireless network, with a clear “cancel” button. As such, a user who is in the middle of trying to activate an M-Ticket — that they may need to make a journey home — can just tap ‘cancel’ and immediately get their existing mobile data connection back.
The LetsJoin portal has a number of issues:
- Roughly once a week, the LetsJoin portal page displays a 404 error, making it impossible to get online via the bus wifi.
- At a similar frequency, but on different occasions, the pages display and allow clicking on the “Go Online” link, but it hangs on the “Connecting” page.
To go into more detail, LetsJoin's captive portal uses DNS redirection. The user’s device connects to the wifi, then the user must open a browser and try to navigate to a page. At that point, the DNS redirect takes the user at the LetsJoin homepage, where they have to scroll past a number of clickbait headlines to find the “Go Online” link at the bottom.
If the wifi network is known — that is, if the user has ever connected to it — the device will connect again automatically. In the case of a phone or tablet, it presents as having a wifi connection, but until the user goes through the rigmarole of trying to load a page in the browser, it doesn’t have a connection. There is no way to tell the device “If this network is present, do not use it.” This causes many apps that users rely on to stop functioning exactly when they need to work.
For example, the Lothian Buses bus tracker app requires a network connection to show bus information. If a user has it open at a bus stop, and a bus using LetsJoin goes past, the phone automatically connects to the bus wifi. Because the captive portal uses DNS redirection, it does not give the chance to fall back to the existing mobile data connection. The app thus _loses_ the ability to connect to the tracker. At busy bus stops, where a user will most want to use the app, they have to _manually_ disable wifi in order to use it. This is not at all useful or expected behaviour from a user’s point of view. The same thing happens with the Lothian Buses M-Ticket app — the user cannot activate the ticket that they need to get on the bus at the point that their phone has connected to the bus wifi.
A more useful implementation of captive portals, as used by most wifi providers on public transportation, is via HTTP redirect. The phone connects to the wifi, makes an HTTP request, and that request is redirected via a HTTP 302 redirect to the captive portal page. On mobile devices and modern laptops, this displays as a pop-up window when the device connects to the wireless network, with a clear “cancel” button. As such, a user who is in the middle of trying to activate an M-Ticket — that they may need to make a journey home — can just tap ‘cancel’ and immediately get their existing mobile data connection back.
no subject
Date: 2017-08-14 11:40 am (UTC)The other thing Lothian Buses gets wrong is not having a way to sign in ONCE. If my phone has a Lothian app I should be able to sign their T&C once and then just reconnect without the rigmarole...
no subject
Date: 2017-08-14 08:39 pm (UTC)