5. Validation

The metadata required to use the like button looks like this:

But the property attribute isn't valid html or xhtml. The “Open” Graph Protocol says that it's inspired by Dublin Core. DC manages to get by using the name attribute like any other meta tag - why can't Open Graph? It's not the worst problem but it just seems needlessly irksome. Facebook has published a presentation describing their design decisions. This would be great, but it's in that Lessig one word per slide style and so it's attractive but completely useless without the presenter.

4. Fragility

Facebook's documentation is frustratingly sparse. For example you need to specify the owner of the page using a Facebook ID, and once you've chosen a name for your profile this is hard to find. The information vacuum has been filled with many erroneous blog posts saying to use the name, or some number from a shared photo (the best source is http://graph.facebook.com/robert.ellison, substituting your own username). Once you've got the admin ID wrong, you can't correct it - the first admin specified is fixed forever. What happens if a site is hacked and a bad actor sets themselves up as the admin? Surely something like the Google Webmaster Tools authentication scheme could have been used instead?

3. Pages with more than one object

Describing the object being liked in the head element limits you to one object per page. For some sites this is perfect, but what about a blog where you have many posts on the home page? It would be useful to have a like button per post, pointing at the permalink for the post in question. I've worked around this by having a like button for the blog on the home page, and a like button for each post on the post pages. Not ideal. I'm using the iframe version of the gadget, possibly there's some more flexibility with the XBML variant.

2. Duplicating existing pages

Let's say you've spent the past couple of years building up a Facebook page for your site/band/blog/movie and have thousands of fans. When you click your new like button for the first time you create a whole new page. There's no way to tell the like button about the existing page or the existing page about the like button. You now have at least two pages to worry about managing and potentially many, many more. You're also starting from scratch on the ‘like’ count, so even if your brand is already popular on Facebook it's back to Billy no-mates for you.

I can't believe this won't be fixed at some point. As with admin authentication above there must be a better way to establish ownership of various objects in the social graph.

1. Vocabulary

For better or worse Facebook has the inexorable pull to start making the semantic web a reality. Given this, and that there are something like twenty-four thousand verbs in the English language it's time for more expressiveness than ‘like’. You also can't comment on the ‘liked’ item in your stream (yet) so no clarification or discussion is possible.

--

Having said all that, if you enjoyed this post please click the ‘like’ button above ;)

Yes.

Some more color. I use Intuit's assisted payroll service, which is fantastic. You run payroll straight out of QuickBooks and Intuit handles all the tax disbursement and filing for you.

I got an email today with an attachment called securedoc.html claiming to be a message from Intuit. The idea is that you open the attachment and then login to view the message.

It really couldn't look any more like a phishing email, however I called Intuit and remarkably it's a real message. They seriously expect me to open an email attachment and provide account information. The support person at Intuit was able to read the message to me and it was just a routine acknowledgment that some tax rates had been updated.

Intuit is seriously training its customers to fall victim to phishing attacks. The right approach would be to say that a message is available and to log in to your account to retrieve it, or better still to send a message through the existing system in QuickBooks. Securedoc.htm is just begging customers to provide their account information to the bad guys.

Intuit's payroll service stores bank account information, employee Social Security numbers and other data that you really don't want to expose. If you're an Intuit Payroll customer please call and complain. If you've received one of these messages I'd also recommend forwarding it to spoof@intuit.com, their address for reporting phishing attacks.