All posts tagged ‘social networks’

File Under: Social, Web Apps

ThinkUp Adds Color, Depth to Your Social Network Stats

If you’ve ever wanted to archive your social network activity, store in your own database and pull all sorts of interesting visualizations out of it, then the new ThinkUp app is what you’ve been waiting for.

ThinkUp is one part metrics app — tracking which of your posts are most popular, for example — and one part cross-network aggregator. It offers features you won’t find on Twitter or Facebook, like a detailed “conversation view” of exchanges with other users. ThinkUp also acts as a backup for your social network data, pulling it into your own database. It even offers CSV files for creating your own spreadsheets.

Since it archives all of your activity, ThinkUp is an especially useful tool for those of us who like to maintain control over our own data. It takes stuff that would otherwise only live in the various networks’ silos and copies it to a database where we’re the administrator. So if we want to ditch Twitter or Facebook in some distant future where those companies start acting against our best interests, we don’t lose the massive stores of updates, links, photos and, most importantly, friend relationships we’ve already set up. And in the meantime, it lets us have fun with all the data it’s archiving.

Although ThinkUp is still a beta release, we took the code for a spin and found it to be stable enough to be useful. At the moment, it only supports Twitter and Facebook data, but ThinkUp plans to add additional social networks in the future, including LinkedIn, Flickr, YouTube and Google Buzz. If you’d like to try out the limited beta, head over to Github and grab the code. You may notice it’s a project published by Gina Trapani, the former Lifehacker editor who is now an independent author, blogger and programmer.

Continue Reading “ThinkUp Adds Color, Depth to Your Social Network Stats” »

File Under: Social, Web Services

Flickr Hooks Up With Facebook for Photo-Sharing Love

Photo-sharing website Flickr has announced a new Facebook integration tool that syncs your Flickr photos to your Facebook account. Flickr’s sync tools are built on top of parent company Yahoo’s Updates platform, and will push photo thumbnails, titles and descriptions to your Facebook feed.

Of course, Facebook also offers way to pull in your Flickr images with RSS, as well as about a dozen third-party photo syncing apps that let you post to both services at once. If you use any of those tools, make sure you disable them before turning on Flickr’s new features, otherwise you’ll end up with duplicate photos in your new feed.

The integration of the two services is the result of a new partnership between Yahoo and Facebook announced this week. Yahoo will continue to let its visitors consume Facebook feeds on various Yahoo properties and post to the social network from its pages. Once users link their Yahoo and Facebook accounts, they’ll see news feeds from their Facebook friends on the Yahoo homepage, the web’s most popular news page, and in their inboxes in Yahoo Mail, the web’s most popular webmail service. Flickr, a powerful social network in its own right, is the next testing ground for this integration. Yahoo plans to integrate other social networks, like Twitter, this summer.

To enable the new Flickr-Facebook integration, head over to Flickr and turn on the Facebook Updates feature. Once that’s done, any new photos you post will be pushed to Facebook. By default, only photos marked public will be sent, though you can tweak the privacy settings on your Yahoo Pulse page (bet you didn’t know you had one of those, did you?).

The new Facebook support certainly makes it easy for fans of both sites to get the best of both worlds, but we’re hoping this doesn’t signal a mad rush to add dozens of sharing tools to Flickr.

Flickr, which helped popularize social photo sharing when it launched in 2004, has long been something of a lone wolf on the social web — the Share This tool on its photo pages is admirably spartan. But it’s also a great reminder that, before the isolated model of Facebook gained popularity, there was just the open web. To that end, anyone clamoring for more sharing tools on Flickr are missing the obvious — all your photos and photo collections have a unique URL attached, and you can share that anywhere you like.

See Also:

File Under: Social

Video: The Open and Social Web Explained

Embedded below is a video of the presentation Chris Messina gave at the 2010 Google I/O developer’s conference a couple of weeks ago.

Chris has been instrumental in birthing and evangelizing many of the social web’s protocols for sharing data across sites and applications (, OpenID, OAuth), and he recently went to work on these technologies at Google. Chris is a designer, not necessarily a programmer, so his presentation is light on code. But it very clearly presents the concepts behind social sharing protocols — how they work, why they’re important and how they are currently implemented across the web.

Plus, he apes Lost, and it’s funny.

See Also:

File Under: Identity, Social

Rethinking Web Logins With OpenID Connect

Even with all the support OpenID enjoys within the tech industry, it’s no secret that the identity management technology still confuses the hell out of most web users.

One of OpenID’s biggest proponents thinks part of the problem lies in the name.

Identity guru and noted open source advocate Chris Messina breaks it down in a post on his Factory City blog, where he lays out his ideas for making OpenID “both easier and sexier” for the general web audience.

Consider OpenID in the shadow of Facebook Connect, its far more successful competitor based on Facebook’s proprietary platform. Forget that Facebook is much more widely known than OpenID — the real problem is that Facebook Connect is attached to an actual thing you can log in to, a website you can visit, a company you’ve heard of.

OpenID, on the other hand, is more nebulous. Your identity… on the web… portable… everywhere… what?

Everyone knows what Facebook is, so add “Connect” to the familiar Facebook logo and most people can work out what’s probably going to happen — the site you’re using is going to connect to your Facebook account, and some information about you and your friends will be shared between the two.

OpenID lacks the brand recognition of Facebook, not just because of Facebook’s fame, but because Facebook is a website and OpenID is an abstraction.

Messina suggests adding “Connect” to OpenID so that it mirrors Facebook Connect, Twitter Connect and other sign-in systems might help. And Messina’s rebranding — the snazzy black button above — is certainly a step up from OpenID’s current logo and branding.

As for the “connect” aspect, Messina gives a layman’s definition of OpenID as “a technology that lets you use an account that you already have to sign up, sign in, and bring your profile, contacts, data, and activities with you to any compatible site on the web.”

In order to do that, however, Messina is proposing more than just a name change. He’s suggesting that OpenID be repackaged as a profile of the OAuth WRAP protocol. The idea is that OAuth WRAP could handle the actual connections between the websites sharing data and OpenID would then offer a standardized way to pass along profile data, relationships, access controls, and activities (what you’ve “liked,” “loved,” “favorited,” etc.).

So, how would that simplify OpenID for new users? For one, it would help solve the “NASCAR problem” — current implementations of OpenID often display a half-dozen or so sign-in options, and the effect is similar to the garish mish-mash of ads covering NASCAR vehicles. It’s visually and psychologically confounding.

Messina’s design would mean that, instead of an assortment of rainbow-colored logos from Yahoo, Google, Microsoft and other OpenID providers, there would simply be the singular black button above. He admits that after you click the shiny black button, the NASCAR problem might still be there on the next step — at least for now — though he does promise some additional screenshot mockups and suggests that “the browser could handle this at an earlier stage.”

See Also:

File Under: Programming, Social

Social Hosting, Good Parenting Are Keys to Open Source Success

It’s often said that you can’t kill an open source project.

The logic behind that maxim is that, as long as the source code is out there and freely available, someone will always show up to work on it, add to it, improve it. Indeed, that’s often the motivation behind releasing a project under an open source license.

One example is, the URL shortening service that shut down temporarily, but whose code is now open source. Another is OpenTape, a clone of the popular (and long gone) Muxtape music streaming app. Both released into the wild after the original developers became overwhelmed in the hopes that someone, anyone, would keep those projects alive. Whether or not the community actually forms around the release is irrelevant. The point is that it could.

But what do you do when an ostensibly open source project lacks support from its creators, and it becomes nearly impossible for the community to contribute? That’s the question programmer Jeff Atwood raised in a blog post Tuesday regarding John Gruber’s Markdown software.

Markdown is a text-to-HTML conversion tool which allows you to write web code using an easy-to-understand plain text format. Markdown text is then converted to structurally valid XHTML (or HTML). Markdown is used all over the web — it’s even understood by the content fields and comment forms within most popular blogging platforms, including WordPress and Movable Type. It’s been ported to Python, Ruby, PHP and other popular languages.

However, the original Perl script has remained largely unchanged since its release in 2004. In his post, Atwood takes Gruber to task for what Atwood calls “bad parenting,” an indictment of Markdown’s lack of bug fixes, updates and improvements.

Markdown was released under a BSD-style open source license, meaning the community can do pretty much whatever it likes with the code, so long as it respects the copyright notices and naming rules. Indeed, many ports of Markdown enjoy rather widespread support with numerous contributors and an aggregate community of active developers that the original Markdown lacks.

So while the various implementations of Markdown have regular fixes and updates, Gruber’s original code lacks such activity. What’s the difference? Atwood lays some of the blame at Gruber’s feet, citing what Atwood calls “passive-aggressive interaction with the community,” and quotes one of Gruber’s famously bristly e-mails (Gruber also writes the famously bristly blog, Daring Fireball) that shows the author discouraging changes. Single programmers rarely have that sort of influence. Which isn’t to say we disagree with Atwood’s assessment, just that Gruber is an extreme example and that it shouldn’t matter either way.

The bigger reason Markdown’s original Perl source doesn’t see bug fixes and maintenance releases seems to lie more its hosting situation than any other single problem Atwood raises. Without a way to easily contribute to your project, your potential users can’t improve your code.

The Perl source of Markdown is hosted as static download on Gruber’s website. Download the zip file and you’ve got a copy of Markdown you can use, modify and even redistribute according to the terms of the license.

But you don’t have a copy that’s easy to patch, and there’s no simple way to contribute back to the project, short of sending code directly to Gruber or to the support mailing list.

If the Markdown source code lived somewhere like GitHub, BitBucket, Google Code or any of the other free, open source code repository hosts, it would be infinitely easier for the community to contribute. To be fair, none of those sites existed when Markdown was released, but moving the code wouldn’t be hard — it’s a single archive with a license and readme text file.

A good project hosting service allows the community to contribute in ways that it just can’t when the code is static download.

Markdown isn’t alone in this respect. Django programmers were very excited to get their hands on the EveryBlock source code when it was finally released. However, since the EveryBlock code is, like Markdown, a static download, there isn’t and easy way for the community to contribute.

I have been using the EveryBlock code in a personal project for some time, and I’ve found at least a dozen bugs and several oversights and contradictions in the documentation. None of these stumbling blocks have stopped me from using the code, but it would be nice if I could contribute patches so others don’t also have to bang their heads against a wall for days on end trying to make the code work.

Yet a static hosting environment prevents that. There’s no easy way for me or anyone else to contribute to the code, update the documentation, add helpful links to a wiki, ask a question and get it answered. As a result, the whole community around the project suffers.

While it’s true I could put the codebase into a version control system and host my own copy, but not only does that feel wrong, it shouldn’t be necessary. The “you can always fork it” motto of open source has proved one of its least helpful tenets, leading to a proliferation of nearly identical code forks that are difficult to keep track of and work with.

We understand that the people who release open source code might not have time to work on it, or might simply lose interest in it over time, but that’s precisely why version control systems exist — to take the burden off the developer and let the contributions of the community pick up the slack in an open, organized manner.

Does a project still need an maintainer and someone to check in code, run tests, merge branches and so on? Sure, but that need not be a single person. Sizable open source projects — take Firefox for example — have dozens of committers and (in theory) no one person winds up feeling overwhelmed.

While in this particular case, it could be argued that Markdown doesn’t need further development. We use it everyday without issue. But the larger issue remains for other projects. Without active development, particularly bug fixes and maintenance releases, your open source project will rarely be successful.

Get your code into a decent version control system and make it easy for other users to do what you don’t have to — make your code better.

Photo by gerhard3/CC BY-NC-SA 2.0

See Also: