Faster Registration?

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.

iOS and Fixed Backgrounds

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.

Considering Drupal's Archiver Interface

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.