Wednesday, March 19, 2008

Opening up to OpenSocial, OpenID, hCard and oAuth

So, there is a flood of propaganda coming out of the web 2.0 conferences either about OpenSocial, OpenID, oAuth or hCard. And many people seem to be smoking the peace pipe and passing it along. Sorry, but I don't smoke, and I don't read the tabloids. Usually, I like to wait until a technology is bound and in print, before I am ready to commit. Sorry, but it is an old guy's habit after seeing too many idealogical fads hit the Internet.

However, a co-worker said something today that actually made sense to me. And it was not about only having one login to remember, or how cool it was to link all your accounts together, or any other feature set that has been tried before. It was the way he related the registration process to a check out process, and indirectly related the registration information to credit card information.

...Okay, so you probably do not get why this excited me enough to write a blog about it, but read on...

For the last few weeks I have been doing a lot of reading on usability, design, and marketing. And the only thing that I think every time someone mentions these technologies is "So great. You want me to both convince users to register with my site, and do so using a process they are unfamiliar with?" What if my user does not have a GMail or Blogger account? How are you not setting me up to just confuse a lot of people? I mean, how do you expect to sell this to non-geeks? The n00bs? My mom? (Yes, my mom is my favorite test-case for usability. If she gets it, everyone does.)

So, the concept of these services as personal information brokers in the same way that Visa and Mastercard are brokers of my credit card information is powerful. If registration is a checkout, your login is your credit card information, and sign-in is like Amazon's 1-click purchase. This ability to relate these systems to a very well established user interaction might just give this whole thing some credit. I can now see a small sliver of light that suggests this stuff might make it to hard copy, might be around in three years, and might be worth my time considering.

To the many behind OpenSocial, OpenID, hCard, oAuth, and whatever else is out there, my suggestion is this: Stop selling this stuff to me, the web 2.0 geek, and start figuring out how you are going to sell it to my mom. You do that, and you will have a recipe for success. So, please go fire up your branding iron and get to work, because you have long chasm to cross if you really want this to catch on.

Saturday, March 8, 2008

GUIDs, UUIDs, and Canonical Names in JavaScript

Creating unique identifiers outside of a database tends to be a bit of a pain. So, why would you do it? What if you were not using a database? What if you have distributed servers? What if you want clients to be able create distinguishable content without constantly contacting the server? For example, if clients are aggressively creating parallel content, then it would be advantageous for you to be able to lazily sync the content without causing significant lag and interruption to the user. I realize that most of you will not run into this, but for those of you who do, here are some helpful notes:

Firstly, I can't tell you how many postings I found that led to tutorials using an ActiveX object to create a UUID. If you have only IE-using clients that do not have stringent security settings, then I guess you can use this. Otherwise, it is no good.

I soon found This UUID library from AF-Design, which is alright, but there are obvious inefficiencies, such as the way it computes time in milliseconds out the long way instead of just using Date.getTime(). Also, a serious design flaw is that it doesn't use any unique data other than time in milliseconds to generate the UUID. To be a true UUID, it would need to utilize unique data to the machine such as IP, or even better the MAC address. Otherwise two machines could potentially generate the same UUID.

Understandably, there is no method for fetching the mac or ip address using only JavaScript within a browser. But, you can make the client's IP available to the JavaScript running on the client browser by echo-ing back the REMOTE_ADDR from a request header back to the client. For an example of how to do this in PHP, see http://unix.cms.gre.ac.uk/code/php/examples/remote_addr.php.

Since I usually do not care to have my unique id's in the traditional UUID format, I tend to go with a canonical name using an MD5 hash of the time and IP. The result is more reliable than the UUID example above, and is actually a bit faster and easy to implement:


function cn() {
var t = (new Date()).getTime();
var ip = '192.168.1.100';
return MD5(t+ip);
}


I hope this helps any of you dealing with a similar design problem.