Like What You See? Now You Can Claim It!

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?



Comments
I would suggest using client variables to associate a presentation to a given client. As you said, IP addresses can change and sessions can be finnicky.
# Posted By Shane Zehnder | 1/7/09 1:03 PM
Why would you chose client vars over session vars? Just curious.
# Posted By todd sharp | 1/7/09 1:16 PM
Todd, couldn't you feed them a presentation id along with a random generated word (password if you will) for that unregistered upload and then they can claim that presentation anytime they want in the future by entering back that info you provided them. They stay anonymous until they want (even beyond the session) and can still claim the preso later.
# Posted By Chad Burke | 1/7/09 1:26 PM
Holy cow, who is that?!?! :)

Not a bad idea, let me think on it. Still, how many people are going to write all that down? I wouldn't, I know that. And if I did, I'd lose it.
# Posted By todd sharp | 1/7/09 1:36 PM
I tend to stick with client variables when trying to associate a web session to one specific user. That way if someone accidentally closes the browser and has to reopen the site, usually a new session is generated where the CFID is going to be the same.

All boils down to preference. I have had issues trying to track by session on my work app and ended up switching to client variables. Most of your users are probably more hip than mine though. ;)
# Posted By Shane Zehnder | 1/7/09 1:43 PM
@Shane: Correct me if I'm wrong, but client var is still cookie dependent on the CFID/CFTOKEN. If you look at the database you generate (because, if you're storing all this in the registry, I'm going to kick your ass) when you store client vars... you'll see that CFID/CFTOKEN is the key pair to data retrieval.
# Posted By Todd Rafferty | 1/7/09 3:19 PM
So far I like Chad's method. When you upload, present a key with a warning that they will *NOT* be able to claim that presentation without that key.

Why do people have to write everything down? People can't copy/paste that key into a notepad or something? :(
# Posted By Todd Rafferty | 1/7/09 3:20 PM
@OtherTodd--

What's wrong with the method I chose?

And, ya, I have to echo your thoughts on using registry for client vars :)
# Posted By todd sharp | 1/7/09 3:23 PM
@Todd: I think session-based storage is good, as I said just a matter of preference. My users are good at breaking things. ;)

@webRat: No registry client storage here. Wouldn't want you to come kick my arse.. heh Besides, just thinking of the word registry makes me think of Windoze... Eeeeew.
# Posted By Shane Zehnder | 1/7/09 4:29 PM

Calendar

Sun Mon Tue Wed Thu Fri Sat
   1234
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Subscribe

Enter your email address to subscribe to this blog.

Tags

actionscript ajax blogging cfsnippets coldfusion flash forms flex funny stuff javascript misc model-glue off topic personal project learn slidesix sql

Recent Comments

Chinese Birth Calendar Accuracy Test
mama to be said: ok so i will be 2 months shy of 18 when i have my baby. this calendar does not technically work for ... [More]

Fixing 'User Profile Service Failed The Logon' on Vista
Mike said: That fix worked although all i did was remove .bak and reset state to 0. User was able to log in to... [More]

Chinese Birth Calendar Accuracy Test
Melissa said: Wrong for my daughter, which it predicted to be a boy... we'll see for #2. Predicts a girl (maybe, f... [More]

Adding Auto Generated Code Downloads to BlogCFC
fweerw said: http://www.ibiblio.org/st... http://www.cambodia.ait.a...... [More]

Check Out The New SlideSix
Todd Sharp said: Thanks for the feedback Ben & Rachel! I'll keep it all in mind as I tweak things over the next ... [More]

RSS


adobe community experts

coldfusionbloggers

FullAsAGoog MXNA

Consumed By Feed-Squirrel.com