Symphonious

Flow|State has an excellent semi-rant about how poor the user experience is when using OpenID - both signing up and logging in. In particularly the question of what happens to all your accounts when your OpenID provider disappears is a particularly good one.

It so happens that I was looking into this just today since I needed a user friendly but secure authentication mechanism. OpenID seemed like a natural choice since I was effectively starting from scratch anyway, why not use a standard? The main problem I had with OpenID didn't really come through clearly in the Flow|State article though - OpenID requires users to log in twice. The first log in requires them to enter a URI, the second log in requires them to enter their password (or in some cases a username and a password). It's bad enough that most URIs are much longer than most usernames or even email addresses, but there's actually a page reload between the URi and the password. When was the last time you saw a webapp display the username and passwords fields on separate pages?

You can do a lot to make things easier on users of OpenID, but the whole protocol is based around the idea of having an extra page load between the URI and the password. You can avoid the problem sometimes if the OpenID provider's session hasn't expired yet but you can't have those sessions hanging around too long or they become a security hole.

So in the end, the best thing we can do is to ignore OpenID and use the old fashioned username and password per site. If we want to have a consistent online identity, provide a way to set your homepage URL and link to it where ever the username appears. You can still impersonate people but OpenID doesn't really stop that anyway - worst case, use OpenID just to verify that the person's homepage is really theirs.

I have to agree with "Jon", Gruber (John with a h) does have a habit of linking to sites that link to him regardless of how good they are. For instance, this link list entry was a complete waste of time…

I wonder if there's any limit to it?

I've struggled with Lucene before and failed to configure it properly resulting in absolutely horrendous search results so a recent need to implement search functionality wasn't something I particularly wanted to take on. In fact, I was prepared to do almost anything to avoid delving back into Lucene filters and parsers and tokenizers and "stuff". This tends to be problematic given that Lucene is the dominate search library - so popular in fact that it's been ported to other languages.

So I took a look at Solr - a web services front end to Lucene. Exchanging Lucene APIs for HTTP requests seems like a good tradeoff for me and Solr comes with a pretty decent configuration for Lucene right out of the box.

As it turns out, Solr's default configuration isn't just pretty decent, it's also surprisingly well commented. Combined with some reasonable documentation it was pretty straight forward to get Solr to do what I want and provide good search results without much effort. With a bit more effort I should be able to get search highlighting working as well which takes search results to a whole new level.

Two things really made me appreciate the choice to use Solr:

1. It has a DirectSolrConnection class that removes the need for actual HTTP requests. As a bonus, it still uses the HTTP URLs and returns the same responses so if you later need to split Solr out onto it's own server you just have to implement the HTTP stuff and not change the result of your processing.
2. It caches searches automatically.

Caching is just so cool to see in action. Using the built in search from Jackrabbit (which also uses Lucene) it was too slow to include the output of a search with each page (think, related links etc). With Solr's caching this isn't a problem anymore.

There's still a bunch of learning to do so that I can get really optimal results - getting searches to work over multiple fields properly so that I can weight the results based on which field matched would be good and I can see Solr can do it - just not quite sure how to make it all happen. Still, the current search is way better than anything I've managed to do before. Thanks to the Solr and Lucene teams!

Alex Iskold has an interesting article "Rethinking 'Crossing The Casm'" which asks how to maintain the interest of early adopters in the face of such an overwhelming number of new products:

According to Wikipedia in 2006, Tom Byers, Faculty Director of Stanford Technology Ventures Program, described "Crossing the Chasm" as "still the bible for entrepreneurial marketing 15 years later." It is certainly a powerful and proven theory, but it does need to be adjusted. The fact that so many things are thrown into the market changes things. Early adopters are enticed by new things much more often today than 15 years ago. Expanding on how to retain the early adopters would be good thing to do in the next edition.

It seems to me that the answer is classic Porter's 5 Forces1 - you need to negate the threat of new entrants, the threat of substitute products and invest in areas that don't have exceptionally intense competitive rivalry. In other words, you need to build a product that is not just compelling now, but also has something that competitors can't easily add.

The first thing to realize is that the early adopters in one niche are usually different people to the early adopters for a different niche. There are some people always on the look out for a new social network that aren't interested in a new chilli source. So you need to pick a niche to invest in that doesn't have such intense rivalry that makes it so difficult to maintain attention.

More importantly though, whatever industry you're investing in, you need to make sure that you have some key advantage over the other players - maybe you happen to know more about music categorization than anyone else (Pandora), maybe you have awesome peer to peer networking technology that massively reduces bandwidth costs (Skype and now Joost), maybe you have a massive farm of servers which makes hard drive space insanely cheap for you (GMail) or maybe you just have key relationships that give you a unique channel to market. There has to be something that you have or that you can acquire that other people will take time to acquire and it has to be a game changer. Then design your product to make the most of that strength. You're creating barriers to entry for your competitors and making it harder for them to take over from you.

To reduce your threat to substitute products you need to provide some benefit to your users that makes it hard for them to switch. The old technique for this was to lock in their data but that's generally frowned upon these days2 so you'll have more success with things like building a community around your product or even just building a brand name for yourself. If no one ever got fired for buying your product, you're in a really nice position.

The most important thing to do though is to keep innovating. Just because you got the attention of the early adopters doesn't mean you should kick back and wait while they carry you across the chasm, you have to keep working hard to keep them happy, to keep providing remarkable aspects to your products that maintains their attention. You have to keep doing what you did to get their attention only different - keep inventing cool stuff, but not the same stuff you've already invented, that's old and boring.

In buzz words, to cross the chasm you have to invent a purple cow to get the early adopters attention then milk that cow while inventing the blue and green cows, followed by the flying horse and a silent rooster to keep giving your sneezers something to sneeze about until everyone catches the cold. Clear?

1 - actually, just basic business but Porter's 5 forces gives me a simple framework to categorize strategies by↩

2 - rightfully so by the way↩

There's this myth that's existed ever since the beginning of OS X - that Cocoa apps are automatically better than any other type of application. They use less RAM, run faster and are just all round better - you can't dispute it. If you take a lousy carbon app and rewrite it in Cocoa it will become amazing and all it's problems will be solved.

This is of course, complete and utter bull.

The latest person to buy into that theory is Paul Stamatiou with his review of VMWare Fusion:

Fusion was built from the ground up in OS X’s native programming environment, Cocoa, and as such Fusion benefits from speed increases and lower memory overhead. The use of Cocoa in the development of Fusion also means that Fusion puts less strain on your computer than any other virtualization product at this point.

Actually, Cocoa requires Objective-C which is a much higher level language than pure C and with every level of abstraction comes increased memory usage and slower performance1.

Cocoa is a great framework and it makes developers a lot more productive but it's not some magic bullet that makes an application fabulous. Yes, it's easier to create a really "Mac-like" application with Cocoa than with Carbon or other frameworks, but from an end user's point of view it just doesn't matter whether or not the application is Cocoa. Let's get over it and move on.

See also:

• Daring Fireball: Some Assembly Required
• Daring Fireball: I Would Not Feel So All Alone

1 - not that you shouldn't use Objective-C, it just won't magically make your code faster↩