Disable mobile widget for launch?

[noahlevenson]

During November's murder board, the group astutely observed that mobile users have some special considerations with respect to bandwidth. Many (most?) mobile users are on capped data plans, and so they must be extra careful not to proxy more traffic than they can afford.

Creating a sane and safe experience for mobile users probably requires a combination of technical features (bandwidth throttling, detecting connection type) and UX features (creating a welcome flow which communicates the situation, provide mobile users with special throttling defaults, etc).

We don't have time to solve this stuff before launch, so we should probably just disable the widget on mobile devices with a "coming soon" message.

This issue touches at least two other issues:

https://github.com/getlantern/product/issues/40

https://github.com/getlantern/engineering/issues/78

[soltzen]

@noahlevenson We can just detect the platform from the user agent and gate it. That should be easily-circumvented but it's enough for your average user. Works?

I can introduce that in the JS code. Looping in @woodybury

As for gating Flashlight clients (i.e., what we call "desktop" users), we can do that through features, but that's beyond the scope of this ticket.

[noahlevenson]

@soltzen Makes sense to me! The only follow-on question I can think of:

Someone actually needs to design the "coming soon" page, right? Seems like it's a good opportunity to capture interested users. If someone is trying to volunteer as a proxy on their mobile phone, maybe they'd be happy to submit their email address in a form to be notified when the mobile version is available? Dunno. (cc: @Derekf5)

@soltzen Will it be straightforward to disable the user-agent gate? Are we gonna parameterize it as an env variable?

[woodybury]

@noahlevenson @soltzen

From our murder board the concern here is if an uncensored user gets mad if broflake uses all their mobile data correct? Maybe before we go down this route of a hard blockage on mobile, we should first determine if this is an issue at all. I.E. answer this question: #41 my gut tells me it's not going to work backgrounded, or possibly even when a mobile tab is not active depending on the mobile browser? If that's the case then using all your mobile data may be a non-issue if the lifespan of a session is very short on mobile.

Given the above and that @Derekf5 already has mobile designs (some of which are implemented is ts) I am wondering if it's not worth it build a coming soon UI. Maybe just toast a data usage warning when a user actually 1. tuns it on, 2. connection is successful, and 3. os is android or iOS.

I'm also concerned a "coming soon" ui may be confusing (unwanted by host) when embedded on a partner's site. Probably better to just hide it entirely in that case.

FWIW looks like snowflake "works" on mobile and there's no warning about data usage.

[noahlevenson]

@woodybury All good points, I definitely defer to you and @Derekf5 on this stuff.

[woodybury]

when I had a data-capped plan I was very careful about what I used network for and would neeeever toggle a switch to share my internet if off of wifi haha. imo the opt in + common sense will probably address a lot of this issue so long as it doesn't work backgrounded (meaning user can't opt in on wifi, background and forget and accidentally use all their data after leaving wifi)

[noahlevenson]

@woodybury I tend to agree with your thinking. Although, just to air out the counterargument: Depending on how we configure client concurrency, it may or may not be possible to really push big megabytes through this thing very rapidly.

A curious kid who read about us on a blog could fire up the mobile widget on his bus ride home from school and decide to watch the mesmerizing UI for 20 minutes, blowing through a GB or two...

[Derekf5]

I agree with what @woodybury has said here. I think we can either launch with it on mobile if it doesn't work as a background process or hide it entirely for launch if it does. Making a note to discuss this on the call tm.