Author Archive

It’s 7pm in Austin Texas and I’m in a deserted lobby at South by Southwest with Nick Gonzalez from TechCrunch. Tomorrow is the day we’ve been building up to for ten months, the day we launch our product, Clickpass. I’m now demoing Clickpass to Nick who wants to review it for TechCrunch.

Almost everyone has left the building and are either back in their hotels or at the Facebook party, but for some reason the wireless is still saturated and has almost slowed to a halt.

On this grindingly slow network, our homepage hardly loads. When it finally does — in an irony not lost on either of us — Nick can’t remember the password he created six months ago when he last tried Clickpass and has to try several times to get back in.

Clickpass was designed to make single-sign-on easy. Before someone starts using it, though, they need to connect it to their sites.

The connection process is not going well. It’s been a while since Nick’s used any of the sites we support and we cycle through yet more password attempts as we try to hook into them. We finally manage to connect up to one of them but, for no apparent reason, Hacker News keeps failing. The demo part of the interview winds up and we get stuck into talking about the business instead. I’m starting to feel decidedly nervous.

Storm clouds gather

Ten months earlier we left London, moved to Boston to join YCombinator and started work on Clickpass — which was back then called Remember Me. We firmly believed that OpenID was one of the most important things to happen to the web and that the core issue standing between a brilliant protocol and widespread adoption was its unintuitive usability.

At the time we started the work of evangelists like Simon Willison, David Recordon, Chris Messina and Scott Kveton have succeeded in making most of the technology community aware of the protocol, but there was still a lot of cynicism and doubt.

As 2008 began and Yahoo and Google both announced their support for OpenID, something began to change.

Earlier that day, the SXSW OpenID session had been standing room only. Despite being in a sizeable room, every seat was taken and people were being turned away at the door as others stood around the walls and down the aisle.

That afternoon in a panel-session on distributed social networks, someone in the audience stood up and asked how OpenID was going to become easier to use. Following a mention from Jeremy Keith (moderating) almost the entire panel complemented our about-to-launch product.

It was a huge room, with hundreds of people and I could hardly believe it as Leslie Chicoine from GetSatisfaction described Clickpass as the “first time that OpenID’s actually made sense”.

Back at the demo now with Nick, in the middle of what seemed to be brewing into a perfect tech-storm, but with our ship still side-on to the wind. We finish up the interview and Nick heads back to his hotel room to write up while I hop next door to use the wireless in the Hilton.

Final tweaks

As the night wore on, many of the problems started to fall away. It turned out that the fact we couldn’t connect to Hacker News was indirectly because the site had, by complete coincidence, been TechCrunched that day.

The massive traffic had revealed a registration bug that was slowing the login system to a standstill. Had it it not been TechCrunched, the same bug would have killed the Clickpass experience the day after. By 10pm though Paul Graham had posted that it was fixed and the site was back to normal. Sometimes you just get lucky.

March 11th — day of launch

1am: Immad has crushed every bug we can find, our four servers are all idling happily and I’m about to head back to my hotel when I get an email from Nick saying that he’s sent the piece to Mike Arrington, but that Mike wants to ask us some questions. Can I hang on to take a call?

2am: I’ve just uploaded the company details to CrunchBase as requested when Mike Arrington calls. We talk for almost two hours about Clickpass, about the pains it’s solving, about how it takes the confusion out of OpenID.

As an entrepreneur you spend a lot of your time explaining things to people who aren’t always paying a lot of attention. However, Mike is 100% engaged throughout the full two hours and totally focused on understanding the product. I’m impressed.

Mike hasn’t used OpenID that much though and at the end of the interview he’s still keen to publish the story but feels we need something more to explain our unique selling point.

He advises me to produce a screencast and hold back from the prescribed 9am embargo for a couple of hours until it’s ready. We finish up and I leave him with an article from Marshall Kirkpatrick highlighting the difficulties around OpenID.

4:10am: I email Chris Messina and arrange to do a screencast with him the next morning. Chris is great at explaining these things and drawing out their significance in a way that people get.

4:20am: Take a taxi back to the hotel.

5am: Bed.

Launch morning

8am: Get up and promptly field a call from Joseph Smarr at Plaxo. With tens of millions of users, Plaxo are by far our biggest launch partner and the integration is yet to go live. Joseph’s hit a couple of small bugs at our end and and works with Immad back in SF to iron them out. SF is two hours behind Austin so it’s 6:30am over there and we’ve still got a bit of time before the 9am PST publication embargo.

At this stage I’m still expecting TechCrunch to hold the article until 11, when they get the screencast, and assume we’ve probably got a couple of extra hours more on top.

Joseph tells me that Techcrunch is twittering our imminent launch. After 10 months of designing, documenting and building it’s hard to believe it’s all really happening.

9:30am: SXSW convention center — I find a table and start testing all of the partner sites making sure everything is doing what it should be doing. Immad is doing the same back in San Francisco. David our designer is producing a “We’ll be back soon” page in case anything goes wrong.

Plaxo has pushed their code live and our little button is now on the bottom of their site. Nobody can see it until we drop our beta-cookie, but it’s there, and ready to switch on for their 40M users.

Disqus.com is looking good. Simon Willison’s Django OpenID libraries are blazing fast and Hacker News is now back to normal loading time. Plaxo is as fast as ever.

10:30am: With everything looking good I start getting to grips with the screencast software and mail Chris to fix up a place to meet.

11:25am: As I shut my Mac and go to do the screencast I happen to glance at TechCrunch. We’re on. Top story. No comments. It seems Marshall’s OpenID critique hit the spot. It’s an incredible review — everything we could have hoped for. Fantastic, except that we didn’t expect this for another two hours and the site’s still behind a password!

11:25am 10s: I call San Francisco: “Immad, we’re live, TechCrunch just published the story — let’s push!”

11:25am and 30s: <ping> Aral Balkan twitters that he can’t see the site — how do people find these things out so quickly?!

11:26am: Immad, as fast as ever, IM’s to say that everything’s live. Clickpass is go.

11:37am: An email arrives kindly offering to sell me Clickpass.cn. Un. Believable. I start buying other countries.

11:40am: Joseph publishes a great post about us on the Plaxo blog. I can’t help feeling a flush of pride.

11:50am: 50 new registrations on the site. Congratulatory emails and twitters start coming in. We’re the top story on Hacker News.

2pm: 300 registrations. The traffic is ramping up but thanks to Martin, our sys-admin, the servers don’t even blink at the extra load.

2:40pm: I call Immad and David back in the office. Everyone is excited and so far, everything’s holding strong. I tell the guys that there’s a bottle of champagne waiting for them in the bottom of the fridge.

3pm: <ping> — twitters keep coming in. I didn’t use Twitter much before SXSW but am amazed at what an incredible realtime snapshot it gives of the early-adopter web. Most are positive but a couple of people don’t really get what we’re doing. There’s clearly still work to be done.

3:30pm: An email comes in from one of our new users asking if they can join the company.

3:40pm: And another.

4pm: We make it onto Techmeme and one of our new users has already written a brilliant blog post about us.

5pm: 600 registrations. The adrenaline is starting to wear off and I suddenly feel exhausted. Draft an email to investors to bring them up to speed and realise that we haven’t even emailed our pre-launch list to tell them we’re live yet.

Lock-down

5:30pm: We haven’t set up our email marketing software yet so after writing up an email of the day’s events, I check, double-check and check again that I’ve put 1000 email addresses into the BCC and not the CC field on GMail.

GMail won’t take 1,000 emails at a time so I split them down into chunks. First chunk — okay. Second chunk — okay.

Write an email to another friend thanking them for their support. Send.

“GMail has detected an unusually high volume of mails being sent from this account. Access to your account will be frozen for the next 24 hours”. Bugger.

5:40pm: Phone a friend at Google. Fingers crossed.

6:10:pm: Hurrah — email back on. Silicon Valley is crazy-connected.

6:30pm: All of my electronics are about to die. MacBook is flat and hard-disk is starting to make strange, not-good, marble-on-a-stone-floor sounds and won’t sleep. iPhone has enough juice left to take a call from Joseph suggesting dinner. I catch up with him and John McCrea and we dissect the day’s events over Guinness and burgers. It’s a great evening and when they head back to their hotels I peal off to join the obscenely long queue for the Digg party.

10pm: Immad calls and we review everything. We’ve got a couple of glitches in some of the ancillary features but the whole core has been as solid as a rock. He’s an incredible developer and together with David’s design skills the product hasn’t just pleased us but also, it seems, our users too. We’re on track to hit 1,000 registrations in the first 24 hours and loads of people are installing the Wordpress plugin. We agree it was a good day.

The next fortnight

The first couple of weeks have been a bit of a blur of emails, investor meetings and bug fixes. They’ve also revealed a ton of work still to do. The concept of password-less single sign-on is totally alien to most people and Clickpass doesn’t yet do enough to explain things.

We did a lot of work to make sure we didn’t contradict the decentralised ideals of OpenID and that people can still use their existing OpenID’s with us. Even so, feedback and reviews have highlighted that there are still things left we can to do to make it easier still for those who want to use pure OpenID.

Making OpenID easier is our raison d’etre. I’m pleased with just how much we’ve done for users but we’ve now got to turn our efforts to developers. Installing OpenID isn’t too difficult but it’s intimidating and we need to change that. Over the coming weeks and months we’re going to be releasing both libraries and plugins that should start to help a lot.

Live on new sites — Ma.gnolia

We’ve also got more sites coming online and at the same time as this article is published, so is our integration with Ma.gnolia.

If you’ve not tried Ma.gnolia before it’s a beautifully designed social-bookmarking site which, like Plaxo, has also always been on the cutting edge of OpenID.

We’re really pleased that people are going to be able to use their Clickpass with it.

Celebrating the victories

There’s an undeniable cult around internet startups and a generous helping of hype. As with any other project, 99.8% of the time is spent coding, designing, documenting, answering support and making sure the finances stay sound.

When the exciting times do come though, they come thick and fast and are exhilarating and nerve-racking all at the same time. Launch was exactly like that for us and a day I won’t be forgetting anytime soon.

Image credits:

Austin is the killer app: Scott Beale/Laughing Squid: laughingsquid.com
Data Portabilty Panel: Ian Kennedy: everwas.com/
Blackberry:1 Entrepreneur: 0 : VCWear.com

After three months away in San Francisco I was recently back in London visiting friends and family. With a couple of weeks to spare I got stuck into booking dinners with old friends. I'm a big fan of the offers on Top Table and with my eye on a nice little brasserie in Hampstead I knew I had enough points to get one of my meals on the trip for free.

Or at least I thought I did, only after so many months away, I'd forgotten my password to get back in. Not only that but I'd registered with an old email address and couldn't even get the password reminder. For the want of a password, me, my page views and my commission were lost.

Usernames and passwords are everywhere. In a web that's becoming more and more specialized and mashed, where storage comes en-masse from Amazon, video from YouTube, maps from Google, presence from MyBlogLog and sharing from del.icio.us, one last feature remains awkward and local: login.

The cost of sign-up

Sign-up: one simple and ubiquitous feature that costs websites users, lots of users. France Telecom recently did extensive research on the subject and found that at every new screen presented during sign up, 50% of users give up and go elsewhere.

That makes sign-up screens a very expensive part of your website. So you've built an incredible new service and spent a fortune advertising it on Google to get maybe a thousand clickthroughs. Of those, perhaps a hundred will be impressed enough with your service to reach that critical sign up screen. Ask the user for a username and password, confirm their email and you've just lost 75 of them.

The simple act of sign-up just multiplied your customer acquisition cost by a factor of four. Getting rid of the process would make your advertising a staggering four times more effective.

Even once the user has finally signed-up the login screen will continue to haunt both them and you. Up to 80% of calls to help desks are from users requesting password resets and every one costs an average of $30 to process.

The pain of sign up and login is both extensive and expensive. In the last two years though, a protocol has emerged to address it, a protocol which shows the early glimmers of even being able to solve it: OpenID.

OpenID, the HTML of identity

In 1990, Tim Berners Lee made the enormous simplification that most information people needed to access could be encoded into plain old HTML. “Information” is as broad a category of data as you can get though and can be encoded in lots of different formats: xml, pdf, jpg and plaintext being just some of them. In making that one extreme simplification though, Tim Berners Lee nailed the core of the problem and laid the foundations for the depth and complexity of the web that exists today.

Two years ago, Brad Fitzpatrick of Six Apart made the same simplification for identity. Identity is a complex and amorphous beast. Who are you, what qualifications do you have, who can verify them and how can I trust them? What's your reputation, who are your friends and are you really my second cousin once removed?

These are very difficult questions to structure and answer programatically and, like document encoding, too difficult to solve in one fell swoop. Brad proposed a solution to a different and far simpler question — are you the same user who was at my site last week?

Remember me … forever

At its core, all OpenID cares about is telling a website that you're the same person, the same user you were last time you visited them. It's a bit like a cookie you carry around with you and drop into any machine you're using — “remember me forever”. OpenID gives you, the website owner, the opportunity to personalize and customize your content to more users more of the time.

How it works

In essence, OpenID allows one website to piggy-back off an authenticated session from another website. I log into my OpenID provider (e.g. Clickpass.com, the startup I founded), pick up my OpenID URL and create a session there. When I want to use another site (e.g. 37 Signals' Basecamp), instead of giving them my username and password, I give them my OpenID URL.

Basecamp then has a quick word with Clickpass and asks whether I've got an authenticated session already set up. If I have, it logs me in to Basecamp and creates a new authenticated session for itself and if not, it sends me back to Clickpass to log in.

The WWW cloakroom attendant

You can imagine OpenID to be a little like the tickets a cloakroom attendant uses. When you leave your coat in the cloakroom of a nightclub they tear a ticket out of their book, pin one half to the coat and give the other half to you. When you want your coat back you give them your half of the ticket, they find the coat that matches it and give it back to you.

OpenID does exactly the same thing with a website. You go to a website, and give them a copy of your OpenID URL which they then pin to your account. Next time you come back, you flash them your OpenID, they look up the account that corresponds to it, do a quick check to make sure you really are the owner and then let you in.

Your user or mine?

So if OpenID is logging the user into your site then who exactly owns them? Is that user ultimately a user of the OpenID provider or the website itself.

A good place to look for the answer to this is Evite.com. One of the reasons Evite became so successful is that it didn't require people to create accounts in order to see their invitations. Clicking on a personalized link sent to you in an Evite email is proof that you own the email address and logs you directly into Evite.

Evite piggy-backs off the authentication from your email account. Nonetheless, it's clear that it is Evite, rather than Hotmail or GMail, that owns the user. In the same way as Evite piggy backs off email, OpenID lets you to piggy back off the OpenID provider's session and at the same time retain ownership of your user. The data that they enter at your site is something that is between you and them and nothing to do with the OpenID provider.

The possibilities

The consequences of reducing the barrier to account creation and login at websites are hard to understate. Users' resistance to signing up to your service falls, the number of users returning to it increases and the amount of time you have to spend reminding them how to do so plummets.

With one account logging them into so many places, the user can also now afford to bring more than just a new username and password to your site and you can afford to demand more. At the same time as lowering the barrier to legitimate users, OpenID raises the barrier to your unwanted visitors.

People are exhausted by having to prove themselves again and again to every new site they visit. OpenID opens the door to portable identity and to them accumulating reputation and credibility which can then be reused elsewhere just as they reuse their EBay reputation on auctions. Portable identity and credibility is, in turn, the key to demanding more proof from your visitors that they are who they say they are and in turn reducing chargebacks, fraud and spam.

One ring to bind them all … and lose them?

With one account to store everything in, many people's first reaction is that they now have one place from which to lose everything. Crack your OpenID provider and you crack every other site. Being able to get into all sites using one password is undeniably attractive but is it worth it if it lets someone else in too?

Today's access-all-areas: email

The irony is that we already face the threat of the latter without any of the convenience of the former. Ever forgotten your password? How did you get it back? Did you perhaps click the password reminder button?

Almost every account you have across the web can be accessed using your email account. As soon as someone has your email account they have the key to your other accounts.

Since over a third of users use the same username and password everywhere, the problem is actually far worse than this as they inadvertently grant access to their email account to each new service they sign up to. I ask for your username, password and email address when you sign up to WinAnotherIPod.com and you give me the same one you use for your email provider and Paypal.

Today's user has all of the risks associated with a centralized login and none of the benefits.

OpenID and phishing

Just like Paypal and Google Checkout, OpenID is a protocol vulnerable to phishing attacks. Click on a subversive Google Checkout link, enter your Google login details onto a phisher's website and you've given away your Google account and payment details. Click on a Paypal button that connects to a bogus storefront and you accidentally give away your Paypal username and password.

OpenID can be attacked in exactly the same way. Arrive at an OpenID enabled website without being logged in and you'll be redirected to your OpenID provider to do so. Don't look too carefully at the URL of that login page and you might accidentally find you've given your details to someone you didn't mean to.

There are various ways of making it far more difficult for this to happen and some that make it almost impossible. At their best, OpenID services like Clickpass.com make a user far more secure than they are using conventional logins and do so across all the sites the user visits.

Make yourself small

The last point is very important because when it comes to being attacked, it's always easier to defend a smaller area than a larger one. If spiders and aliens are descending on you in a computer game (or indeed in real life) you get your back against the wall. Leave the keys to your house under every pot in the garden and they're more likely to be found than if you leave them under just one.

Web users today defend their security and their privacy on lots of fronts simultaneously. For people who use the same password everywhere, every new account is a new place for it to be compromised, every new place you enter your details is another place they can be stolen from.

With only one account to log themselves into, user can afford to be more careful about how they do it They can use email authentication, SMS confirmations and even RSA key-fobs to secure that OpenID account and, by association, every other account that it links to. The power of single sign on means that the heightened level of authentication can now be re-used and re-demanded across the user's entire network of sites.

So where is it?

It would seem like OpenID is the the wonder-drug of the internet. With the power to decrease password reset requests, spam and fraud and the ability to increase conversion rates, user loyalty and security it seems almost too good to be true. Today unfortunately it still is.

OpenID is fully functional but still raw and too tricky for the average internet user to be able to understand. Even as I write though there is change afoot. Various startups and initiatives, including the OpenID specs themselves, are filling in the gaps and rounding off the corners.

The user experience isn't yet finally complete but with people like Verisign, Vidoop and our team at Clickpass working on solving the remaining parts of the puzzle, the future for OpenID looks very, very promising.

Fluxiom is one of those web apps you seem to keep bumping into. It was first glimpsed back in November when the demo trailer was released and put up on Digg. Humming with a slinky jazz soundtrack and oozing shiny surfaces and fade effects, the two-minute teaser did everything to get our juices flowing so, when the possibility of an account dropped through our door we were happy to test it out.

What is it used for?

Fluxiom is a digital asset manager. So if you’re working from home, from the office, or in collaboration with a team, you’ll probably find a use for it. If you find yourself emailing documents here there and everywhere in a bid to stay up-to-date, then you’re sure to find Fluxiom useful. Simply upload the files, fire up your web-browser and they’ll follow you from machine to machine like a lovesick puppy.

The User Interface

The user interface is mouth-wateringly pretty. Once logged on, it’s hard to pay attention to anything other than just how utterly gorgeous the UI is. It’s universally adored wherever it goes too. At a sneak preview back in December there were actually gasps when it first went up on screen.

Tagging, uploading, downloading and sharing are only a slide-out-panel away and both fast and easy to use. Users and permissions are managed on a separate screen and asset previews are displayed in a scalable popup window.

Technical analysis

Cross-browser performance is very impressive. Much of Fluxiom is built on Script.aculo.us which itself is built on Prototype and the different frameworks really deliver.

We tested Fluxiom on IE6, Firefox 1.07 – Windows/Mac and on Safari and found no perceivable difference in look or performance across any of them. Anyone worrying about a Mac-bias has nothing to fear.

Download times are quick and initial startup takes about 5-10 seconds across a 500k connection. Memory usage is pretty much the same as other web apps. On our XP machine, Firefox 1.07 ticks over on about 21Mb of RAM and goes up to 35Mb after loading Fluxiom. GMail by comparison works at 32Mb.

The layout is clear and uncluttered although the fonts seem too small, making it difficult to read the text. Increasing the text size in Firefox didn’t seem to do much to rectify this.

The app will unpack a zip file upload although you can burn quite a lot of server time during the process. Full text search through Word documents, Excel files and PDF’s is also very impressive and worked quickly on the few files tested.

The Features

Uploading and Downloading

It’s a bit frustrating that you can only upload one file at a time. In order for Fluxiom to really fly, it’ll need some sort of drag-and-drop uploader tool. Also, we couldn’t figure out how to use the Tags functionality. This is either because it’s in Beta (and not finished), or because it’s not intuitive – it’s hard to tell at this stage. However, once you start your upload, the progress bar is quite handy.

Downloading is very simple. All you have to do is select the files you’d like to download, and click “Download”. If you select more than one file, it zips them up into one file for download.

Drag Selection

This is by far one of the most amazing usability features that Fluxiom has to offer. If you want to select multiple files, you simple click and drag, as you would on your desktop. We’ve never seen this on a web app before, and it is quite an achievement.

Sharing

Fluxiom makes it really easy to share your digital assets with others. All you have to do is select the files you want to share, click “Share”, type in an email address and choose from three options:

1. Send link – Send a password and a link to download a .zip archive of the assets
2. Send attachments – Send an email with the assets as file attachments
3. Use my email client – Open a new email in my local email app with a password and a download link

RSS Feed

Fluxiom allows you to subscribe to a global RSS feed for your digital assets. Whenever someone adds a file, your RSS feed gets updated. This is super useful, but we think this feature would be much better if the RSS posts included a URL to download the file.

Previewing Assets

Fluxiom has a nice feature for looking at your image files. Simply select the file, and click “Preview”. It opens up a new window with the file displayed, and some brief file info. The coolest thing about this feature is that you can resize the window and it dynamically resizes the image, to fit inside the window – nice touch.

The Highlights

Judged against traditional web-applications, Fluxiom is very fast.. There is almost never any page refreshing and despite actions feeling occasionally sluggish, they are nonetheless lightning fast compared to a page refresh.

The use of AJAX in Fluxiom is a real bonus – not so much because it makes it quicker (which it does) but because it makes the experience much more pleasant. With critical functionality only a slide-out away it is far easier to get things done than in traditional cluttered web pages.

Traditional apps often cram so much into a page that it’s hard to think, let alone work. Fluxiom uses AJAX brilliantly to keep such tools discretely stowed until the moment they’re required.

The Lowlights

Although the UI is always intuitive, it can be a little confusing on the functionality side of things. The filtering buttons are unhelpful and often make you unsure of exactly what you’ve done at any given time.

The steps required to tag an asset are easy but not obvious and the drag and drop addition of editing privileges to users is unintuitive and somewhat gratuitous.

The asset window needs occasional refreshing, however, it’s not clear when you should do this. This is something that you’d expect to be automatic rather than user-driven.

Conclusions

The true test of any application is how well it does the job. How much easier does it make your work? Someone using the software long term can only really give the answers and on a day-to-day basis as this is where Fluxiom will come into its own.

As a web application in its own right though, Fluxiom is a knockout. It works across all the major browsers, is responsive, incredibly pretty and leagues ahead of traditional form-driven interfaces.

Pitted against other web apps, Fluxiom is a real winner. It occasionally suffers from being slightly difficult to use, in some respects, but far less so than any other web app. At the end of the day, its speed and beauty far outweigh any of the niggles.

Rating

• Software name: Fluxiom
• Maker: Wollzelle
• Price: Starts at 9 Euros per month
• Rating: 4 out of 5