Fewer Rails flash messages

Clearance 0.12.0 was released last week with a continued focus on user and developer experience.

For users: flashes

We removed redundant flash messages like ‘Signed in.’, ‘Signed out.’, and ‘You are now signed up.’ because it was visually obvious when you completed those actions.

We previously used flashes more to follow typical Rails convention (in controllers, successes get a flash and a redirect and failures get error messages and a render template) than providing informational value to the user.

For users: redirects

When a user reset their password, they used to get redirected to the sign in page with a flash message that said ‘You will receive an email within the next few minutes. It contains instructions for changing your password.’

We changed that to render a create.html.erb template with the same text because the sign in form is not what you want to see when you don’t know your password. We also wanted to make it clear that you have to leave the app to continue.

These changes became more obvious as we started to use sexy CSS3 flashes, which displays the flash for a few seconds, then hides itself without breaking a layout.

For developers: Rails version support via Appraisal

Clearance now works with Rails 3.0.x, 3.1.x, and 3.2.x. We use Appraisal to test against these versions of Rails:

['3.0.20', '3.1.11', '3.2.12'].each do |rails_version|
  appraise "#{rails_version}" do
    gem 'rails', rails_version
  end
end

For developers: no password necessary

We simplified the Cucumber features so developers don’t have to specify a password.

Previously:

Given I am signed up as "email@example.com/password"
When I sign in as "email@example.com/password"

Now:

Given I am signed up as "email@example.com"
When I sign in as "email@example.com"

We defaulted the factories so they always create users with password of “password”.

For developers: RSpec-compatible matcher

There’s a deny_access matcher. Since the earliest versions of Clearance, there was an “Shoulda macro”, which has fallen out of favor in place of matchers. This matcher only depends on Ruby and “should” work with any test framework like RSpec or Test::Unit.

Written by Dan Croak.

Email and password confirmation bias

I don’t believe email confirmation or password confirmation are desirable in web apps for early-stage startups.

Clearance

We wrote and maintain a user authentication and authorization Rails engine called Clearance. It serves a narrow focus for users to sign up, sign in, sign out, and reset their password, all using their email address and a password of their choice.

Clearance is almost 3 years old but we still use it on almost all of our projects. Each new project is an opportunity to re-evaluate what’s good and what sucks about Clearance.

User experience

Early on, our goal was mostly a great experience for developers, seen in things like:

• Generated Cucumber features
• Shoulda test helpers
• Consistent sign_{up,in,out} naming

Lately, our goal is a great experience for users, seen in things like:

• No email confirmation
• No password confirmation
• No 403 Forbidden status code (while technically correct, Chrome and other browsers display a scary screen for 403s)
• HTML5 email fields (so iPhone users and others get the @ sign on their keyboard)
• Lowercasing all emails (so iPhone users whose keyboard defaults the first letter to uppercase can still sign in without confusion)

See the CHANGELOG for more. The most unusual decisions were the confirmation decisions.

No email confirmation

When you sign up, you’re interacting with the product for the first time. Maybe you’ve heard good things from friends and have skimmed the landing page. Now, you want to try it. Your purpose is to get your hands on it.

So, you enter your email and password, then press “sign up”. If you’re presented with a screen like “please check your email to confirm your account”, you’re kind of bummed.

Maybe you have GMail open in another tab or maybe you’re an ⌘+Tab master and you flick over to Mail.app real quick, see the confirmation email, open it, click the confirmation link, which opens a new tab in your browser, signing you in and presenting you with a screen like “thanks for confirming your account”.

You just took about five actions, made about three decisions, and this is if you’re very savvy and already have your email client open. That, to me, is a burden. Why would you want to get your relationship started with a potential customer by burdening them?

We have numbers that show you lose customers this way. In one example, we have a consumer app with 9,204 email sign ups, but only 4,607 confirmations.

That’s a 50% conversion rate between a user declaring their intent to try the product and actually trying it.

By removing the email confirmation step, our conversion rate goes to 100%. Meanwhile, the user has only had to enter two fields, press “enter” or a “sign up” button, and they’re immediately signed in and using the product.

But what if someone mistypes their email address?

We think what we’ve provided now is a good user experience but you could argue that making sure the app can easily recover when someone mistypes their email address is also providing a good user experience.

For the moment, I’m trying to not let edge cases dictate how the majority of users interact with the library.

But what if spam becomes a problem?

It’s not a problem yet. As an early-stage startup, your problem is attracting, converting, and retaining users. Focus on that problem first, and deal with spam later.

No password confirmation

Have you ever enjoyed typing your password twice when you signed up for a product? The answer for most people is “no”, and that should drive this decision.

But what if someone mistypes their password?

By default, Clearance signs users in for a year. How often will people need to use their password? It depends on your app, but likely very rarely.

There’s also a password reset, which incidentally does rely on email confirmation. In this case, I hope the extra steps evoke more of a feeling of “that makes sense, they’re securing my account for me, someone who’s invested time into their product”.

User experience-driven open source

We’ll continue to test how people feel about the experience in each real product where we use Clearance. If my hypothesis that people feel good about the email confirmation on password reset turns out to be incorrect, I’ll experiment with the default copy in the flash messages and email body to see if we can move the needle on user’s feelings that way before changing the feature.

I’m excited about these user experience-driven changes to our open source library and I hope you’ll put them to the test.

If you’re already using an old version of Clearance, please read the upgrade instructions. Please also follow Clearance on Github.

Happy coding.

Always remember me

Clearance now uses only cookies with a long expiration as its default. The effect is always remembering the user unless they ask to be signed out.

“I’ll never let go, Jack! I’ll never let go!”

A better “remember” default

A couple of weeks ago, I asked how Clearance should handle “remember me”

PJ Hyett’s argument won the day:

Assuming people using shared computers can’t remember to log out is insulting at best and annoying to everyone else that has exclusive access. Cookies with long expirations should always be the default.

Clearance, as of today’s 0.8.2 release, works exactly this way.

Cleaner under the hood

Fewer conditionals. No special cases. Just do one thing well.

       def current_user
-        @_current_user ||= (user_from_cookie || user_from_session)
+        @_current_user ||= user_from_cookie
       end

       def user_from_cookie
         if token = cookies[:remember_token]
-          return nil  unless user = ::User.find_by_remember_token(token)
-          return user if     user.remember?
+          ::User.find_by_remember_token(token)
         end
       end

If you look through the recent commits, it’s a glorious sea of red as lines of code were removed.

Deprecations of shoulda macros

Originally, we had between a dozen and two dozen shoulda macros. They’re almost all deprecated now, continuing a trend over the last six months. The macros that have survived are:

sign_in_as(Factory(:email_confirmed_user))
sign_in
sign_out
should_deny_access
should_forbid

Want to upgrade?

You’ll want to:

• migrate your schema
• watch out for a cookies gotcha
• regenerate Cucumber features
• remove the “remember me” checkbox!

Migrate your schema

If you decide to upgrade, you’ll need to migrate your database schema, as we also finally addressed the “double duty” that token/token_expires_at used to play. It is now split into a confirmation_token and a remember_token.

Cookies gotcha

Like most things in software, this decision comes with a tradeoff. When cookies are set, they are not available until the next request.

So be careful with functional tests that depend that cookies. Try to use the current_user method where possible.

Cucumber features

This is a minor change. They mostly combine “remember me” scenarios into the basic scenario. If you don’t want to run the generator again, you can probably figure out what needs to be altered on your own.

Issues

As always, if you find any issues, please report them at Github Issues. Thanks and happy coding!

Written by Dan Croak.

Blossom the lovely stars, the forget-me-nots of the angels

“Silently, one by one, in the infinite meadows of Heaven, Blossom the lovely stars, the forget-me-nots of the angels.” Evangeline by Henry Wadsworth Longfellow

You’re writing a Rails app. You want users to be able to sign in.

You decide to use Clearance.

How do you expect it to handle “remember me” out of the box?

Remember unchecked by default

Basecamp:

Gmail:

Remember me checked by default

Eventbrite:

No remember me, automatically sets a cookie

Github:

Tumblr:

What should an authentication framework prefer?

Right now, Clearance comes with remember unchecked by default. I’m leaning towards changing it to checked by default.

What do you think?

Already confirmed

If you’re using Clearance and Airbrake, chances are you’ve seen this error:

Forbidden: confirmed user

You see, in the dead of the New England winter, we got academic about being HTTP fluent. In the process, we made our Rails apps less usable for one edge case:

Users click their confirmation email more than once.

Why (using email as a bookmark, double-clicking) doesn’t really matter. Airbrake has shown us it happens… a lot.

No more errors, no more books…

Clearance used to raise a 403 Forbidden and display a blank page. Not a good user experience. Last week we scratched our itch and changed it to  display a flash message and redirect somewhere depending on whether the user is signed in or signed out:

Already confirmed.

A little less dogma. A little more useful for the user.

Written by Dan Croak.