Nick Bradbury

Are You Paying Attention to Facebook?

Way back in 2004 I wrote about how a scrappy young Google was replacing an increasingly stodgy Microsoft as the predominant tech company. A year later I wrote about how Google hoped to benefit from knowing what you're paying attention to.

These days Google is turning into the stodgy company and Facebook is the scrappy upstart. And now Facebook is the one hoping to benefit from what you're paying attention to.

Frictionless sharing is Facebook's latest attempt to find out what you're paying attention to. They want to know what sites you're visiting, what songs you're listening to, and pretty much everything else about you, so they can surface more relevant content in your newsfeed and show you more relevant ads. They also want to build a more thorough profile of you in order to enable up-and-coming features like timeline, and to open up more possibilities for those who develop apps on their platform.

But if Facebook wants to collect this information, they need to do it in a way that doesn't lead customers to believe their privacy is being violated. And based on the reaction to frictionless sharing, it appears they've failed to do that. They're gathering - and exposing - all this attention data in way that scares an awful lot of people and will surely invite increased government investigation. That could backfire on them in a big way (remember how diminished Microsoft was following their wrangling with the DOJ?).

All of this makes me more confident of our decision to make privacy the focus in Glassboard. When we created Glassboard, we anticipated an eventual backlash against popular social networking services that violate your privacy. And based on the news we read every day, it seems like that backlash may come even sooner than expected.

Announcing Glassboard 1.2

Last month I wrote about a beta version of Glassboard which included a handy "invitation code" feature which makes it much easier for others to join your private boards.

Well, it's out of beta now - you can get it from the Android Market and the iPhone App Store.

If you'd like to find out more about this release, stop by the Glassboard Blog for details.

In Defense of Android's Hardware Buttons

Lately I've seen a few posts criticizing the Android hardware buttons. I get where they're coming from - especially regarding the sometimes confusing way the back button is handled - but now that I've switched to Android, these buttons are among the things that make it so hard for me to use an iPhone again.

As an Android developer, I love that I can tuck actions into the menu button instead of having to use precious screen real estate for icons that perform those actions, as iPhone developers are forced to do.

Seriously, how many iPhone developers would love to stop fretting over where to place their settings icon, or their accounts icon, or their mark all read icon, etc.? Wouldn't it be nice to have a common place to put all those things so you didn't have to clutter your UI with them?

I'm also a fan of the much-maligned Android back button. Yes, some apps intercept the back button and make it act weird. I hate that, too - which is why I don't use those apps. Those crappy apps  aside, I like having an easy, consistent way to navigate between activities and apps.

Now, by this point iPhone users may have written me off as an Android fanboy, but that's not the case. There are plenty of things the iPhone does better than Android - most importantly the iPhone wins on overall UI consistency and attention to detail. But as both a developer and an end user, the hardware buttons make Android easier and simpler for me.

The Long-Term Failure of Web APIs

Years ago, when developers such as myself started the transition away from OS-specific APIs to web APIs, we believed that doing so would empower our software and save it from the confines of the desktop.

And we were right.

But we've also learned that while web APIs enable us to tap into a wealth of data, they can only be relied upon in the short term. The expiration date of software we create has been shortened due to the whims of those who create the web APIs we rely on.

I wrote the first version of HomeSite back in 1994, and seventeen years later I can still run it on the latest version of Windows.

I created FeedDemon 1.0 in 2003, and it was the first app I wrote that relied on web APIs. Now those APIs no longer exist, and almost every version of FeedDemon since then has required massive changes due to the shifting sands of the web APIs I've relied on.

You might think you're immune to this problem if you only integrate with APIs created by large players such as Twitter, Facebook and Google. But in recent years we've seen Twitter switch to a new authentication system, Facebook deprecate FBML, and Google discontinue several APIs. All of these changes have broken, or will break, existing apps.

The end result is that developers are spending more time upgrading their software to ensure that it continues to work with web APIs they've integrated with, and less time adding the features and refinements that would really benefit their customers.

That's a long-term failure, any way you look at it.

Anti-social FeedDemon (Killing Features, Part II)

Last night the changes to Google Reader went live, and as promised, they've removed the sharing features. This means that the sharing features in FeedDemon which rely on Google Reader will eventually stop working, so I'm forced to remove them.

A few years ago I wrote about the pain and pleasure of killing features, but deleting sharing from FeedDemon has been all pain and no pleasure. Those features took a long time to create, and I relied on them every day. Seeing what my friends are sharing, and sharing back with them, has become part of my daily routine.

I don't fault the Reader team for removing those features - it makes sense for Reader to integrate more tightly with Google+. And I certainly don't fault them for eventually removing those features from their unofficial API. If anything, I want to thank them for letting developers such as myself use their API for free for so long.

But I'm surprised that the Reader team didn't make the transition to Google+ an easy one. I realize that Reader users are a dwindling bunch, and most of them never used the sharing features. But many of those who relied on sharing are influencers, including well-known tech journalists, bloggers and developers. It strikes me as a bad idea to leave these people with a sour first impression of Google+, yet that will be the result of the painful transition from Reader sharing to Google+ sharing.

As far as FeedDemon goes, in a few days I'll have a build ready which removes the sharing features. But I'm going to hold off releasing this build for a little while since sharing still works at the API level. In other words, right now you can still use the Reader sharing features in third-party apps like FeedDemon even though those features aren't available in Reader itself.

Before the end of the year, though, there will be a new FeedDemon release which does away with sharing, and every FeedDemon customer will need to upgrade. That pains me, because like every developer, I'm used to having new releases improve upon previous ones. For some this release will feel like a downgrade, and I know I'll take some heat for it since many customers won't be aware of the reasons for the loss of sharing.