Stop asking questions.

Posted on July 19, 2009

I’ve had an ongoing conversation with a few people over the course of a few projects about the questions to ask when people sign up on the web or what hoops you make them jump through.

Ask most people what they need to know about user’s and you’ll end up with a list of information from the useful like name to the truly useless like job title or title. Give me one good reason for either. Are you going to be sending Mr John Smith or Dr. Sarah Jones a letter using their formal titles?

When it comes to things like Job Title, the reason I usually hear is that it’ll be useful for marketing and demographics later. Maybe, but I’ve never actually seen that later come to anything. So I don’t buy it.

If the signup form is the depth of your engagement with your user you might as well drop the pretense of a web application and go back to sending newsletters. Just don’t do it. Ask your user the bare minimum number of questions you need to get them started using what your product does now and stop throwing up barriers to entry.

Aside from just the questions that are asked there are other things, the hoops almost every site makes you jump through before you can start using it. Probably the best example is the ubiquitous confirm your email step. Do we need to be doing this? In some circumstances I’ll admit it makes sense, if your delivering content via email for example or signing up for a mailing list. Of course you want to make sure the user wants what you’re sending them.

But for every other site, I’m not sold. It’s just another step they have to take to start using your service and all the little steps all add up to users hating signing up for new things.

Also it begs the question, why even bother? For 99% of websites the only reason to make sure a user has entered their email address correctly is so that you can let them recover a password. You’re adding the step for people that have lost their password and haven’t managed to get their email right. That’s going to be a fairly small proportion of your users; even less if you let login with their email address, then they’ll know it’s wrong anyway as soon as they try it.

Do we pander to the idiots or make things as quick and easy for everyone else? I’ll take quick an easy any day.

I’m finding myself not just asking what any given field in a form is for and making it justify it’s self, I’m trying to figure out how to get by without it. I’m leaning towards going beyond just the bare minimum and into the realm of how can I modify this service to work with even less.

Some thoughts on unit tests

Posted on July 9, 2009

First of all, I don’t go in for the whole write a test that fails before I write any code. But I do aim for as close to 100% code coverage as I can get, again sometimes I pick and choose what I want to ignore when it comes to missing methods. Testing every getter and setter in a Java bean for 100% coverage seems like total overkill to me.

I do rely heavily on tests when it comes to regression testing – making sure I haven’t broken anything. I’ve spent time having to go through every page on a fair sized web app after every release and inevitably finding something broken that I then had to quickly patch. Once it’s patched you start the testing over again and probably find a few more things. With no way back  it ends up an all nighter. It’s not a lot of fun and testing helps prevent it.

The other reason I write tesst is that they help a huge amount when I refactor code. Like over the last few days. I’ve spent them undertaking a major retooling of large swaths of code. I’ve been pulling out all the RDBMS stuff from some user management code and replacing it with a Hbase implementation. It’s also shown me that the code was pretty tied to the RDBMS implementations, much more than I’d originally thought.

It’s not anymore, and I’m not sure I could have pulled it apart without a coherent set of unit tests. I’ll post a little on the strategy for writing tests I’ve implemented to prevent it in the future a bit later.

I’ve made a little JSR303 annotation library

Posted on July 7, 2009

I’ve been playing with Hibernate Validator 4.0 lately, it’s an implementaion of JSR 303 Bean Validation – basically the ability to annotate validations for your beans. Great in Hibernate as you’ll know if you’ve ever done it because you’re object describe the constraints and Hibernate enforces them for you.

JSR 303 builds on it by codifying the annotated validation framework into a standard you should be able to use from front to back and everywhere in between maintaining your rules for what is and is not valid. Of course that’s the pot of gold at the end of the rainbow, it’s far messier living on the bleeding edge before the standards have been officially released.

I’ve released a small very early project that builds on some of the stuff I’ve done using the Hibernate annotaions with Springframework in the past. Basically, wrap a Spring validator around the Hibernate one – or in this case around a generic javax.annotations validator.

I’ve also added a few new constraints that I need. NotEmpty validates that a field must not be null and must not have a size of 0. Email validates email addresses and URL validates Urls. It’s an early release, but check it out here on GitHub if you’re interested. If you want to use it feel free if you want to make additions I’d love to accept them.