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.

I first heard about the world of online competitive software development from an announcement on Slashdot back in 2003. It guided me over to TopCoder to sign up for the second annual Google Code Jam .

I think I missed (by mere minutes) the registration deadline for actually competing in Code Jam, but since that introduction, I spent a little time on TopCoder over the years. It was extremely cool to be able to hop online and develop solutions to competition-style algorithms problems against some of the most brilliant algorithms guys in the entire world. Sometime soon, I hope to have some time freed up to give it another go.

Since then, TopCoder has added many types of competitions other than algorithms, including Architecture, Assembly, Testing, Design, Development, and more. I haven’t tried any of the competition formats other than the original Algorithms competition, but many of them actually have a cash prize purse.

At any rate, back to Code Jam. Google ran the first six Code Jams on the TopCoder engine, but this year made the switch to running on their very own AppEngine. They’re going to allow you to download a dynamically-generated question in the style of the Google Treasure Hunt 2008, and you’re then on the clock to upload a correct set of answers back to their AppEngine app for scoring within the allotted time.

One of the biggest improvements that results from this switch is that you can now use any programming environment that you’d like. The only requirement is that it runs on your computer. Gone are the days of choosing one of TopCoder’s 4 languages (C#, C++, Java, or VB.net), Google Code Jam’s 5, or the 22 supported by the ICFP’s official LiveCD.

Roy Leban blogs about stupid password policies over at his thisUser blog. I’ve got some good news for Roy and his readers: I’m currently making a living turning all of the things that he rants about into relics of the unenlightened past. And while I have to concede that it’s a slow uphill climb, there are some very exciting things that you can do today to start simplifying your online life.

The first one worth mentioning is a thing called OpenID, which is pretty much just single sign-on for the Internet. This is not a terribly new idea–Microsoft has been pushing for something very similar in the form of Microsoft Passport Windows Live ID for around a decade. OpenID has the added benefit that you can use it even if you’re not convinced you’d like to involve Microsoft in your online life.

In fact, you can even host your own OpenID. For example, I use the address of this very blog (http://scott.blomqui.st) as my personal OpenID. (You can see it in action in my previous comments on Roy’s blog such as here. Notice the shiny orange OpenID icon to the left of my nickname?)

If you want an OpenID, I’d suggest myVidoop. (Full disclosure: I’m the CTO of the company that built it.) We’re one of the better-known OpenID providers, and unlike the other OpenID providers, we actually have a way of making money.

The big problem with OpenID today is that there are much fewer than 20,000 sites that allow you to log in today using OpenID. Which brings us to the other neat thing about myVidoop–we provide a cross-platform browser plug-in that helps you by managing your usernames and passwords as you cruise around the web. This enables you to sign in once when you open your web browser, and then we take care of signing you in to the other sites that you visit, whether OpenID-enabled or not. (Oh, and we also use a fun alternative to passwords for signing you in to the myVidoop site, so it can literally make your life almost password-free.)

I’d be thrilled if you’d give myVidoop and our password management plug-in a try and give us your frankest feedback over on GetSatisfaction.

Finally, I’ll mention for the benefit of the web site owners in the audience, there’s an experimental Vidoop project called Email to ID. If you have a web site that would be using OpenID if only most users already had one, Email to ID is your solution. Email to ID gives every user an OpenID, and the authentication mechanism is their email. (As strange as that sounds, that’s the way things already work only less conveniently–you can reset pretty much any of your passwords by simply requesting an email, so we just made the security dependency on your email box explicit.) You can find some more detailed analysis of Email to ID at Silicon Florist.

A post on TechCrunch today about how incredibly much AT&T charges, per byte, for SMS messages reminded me to throw up my quick thoughts on my dream for a future where bytes aren’t discriminated against based on information about their content. Or at least not quite like they are today.

While I have to tip my hat to the cellular providers for managing to pull off the biggest market segmentation coup since airlines discovered that businessmen don’t stay over Saturday night, I have to admit that I find it frustrating that it’s far more expensive for me to update my twitter status sending an SMS than using my mobile web browser, despite that thousands fewer bytes get transmitted for the SMS with lower expectations on speediness.

The net neutrality purists might argue that the way to fix this bizarre state of affairs would be to require that no data should be discriminated against under any circumstances. That definitely sounds like a worthy goal, but I don’t think that’s quite the right approach.

There are some applications, such as real-time video or voice, where I might want certain data to be bumped to the front of some line. If I want to make use of an application that has such requirements, seems to me to be totally fair for the data provider to charge me for that–perhaps I have to pay my broadband or cellular provider more for the monthly privilege of requesting that a certain amount of data be delivered with a low-latency guarantee or with a minimum throughput commitment.

Seems to me like that would let the market sort itself out. It gives the providers an incentive to give me options around network quality-of-service, it gives me an incentive not to ask to use such new features except in situations where such premium usage makes my life better, and it gives Internet application developers the tools that they need to offer their end users innovative new experiences so long as their users show up with the required premium features.

I’m probably completely neglecting the case where Google might offer to pay the low-latency premium for users who commit to using Google exclusively, or something like that. But I think I’m more interested in seeing ways to improve voice and video as long as my mundane traffic doesn’t perceptibly degrade from where we are today.

Update: removing the break in the middle of the post. Not sure how it got there, but it’s a little annoying.

Nathan Bell blogs about how he wishes OpenID would just go away, or at least fade into the background so that users don’t have to know quite so much to use it. I really like how he’s thinking over there, and will take some time to write up my thoughts on most of it sometime soon.

Meanwhile, I wanted to throw in my two cents on requirement #3 that he laid out in his post. I and some other Vidoopsters (Michael, Chris, Will) were working on one of our OpenID usability efforts and ended up convincing ourselves that the trust page doesn’t matter if no profile data is being handed off. The boolean value that represents the success or failure of an authentication attempt is certainly no more of a data leak than the claimed identifier that had already been submitted.

Or am I missing something?

I was at lunch today with Chris Messina and some others from Vidoop, and somehow as often happens with me, we got into a very interesting discussion about the way Microsoft does things. In particular, Chris indicated some frustration with a lack of traction that he’s gotten with Microsoft in the past regarding technologies that he and others advocate. He cited a long string of press releases and public appearances supporting the technologies that will make up the open web and an equally long string of failures to deliver any level of support in actual code. He’s definitely right–what gives?

Being the Microsoft fanboi devil’s advocate that I am, I claimed that the Microsoft that exists today isn’t the same Microsoft as we all know from 10 years ago (or even 5). I admit that there are a tremendous number of things that Microsoft doesn’t yet demonstrate a deep organizational understanding for, including Open Source, Open Standards, the consumer Internet, etc., but the one thing that I do know from my 7.5 years with the company is that they’re nothing if not self-critical, especially when they’re not winning the game.

I challenged Chris to name some things that he thinks he’s learned about Microsoft over the last few years and give me a chance to argue that some of them have changed. He threatened graciously offered to write up a blog post with at least 5 misguided things of which he would accuse Microsoft along with examples of how they could prove him wrong by speaking with code. I think that sounds like a great idea. I can’t wait for the conversation to begin!

Following Clickpass‘s lead, there are 3 key scenarios that a Universal OpenID Button needs to enable in order to gain widespread use on the web: 1) new user sign up, 2) existing user sign in, and 3) merge existing Identity 1.0 user with a new or existing OpenID user.

Despite the existing best practices for all 3 requirements (and many more), as you look around the web you’ll find implementations that demonstrate dozens of completely different takes on what it means to be an OpenID Relyer. One very important side effect of Clickpass’s approach is that their button essentially comes along with mandatory best practices. That is, any site which chooses to implement the Clickpass button will behave nearly identically to any other site that chooses to implement the button.

By necessity, this minimum set of behaviors will be very small–sites probably wouldn’t be as quick to get on board with the button if full-on AX support is required, for example. But the clear guidance that such a button program would provide would be invaluable in helping site owners understand what work goes into getting started with OpenID and doing it right.

Just to throw out a strawman to get some conversation going, I’d say that a Universal OpenID Button should start by supporting the three scenarios I called out above plus it should help users get their very first OpenID if they don’t already have one. This last bit might seem like it diverges from Clickpass, or even from the current practice of each site owner choosing which OpenID provider(s) to refer users to for whatever arbitrary reasons they like, but it doesn’t have to. Site owners could still choose to send their users to myVidoop.com or MyOpenID.com or Clickpass in the interest of either themselves or their users. Or if they don’t want to choose favorites, they could send their users to the OpenID Foundation for help in choosing a provider.

By the way, next post will be the one where I start going into deeper technical detail on how I think we can pull this off.

The great OpenID usability work that Clickpass recently launched and the reactions that followed have induced me to spend some time thinking about what this all means for OpenID.

The first conclusion that I reach is that Clickpass-style single-click single sign-on is almost inevitably the future of OpenID–it makes it trivially simple for even the least savvy user to understand how to sign up and how to sign in. And interestingly, Clickpass is not the first company to realize this–they’re simply the first company to tell a story that causes this to stand out to me as a particularly brilliant feature. Yahoo provides an OpenID button (whose obnoxiously typical terms of use require a 25 pixel moat around it), and Microsoft’s Passport Live ID has employed a button for approaching a decade.

The problem with all of these buttons is that there are bound to be so many of them. As in my article on annoying social bookmark icons, I can already begin to imagine the OpenID button area that we’re soon to start seeing pop up (and there are already some examples of poor re-inventions of the button-area):

The right way to solve this problem is for us all to agree right up front on a way for each publisher to only have only one button–an OpenID button. Clickpass has an implementation that’s more than halfway there, and I think that one possible future would consist of Clickpass having opened up their button to the point that a user who already has any other OpenID gets a first-class experience with the Clickpass button. I believe that Clickpass won’t ultimately thrive without being as open as possible and collaborating closely with the OpenID community, but from my brief conversations with Peter Nixey, it seems clear to me that they get that.

Another possible future (which is not mutually exclusive with the previous one) consists of the OpenID community coming together to build an OpenID button that does things right. Clickpass would certainly still have a business in providing added value over the community-owned OpenID button, but the community button would provide a non-proprietary alternative for those site owners who value openness over features.

I’ll follow this article up shortly with a description of the minimum set of features that would be required for a community button to take off.