A user sent in an interesting suggestion for SlideSix the other day. He liked that we offer the ability to upload a presentation without registering, but he thought it would be cool to give trial users the opportunity to 'claim' that presentation once they had registered.

I liked the idea a lot, and quite frankly kicked myself a bit for not thinking of it. So I started thinking of the possible ways of implementing the feature and the pros and cons.

Implementation Option #1 (The 'Yucky' (TM) Option):

Architect the feature in such a way that users can claim their upload at any time in the future.

In order to do this there needs to be some sort of way to identify or track who uploaded a presentation. The first two things that came to mind were:

• IP Address
• Email Address

If I were to associate the users IP address with the upload I could easily retrieve the uploaded presentations at any point in the future and display them to the user on subsequent visits. So this solution is attractive mainly because it is 'semi-permanent' and it does not require the user to 'knowingly' provide any personal information. However, there are a number of things that made me uncomfortable about this solution. For one, IP addresses are not permanent. Secondly, people tend to freak out when you store or utilize their IP. Third, if users uploaded a trial from a public location there could be all kinds of problems with users claiming presentations that did not truly belong to them. To put it in technical terms, it just seemed yucky.

A better option would be to give users the option to enter their email address. I could associate the email address with the trial presentation and then send an email to the user with a link to claim the presentation. The advantage to this method is that the user must knowingly and willingly provide their email address while uploading the presentation so there is no concern over tracking personally identifiable information without the users permission. The downside is that this sort of alienates the whole appeal of being able to upload a presentation without providing any personal information. Sure, it sounds a bit silly that someone would upload a presentation that may potentially already contain personal information but would not want to provide their email address. But the point is that the presentation does not have to contain personal information. I also wanted to keep the process simple. One step - upload a presentation file.

Another downside to both of these methods is that they 'let the user off the hook'. I'm giving them an opportunity to leave my site without registering. In the case of the email address, were they willing to provide it, I'd have the ability to follow up with them. But the odds of them being anything but annoyed with a follow up email are slim.

Implementation Option #2 (The 'Chosen' Option):

The options above have their advantages, but the disadvantages far outweighed them in my opinion. The last thing I want to do is alienate users or make them distrust me. So what I ended up implementing was a simple session based tracking mechanism. Here's basically how it works:

• User uploads trial presentation
• (Behind the curtains) we import and convert, storing the presntationID in a session variable
• User is automatically redirected to presentation
• A friendly message is displayed above the presentation for the duration of the session stating 'Hey, if you like what you see you can register now and claim this presentation'
• When registering (within the same session) we present a link to the trial presentation and gently ask 'would you like to claim the presentation'

I like this implementation for many reasons. First, the user does not have to provide anything but a file to upload and we do not track any user sensitive information. Next, the user is given the option to immediately register. There is no wasted opportunity and hope that the user comes back to visit again. There are many options and my competition would love to give users an option to sign up with themselves rather then me.

So that's about it. A simple, clean solution to an interesting dillema. How would you have implemented this solution?