Generating content from registration

Posted: November 7th, 2009 | Author: monolith | Filed under: Ruby on Rails | Tags: commune2, Rails, registration, RoR, Ruby on Rails | 1 Comment »

There is a catch 22 problem with getting content for commune2.  And this really is a problem because the content is mostly user submitted posts, and (just a guess here but) people don’t want to post unless they see other posts out there already.  This must be a common problem, but I haven’t really seen a solution like the below anywhere else… although it is really simple.  That’s not to say there aren’t websites with something like this… I just haven’t seen any.

The solution: the registration process should include posting an idea (posting content).  This should accomplish the following:

• Content will increase (at minimum) proportionally with the number of users.
• It gets the person more committed to the website because they contributed some content.
• It helps the person get comfortable with posting in the future.

There are also some drawbacks to this idea, including: the registration process is longer and more difficult because it requires more thinking!  We need to make this easier.  How to do this?  I decided to offer a few brainteaser questions to get people thinking.  However, since I don’t want everyone looking at the same brainteaser question, I added some randomization.

OK, now that you know what we’re trying to achieve here, let’s get to the technical parts…

The Code!

The code is actually hosted on Github.  Since this is not really a tutorial, I will cover only some of the more interesting pieces.  Keep in mind that there were some other (mostly cosmetic) minor changes in this release.  If you see something curious that I do not cover below, just ask me.  Also, keep in mind that this is not intended to show any best practices – this is pre refactoring – so there is probably a lot left in here that could be improved.

You can see the code changes here.

The “fun” stuff

Commune2, for better or worse, has a scorecard object that’s created for most objects.  Meaning, a user has a scorecard, an idea has a scorecard, a project has a scorecard, etc.  This scorecard is meant to keep track of some counts, so that we wouldn’t have to recount the number of ideas a person has, or number of projects launched off of an idea, or number of group members on a project, etc.  This complicates our idea post during registration because the new user does not have a scorecard yet… the scorecard is generated by an observer AFTER the creation of the user.  So how does one post any idea – which should increase the idea count on the user’s scorecard – while the scorecard does not yet exist.  Well… we don’t.  We WILL create the user first, and the scorecard WILL be created, and then we will create the idea.  But, we need to do this seemlessly from the user’s perspective.  How do we do this?  It’s not really a problem if you think about it.  We can save the user record, and then save the idea as two different steps.  BUT – we need to make sure everything is valid first!

This is the code (starts on line 51 of the users_controller file):

unless @idea.valid?
  if @idea.errors[:title]
    @user.errors.add_to_base("Idea title " + @idea.errors[:title])
  end

  if @idea.errors[:description]
    @user.errors.add_to_base("Idea description " + @idea.errors[:description])
  end
end

Basically, we validate the idea and add any errors to the user record.  Before saving the user record, we check if there are any errors.  Best solution?  Not sure, but given the situation, it works.

The next problem: how do we prevent displaying these ideas to the public until the user activates the account?  We care about this mainly because the latest ideas go to the top, and it will just not look good if all or most of the top ideas are posted by anonymous users.  I decided that, at least for now, the easiest thing to do would be to add a “recent” method to the Idea object.  This method would return recent ideas only for activated users.

This is the code (starts on line 94 of the idea file):

def self.recent(how_many = 3) # default is 3
  # this is a class method
  # usage => Idea.recent(5)

  find :all,  :limit => how_many.to_i, :include => :user,
    :conditions => 'ideas.active = true and users.activation_code is Null',
    :order => "ideas.created_at DESC"
end

Simple.

A few more interesting bits to go…

At least for now, I wanted to allow only admin level users access to any actual icebreaker pages (to view the all, edit, create, etc).  So, some code in the icebreakers_controller file takes care of that:

before_filter :admin_only

...

def admin_only
  unless current_user.admin?
    flash[:error] = "Access denied"
    redirect_to root_path
  end
end

And to be extra super cautious, a custom validation in the icebreaker (model) file:

validate :user_must_be_admin

...

def user_must_be_admin
   errors.add_to_base("You don't have administrator rights") unless user.admin?
end

Finally, let’s show some of these icebreakers, randomly, during registration (this is from the new user view file):

<% Icebreaker.random(3).each do | icebreaker | %>
  <li><%=h icebreaker.question %></li>
<% end %>

Now, there was a bunch of other code (and not enough test cases) but that you can see for yourself on Github.   Of course, if you have any specific questions on any of the code, let me know!

And that concludes this post.

---