This week in video: Facebook and the OpenID Design Workshop

http://www.viddler.com/player/423b8f4b/

Needless to say, it’s been a big week for the open web, with Facebook joining the OpenID Foundation and hosting an OpenID Design Workshop.

Above is the latest episode of theSocialWeb.tv called “An Open Discussion with Facebook”, filmed yesterday on location at Plaxo. John, Joseph and I talk about the week’s news with Dave Morin and Luke Shepard of Facebook, going into some detail about Facebook’s new emphasis on their open strategy.

OpenID Design Workshop

I also recorded a bunch of video from the OpenID Design Workshop (which John McCrea did a great job liveblogging):

video preview

OpenID Design Workshop Introductions

Luke Shepard and Dave Morin introduce the schedule for the day; individual attendee introductions.

video preview

Julie Zhou from Facebook presents on Facebook Connect

Julie presents the design thinking behind Facebook Connect. Slides.

video preview

Max Engel presents MySpace usability research

Max presents usability findings from research on connecting MySpace to other sites, like AOL. Slides.

video preview

Brian Ellin presents RPX and the history of OpenID interfaces

A look at the history of OpenID interfaces, with insights into what people type “into the box”. Slides.

video preview

Eric Sachs and Brian Kromrey present on federated login research/popup

Eric Sachs and Brian Kromrey talk about their work implementing OpenID and present the new popup flow. Slides.

video preview

Chris Messina presents on OpenID Contexts

I present on using OpenID in different contexts. Slides.

video preview

OpenID Provider Report Back

The results of the 2-hour OP breakout session.

video preview

OpenID Relying Party Report Back

The results of the 2-hour RP breakout session.

Jelly Talks

And there’s now video available from the conversation I had last week with Dave Morin on the inaugural episode of Jelly Talks:

Part 1: Facebook Connect & OpenID

http://d.yimg.com/cosmos.bcst.yahoo.com/up/fop/embedflv/swf/fop.swf

Part 2: Facebook Connect & OpenID – A Community Effort

http://d.yimg.com/cosmos.bcst.yahoo.com/up/fop/embedflv/swf/fop.swf

Part 3: Facebook Connect & OpenID – User Experience

http://d.yimg.com/cosmos.bcst.yahoo.com/up/fop/embedflv/swf/fop.swf

Part 4: Facebook Connect & OpenID – Q & A

http://d.yimg.com/m/up/fop/embedflv/swf/fop.swf

Welcoming Facebook to the OpenID Foundation

Facebook logoThe day after Facebook’s 5th birthday, I join David Recordon and the rest of the board of the OpenID Foundation in welcoming Facebook as our newest member, in rapid succession to Paypal just a few weeks ago. The significance of both of these companies investing in and becoming part of the OpenID family can not be understated.

I’m particularly excited that Facebook has joined after the conversation that Dave Morin and I had last Friday during our Jelly Talk. Dave and I were in vehement agreement about a lot of things, and tantamount was the need for the user experience of OpenID authentication to improve.

The crux of the issue is that with OpenID, choice is baked in, which is a good thing for the marketplace and ultimately a good thing for users. The problem is how this choice manifests itself in interfaces.

Facebook Connect is simple because there is no choice: you click a button. Of course, that button only works for the growing subset of the web who have Facebook accounts and want to share their Facebook identity with the web site displaying the button, but that’s why their experience trumps that of OpenID’s. If you take away user choice, everything becomes simple.

But I believe that we can do better than that, and that we can arrive at a satisfying user experience for OpenID that doesn’t necessarily have to dispense with choice. And from the sound of our conversation on Friday, and with Facebook’s membership in the OpenID Foundation, I believe that we now have a mandate to confront this challenge head-on, as a top priority.

To that end, Facebook will be hosting the second User Experience Summit for OpenID on February 10th. The goal is to convene some of the best designers that leading internet companies can muster, and bring them together to develop a series of guidelines, best practices, iterations, and interfaces for making OpenID not just suck less, but become a great experience (in same vein as the hybrid OpenID/OAuth flow that we saw from Plaxo and Google last week, and in line with Luke Shepard’s proposals for an OpenID popup).

Although Facebook has not announced any plans for implementing OpenID specificly, their commitment to help improve the user experience suggests to me that it’s only a matter of time before all of the major social networks, in some way, support OpenID. If there were any lingering doubts about the competition between Facebook Connect and OpenID, hopefully the outcome of a successful collaboration will put them to rest.

Twitter and the Password Anti-Pattern

Twitter / Alex Payne: @factoryjoe Yes, OAuth is ...

I’ve written about the password anti-pattern before, and have, with regards to Twitter, advocated for the adoption of some form of delegated authentication solution for some while.

It’s not as if Twitter or lead developer Alex Payne aren’t aware of the need for such a solution (in fact, it’s not only been publicly recognized (and is Issue #2 in their API issue queue), but the solution will be available as part of a “beta” program shortly). The problem is that it’s taken so long for Twitter’s “password anti-pattern” problem to get the proper attention that it deserves (Twitter acknowledged that they were moving to OAuth last August) that unsuspecting Twitter users have now exposed themselves (i.e. Twitter credentials) to the kind of threat we knew was there all along.

This isn’t the first time either, and it probably won’t be the last, at least until Twitter changes the way third party services access user accounts.

Rather than focus on Twply (which others have done, and whose evidence still lingers), I thought I’d talk about why this is an important problem, what solutions are available, why Twitter hasn’t adopted them and then look at what should happen here.
Continue reading “Twitter and the Password Anti-Pattern”

On invite-only betas

Fred Wilson wrote about the value of blogging and building social capital, demonstrated by the hundred requests for invites he received on his post on his recent investment, Boxee, an invite-only service.

Now, while I find the behavior of public invite-requesting curious, I understand it.

I also think there’s another side to this equation that I’d like to point out, being one of the fortunate early adopters who happens to get invited to a lot of early alphas and betas… and that’s understanding the relationship between the creator of the beta and the testers. Or, to put it another way, requesting an invite to a service for one’s own benefit is one thing; understanding that an invite is a privilege given in exchange for feedback and suggestions provided is another. And the secret to getting early access to beta programs is, perhaps obviously, to be a good beta tester.

There are any number of ways to demonstrate that you’re worthy of an invite to an invite-only alpha or beta program. One problem is that a lot of beta feedback is submitted privately, outside of public forums. Whenever I can, I attempt to use more public forums, both for my own recollection, but also for the benefit or other testers, developers and later users.

In other cases, I’ll use Flickr or Twitter, leading to interesting phenomena, similar to what Fred describes.

SpotifyIn particular, I’ve been alpha testing a music player called Spotify for some time. It’s an incredible service and recently opened up with three levels of service, although it’s sadly not available in the US yet owing to licensing issues. Now, the only way to get an account with the service is to request an invitation.

It just so happens that I screenshotted an element of the new interface, uploaded it to Flickr and titled the photo “Spotify Invites“. That photo is now the second result for that phrase on Google and people have noticed, quickly exhausting my supply of invites.

The problem with this scenario, and with Fred’s, is that many folks seem eager to get access solely for their own benefit, without thought to the quid pro quo that makes beta programs successful (and ultimately benefit both the developer and subsequent users!). And I think it’s worth it to point out that beta programs aren’t just freebie give-aways: the gate is there for a reason!

I wrote this post in 2005, back when Gmail was an invite-only service (!!) and I was thinking about the relationships we were attempting to cultivate with the Flock alpha tester program:

So what of all these invite-only (or formally invite-only) services where you have to know someone on the inside to get a golden ticket? Does it artificially increase desire? Does it help services grow organically and cut down on trolls and spam, creating more value for invitees? Does it create more investment from the user community and perhaps establish even minor connections between invitor and invitee? Or does it create a false hierarchy around an inner circle of well-connected geeks?

Who knows?

What I do know is that it’s a curious trend and happening rather profusely across the web. Good or bad? I can’t quite say — except that in the case of Flock, we’re using the invite system to start out slowly on purpose. We want to not only be able to scale up organically, but we also want to cultivate relationships with our brave early adopters so that we can build the best experience possible over time. And to that end — we want to make sure that when we do launch publicly, we’ve hammered out all the glaring issues — as well as minor ones — so that sum total Flock makes you more productive, more explorative, and more voraciously social on the web. So for now, Flock will remain available to few kindred souls with enough courage to shove through our bugs and dodge the sharp edges. In the meantime, do add yourself to our invite lottery so that your name will be there when the next round of invites go out.

Not much has changed in terms of the structure of invite-only betas (even though the tools for managing them have improved), but I think something of the intimacy and purpose of these programs have been missed as more of the mainstream have gotten used to handing out just their email address for access to such initiatives.

As Fred points out that there’s value in building up social capital so that you can help stoke interest in new projects and draw the interest of potentially valuable contributors and testers, but it’s just as important to highlight the value of diligent and hard-working testers who have an interest in improving products and becoming partners in the potential success of such projects. I think there’s the potential for mutually reinforcing and ongoing relationships in the execution of a productive beta program, and that those longer-term relationships should not be overlooked.

. . .

To that end, I’m looking for some highly motivated and qualified testers for , Real Mac Software’s new webpage screenshot utility. Be one of the first ten to leave a comment with your proper email address and a description of how you approach beta testing and I’ll send you info on where you can sign up. As I’m eager to see LittleSnapper mature, I won’t settle for just anyone — prove to me that you’d add value to the alpha tester program! 😉

The OpenID mobile experience

Two days ago, Ma.gnolia launched their mobile version, and it’s pretty awesome (disclosure: Ma.gnolia is a former client and current friend/partner of Citizen Agency).

In the course of development, Larry asked me what he thought he should do about adding OpenID sign-in to the mobile version. He was reluctant to do so because, he reasoned, the experience of logging in sucks, not just because of the OpenID round-trip dance, but because most identity providers don’t actually support a mobile-friendly interface.

Indeed, if you take a look at the flow from the Ma.gnolia mobile UI to my OpenID provider (using the iPhone simulator app), you can see that it does suck.

Mobile Ma.gnoliaiPhoney OpenID Verification

I strongly encourage Larry to go ahead and add OpenID even if the flow isn’t ideal. As it is, you can sign up to Ma.gnolia with only an OpenID (without a need for creating yet another username and password) and so without offering this login option, the mobile site would be off-limits to folks in this situation.

So there’s clearly an opportunity here, and I’m hoping that out of OpenIDDevCamp today, we can start to develop some best practices and interface guidelines for OpenID providers for the mobile flow (not to mention more generally).

If you’ve seen a good example of an OpenID (or roundtrip authentication flow) for mobile, leave a comment here and let me know. It’s hard to get screenshots of this stuff, so any pointers would be appreciated!

The problem with open source design

I’ve probably said it before, and will say it again, and I’m also sure that I’m not the first, or the last to make this point, but I have yet to see an example of an open source design process that has worked.

Indeed, I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.

Call me elitist in this one aspect, but with all due respect to code artistes, it’s quite clear whether a function computes or not; the same quantifiable measures simply do not exist for design and that critical lack of objective review means that design is a form of Art, and its execution should be treated as such.
Continue reading “The problem with open source design”

Making the most of hashtags

#hashtags logoA couple of days ago a new site called Hashtags.org was launched by Cody Marx Bailey and Aaron Farnham, two ambitious college students folks from Bryan & College Station, Texas.

I wanted to take a moment to comment on its arrival and also suggest a slight modification to the purpose and use of hashtags, now that we have a service for making visible this kind of metadata.

First of all, if you’re unfamiliar with hashtags or why people might be prepending words in their tweets with hash symbols (#), read Groups for Twitter; or A Proposal for Twitter Tag Channels to get caught up on where this idea came from.

You should note two things: first, when I made my initial proposal, Twitter didn’t have the track feature; second, I was looking to solve some pretty specific problems, largely related to groupings and to filtering and to amplifying intent (i.e. when making generic statements, appending an additional tag or two might help others better understand your intent). For consistency, my initial proposal required that all important terms be prefixed with the hash, despite how ugly this makes individual updates look. The idea was that, I’d try it out, see how it worked, and if someone built something off of it, or other people adopted the convention, I could decide if the hassle and ugliness were ultimately worth it. A short time after I published my proposal, the track feature launched and obviated parts of my proposal.

Though the track feature provided a means for following explicit information, there was still no official means to add additional information, whether for later recall purposes or to help provide more context for a specific update. And since Twitter currently reformats long links as meaningless TinyURLs, it’s nice to be able to provide folks with a hint about the content at the end of the link. On top of those benefits, hashtags provide a mechanism for leveraging Twitter’s tracking functionality even if your update doesn’t include a specific keyword by itself.

Now, I’ll grant you that a lot of this is esoteric. Especially given that Twitter is predicated on answering the base question “what are you doing?” I mean, a lot of this hashtag stuff is gravy, but for those who use it, it could provide a great deal of value, just like the community-driven @reply convention.

Moreover, we’ve already seen some really compelling and unanticipated uses of hashtags on Twitter — in particular the use of the hashtag as a common means for identifying information related to the San Diego fires.

And that’s really just the beginning. With a service like Tweeterboard providing even more interesting and contextual social statistics, it won’t be long before you’ll be able to discover people who talk about similar topics or ideas that you might enjoy following. And now, with Hashtags.org, trends in the frequency of certain topics will become all the more visible and quantifiable.

BUT, there is a limit here, and just because we can add all this fancy value on top of the blogosphere’s central intelligence system doesn’t mean that our first attempt at doing so is the best way to do it, or that we should definitely do it at all, especially if it comes at a high cost (perceived or real) to other users of the system.

Already it’s been made clear to me that the use of hashtags can be annoying, adding more noise than value. Some people just don’t like how they look. Still others feel that they encumber a simple communication system that should do one thing and one thing well, secondary uses be damned if they don’t blend with the how the system is generally used. This isn’t del.icio.us or Ma.gnolia after all.

And these points are all valid and well taken, but I think there’s some middle ground here. Used sparingly, respectfully and in appropriate measure, I think that the value generated from the use of hashtags is substantial enough to warrant their continued use, and it isn’t just hashtags.org that suggests this to me. In fact, I think hashtags.org, in the short term, might do more damage than good, if only because it means people will have to compose messages in unnatural ways to take advantage of the service, and this is never the way to design good software (sorry guys, but I think there’s room to improve the basic track feature yet).

In fact, with the release of the track feature, it became clear that every word used in a post is important and holds value (something that both Jack and Blaine noted in our early discussions). But it’s also true that without certain keywords present in a post, the track feature is useless. In this case in particular, where they provide additional context, I think hashtags serve a purpose. Consider this:

“Tara really rocked that presentation!”

versus:

“Tara really rocked that presentation! #barcampblock”

In the latter example, the presence of the hashtag provides two explicit benefits: first, anyone tracking “barcampblock” will get the update, and second, those who don’t know where Tara is presenting will be clued into the context of the post.

In another example:

“300,000 people evacuated in San Diego county now.”

versus

“#sandiegofire: 300,000 people evacuated in San Diego county now.”

Again, the two benefits are present here, demonstrating the value of concatenated hashtags where using the space-separated phrase “San Diego” would not have been caught by the track feature.

What I don’t think is as useful as when I first made my proposal (pre-tracking) is calling out specific words in a post for emphasis (unless you’re referring to a place or airport, but that’s mostly personal preference). For example, revising my previous proposal, I think that this approach is now gratuitous:

“Eating #popcorn at #Batman in #IMAX.”

Removing the hashes doesn’t actually reduce the meaning of this post, nor does it affect the tracking feature. And, leaving them out makes the whole update look much better:

“Eating popcorn at Batman in IMAX.”

If you wanted to give your friends some idea of where you are, it might be okay to use:

“Eating popcorn at Batman in IMAX at #Leows.”

…but even still, the hash is not wholly necessary, if only to help denote some specialness to the term “Leows”.

So, with that, I’m thrilled to see hashtags.org get off the ground, but it’s use should not interfere with the conventional use of Twitter. As well, they provide additional value when used conservatively, at least until there is a better way to insert metadata into a post.

As with most technology development, it’s best to iterate quickly, try a bunch of things (rather than just talk about them) and see what actually sticks. In the case of hashtags, I think we’re gradually getting to a pretty clear and useful application of the idea, if not the perfect implementation so far. Anyway, this kind of “conversational development” that allows the best approach to emerge over time while smoothing out the rough edges of an original idea seems to be a pretty effective way to go about making change, and it’s promising to see efforts like hashtags.org take a simple — if not controversial — proposal, and push it forward yet another step.

WP-Imagefit proportionally resizes images to fit your blog template

I’m happy to announce the release of my second ever WordPress plugin called . (My first, which I’ve neglected for sometime, is called WP-Microformatted-Blogroll).

WP-Imagefit is extremely simple and serves one purpose: to get images in blog posts to fit inside the columns that contain them. In fact, this plugin is used on this blog, so if you see ever images load wider than the column and then quickly snap to fit the container’s width, it’s this plugin that’s doing that.

I originally discovered this trick thanks to Oliver Boermans‘ NetNewsWire Ollicle Reflex style. Working together, he extracted the resizing code into a jQuery plugin called jquery.imagefit.js and made it available to me for use in my EasyReader NetNewsWire theme.

I had hacked it to work for my blog theme but decided that I should turn it into a WordPress plugin so I could use it elsewhere (and given that CSS’s max-width attribute not only wasn’t cross-browser, but also shrunk images horizontally, I needed a better solution). So, there you have it.

Go ahead and download it. Installation and setup is standard as long as you have an -compliant theme like K2 or .

I have a WordPress.org project page setup, the source is available (released under GPL), and if you want something to look at it, here’s the official homepage.

Feedback/feature requests/patches certainly appreciated and encouraged!

Coverflow for People

Address Book Coverflow v1

Ever since Apple bought Coverflow, I thought that it would make an awesome interface for browsing people. In fact, I had previously designed “people in the browser” for Flock to look something like this in the early days:

Friends Feed Reading

Of course, at the time, the design required a few things that we still lack, namely: 1) bigger default personal photos or avatars, 2) ubiquitous universal identifiers for people (this was before OpenID) 3) and free access to public data about people, typically found at the end of those identifiers.

Anyway, CoverFlow for people is something that I think could be a very powerful way of revealing “the ghosts in the machine” — across Leopard — or in interfaces generally. Imagine this kind of view showing up in Mail.app, Adium, iChat… where your friends, family and the rest get to update their own user pictures on a whim, and set their status and contact preferences in a way that visually makes sense. The new integrated Gtalk features in Gmail seem to be prioritizing your “Top 250”, so this is also something that could be added to the People Coverflow API without much trouble in order for the interface to scale accordingly. Anyone able to hack up a demo of this idea?

Apple Tablet Concept: the iPad Touch

I don’t really do much industrial design (there’s probably a good reason for that) but I couldn’t get over a niggling (though probably baseless) inkling that Apple will be coming out with a tablet this spring. I mean, if anyone can ship a tablet that’s not lame, it’ll be Apple. Besides that, there’s just too much evidence out there that suggests rather convincingly that Apple intends to put one out sooner or later (), so rather than sit around and wait, I thought I’d mockup what one of these devices might look like:

iPad Touch

Here it is with the touch keyboard:

iPad Touch Email

With a wireless keyboard:

iPad Touch with Wireless Keyboard

And with CoverFlow™:

iPad Touch Coverflow

So, there were some other ideas I had about this too that venture into the realm of pure conjecture. I mean, I could have just blogged these ideas without pictures, but I think it’s certainly more compelling with them. Anyway:

  • The OS will actually use the same OS as the iPhone. I mean why else would they invest so much in a paired down OS if they’re only going to use it on one platform? Ludicrous! Instead, this device will basically be a glorified iPhone, just 2.5x the size. Here’s the kicker <wild conjecture>: the iPhone SDK was delayed in order for 1) Leopard to come out (so you wouldn’t write Tiger-apps for the iPhone) and 2) because this device will launch at MacWorld, and the iPhone SDK will work for the Apple iPad Touch as well.</wild conjecture> Pretty clever eh?
  • Just like the name implies, and just like its cousin the , this device is all about tactile user interface. There’s no solid state keyboard on this bad boy. Instead, it’s a pure software keyboard, able to be gloriously adapted and regiggered to fit the task at hand, or able to have key identifiers in any language imaginable. Heck, you could even have a Halo-specific keyboard with specific buttons for each type of grenade.
  • To add an additional Minority Report-quality to this device, Apple will probably introduce their own software-driven version of the clickwheel, and it’ll probably look something like the QuickSilver constellation menus or the new Sapiens app. This interface will be necessarily for navigating around without a Dock and without having to return to the home screen. And, don’t forget how good CoverFlow looks at larger sizes.
  • Although this device wouldn’t have a CD or DVD slot, it would still be an excellent device for movie playback (for all the movies you buy from the iTunes store, of course!). Imagine being cramped in an airplane seat — no more dinky iPod Video… and no more awkward 15″ laptop. You get a perfectly mobile, conveniently flat device for even the seats with the least legroom.
  • bottom-loaderSpeaking of the lack of optical drive (well, the bottom-loader theory is interesting)… this device is all about wireless, just like the iPod Touch. Fortunately it has all the same ports as the MacBook Pro, but is only as thick as the lower part of that system, given that the screen is just a thin layer above the inner workings.
  • There’s no mouse or touch pad on this device (though you can add a mouse via Bluetooth or USB). As with the Touch series, you interact with everything directly, rather than having the traditional out-of-body pointer experience.
  • Dashboard Widgets really get their due here with a souped up WebKit rendering engine — supporting CSS animation and transforms, downloadable fonts, offline storage (for those airplane rides, again) and SVG, not to mention a lot of Core Animation goodness. And yes, with the SDK, native apps will of course be possible.
  • Losing the optical drive helped another area that rocks with this device: battery life. It’d say 12 hours without too much trouble, thanks too to converting to flash drives.

So that’s about it. Part of this exercise was just to come up with a bunch of random ideas and see what other people think or what they want from an Apple tablet. If you ask me, less is more here; I don’t want just another Windows-style tablet with all the bells and whistles. I actually like my iPhone better without third-party apps. If Apple’s going to build the Apple iPad Touch (or whatever better name they come up with), I expect nothing less than a slick, streamlined experience that feels less like a computer and more like a lifestyle object.

Oh, and one more thing. 😉

This baby will retail at $699 for 32GB and $899 for 64GB (remember, flash drives are still pricey) available immediately (well, if I were speaking at MacWorld 2008 it would be…).