Registration codes

[Cifram]

Every account should have a set of codes generated for it, which can be given to others, say via printed cards we hand out at the con. Each code will be good for one registration, and will link the newly registered user back to the person who referred them.

[OhligerJ]

Here's the architecture I have in mind:

Database: New table, 4 columns (5 if we go with the design pattern of including an id column as primary key), 2 foreign keys. Suggested table name: user_registration_codes

Columns: inviter: this contains the user id of the person who has already attended ShadowCon. Foreign key to user.id. Not Null. _regcode: random alphanumeric string. Recommend it be a standard length, something short enough to not frustrate humans with a real code, but long enough to make successful guessing unlikely. Not Null. invitee: id of person being invited. Foreign key to user.id. Nullable. _regdate: date of invitee registering. Nullable.

User experience: Invitee receives business card or paper with registration URL and a registration code. They go to URL, fill in registration information plus the code. They receive feedback on success/failure.

Inviter has list of available codes visible only to them on their profile (or however else we want to show them how many unused codes they have). They write these down on business cards or pieces of paper, and hand them to an invitee. Later: also list people they've invited who have registered

Framework: We'd need to generate the strings, insert them into the db. Rails has easy ways of doing this, don't know if Django does. Is there a limit to the number of codes per person? Once invitee submits registration form, we check the code against this table. If the code exists, we create the new user in the users table and add their user_id into this table and insert current_date in the date column.

Were there any other requirements around this?

[Cifram]

This all looks pretty reasonable to me. I was imagining having some kind of system where we could extract the user ID from the code, but the more I think about this, the more I think that's not useful. Just generating random codes and putting them in a table should be fine.

Key element of the user experience that may need some more thought: If somebody gives out a code, there is an indeterminate amount of time before that code gets used, and a chance it'll never be used at all. So keeping track of which codes have been given out is potentially a bit hairy. So I'm not sure about the value of this code screen as proposed.

What I might want to do instead is have a Referrals screen. We have two major types of referrals proposed: cards and the e-mail form. (The e-mail form was something I proposed at this meeting. Basically, we provide a referral form where they enter an e-mail address and a short message, and it sends an e-mail to that person with a link back to the website and a referral code.) So the Referrals screen has the e-mail form, and a list of all the cards they've been given, and all the e-mail referrals they've sent, with each one noting both the status of the referral and, if they've registered, the account name now associated with it. No need to list the actual codes. It would look something like this:

Shadowcon 6 Cards

Card	Status	Account
1	Registered, Not Validated	George
2	Valid	Sally
3	Unredeemed
4	Unredeemed

Shadowcon 7 Cards

Card	Status	Account
1	Unredeemed
2	Valid	Larry
3	Unredeemed
4	Unredeemed

Email Invites

Email	Status	Account
bob@bob.com	Registered, Not Validated	Robert
hamburger@food.com	Valid	Mary
joe@gmail.com	Unredeemed

Note that the statuses listed also assume the validation system. We don't need the e-mail form or the validation system to all be in place for the card codes to work. Just want to think ahead to how all this will eventually integrate.

[OhligerJ]

I'm satisfied with letting the participants have complete control of the codes once we hand them out. If the person they hand their code to doesn't sign up, they get to decide how long until they give that code to someone else.

The thing I don't like about the referral form is that either it puts more work on us to make sure the user has a limited number of invites (if that's what we want to do), or we let the user refer as many people as they want. The beauty of the code system is that we have control of how many invites can go out at once, and that control involves a simple random generation and assignment on insertion into the DB.

[Cifram]

My concern is over the user experience. How do I keep track of which of these codes I've given out? The website can't reasonable contain any notes until the code is actually redeemed, which may take a while or not happen at all. In that time, I need to keep track of which code I've given to who, and each person will need to use their own system to do so, and some people are likely going to accidentally give the same code to multiple people.

Discussion of e-mail invite limits is probably beyond the scope of this issue. I included them here because they'd tack onto the same system, but they're not really the point.

[OhligerJ]

I do want them to be able to see, in their profile, which unclaimed codes are attached to their account. If they only have a couple unclaimed codes attached at a time, that should be easy to keep track of. If we give out codes in chunks of 10, or even 5 at a time, then yeah, we might need to think some more.

Going back to an earlier point of yours: we're three dudes with full-time jobs and full lives. We don't have much time to code up everything. So I would propose that we find the simplest solution that covers the most ground.

[Cifram]

So if we want to keep this as simple as possible, we just skip the referral page entirely. Whether we show the actual codes on it or not doesn't significantly change the complexity.

I think the disconnect here may be this point: The cards are being printed. If we have the ability to generate codes ready in time, we (as in the staff in general, not just the 3 of us) will write the the codes on the cards BEFORE handing them to the attendees. We will at no point expect the attendees to transcribe the codes off the website themselves. That's honestly asking too much of them, and would likely serve as a significant chilling factor on recruitment, which is the opposite of what we want.

[a-lost-shadow]

Here are some things that I think could make the user experience easier: Short Term

• Put a QR code on them that will take them to a login page with the referral code. This would be a bit more work upfront, but not too much on the website end
• Keep the cards to something like 7 alpha-numeric digits (excluding common confusion characters like IL0O)

Long Term

• Automated tracking of when referrals have been used --- Check box on whether a referral has been handed out --- Notes field in case a user wants to remind themselves of who/when it was handed out
• Ability for users to re-print a card's info in case the card is lost
• Ability to send an e-mail with a referral link --- Automatically fills in the checkbox and notes field above
• Ability for staff to see what referral codes have been redeemed

[Cifram]

I'm a little skeptical of the QR Code thing. As a tech savvy Silicon Valley programmer, I don't think I've ever scanned a QR code that encoded a URL, and don't know offhand where I'd go in my phone to do so. I'm sure I could figure it out, but I think just providing a URL and a code directly is going to be a lot easier for most people to understand.

Mind you, we won't be able to do QR codes for the first run anyway, because this year we aren't getting the fancier custom printing that allows us to individually customize each card. We're just getting a run of identical business cards with a blank space, and writing the codes with a pen.

That said, I agree on keeping the code fairly short. I was thinking 8 digit alphanumeric, because I'm a programmer and I like numbers in the doubling ratio. :-)

The tracking of when a code has been used, and e-mail referral link, are already part of the long-term proposal. The notes associated with a referral are not a bad idea, but I'm not sure it's necessary UNLESS we explicitly issue codes on the website, which I'm not convinced is useful. If you're already on the website, odds are the e-mail referral form is what you need.

Staff seeing referral code redemptions makes sense, but I would have assumed we'd just kind of get that for free from the Django admin interface... But thinking about it, it might be good to make a special screen outside the admin interface for that, because the info wouldn't be organized in a very readable format.