Working on a photoblog theme for WordPress

After seeing that Andrew Spittle is working on a WordPress theme for a mobile photoblog (as discussed here), I thought I’d do the same. I happen to like Autofocus pretty well, so I’ve just made a child theme, with a few Twitter-specific modifications. Follow it on Github: https://github.com/boonebgorges/boones-photoblog. (Keep in mind, you’ll need the parent theme Autofocus installed for the Boone’s Photoblog theme to work.)

Shorten your own dang URLs

In my last Project Reclaim post, I talked about using WordPress as a Twitpic-like personal mobile photo service. When the ultimate goal of the photoblog is to send a tweet, it’s almost always necessary to use a URL shortener. But trusting your URL shortening to a free service is a dangerous move. If that service goes out of business, or if they decide to take down the database for some reason or other, the links in those tweets will break. (This problem is delightfully called “linkrot”.)

So, while URL shorteners are sometimes necessary, they’re also an obvious instance for reclaiming your data. Moving to your own URL shortener means that you control the domain, you control the content, you can back up the database however you’d like, etc.

I went with a piece of software called YOURLS. It’s written by Ozh Richard, a WordPress developer, and there’s a slick WP plugin that makes it a great choice for use with my WP photoblog. Here’s a short walkthrough of how I set it up.

Setup

  • Get a domain. Something short is nice, obviously. I just started typing two- and three-letter domains into my domain registrar’s search box (I use Dynadot), which showed me the top-level domains available, until I found one that was easy to look at and remember (http://blo.so). Make sure you do whatever setup your registrar requires to get the domain working – probably as simple as setting the nameservers to your host’s NS addresses.
  • Install YOURLS. The instructions provided at the YOURLS site are pretty concise, but here’s the gist: upload the software to the server, create a new database, copy the sample configuration file to user/config.php, and fill in the configuration file with the proper database info, etc. You can get more YOURLS config info here.
  • Configure an Apache virtual host, if necessary. If your hosting provider doesn’t have cPanel or some other tool that easily lets you point your new short domain to a subdirectory, you’ll need to do it manually by creating a new Apache virtual host file and activating that site. This website has a pretty good explanation. But essentially, just copy the default configuration in sites-available (likely at /etc/apache2/sites-available) and change the info in the VirtualHost section.
  • Install the WordPress plugin. The YOURLS: WordPress to Twitter plugin is easy to install and set up. Once the plugin’s installed, go to Dashboard > Settings > YOURLS and fill in the necessary information. Setting up the Twitter bit is a pain, thanks to Twitter’s requirement that you get a developer’s key, but it’s easy to do. Just follow the on-screen instructions.

At this point, everything should be set up. Send a test post or two to try it out.

Bonus! Use me with Tweetdeck

YOURLS has a REST API that can be used with a bunch of applications. For instance, I’ve configured my TweetDeck installation to do its URL auto-shortening with blo.so. Go to Settings > Services and choose Other from the URL shortener dropdown. Your endpoint will look something like http://blo.so/yourls-api.php?signature=XXXXXXX&action=shorturl&url=%@&format=simple. You’ll have to replace blo.so with your own URL, of course, and the XXXXXXX signature with a custom YOURLS signature password. You can get it from the YOURLS admin screen (http://example.com/admin/tools.php > Secure passwordless API call)

Here’s the great thing. There’s no reason why a couple people can’t share a single YOURLS installation. In fact, I’ll put my money where my mouth is, and start my own URL shortening co-op. I’ll give usernames/passwords to blo.so to the first couple friends who want in. Send an email to boonebgorges at gmail if (1) you are my friend, (2) you want in on blo.so, and (3) you promise to actually use it and break the bit.ly/tinyurl habit.

Kicking the Twitpic habit with WordPress

Twitpic and its ilk are pretty convenient, especially when they’re integrated into mobile Twitter apps. But as recent articles have shown, the terms of service of such services can be downright icky. Twitpic may have changed its tune a few days after the outcry, but honestly, if it takes an outcry to make a company not be evil, then maybe you shouldn’t be dealing with that company.

This is a perfect little side project for Project Reclaim, and something of a no-brainer. Twitpic etc are stripped-down publishing platforms. I already run a couple installations of a non-stripped-down publishing platform, namely WordPress. So I set up my own photo blog in just a couple of minutes.

I already have an instance of WordPress Multisite that I use for a bunch of different purposes. So setting up the blog itself was easy – I went to my Network Admin panel and clicked Add Site. If you’ve never worked with WordPress Multisite before, you should know that it’s already built into the WordPress installation that you may already have. You can read more about how to turn on Multisite at the WordPress Codex, or you can watch a somewhat out-of-date but otherwise charming video of a handsome and engaging speaker talking on this very subject.

Then I found a theme that looks nice with photographs. I didn’t look very far. My favorite visual theme has, for some time, been Allan Cole’s AutoFocus. In the future, I’ll probably build a child theme that has a few tweaks appropriate for my mobile photo blog, but it works pretty nicely out of the box.

Then I fired up my WordPress Android app (there’s one for the iPhone too) and connected it to my new WordPress blog. (You’ll have to enable XML-RPC on your WP blog if you want to use the mobile app.) I tweaked a few of the blog setting in my app, so that the photo would be linked after I published it, and the thumbnails would be of an appropriate size.

Finally, I got a WordPress plugin that sends tweets every time a post is published on the photo blog. I’m using YOURLS (more on this in an upcoming Project Reclaim post), but there are lots of them out there that are freely available. Just search the WordPress plugin repository.

Now, when I want to tweet a picture, here’s what I do. Open the WP app. Create a new post. Click the Media button. Take the photo. Add the content of my tweet in the Title field. Publish. (Don’t have to do it in this order, of course.) Totally painless – and I don’t have to worry about any terms of service. Yippee!

For more reading, here’s another blog post about the very same idea.

Related posts:

  1. BuddyPress and the YOURLS: WordPress to Twitter plugin
  2. Shorten your own dang URLs
  3. Enabling Popularity Contest for WordPress networkwide use

Making the Thunderbird interface more Gmail-y

As part of Project Reclaim, I’m gearing up to move my email off of Gmail and onto my own server. Email is, and long has been, central to my life online – it’s my main point of contact for so many personal and professional connections, and my email archives are the closest thing I’ve got to a record of my online activity. So I’m keen to make the move as smooth as I can.

For that reason, I’m handling the transition in stages. The first stage involves transitioning email client software away from the Gmail website.

Choosing a client

I’ve chosen Thunderbird as my alternative, for a couple reasons.

  1. It’s open-source.
  2. It’s highly extensible and customizable.
  3. It works across platforms. That’s important, because I’ll be migrating away from OSX.

Choosing Thunderbird is not without its sacrifices. For one thing, moving to an OS-native application, rather than an app that runs in a browser window like Gmail does, means that I’ll no longer be able to count on having a consistent UI and feature set between different devices. In some cases, this is not a huge loss. The UI for Gmail on my Android phone is really quite different from the normal web version, and it’s never bothered me very much. My biggest worry, though, is that I’ll have multiple workstations – a primary work machine and a netbook, for example – with different email setups. I’m hoping to mitigate the problem by coming up with some idiot-proof backup and syncing methods for the fairly small number of files that comprise Thunderbird’s configuration. (This’ll be necessary for other software transitions as well, like my gradual move to Vim. It’d be quite easy with Dropbox and some strategically-placed symbolic links, but I’m trying to break the Dropbox habit too :) )

It’s a considerable comfort that, now that I have a smart phone (and am thus no longer reliant on public or borrowed computers for email access), the vast, vast majority of my email use is centered on a handful of devices, all of which I own. The last time I checked my email on a device other than my own was probably three years ago. Weird, now that I think of it.

The other sacrifice is related to UX. I happen to like Gmail’s interface. In particular, I’ve grown quite used to Gmail’s thoughtful keyboard shortcuts, which make it possible to do nearly navigation without touching the mouse. Coming up with a reasonable facsimile of these shortcuts in Thunderbird would be the biggest part of my configuration process.

Keyboard Shortcuts

Thunderbird has pretty good keyboard shortcuts out of the box. I didn’t feel like learning a whole new system, though, so I wanted a way to map Gmail-style shortcuts onto Thunderbird. There used to be a Thunderbird extension to do just that, called GmailUI. But the GmailUI website suggests that the extension is only compatible with Thunderbird versions 0.8-2.0 (Thunderbird’s currently in 3.1), which would explain why the extension doesn’t show up in a search on tho Mozilla repo (the “Expression Search” plugin does come up, which is a fork of a part of GmailUI that I’ll talk about in a minute – but it doesn’t do keyboard shortcuts).

So I looked for a more general method for customizing Thunderbird’s keyboard shortcuts, and found it with Keyconfig. It’s pretty straightforward to remap keystrokes using Keyconfig (Tools > Keyconfig), though it can be a bit of a pain because many of the standard Gmail shortcuts (like j and k for up/down navigation) are already in use by Thunderbird, so that changing one shortcut often means making two. You might find it helpful to borrow my configuration, which I’ve pasted below. Add these lines to your user.js config file (create if it doesn’t exist):

	user_pref("keyconfig.main.key_killThread", "][I][");
	user_pref("keyconfig.main.key_markJunk", "meta shift][J][");
	user_pref("keyconfig.main.key_markReadByDate", "meta shift][D][");
	user_pref("keyconfig.main.key_markThreadAsRead", "meta shift][R][");
	user_pref("keyconfig.main.key_newMessage", "meta shift][M][");
	user_pref("keyconfig.main.key_newMessage2", "meta shift][N][");
	user_pref("keyconfig.main.key_nextMsg", "][J][");
	user_pref("keyconfig.main.key_previousMsg", "][K][");
	user_pref("keyconfig.main.key_reply", "][R][");
	user_pref("keyconfig.main.key_replyall", "shift][R][");
	user_pref("keyconfig.main.key_toggleMessagePane", "][V][");
	user_pref("keyconfig.main.xxx_key74_SwitchPaneFocus(event);", "][D][");
	

Briefly, this does the following. First, it maps some familiar keystroke combos from Gmail to Thunderbird: j and k to up and down, and r and R to Reply and Reply To All. Second, because two-stroke codes from Gmail (like gi for Go To > Inbox) don’t seem to be supported natively by Thunderbird, I’ve mapped D to SwitchPaneFocus, which lets me get back and forth between the folders pane, the message list pane, and the single message pane, for easier navigation. As I get more comfortable with it, I might write my own extension that ports over some of the other most convenient Gmail shortcuts, but for now this covers a good 80% of what I might regularly use.

The other big shortcut missing from Thunderbird is y, which is the Archive command in Gmail. For that purpose, I installed Nostalgy, which allows you to move messages with keyboard shortcuts. I don’t think I’ve set this up in 100% the right way, but here’s how I’ve approximated Gmail’s y using Nostalgy. First, at Tools > Nostalgy > Keys, I’ve set ‘Save message’ to ‘shift Y’ and ‘Save as suggested’ to ‘Y’. ‘Save as suggested’ seems to work on a session basis; it suggests the folders that you’ve used since the last time you started Thunderbird. Thus, every time I start Thunderbird, the first time I want to archive a message, I use the more verbose shift-Y. A dialog at the bottom of the window suggests places where I might put the message; I select Gmail’s All Mail folder. Then, the next time I want to archive a message, I can use y by itself to go to the suggested (i.e. the last-used) location. Since I just throw all of my email into All Mail – no complex tagging or organization – this is all I need.

Bonus! Offline Access and New Email Throttling

Moving to a non-web-based email client is not all bad. For one thing, moving to a local application means that my email – archives and all – are available offline. I know that Google Gears and some of the new HTML5 goodies mitigate the issue somewhat with respect to Gmail, but offline access for a webapp is always going to be something of a hack.

On a related note, one thing that I have always hated about using Gmail is how it weaves together the process of checking for new email and accessing old email. I like to check for new mail at specified intervals only (once every few hours); anything more than that is extremely distracting. In Gmail, this meant closing the browser tab. Yet, fairly frequently, I find that I need to access an older email from my archive in order to do a specific task. In Gmail, this meant checking my new email as well. Now that I’ve moved to Thunderbird, I can access my archive without checking for new mail – the way it ought to be!

Setting it up this way was not straightforward. There are a few things you’ve got to do:

  1. In Tools > Account Settings > Server Settings, configure the ‘Check for new messages at startup’ and ‘Check for new messages every x minutes’ however you’d like. I have them both disabled, so that email can only be checked manually.
  2. Here’s the tricky part: Gmail, in its futuristic wisdom, uses a special protocol called IDLE to push new email to remote clients – bypassing the settings from step (1). (This took me half a day to figure out.) Disable this feature at Tools > Account Settings > Server Settings > Advanced > ‘Use IDLE command if the server supports it’.

I’m planning to spend a few weeks improving and getting used to this setup before starting the migration to self-hosted email.

Related posts:

  1. Project Reclaim and the email dilemma
  2. Automated and redundant Wordpress backup via email
  3. Making Userthemes work on WordPress 3.0

Project Reclaim

Update: I have begun aggregating these posts at projectreclaim.net.

Lately I have been feeling increasingly uneasy about the state of my digital affairs. I am a leader on a number of open source software projects that pride themselves on, among other things, their ability to enable users to “own their own data”. Moreover, I am trained as a philosopher, and have spent a pretty fair amount of time reading and thinking carefully about the nature of data and our relationships with it. If anyone is in a position to develop and advocate for good models of digital independence, I am.

Yet, when I look around my digital world, I see instance after instance where I am, to a greater or lesser extent, completely reliant on the good will of commercial entities and their propietary systems. To wit:

  • My Twitter account is a big part of my online identity
  • The last five years of my private correspondence, personal and professional, is in Gmail
  • I use Dropbox for syncing documents between devices (like my blog_sandbox.txt file, where I’m writing this post!)
  • I use Picasa Web Albums to back up and share photos
  • I have a Mozy account to back up the rest of my important files
  • Until recently, I had an iPhone. I still use a Mac
  • I use Remember The Milk for task management
  • I store source code for all my projects in Github

Some of these are products; some are services. Some are free; some of them I pay for. And – for sure – some of the companies behind the products and services listed above are more evil than others. So I don’t want to pretend that my reliance on each of them is equally bad. But each item on this list plays a crucial role in my digital life, and each one of them operates in a way that is beyond my control, both literally (I can’t modify the source code) and more figuratively (questions about ownership, exportability, transportability are icky).

I’m planning to extricate myself.

Project Reclaim

In order to make it sound a bit fancier, I’m giving my project a name: Project Reclaim. ‘Reclaim’ because it’s a manifestation of my desire to fight the inertia that leads us to give up control over our computing experiences, my desire to reclaim control and ownership. ‘Project’ because this will be hard, and ongoing. And why give it a name at all? I’m hoping that, by being public about it – putting my experiences in a series of blog posts and tweets under a common tag – that I’ll be able to hold myself accountable, and hopefully guide others who are hoping to reclaim their lives a bit as well.

In short, Project Reclaim is the process of weaning oneself off of digital platforms that are closed source and/or under the control of others.

Methodology

How will Project Reclaim actually work?

  1. Assess the situation I’ll first need a way of figuring out which systems and platforms are worth moving away from, what their replacements should be, and in what order I should effect the transition. I’ve got a few rules of thumb.
    • Open source is better than closed source. I write open-source software for a living. I believe that, on balance, it makes better software. And I believe that using software where one has access to the source code is a necessary component of maximizing one’s digital autonomy. Thus: if the third-party system I’m currently using is also a benefactor of open-source communities (like, say, wordpress.com), it makes it less urgent to move away. And, when selecting replacements, select open source if at all possible.
    • Paying is better than getting something for free This might seem like a contrast to the previous rule, but I don’t think it is. When you use a free service, somebody’s paying the bills. Usually that means targeted advertising – think Facebook and Gmail. Paying service fees, on the other hand, and agreeing to the contract that comes with it, generally has the effect of making the relationship more transparent. Of course, this is far from absolute, but it seems reasonable in a broad sense. Plus, I like to support developers and services that are truly valuable.
    • Go for the low-hanging fruit In cases like email, there are well-established, straightforward (though not necessarily easy…ugh) ways of fending for yourself. No need to invent the wheel. On the other hand, some of the areas where alternatives are less obvious – social networking-type data springs to mind – also happen to be areas where I have some expertise and leverage. So, in those cases, it might be worth innovating.
    • Get the important stuff first My email history is more important to me than my Twitter history; the convenience of Github is more valuable to me than the convenience of Dropbox. Plan the Reclaim accordingly.
    • Get the vulnerable stuff first Recent statements by Twitter have made me think that the way I interact with the services is more subject to change in the upcoming months than, say, the way I interact with Gmail. That’s frightening. The more profit-hungry the company is – and, thus, the more disinclined to have the customer’s freedoms in mind – the more urgent it is to pull yourself out.

    Clearly, some of these considerations are at odds with each other. But they give a rough framework for deciding whether, when, and how to carry out the mission of Project Reclaim.

  2. Make the switch Here’s where the action happens: I do what I need to do to move myself to the replacement.
  3. Write about it This weekend I spent an afternoon on the problem of Twitter, and I ran into a ton of technical problems that remain unresolved. I imagine that there will be similar hurdles for each part of the project. I’m hoping that, by writing about the problems (and, where they exist, the solutions) I can help other people to take some of the same steps themselves, or even to spur someone really smart to come up with better solutions than the ones that currently exist.

What I expect from myself

My goal, ultimately, is to move away from third-party, closed-source services and platforms altogether. It might take some time. So I’ll make some interim goals: by the end of 2011, I’m hoping to have my email moved, my microblogging federated, my own backup system on my own server space, and my computer running an open-source OS.

Even if I manage to meet this goal, there’s a very real sense in which Project Reclaim will necessarily be an exercise in futility. I’ll always have to buy server space, and who’s to say that Amazon or Slicehost won’t go berserk tomorrow? I’ll always have to connect to the internet, which leaves me perpetually at the mercy of the ISPs, who are IMO more evil than all of the other service providers put together. It’s a depressing state of affairs: the kind of autonomy I want might be impossible given the way that the economy works. I take some solace in the fact that philosophers have spilled much ink over the problem of free will without coming up with a clear formulation of exactly what kind of autonomy would be worth arguing for. At least I’m not alone in my delusion.

That said, it’s a fight that I feel I have a responsibility to fight. If I’m going to continue to argue for the use and development of open source software, I have to start putting my money where my mouth is. And so, to me, Project Reclaim is less about my being a paragon of virtue, and more about my wanting to sleep a bit better at night.

Do I think that everyone should do this? People should prefer open solutions to closed ones, all things being equal. But generally, all things are not equal. Most people don’t have the time to write their own software, to run their own servers. For those people, decisions about their digital life are (rightly, I think) made more on the basis of aesthetics and convenience than lofty concepts like Autonomy and Ownership. But there are a few considerations that are perhaps relevant for the kinds of people who read my blog:

  • Open source developers who tout the importance of data ownership and other such freedoms have a special responsibility to model best behavior in these areas.
  • Academics, more than anyone, should be sensitive to the dangers of leaving the crucial pieces of one’s online self in the hands of corporate entities. That’s true for personal artifacts like email, but perhaps doubly so for scholarly work that ought to be part of a public trust.
  • Educators, like open source developers, should model best practices, encouraging students to take control over their digital identities.

So, while I wouldn’t belabor the point for the average Joe, I do think that people who consider themselves members of one of these groups – as most people reading my blog probably do – that they should think carefully about their relationship with the tools and services that enable their digital existence.

To freedom!

Related posts:

  1. Project Reclaim and the email dilemma
  2. Done with Apple
  3. Shorten your own dang URLs