Regarding using Open ID – I have not considered that for this product, but once we get the product launched will investigate this more and consider it. It’s a fair comment – to be honest I didn’t want to add the complexity in coding… my developer is my business partner, and he has a day job, and I have other work so this product unfortunately does not have our full-time focus. Believe me, if it did there are any number of things I would love to do to make it better, and this might be one! I will add it to the list of future requirements to consider and give it my attention later. Thanks for voicing your concerns!

Think about it this way: Would you patronize a restaurant that made you give your name and address, telephone number, age, income, before seating you? I wouldn’t. They don’t need that information to provide the service. And most web sites don’t either. They make you provide it usually because it serves their advertising strategy or because the investors think there’s some value in collecting demographic information on subscribers. But in reality, most sites can function perfectly well without anything but a unique ID. Which brings me to OpenID.

When it comes to signup processes, I won’t be satisfied until I don’t have to put in *anything*. That is, the web equivalent of a cash transaction. One step away from this is to accept OpenID for the registration. These are globally unique and much easier for the user since they don’t have to remember yet another name and password. In addition, your site can get some demographics that the user wants to reveal from the OpenID site, saving the user the trouble of having to type them in yet again. To extend the credit card analogy, accepting any OpenID is like accepting MasterCard or Visa. It makes it easier for the customer to buy your wares and visit your site.

I hope this didn’t come across as too much of a rant, but I find that designs for sites are too often oriented toward what the site wants, not what the user wants. Thanks for listening.