Registration Through Site Engagement

I think that lowering the barrier to user registration is important for sites that are striving to build a social community to look at. I been mulling over how the the registration process can be streamlined to its essential components while still capturing necessary end user data and keeping a reasonable barrier up against spammer registrations. Some of my first thoughts about this are captured in this post.

I loath to admit it but I think OAuth solutions like Facebook and Twitter really serve a site well for simplifying new user registration. While there are privacy concerns around a third party authentication approach, the reality is that Facebook et al. streamline account creation in a positive way for end users- the UI is consistent, management is centralized, and there is sense of brand continuity. Though I object to letting Facebook authenticate my sessions it's clear that most people don't or perhaps don't understand the ramifications. OpenID is another good remote authentication system option though the adoption rate has never been good and it pains me that there isn't an OpenID provider in core- though there is one in contrib.

With or without third party authentication systems I think Drupal's standard user registration system needs simplification. As I noted before, Login Tobbogan is a significant improvement over stock Drupal as it can reduce the number of steps it takes to get a new user participating on the site- the data required is a user name, email address, and password, and the new user has an account with a non-authenticated role- until they confirm their account with an email response.

There are two items here that I want to explore further:

  • how to further reduce the amount of data collected
  • how to give the appearance that a user can interact with site features regardless if they are a registered user

On this first point, I'm assuming that providing data is a barrier to user participation- the more you require from an end user the less likely they are to provide it and thus participate. On the second, I'm assuming that users will be more willing to enter text in a comment box rather than click a "login to comment" link. I recognize that both of these are significant assumptions. I should also note that this is not a "one-size-fits-all" argument- there are many instances where reducing barriers to participation is not valuable or useful goal for a site.

Drupal's standard behavior for commenting is to provide information to the end user to let them know if they can or can't- and if they can't that they should register. So in this case, in order to participate, a user has to have the desire, recognize that to do so they need to register, then register, then actually comment. An alternate way to do this would be to let the user comment and then prompt them for their information after they've finished- this would let them participate and hopefully make them feel excited enough that they'd want to. Though this too risks losing a user after they've actually participated- arguably worse.

I'm interested in identifying features that anonymous users can "see" but can't engage without user accounts. Instead of focusing on the negative aspect- login to do something- allow the engagement activity itself to trigger the registration. So practically what this means is get rid of "Login or register to post comments" and show the comment form. Drupal allows for comment moderation quite simply so let it do so. But this isn't actually that much of a step forward. How can we translate the actual act of commenting to constitute grounds for registration?

I took the easy way out and simply am launching a modal registration window when you click on the comment form. I assume that if you click on the comment box you want to comment and that if the amount of data collected is reduced the barrier to registration is low- and in this case, it's simply an email address and a Captcha.

Comment registration

When an anonymous user clicks on the comment form a registration modal is launched.

The modal registration

The modal window that contains the registration form.

I'm still using a Captcha on the registration as this is an experiment on my part. I don't think it's actually needed- I'm not seeing any spam registrations, though I am getting comments from anonymous users (spammers) in my moderation queue because the modal window doesn't actually block a user from submitting the comment, it just tries to get you to register. Login Toboggan will actually prune these out after a specified amount of time as well if it is configured to.

Obviously the modal is lacking some context- why are you being asked to provide your email? What is the site going to do with it? It would also be nice to do some clever things with ajax and iframes to handle navigation between the user forms and the content page more gracefully.

Further, showing the modal on click is breaking a different kind of expectation of how page elements work. Perhaps showing a email text box when the user tries to submit form would be clearer, though I like the drama of the modal telling the user that they are going to become an official member of the site.

Commenting is just one place where this can be done- rating, flagging, subscribing, and any other number of types of activities could have similar behavior for an anonymous user. Some of these may require more tweaking than comments as they don't really have a "moderation" state but I don't think that is a blocker for showing people that they can participate on a site regardless of their account status.

Now With More Register

In the interest of creating a faster registration process based off of this post, here's some prototyped code that changes the user/register form into an email form and allows for immediate user creation. Actually this is just used right on top of Login Toboggan and assumes that the setting for register immediately is on. This is a quick (and hopefully simply and somewhat "secure") way to implement this functionality. First alter the registration form to use the users email address.


Once Again, Configuration Matters- or Don't Assume APC is Doing You Favors

APC Status

A classic unhealthy cache- high miss rate and high fragmentation.

When people talk about performance and Drupal it is rare to not hear APC get mentioned. It is probably the must have performance solution for Drupal. Which makes sense- it's easy to install, effectively reduces the time it takes to load all of the .module, .php, and .inc files, and is usually enable and forget. Basically an easy win.

And yet as I'm about to point out, every article you will ever read about performance should tell you that you need to analyze what you're doing before you assume you've made things better.

KCachegrind Redux


KCachegrind- or in this case QCachegrind- has a great visulaization of the call graph.

There are a number of tools that are quite wonderful for investigating PHP's call stack. I am rather fond of KCachegrind (which I suppose makes me a bit nostaglic). Having regretfully followed Apple's upgrade path I have found myself without KCachegrind. The instructions that I wrote previously for installing KCachegrind on OSX no longer work because Fink's KDE packages are unfortunately not ready for 10.7+.

Happily there is a fairly painless way to work around this. This post is where I started from. Basically it eshews using KDE and instead just installs the QT libraries to run KCachegrind. This makes the process much less time consuming and seemingly less prone to dependency issues. I had to change a few things so I've repeated the steps here, however credit goes to Paul Kehrer for the direction.

  • Download QT and install it. I used 5.0 beta version and seems to work fine.
  • Install Graphviz.  I used fink -b install graphviz
  • Download KCachegrind from:
  • Unpack KCachegrind and navigate into the directory and into qcachegrind. I used qmake-4.8 -spec macx-g++; make
  • open should open up the application. You can move it to your Applications directory if you want.
  • I modified my xdebug settings in php.ini to use: xdebug.profiler_output_name = callgrind.%R.%t This lets KCachegrind open the grind files without having to select the "All Files (*)" option. There is a patch metioned here: that lets KCachegrind open any file type though I think this has actually been applied to current releases. Plus, if you change the output file name I think this is somewhat moot.