By Request: Flickr and the Instagram That Wasn’t

Standard

I recently asked on Tumblr whether there were any topics that people would like me to write about, and I received a number of interesting suggestions. Here’s the first:

highleverageinning said:

Flickr next. No joke. How to fix etc.

I’m taking this one on first both because it’s timely and because it’s relatively easy for me to address:

I’m the wrong person to ask.

Despite being a longtime Flickr Pro user, and (probably) holding the distinction of having the oldest unopened Flickr welcome message in existence [see below, unopened since December 16, 2004], I’m not really much of a Flickr user. I’m not a photographer, and I basically use Flickr as a convenient dumping ground that lets me visually scan my own pictures easily. While community is key to many people’s experience of Flickr, I’ve never felt part of a community there.

I genuinely have no idea what Flickr should do.

See? Short, easy answer.

But the catch, of course, is that I have some thoughts on what Flickr shouldn’t do. Or to be more precise, I have one thought on what Flickr shouldn’t do: Flickr shouldn’t try to build a better Instagram.

Yes, Flickr probably should have built Instagram before Instagram built Instagram. But it didn’t happen. Don’t try to play catch up. Flickr needs to  focus on fixing the problems that kept them from building the last Instagram before they have a shot at building the next one.

I note this because I read Mat Honan’s Flickr’s Engagement Problem May Be Too Big for Even Marissa Mayer. Which you should go read now, especially if you want to be able to judge whether I’m accurately representing Honan’s post. Which you should.

It an excellent piece and I’m nitpicking here, but I was bothered by this sentence regarding Honan’s test of the activity levels around Flickr vs. other services: “Perhaps more damning than the poor showing in terms of up votes was how ignored it was in real-time. It was only even viewed a total of five times on Flickr in that first hour.”

While I don’t think Honan is suggesting that Flickr build a better Instagram, exactly, it does feel like he’s suggesting that a viable Flickr is one that’s focused on a real-time, mobile, social photo experience as soon as possible, and that sounds to me a bit like trying to take Instagram head on rather than building a better Flickr.

It’s odd to say in these mobile-first, social-always days, but maybe Flickr would be better off building from their strengths. As Honan points out, Flickr “has great privacy controls, excellent display and sharing tools, makes a wonderful archive, and, despite years of neglect, enjoys tremendous good will.” What if Flickr stays focused on the web for a little while, and accepts (or embraces) a “slow photo” mindset against Instagram’s stream of consciousness, and Facebooks stream of…well, every-fucking-thing?

Could work. As I said: I really don’t know.

But I do know that Flickr shouldn’t try to build a better Instagram.

Identity : Anonymity :: Community : Network (?)

Standard

There’s been a fair amount of discussion around Google’s “real names” policy on Google+ in certain circles. Most recently in my stream, Fred Wilson pointed to Corey Doctorow’s post on the topic, and the discussion around that post crystallized some of what I’ve been thinking on the issue. To be specific, the crystal is:

The “anonymity vs. real names” debate is in large part a discussion of a very different issue: community vs. network.

Ages ago, in the days before Google+, the discussion tended to revolve around Facebook comments outside of Facebook. “If we implement Facebook comments,” the corporate presentation went, “it will improve the quality of the UGC on our site, because comments will be tied to users’ real identities. If people’s comments are linked to their Facebook profile, they will be respectful of both our content and other’s contributions, because a meaningful degree of accountability has been added to the system.”

The next slide of the powerpoint was inevitably the real money, though, pointing to the awesome traffic potential that came with hitching one’s buggy to the Facebook rocket: “because users can easily share their comments to their Facebook friends,” the presentation would continue, “we make better use of users’ existing social networks in our efforts to build traffic to the site.”

And there’s the rub.

Requiring a fixed external identity online addresses a very real concern, but it’s reactive. It is, in many cases and possibly at best, a response to the ease with which users can find a new-to-them site or service these days. It is, in an unfortunate number of cases, an attempt to shortcut the process of building a community in favor of importing networks, and then trying to preemptively create some order out of the mess that almost inevitably results from that import.

In Google’s case the network import in question was…well, Google’s, but I don’t think that changes the formulation to any meaningful degree: my Google+ circles are just as far removed from my gmail “contacts” list as the squares, lists, scenes, or cadres dreamed up by any unfunded Brooklyn startup.

The issue, in my view, isn’t whether giving users of a service the ability to be “anonymous” to other users of that service is harmful to that service — I maintain that UrbanBaby settled that question nearly a decade ago, in favor of anonymity — but whether an external identity requirement does anything positive at all.

Because so many people now have established identities and communities online, the idea that you can just tap into that pre-existing structure is incredibly seductive: you find one person who’s right for your new service and they bring a whole community with them.

The problem is that the network effect can help expand an established community, but it can’t build one. Drive-by visitors are generally more trouble than they’re worth, as many Dugg and Slashdotted sites will report.

Until people have a reason to take (credit || responsibility) for their activity on your site, you’ll have a real problem with bad apples, anonymous or otherwise. Once people do care, the community will make an effort to take care of problems whether or not they know the “real name” associated with that problem.

My “network” is made up of many different communities, and some of those communities don’t like one another very much. Assuming that pulling that entire, extended network into one central location is a good idea is…well, just not a good idea.

Bonus: any commenters who provide an explication of the “bartender” label that appears on Fred’s AVC comments get a free beer from me at the time and of their choosing (within reason). Bonus points for offering a (probably inaccurate) derivation of the term “86”.

On Making Stuff

Standard

For the past couple of weeks I’ve been spending whatever time I can spare on a little project: building kisttr, a Kickstarter Backer Tracker. It’s a pretty straightforward hack that allows you to “track” (or “follow”, if you prefer) a group of Kickstarter users and see what new projects they’re backing without having to visit each of their profile pages on the site.

As I was putting it together, a part of me couldn’t help but play out a little dialogue:

“So this thing just sends you a daily email that lists the new projects some people are backing on Kickstarter?”

“Yes. Though it does show them on a Web page, too.”

“And you spent two weeks building it?”

“Correct. Late in the evening, mostly.”

“It kind of sounds like a feature, not a product.”

“True. Very true.”

“And it actually kind of sounds like a feature that Kickstarter is likely to release themselves at some point.”

“Agreed.”

All of the points raised above are entirely valid. I fully expect that Kickstarter will sooner or later release an update that makes kisttr obsolete, it’s definitely a feature rather than a product, and it took me an awfully long time to build something that a competent developer could have banged out in a matter of a couple of days.

But to me, all of that is missing the real point.

Kickstarter may well release an equivalent feature, they don’t offer it right now, and I want this right now. Kisttr isn’t as elegant as I’d really like, but it works — and it’s a lot better than not having anything at all.

And while I’m a slow and clumsy programmer, after spending some focused hours designing and building this, I’ve remembered a bunch of tricks that I’d forgotten and learned a few new things, as well. [Amazon’s Simple Email Service is kind of neat, I’m an idiot for not making better use of CSS frameworks before, and so on.]

Today I have a better understanding of a few design and development issues than I did two weeks ago, and even though (or maybe because) I’m more of a “product” guy, that’s incredibly valuable.

When it comes down to it, it’s just fun — and wonderfully satisfying — to take a project from a barely articulated idea to reality. Making something that didn’t exist before is a real pleasure — even if what you’re making isn’t that big a deal in the grand scheme of things.

The further I get into this process (it’s still underway, since there are still a number of holes to be patched), the more strongly I believe that I get the real benefit from the process of building kisttr — the end product is just a little bonus.

Anatomy of a Better Twitter Bot

Standard

So you may recall that I put together a Twitter bot for the lyric of the day club a few months ago. You may also recall that I mentioned that my co-conspirator Daryn Nakhuda has the ability to write code that doesn’t, you know, “fail mysteriously and silently” and such.

Well while it’s taken us a while to get there, but Daryn has now rewritten the LOTD bot. While I was on vacation and virtually inaccessible, Twitter disabled the “replies” API call, which meant that the LOTD bot couldn’t access the lyrics that people were posting. And since I was without internet access and had intermittent cell phone coverage, the bot went down and stayed down until Daryn managed to contact me.

After an amusing little incident where I accidentally sent the admin password for the server to hundreds of people, Daryn got coding and wrote LOTD Bot, Mark II. In addition to general improvements, Daryn added one completely awesome feature: now, if the bot can’t get replies from the Twitter API it fails over to do a search on Summize to find new replies to post. Sweet, no? Here are the (slightly updated) requirements and info for LOTD Bot, Mark II:

Requirements
To run a variation of this @lotd script, you must be able to understand Perl well enough to make some basic modifications to the script, and must be able to set up a simple database table (phpMyAdmin is your friend). In addition, you need a server or account at a Web hosting service that:

  • Allows you to set up a (small) database.
  • Allows you to run perl.
  • Has the XML::Simple and LWP::UserAgent perl modules installed, or will allow you to install them.
  • Allows you to run scheduled jobs (i.e. cronjobs)

Overview
It’s a very simple setup: there’s a single perl script running on my server that gets the replies posted to @lotd via the Twitter API (or via a Summize search, if the API call fails), loads them into a database table, and then republishes the posts in the lotd account (again via the API). It’s scheduled to run once every 15 minutes, around the clock. The script uses the XML::Simple and DBI modules, but doesn’t have any other dependencies.

To run your own bot using this script, you’ll need to:

  1. Create the Twitter account that will be the repost bot.
  2. Create a database table as described in the next section.
  3. Update the script below:
    • The DB connect information for your database. (Line 14)
    • The Twitter username/password information for your Twitterbot account (there are “read from” and “write to” values, but they’ll point to the same Twitter account in most cases). (Lines 16 – 20)
    • The regex to remove @YourTwitterBot from replies before it reposts them. (Line 40)
  4. Upload the finished script to your server.
  5. Set up a cron job to periodically run your script (@lotd runs every 15 minutes).

…and that’s pretty much it.

Get the Database Table Structure (MySQL CREATE)
Click the link above, copy and paste, and change the table or field names as seems appropriate.

Get the Example Script
Click the link above, copy and paste, and make the updates noted in the post above. If you change the database table or field names, make sure that you also update the script appropriately.

Gedankenexperiment: Here is the Internet

Standard

A digital native is a person who has grown up with digital technology such as computers, the Internet, mobile phones and MP3. A digital immigrant is an individual who grew up without digital technology and adopted it later. A digital native might refer to their new “camera;” a digital immigrant might refer to their new “digital camera.”

Description of “digital natives,” coinage generally credited to Mark Prensky

The idea of building competitors to Twitter on the same platform, or redistributing Twitter to multiple players reminds me of the idea that New York City should be rebuilt in Ohio because it would be cheaper. Or perhaps we could distribute a little of New York City in every state of the Union. New York City is what it is because of the people who live and visit there. Building another New York City in Las Vegas doesn’t result in the phenomenon that is New York City.

Echovar on decentralizing Twitter

There are roughly three New Yorks. There is, first, the New York of the man or woman who was born here, who takes the city for granted and accepts its size and its turbulence as natural and inevitable. Second, there is the New York of the commuter—the city that is devoured by locusts each day and spat out each night. Third, there is the New York of the person who was born somewhere else and came to New York in quest of something. […] Commuters give the city its tidal restlessness; natives give it solidity and continuity; but the settlers give it passion.*

E.B. White, Here is New York (1948)

It took a week or so for these three things to snap together in my head, but when they did I was surprised how beautifully and accurately E.B. White described the population of the Internet.

I consider myself, and many of the people that I know, settlers: we have chosen to live a part of our lives online, and building online is important to us. Commuters have long since arrived—people who come online for work, or to do a little shopping, or in search of entertainment, but for whom the Internet is simply an interesting, useful, nice place to visit.

I’m not certain that there are yet many, if any, true natives, but I’m looking forward to seeing the (to me) strange changes engendered by people who can take the physical and metaphorical connectedness of the Internet for granted as a part of their daily lives.

* Personal note: my parents (both originally from the Midwest) moved to New York in 1968, and I was born in 1971. When I first read this passage, years ago now, I finally started to understand how my parents’ New York was different from my own—and that New York was important to them in a way that I think I can never entirely understand.

Anatomy of a Twitter Bot

Standard

Update: If you’re here in search of sample code for a Twitter repost bot, I would strongly recommend going to the Anatomy of a Better Twitter Bot post, which has a much-improved iteration of the LOTD bot code.

Update: Since Fred Twittered this post, it has reached a somewhat larger audience than expected and I’ll add an addtional note: there will be some interesting new stuff happening with @lotd. I’ve been chatting back and forth with Daryn Nakhuda, a gentleman and a real programmer, about possibilities, and when you put together his ideas, my ideas, and his ability to write sane, reliable code, cool things should result. Stay tuned.

While the logic of “hide your shame” should dictate that I never, ever reveal the code that runs the Twitter Lyric of the Day Club, there’s been enough interest that I’m just going to suck it up and publish it. For any programmers who end up at this post: yes, the code is a little eccentric, and yes, there are a number of ways that it could fall down and hurt itself. Believe me, I know. That said, here’s the rundown:

Requirements
To run a variation of this @lotd script, you must be able to understand Perl well enough to make some basic modifications to the script, and must be able to set up a simple database table (phpMyAdmin is your friend). In addition, you need a server or account at a Web hosting service that:

  • Allows you to set up a (small) database.
  • Allows you to run perl.
  • Has the XML::Simple perl module installed, or will allow you to install it.
  • Allows you to run scheduled jobs (i.e. cronjobs)

Overview
It’s a very simple setup: there’s a single perl script running on my server that gets the replies posted to @lotd via the Twitter API, loads them into a database table, and then republishes the posts in the lotd account (again via the API). It’s scheduled to run once every 15 minutes, around the clock. The script uses the XML::Simple and DBI modules, but doesn’t have any other dependencies.

To run your own bot using this script, you’ll need to:

  1. Create the Twitter account that will be the repost bot.
  2. Create a database table as described in the next section.
  3. Update the script below:
    • The DB connect information for your database. (Lines 21, 43, 75)
    • The Twitter username/password information for your Twitterbot account. (Lines 6, 84)
    • The regex to remove @YourTwitterBot from replies before it reposts them. (Line 18)
  4. Upload the finished script to your server.
  5. Set up a cron job to periodically run your script (@lotd runs every 15 minutes).

…and that’s pretty much it. As I said in my first email to Fred about this, “the hardest part of making something like the @lotd bot is just having the idea — once you’ve got the idea, Twitter makes it easy to build what you’ve got in your head.”

Good luck, have fun, and let me know about anything interesting that you make!

Update: In response to a couple of questions, I guess I didn’t make it explicit—this stuff is released under the Woodie Guthrie license: “This song is Copyrighted in U.S., under Seal of Copyright # 154085, for a period of 28 years, and anybody caught singin it without our permission, will be mighty good friends of ourn, cause we don’t give a dern. Publish it. Write it. Sing it. Swing to it. Yodel it. We wrote it, that’s all we wanted to do.”

Get the Database Table Structure (MySQL CREATE)
Click the link above, copy and paste, and change the table or field names as seems appropriate.

Get the Example Script
Click the link above, copy and paste, and make the updates noted in the post above. If you change the database table or field names, make sure that you also update the script appropriately.