Deja vu: Still wary of Facebook
Facebook Uploads
Sorry, we cannot support uploads sent via email. Upload photos from your iPhone with our free application, Facebook for iPhone:
http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=284882215&mt=8
This is the message that I now get when I try to use the Facebook feature of emailing photos to my account. For a long time, I have emailed an alias on my domain which forwards on to both Flickr and Facebook, get to get photo into both places at once.
My blog brings in these photos from Facebook using Fotobook. Now I can longer use this workflow. Instead, Facebook wants me to stop using the “open” import mechanism of SMTP, and instead wants to force me into the mobile walled garden of the Facebook app on the iPhone. Now, don’t get me wrong, the Facebook iPhone app is fantastically produced by Joe Hewitt, and I have no beef with it at all. I just don’t like being forced into one workflow which will then only work with that one provider. Facebook, by taking away a feature, changed the entire game.
Open protocols give us the ability to develop our own patterns, and tweak the implementation over time. When blogger (and others) allowed us to abstract the implementation behind DNS records, it felt better (as well as being able to export the data out).
Facebook Connect
There are advantages to the walled garden though. I have been really worried about seeing Facebook Connect buttons shown up around the Web. The UX for FB Connect is very nice indeed, which is why I was so worried. The majority of people won’t choose the Open platform purely because “they should”. Open needs to compete on its own rite.
This is why I was so pleased to see Open Connect:
We need to do this quickly, as people will only put “one” of these on, and it should be the open meta platform.
I think that there is a place for the browser to help out here too, as I have mentioned before. If you login to the browser once, and we agree on the protocols, the browser can do the handshake for us. A great UI….. none at all.
Time to “make the Web better” instead of how Facebook tries to “make a better Web”.
December 14th, 2008 at 3:51 pm
I like the idea of Open Connect, but the workflow shown in his example has a huge password anti-pattern embedded in the 3rd screen that undermines the whole point of delegated authentication.
Putting up an “OpenID plus password” dialog is missing the point of both OpenID and OAuth.
December 14th, 2008 at 4:53 pm
Yeah, the _idea_ of Open Connect is appealing, but the _execution_ of Facebook Connect is very slick – and that wins out, especially for the mainstream user. For the developer though, there’s a double-win with Facebook Connect. Not only are you delivering a good user experience (or, at least, an understandable one that wont result in a ton of user problems), but the Facebook Social graph (or more importantly, the mechanisms for getting your brand across it) is mature and well understood. In other words: Facebook Connect is unlikely to be expensive, and has the potential to deliver huge upside. In an economic environment where we’re all needing to really, really focus on bang-for-the-buck, that resonates (even if you grok the more distant win of a truly open web).
December 14th, 2008 at 5:08 pm
@Kevin
Good points. I am just glad that people are really playing with prototypes and working on the UX side of things. Still time to fix the implementation.
December 14th, 2008 at 5:10 pm
@tobias
Your comment is exactly why I am worried :) Once you implement you are adding real value to the walled garden, and it is hard to get out. For example, TechCrunch has blog content tied to FB accounts. How do they even back down from that without problems? A true open approach allows you to flip around without having that cost, and also gives users the choice to talk to your service in the manner in which they want too.
December 14th, 2008 at 5:26 pm
@Kevin – uhhh – need to follow now all your comments, to tell people that it’s NOT the password anti-pattern ;) It may look like initially like the anit-pattern, due to the seamlessly interface, but it isn’t!
Please take a look at the URLs in the top of the screens. To improve the UX I have concepted in this mockups, that the RP and Provider commit to the same UI so that it feels(!) seamlessly without interruptions. But the delegation still takes place.
The user will be delegated(!) to his OpenID provider in the screen and authenticates there! It’s no(!) anit-password pattern. Again – check the URLs int he mockups ;) :D
At the original post we already discuss the phishing problems, which still affect this and other solutions like Friend Connect + OpenID based Provider parties!
December 14th, 2008 at 8:56 pm
Are you _sure_ you were emailing your pics to Facebook? I spent a long time trying to get that working, and it turned out that (in Australia anyway) Facebook only supported multimedia messages (MMS) to an email address.
That was fairly confusing, because the doc said “send your photo to [email protected]“, but “send” in this context did NOT mean email.
Anyway.. that’s kinda ignoring the point of this post, but it’s just something which annoyed me…
December 15th, 2008 at 5:26 pm
@Nick,
Yah, it was taking in the email just fine (and uploading it to the “Mobile Uploads” folder which I then importanted here).
Then the Mobile Uploads folder kept getting rebooted and I have multiple of them, but that is another story. :)
Cheers,
Dion
December 27th, 2008 at 12:48 pm
i already have a facebook acc with over 700 friends and someone screwed with my acc and i can see it on my friends facebook so i know its not deleted can you help?