A common problem: users start interacting with your site on mobile
(they put something in a cart, they fill in part of a form, they star a couple of items) but then they want to continue on desktop.
Traditionally, this is being solved in 4 ways:
— Users have to do everything again on desktop. This is about 90% of the sites I know.
— Users need to register an account at the site, then sign in with the same account on desktop. Registering an account is something you don't want to do on mobile, though.
— Users can login through an auth provider like Facebook or Google. Much better than above, but still a lot to ask for if it's the first visit to a site.
— Users can fill in their email address and the site will send them a summary and a link. This is the least demanding option so far, but it still requires users to share their email with a site, and it's prone to get caught in the Spam folder and to get abused.
Thanks to +Rick Farrell
, I was introduced to an idea of yet another alternative. I don't think it's being used anywhere, it's really just an idea, so I made a little demo here:http://filiph.net/mailto/
The main idea is to use the mailto
URL scheme. Links with this scheme open the default email client and (normally) pre-populate the To field. But it also allows to pre-populate the email's Subject, Body, and other fields.
An example: mailto:firstname.lastname@example.org?subject=Hey+there
The other part of the puzzle is that you can actually leave the address (To field) blank.
So you can have a button on your site that brings up the user's default email client, populates the message with a fitting subject and a body (including a link back to the site, ideally with a way to restore their session), but leaving the address to them. They can send it to themselves, or to anyone they please. Inputting the address will be less painful (most email clients do autocomplete) and the email will not end up in Spam.
The demo at http://filiph.net/mailto/
takes the most basic Dart demo web app ("Name Reverser") and adds this functionality to it. In this case, the state is fully encoded (and encrypted, for good measure) in the URL. This can work for a number of apps. Another obvious way would be to save the state on the server and only send the id of the saved state.
Implementation is easy. It's basically just the code you see below, plus listening to events.
This is not
meant as a substitute for the 4 options above. It's just another option, for the paranoid/lazy.