Journal | A genius, so to speak, for sauntering

Photography & Social Media

Thursday · March 4, 2010 | posted under: Website Business · Media · Tech Notes | 2 comments

The Clam Diggers | Chinitna Bay, Alaska

As new social media outlets sprout like weeds I have found myself developing a new rule when dealing with them: I'm not uploading my images to your servers. Sure, I may post an iPhone shot or something similar—in fact I often shoot iPhone snapshots specifically for Facebook and I'm leaving already-uploaded images out there for the time being, but my real images are staying on my server. There are a few reasons for this:

1. It's work to prepare images for the various outlets and they inevitably compress them too much making them look bad to save some bandwidth.
2. I don't really trust them—there is increasing pressure to monetize and control user-generated content.
3. I have a idealistic view of the internet as billions of bright, free, individual lights. As we consolidate our creative efforts onto the servers of a select few media companies we weaken the democratization of the internet.

Dave Winer expressed this third point beautifully earlier this year in a post urging us to host out own content:

The most ridiculous thing is that corporate news organizations are trusting the new media companies to host their content. So the reporters there are subject to the whims of two layers of corporate media! Talk about dilution.

If you want to break out, your content is going to live in a little boat and will float in a harbor filled with battleships, aircraft carriers, nuclear powered submarines and pirate ships. They either won't care if you stay afloat, or worse, they will try to sink you.

But this presents a problem: I still want to participate in social media.

A solution: The Digital Hub

If you have a website, you already have the means of hosting your content. You don't need a third party to duplicate your material on their server, you just need to be smarter about the way you host it so it's ready to interact with other services. Other services allow you to do this by exposing an application programming interface (API). An API is your door into another service; it lets you interact with another piece of software. And that's all social media services are, software. Facebook is just software and Facebook has an API that lets you interact with it. So instead of uploading our content to another service, we keep our content on our server, our digital hub, and serve them through the other service.

We can think of this whole enterprise (my server, their servers, the user's browser) as one big piece of software that is broken into manageable sections which follow the well-known model-view-controller paradigm.

Model:
The MySQL database and related software hosting photo-mark.com which contains the images and the metadata associated with them. (Technically there is more than one model: the journal lives in the database and is distinct from the images and the portfolios, collections of images, form their own models too.)

Controller:
The software which connects the model to various outlets. This is where we implement with the API of other services. This includes code for generating thumbnails on-the-fly, generating HTLM for the website, RSS feeds, and writing FBML and FBJS to the Facebook Canvas.

View:
The outlets themselves: the photo-mark website, Facebook application, RSS readers, etc. You can think of this as the way the content is presented to the user.

The important thing to note is that the images and metadata live in one and only one spot. If I want to change a caption or alter a photo, I don't need to track down each place that image lives. I can do it once and this change should be reflected anywhere the image is seen. This also is a basic programing tenet: DRY—Do not Repeat Yourself.

Any time a new media outlet pops up that has an API, I can simply write some new controller code that interacts with it and nothing else has to change—my little hub stay the same. Some APIs are so simple that they amount to nothing more than a file format. Google, for example, has a place for images at the top of their profile pages. It gets these by consuming RSS feeds that use the Yahoo Media extension. Most people give it their Flickr feed, but it can be anything you want so long at it adheres to the standard. Here's mine. Those thumbnails are coming from my little hub with links directing flow back to photo-mark.com. That's about as simple as it gets.

For something a little more involved lets look at Facebook.

When you look at a Facebook profile, you'll see that a person's images all live under a tab called 'photos.' 'Photos' is just a Facebook application and Facebook apps aren't just for big services, anyone can write their own. When you've done this, you can install it in your own tab and fill it with just about anything you want, including dynamically generated content. From a technical point of view, this isn't very difficult. The front end is all written in a variation of HTML and javascript called FBML and FBJS respectively. If you already know HTML and javascript you are 90% of the way there. The hardest part is navigating Facebook's process of setting up and configuring and application, but It's fairly well documented..

Take a look at the photo-mark application and you will see that beneath the main image banner there are two tabs: Journal and Photos. These are views of the two models living in the photo-mark.com database. Everything you see here lives on photo-mark.com. (That's not entirely true—Facebook caches the thumbnails to speed things up). When a viewer arrives at this tab, the Facebook server requests a 'canvas' document from photo-mark.com. The document we send back looks a lot like a webpage, but written in FBML and FBJS. When Facebook gets this file it parses the FBML and FBJS, turning them into normal HTML and javascript which is then sent to the viewer's browser. The canvas page that we send to Facebook looks like this. It won't look good or work very well in the browser, because although it looks like javascript and html it is really FBML and FBJS—it has yet to be parsed by Facebook into browser-friendly code. The FBJS creates the functionality within the tab and can grab information as needed via ajax requests to the photo-mark.com server or in some cases from Facebook's server. For example, when you click on a journal title to get the full post, the javascript makes an ajax request for the information. Part of the controller code on the photo-mark server is prepared for this request and formats the page in a way that works within the Facebook layout. The post you are reading right now for instance looks like this to the ajax request. It's just HTML.

The Facebook page isn't quite done and it's not a perfect solution. Adding photos to a photo-mark gallery, for instance won't automatically inject a post into the news feed, and it would be nice to implement comments on photos, but it's a good start. In the end it simplifies my life, keeps me in control of my own content, and makes it increasingly easier to support social media services as they sprout. Little projects like this are one of the reasons I'll tell anyone who will listen that they should develop programming skills and that we should be teaching kids programming principles and languages early in their education. Today and even more so in the future, programming skills will determine your freedom.