In the same way I dismissed the “here is your data / download it” and “install smart client that will backup your data nicely” you dismissed emails with opt-in. I see now things might not be so smooth as I thought.

But, I still have one option, I will try this and see what users of real app say… will they care about it at all, will it cause more confusion than it will be worth, etc.. experimenting is always fun.

Alex:
The first part of your scentence is what I was aiming for. The point of this is NOT that the service doesn’t need to take care of backups any more. It’s more that the user also has the data.

Your 3 points are good, I will try some combination of them and see how it goes. For all of you that mention API , I think API access to your data is very good and more basic feature than the “emails for backup” .. it’s not only usable for backup but also in integration of your app with the outside world.

Yes your idea is the middle ground. It gives the data and options to users that want them. This is a good and not problematic solution I think.

My proposal was a bit more extreme in trying to make sure users won’t loose their data (even the ones that won’t care or know how to set up ther backuping. ), but by the same reasons it’s also more problematic (which can be seen by your comments).

CaptainOBackup:

Yes, I know decent sites should have good old centralized backup solution. But as you can see not all sites are as decent when it comes to real problems, or their backuped systems fail and user is simply notified that their data is “no more”.

This idea with emails doesn’t mean that you don’t need to have backups. It means that the each user ALSO HAS the HIS data on his disc.

I have some client that I made portal for, the hosting provides daily backup, but every now and then she asks me to manually download backup data of her mysql database and send it to her. When I send it to her she is relieved because she is holding the data now, she can bake it on a CD or whatever, it’s there..

Ted Z:
This is good third option, a little more progressive than “you can download your data”. It would be especially handy or the only option if there was in size that would make problems to regular emails also.

Chetan:
That was my mistake,… we have no plain passwords stored on server yes. I also haven’t concretely looked at how exactly we would encrypt data. Does anyone see any problems in hashed (& salted) passwords being the key for encryption?

Links were proposed to me by Zemanta plugin, I agree I wouldn’t have to click the password keyword to make a link to wikipedia ,.. My fault

About “why email” vs the other solutions..
I agree email is not the ideal medium for this. But it’s sadly sort of the only one with such properties.

A) On one end you have option where you offer users links to download their data. Nice, totally unobtrusive.. BUT.. I don’t even back-up my important files on local disc until it’s too late. Do you think people would “back-down” data from their bookamrking services on regular basis?
B) On the other end you have a smart client that silently makes backups for them in the background, and also does conversion between formats, etc… So user just says at any point. I want my data in CSV and get’s it. BUT do you think anyone would install a native application to use a online browser based service. That “no download or install” is the key accessibility point why web-services are so popular.

Android:

I agree with you a lot. And I also agree email used like this has concrete flaws, as I tried to explain above I proposed to use it in this because I see no other real option. Google “exporting” to natural formats/protocols like you mention pop3 / iCal is really good approach. I wasn’t even aware of it.

I agree that for tech savy people good api-s that allow you to make your own little solutions are very good. But this only covers smaller amount of internet users. Otherwise I also fully agree with your reasons

2) Allow the email thing *as an option*, but make it opt-in, and not the only method for pulling their data out of your webservice. As mentioned above, email for file storage is weaksauce.

2) Automatic offsite backup. Amazon S3, some webserver farm in a neighboring state/country, something like that. If your server crashes, it might be their fault they didn’t use the backup options, but it’s still your fault that their mistake cost them all that data.

Also, opt-in and regular exports are extra work, which people just won’t do. Even if it’s a single click away, it’s still one click too many. So you have to find a way to either force your users to make backups (yuck), notify your users to make backups (nicer, but won’t do, and it’s still annoying), or provide a good backup yourself, possibly off-site. The third solution is the only good solution for cases like these, and of course the hardest to provide.

I quite like Ted’s idea; you back it up somewhere online, and only provide a link to that backup. This approach has a few problems (privacy of the backup, safety of that data, spamming with backup notifications), but it’s a very good start.

Does it mean you will be storing users’ passwords in plain-text? BAD bad idea…

Also, what’s up with all the links to Wikipedia? Seriously, how many internet users need to look up the term ‘Password’?

If you are taking proper backup of user data on your site, you don’t need to burden users with “backing up” their own data, which in essence – sending their data email – would be.

Also, sending their data zipped via email, could also lead into obscure privacy issues.