Website Registration as a Usability Anti-pattern

In software engineering, an anti-pattern (or antipattern) is a design pattern that appears obvious but is ineffective or far from optimal in practice. (Source: Wikipedia)


Whether the users are Software Developers or a sixty-two year old journalist I affectionately call ‘Dad’, users agree that Website Registration blows.  It’s a hurdle we must endure to get to our beloved internet content; or at least that’s been the status quo for a number of years.


In a recent twitter conversation with @SQLServerCentrl, I complained to them about their registration requirements.  I hadregistered to see a certain article (it turned out not to help me, even though the search terms indicated it would); and I kept receiving their newsletter. As I was clicked on a link in one of their newsletters a few weeks later, I realized that I had forgotten what password combination I had used to register.  Then I realized that you can’t see any content on their site without registering.

I asked them about it, and their response was:


@gortok sorry to hear that, but the registration allows us to track stats. If you’re getting the newsletter, you should be registered

That doesn’t make any sense; doesn’t Google Analytics provide anonymous tracking?

That tête-à-tête ended with them pulling out the numbers card in Argumentum ad Populum style.

How many times have you, as a software developer, heard this refrain from your business analyst or marketing department: We need to be able to track users and collect information about them so we know who to market to. This refrain normally spawns a requirement (or two) that the end user must register in order to see content on the site.  All of the tie-wearers agree that that’s the only way to get all of this information, and so it is done.  If you develop software, and you let this happen, you have now commited the worst kind of design pattern, the Usability anti-pattern.  Jeff Atwood calls it a ‘barrier’, but it is so prevalent in websites that it can only be considered a design-pattern at this point, and an anti-pattern at that.

It’s an anti-pattern because while it’s easy to do, and it fulfills the business requirements, it gives users a bad taste in their mouths about your website.  When’s the last time Wal-mart required anything out of you other than walking into their store? 

There are reasons to ask a user to register on your website:

Common Reasons to ask for Website Registration


1. It’s the easiest way to track what you look at.

2. It’s our way of tailoring what we deliver to you.

3. We sell your information, we can’t sell it if you don’t give it.

4. We have ‘affiliates’ that we ‘share’ your information with to ‘better serve you’.

5. No reason given. Just a Privacy Policy written by a Lawyer (That gives me a warm-fuzzy).


If you look at all of these reasons (except #3); you’ll notice one thing they all have in common. They’re bogus. They don’t mean anything.  They’re simply excuses to get you to give them the benefit of the doubt.  When you go into a store to look at a product; does the store owner stop you at the door and force you to give him your name and address before entering? The answer is a resounding No.

What’s worse is that asking for personally identifiable information from a user now brings up legal issues, as this FAQ regarding registration from the Chicago Tribune website so aptly shows:


We specifically ask your birth year to assure compliance with our Privacy Policy concerning minors.


Wouldn’t a better idea be to not ask for personally identifiable information in the first place?

Besides selling your information or spamming you with emails, there is no reason for a website to retain any personal information about you.

Yet, we seem content to let this happen across our web-applications and websites. We force customers to give us some sort of information in return for viewing our content.  In the worst cases, you must log in every time you want to look at content (SQLServerCentral), and in the lesser cases, you only have to register and log in when you actually want to buy something.  At the good end of the spectrum, you have websites that set the bar low enough where this isn’t even an issue (Stack Overflow, Google, Amazon).

The harder (yet infinitely more usable) pattern is for a website to take one of three paths:

  1. No registration whatsoever.  Why would you want to register to read daily content, some of which you may never even care about?  What does registration get you? Nothing.  Registration is used simply to tie you as a user to what you look at.  Guess what? It’s the same information that can be found with Google Analytics. The only difference is, this information can’t be sold to a marketing company.
  2. Incremental registration after the user has poked around your site. A great example of this is buying something off of NewEgg or Amazon. You select the product, fill out your billing address, buy it, and then they ask you to fill out one or two more fields (usually just choosing a password), and that’s it.
  3. Registration for ‘advanced’ features or for continual participation. Stack Overflow uses this method.  As a Unregistered user, you can ask questions, browse the site, and you can even gain reputation. However, that reputation doesn’t persist across cookie deletion unless you register.


All of the methods I mention are widely used, and they’re all relatively easy to do. So why do businesses still ask for this information?

It’s easy, it’s cheap, and by the time you realize you’ve been hoodwinked, they’ve got your information, and you’re left with whatever they’ve seen fit to give you.  In most cases, you’ve gotten the short end of the stick.


Building a Website: Part 1: The Functional Specification

In our previous adventure, I talked about building an ASP.NET website for a local school.  This site would have a small Content Management System attached to it.  Nothing fancy, just something small.  But you see, I forgot a cardinal rule of programming: Get the functional specification. Oops.  Luckily, the site idea has been swimming around in my head for ages, so it should be rather easy to crank one out, right?  Let's hope so.  This specification will follow the example set by Joel Spolsky of Joel On Software.  Without further ado (or maybe with it, given my rather long intro), the functional specification.


Overview is a website that allows teachers from St. Anns to update the parents and community on what is going on in their school.

Warning: This specification may cause paralysis if read for too long. It's not complete. It will change. Hopefully not too much. The screens shown here are for illustrative effect, they are not meant to be taken as the final product.  The look and feel of the site will be refined and changed based on user feedback.

This specification only deals with what a user would see when they visited


In designing products, it helps to imagine a few real life stories
of how actual (stereotypical) people would use them. We'll look at two

Scenario 1: Samantha (The Teacher).
is a Teacher at St. Anns.  In between dealing with kids, parents, meetings, and planning, she has very little time to worry about weather or not people on that distant thing called the internet are kept up to date with what is happening in her classroom.  Up until now, she's always just put the newsletter in the Kid's bookbag, and sent them home.  If the parents needed to read something, the hope was that the child wouldn't ingest it or use it for spitballs.  For anything important, the United States Postal Service was used. Given that we're 8 years into the new millenium, and a full 12 years after the World Wide Web became huge, Samantha (being the smart teacher that she is) knows that it'd be far easier to copy and paste her news letter onto a website than it would be to print it out, make copies, and put them in her kids' bookbags.  Not to mention it'd be much more 'green'.

So Samantha logs on to, and decides to upload her news letter.  In friendly way, the site asks her what she wants to do, and if she wants to upload the newsletter, she simply copies and pastes it from Word, hits 'save', and her work for the day is done.  She can do this for every other section on her teacher page as well.

Scenario 2: Tammy, the Mother.

Tammy is the mother of two wonderful children that seemingly lose their newsletters walking from the school to their car.  It happens.  When she needs to find out information, she simply navigates to the site, and can easily select her child's classroom.  Once there, she sees that the weekly newsletter has been posted to the site, along with a note about upcoming events that's easily viewable.  Since she'd forgotten about the Picture day, she goes ahead and calls the school and asks if it's too much trouble to be sent another form.  Just like that, she is kept up to date on her children's school events.


Where to Go From Here

At this point, we've got a jist of what we want the site to do, so we'll go ahead and base a data schema off of this and start building the site.  We're pretty sure we're not going to get it right the first time, so we're not really worried about that. 

This is the site in a nutshell.  In the next article, we'll work on the data schema.

To MVC or not to MVC?

I have been following ASP.NET MVC ever since it was brought up as the meta-pattern behind Stackoverflow.  As I referred to in my last post, I'm in the process of building a website for a local Catholic school.  Part of the the act of building the site is determining whether or not I want to go the extra mile and really make it something special, or if I just want to 'make it work'.  The traditional Web Forms + NHibernate + SQL Server will make it quite easy to build; but then I wouldn't be learning anything new.  MVC does seem like overkill for the task at hand, however.  So the question at hand, Speed? Or doing it the right way?

Building an ASP.NET Website

Over the past few months, I've been working on upgrading St. Ann's Catholic School website from the circa 1996 look to something more modern.

So far, I've done the following:

  • Organized the site in a logical fashion
  • Implemented a menu system using Tanfa's CSS driven Menus
  • Used Purplehaze.css as a baseline for the website's cascading stylesheet
  • Created and helped edit static content for the site (I instructed a non-technical person on how to upload the static content and change the content so far.)

 Since that's done, I can focus on the dynamic nature of the site. There are a number of stated features to be implemented, including:

  • Ability to add weekly newsletters
  • Ability to add homework
  • Ability to add events (a la Google Calendar)
  • Ability to see recently added information

 To make this happen, I need to take the following steps:

  1. Create Database Schema
  2. Use NHibernate and My Generation to create POCO objects and theData Access Layer and Mapping files
  3. Create Business logic and create individual modules listed above
  4. Deploy and Maintain

I intend to use this blog to document this, and obviously the code will be released (open source, license unknown) to allow other schools to create dynamically driven sites without having to rely on sites like TeacherWeb. I don't have anything against TeacherWeb, I just can't believe that schools would pay for what amounts to a WYSIWYG editor (not unlike Frontpage).

You may wonder why I'm using CSS Menus and Stylesheets from other authors instead of rolling my own.  I could do both (though the latter would be far easier than the former); the reason is easy, never design what you can steal.