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.
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.
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.
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.
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: http://kcachegrind.sourceforge.net/html/Download.html
- Unpack KCachegrind and navigate into the directory and into qcachegrind. I used qmake-4.8 -spec macx-g++; make
- open qcachegrind.app 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: https://gist.github.com/1029580 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.
How do you reduce the barrier to becoming an authenticated user in Drupal? There are a few goto solutions: Email Regiatration, Login Toboggan, captcha on the user registration form, etc. These are effective and well tested solutions that allow new users to register and reduce the threat of bot registrations. Single signons with Facebook or Twitter are also viable options and arguably reduce the barrier with the lowest risk. Unfortunately they require third party account which doesn't meet the need for a user who wants an account only on your site.
In my mind Login Toboggan offers an interesting solution to this issue by creating a specific role for a user that can be created and logged in but not given full rights until they confirm their registration. Where it doesn't lower the barrier is that it still requires creating a username and password during account creation.
The thought experiment here is how much of the registration form can we strip away to get a user created without out overly risking bot registrations. Since email addresses are for the most part unique, is it possible to use only an email address to create an account without a username or password? The following is a flow chart that this kind of registration might use with a nod to Email Registration module. Proto code forthcoming.
I sized the background images for this blog based on view port size. There are sized versions for each breakpoint in order to reduce page load size- the 480x320 size saves more than 80k for the intial page load compared to the desktop version. I'm building the page this way with the smallest version of the image as the default and then selecting what is an "appropriate" size based on media queries. Each viewport size is a crop from the same background image so even when resizing the browser you aren't thrown too far off from the orginal perspective of the image. I used CSS to fix these backgrounds- this prevents the background image from scrolling which means that the image can be cropped to standard viewport sizes keeping file size lower.
One of the annoying things about using Tar is that unless you remember -C the files that you are archiving include their full path. This means that when you go to extract the files you get the full directory tree. Though there are clearly good reasons for this, when you're just trying to put together a few files to send out this is probably not behavior that you want.
Poking at Drupal's ArchiverInterface it I ran into this problem. I want to be able to build arbitrary archives of single files at the root of the archive that can be used elsewhere without having to munge file paths at a later date. Using both types of archiving (Tar and Zip) that are implemented in core the files in my archives have their full paths. Looking at the code this seems to be borne out.