Scott Blomquist

Selection paralysis

I got to thinking lately about how I wish I had a wiki on my personal web site, because I want to do some quick’n’dirty semi-structured and richly linked writing to share with others so I can get feedback and input. I spent some time catching up on what wiki systems are best at what, and discovered I was completely daunted by how many different choices there were.

I eventually whittled the list of candidates down to just short of 10 different packages, and then got stuck again. What happens if I pick one today and invest considerable time in it only to discover that a different one fits better with what I’m using it for? Is there any way to migrate the data to a different wiki package at or near full-fidelity?

More »

I get bitten all the time with minimum username length requirements. The most common number that I bump up against is 6 characters, probably because my usual username is 5 characters so I wouldn’t hear about requirements of 4 or 5, and it’s obvious to everyone that requiring 7 or 8 characters is silly. But why have a minimum length in the first place?

Help me out here—I want to believe that when Zoho tells me that I need to use 6 characters, it’s for some reason other than “the developer who wrote that validation code picked 6 arbitrarily”. But I can’t for the life of me imagine what the other, better reason might be.

Even worse than Zoho is Google’s Picasa. Before successfully choosing a username there, I managed to uncover 3 different error messages, two of which are completely useless:

1. Please enter a username between 6 and 30 characters.
2. Please enter a username without invalid charcters.
3. The username ‘xxxxx_’ is not available.

Okay, for message number 1, I can understand what to do in response to the message, but it frustrates me nonetheless. As far as I can tell, the only “charcter” (their misspelling, not mine) that triggers message 2 is ‘@’. Any other character that’s not a letter or a number results in message 3 (which was caused by the _ in this case).

I know that neither the Zoho developers nor the Picasa develoeprs are likely to read my meager blog rant. But for those of you out there who do web development today or in the future, please keep in mind that there are some of us with well-established usernames that are only 5 characters (or 4 or 3 or shorter, for that matter) that would love to not be subjected to capricious and silly rules when using your site. If there are technical reasons for arbitrary-seeming restrictions, then fine, but in most cases there shouldn’t be.

Read about the new movie recommendation engine Jinni on Techcrunch earlier today. I’ve done a few queries, and love the particularly rich axes along which they slice and dice the catalog of movies. They call their taxonomy the Movie Genome Project, and admit that it aims to do for movies what the Music Genome Project (most famously in use at Pandora) has adeptly done for music.

While they’ve done a great job of building a really nice movie recommendation service so far, and I can’t wait to see where they go next, one particularly significant missing piece today is integration with the Netflix API. As with most of the profile data that I scatter around on the web, I don’t want to have to enter movie ratings on every single web site that could use them to improve my experience. The good news is that Netflix has cracked open most parts of their user database and will allow me to grant access to third party sites using OAuth to read the ratings that I’ve already entered, as well as add ratings for additional movies. They will also allow sites to add movies to my queue or even stream the movie via Watch Instantly.

If Jinni were better integrated with Netflix, it might become the only site that I use to manage my movie-rental experience. Which is great for Jinni, and just fine for Netflix. If Netflix spends only enough money on web application R&D to provide a basic experience, they can focus more resources on doing what they uniquely do best—getting movies in front of my eyes either via mail or via streaming over the Internet. That is, by enabling sites like Jinni to supplant some of the work that Netflix has historically had to be good at, Netflix ends up with a more satisfied and loyal customer.

Update: Minor edit to fix up an unclear pronoun in the last paragraph.

During the wrap-up circle at today’s IIW2008b (which is the acronym for this fall’s Internet Identity Workshop), Phil Windley said that this may not have been the best IIW ever, but that it was the best in a while. I admit that I didn’t start attending until IIW2007a, but this was definitely the best IIW ever for me. (btw, Kaliya, I believe amorphous blobs of chairs are far more egalitarian than circles… Seriously.)

I’ve finally been lurking in Identity Land long enough to know most of the key projects, and many of the key people. Accordingly, the number of relevant and interesting conversations that I manage to find continues to climb with each IIW.

The other thing that I think contributed to my feeling that it was such a good event is that many of the projects in the space are finally reaching a significant level of adoption and awareness. This adoption and awareness is driving people to come together to solve some of the remaining difficult problems before we can break through to the mainstream. It’s also driving some of the traditionally competing technologies in the space to come to an understanding of each other’s technologies, and to look for common ground and opportunities to collaborate on mutually beneficial efforts.

One of the best sessions that I attended was a session led by Paul Trevithik that sought to explore what request the identity community would put to the major browser vendors for inclusion in future versions of their browsers. When people from each of the OpenID, iCard, and SAML communities showed up, many of us who have become familiar with the politics of IIW figured that we were going to reach a stalemate in the first 15 minutes and end up having made very little progress. But it turned out that we all came together and quickly found some common ground. We all readily agreed that if the browser could help a user discover and catalog which credentials he has, and could help match them up to relying parties that can use them later on, we could all get on about our business of actually making our protocols do what our protocols do and rest easy with the knowledge that future web browsers will help us out.

Now that we know what problem should be solved by future browser facilities, we still have some tricky technical work to do to get to a proposal and then still more work to get to an actual prototype. But I’m optimistic that we, the united identity community, can get there.