<div>On 6 July 2012 10:44, Mark Newton <span dir="ltr"><<a href="mailto:newton@atdot.dotat.org" target="_blank">newton@atdot.dotat.org</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
The issue here is applications doing things users don't expect:<br>
A self-created problem.<br>
<br>
Users don't expect that visiting <a href="http://google.com" target="_blank">google.com</a> causes their browser<br>
to deliver them a portal instead.<br></blockquote><div><br></div><div>Correct, but most of them will try visiting it on a network they've never connected to before just to see if it just works. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
By attempting to break that expectation, network operators who rely<br>
on captive portals create a rod for their own back by giving users<br>
an unexpected error message instead.<br>
<br>...snip...<br>
<br>
But if it doesn't work, or if users hate it and don't use it, or<br>
if the cost of answering the phone for their support calls destroys<br>
your profit margin, that's hardly a technology problem, is it?  It<br>
just means you got your business model wrong.<br></blockquote><div><br></div><div>I think you've hit the nail on the head here, but for a reason different to what you'd expect. The broken part of the model is that users have come to expect they should call an ISP to get signed up, wait for 1-2 weeks and possibly be required to purchase a small magic box they plug into the wall to make it all work. Y<b>et despite all that</b>, most of them will connect to a new network (cabled or wireless) and try to get access anyway.</div>

<div><br></div><div>The captive portal systems have removed this process where one company pokes another to poke another to get a connection to the point on your wall because we already deliver to all the end-points we're providing the portal on.</div>

<div><br></div><div>I personally feel the support calls on users loading HTTPS pages the first time they try to connect* are a fair trade off for being able to deliver most connections without a customer ever having to put a phone to their ear. But at the end of the day that's a choice we've made and doesn't mean it's going to be how everyone feels, some hotspots might even decide to drop port 443 traffic from being redirected just so they don't have to explain it.</div>

<div><br></div><div>*We offer either captive portal (HTTPS page) or PPPoE authentication, the user decides what they want to use.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
Think about how payphones work.  Users don't dial their number<br>
and then get randomly connected to some unexpected third party;<br>
they'd go apeshit if that happened!  They know they're going to<br>
need to do "something" to make the call work before they even<br>
start. Can you leverage that model and those expectations to<br>
make what you're doing work?<br></blockquote><div><br></div><div>This is just it, that's all well and good when you're connecting up at a new house, but forcing this on come-and-go hotspot users, hotel guests, student accommodation, mining camps etc would only serve to balloon out signup times and confuse users who don't want to make a long term commitment, they just want to plug and play within the first 5 minutes. If a legitimate https error is the by-product of this process then fielding those very few calls is just part of the cost of doing your business this way; but if Skeeve or anyone else can find a solution that's relatively simple and works, their whole signup process is seamless and already 10 times more user friendly than anything I can get via a retail provider without having an existing internet connection with which to sign up through.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
  - mark<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Full disclosure: I work for the largest provider of captive portal services in Australia (to the best of my knowledge!) servicing a variety of sites and signup methods. </div>

<div>My views are my own and do not necessarily reflect the views of the company etc etc.</div><div><br></div><div>- Andrew </div></div><br>