esjewett.com

This is a quick how-to, showing how to route your Twitter feed through Yahoo! Pipes to filter and cleanse it, then consume it using ESME actions.

I've created a parametrized Yahoo! Pipe here where you can input your Twitter username and get back a feed of all mentions of "ESME", "esme", or "Esme" from your Twitter timeline.

(Pipe address: http://pipes.yahoo.com/pipes/pipe.info?_id=fJZ29qrr3RGjLPJI6icw5g)

Once the "Run Pipe" button is pressed, the filtered time-line displays. I've also removed the username from the beginning of the Tweets, for better display in ESME.

Feel free to use this pipe with your username, or "Clone" it and modify it as you like. The structure of the Pipe as it is now is available as an image here.

Once the pipe has been run, it is possible to retrieve the output as an RSS feed. Copy the link for the RSS feed for this pipe, as we will need to consume it using an ESME action.

Now navigate to your ESME server. We need to use a relatively recent version of ESME, specifically a version including the recently merged actions branch. I'm using http://esmecloudserverapache.dickhirsch.staxapps.net/ in this example.

Log in to the ESME server and create a new action. Fill in the action name as desired. For the test, use the "every N mins" test. I'm chosen 5 minutes as my interval, which means that the pipe feed will be queried every 5 mins for new entries.

For the Action, use the rss: action type, followed directly (no space) by the URL of the Pipes RSS feed that we copied earlier. Your action form should look like this.

Click the "Add" button and your recent Tweets containing the word "ESME" will start showing up on the ESME server. One neat aspect of this is that any hashtags (#esme for example) in your Twitter updates will be converted to ESME tags automatically.

This only works for public Twitter updates, as Yahoo! Pipes doesn't support authentication for feeds. You could query your private Twitter feed directly from the ESME server, embedding your Twitter username and password in the URL, but I strongly recommend against this as your username and password will be stored in the ESME server database, which you do not control.

Originally posted as a comment by esjewett on The Inquisitr using Disqus.

These are excellent points, but it only gets at half of the equation. As I see it, the two main questions when working on my personal workflow are effectiveness and flexibility. My impression is that when people are thinking about their workflows there is far too much emphasis on the stability of the platform (which is your point, and a good one) because of an inflated estimate of the costs associated with a workflow change.

The basic question is this: Is a change to my workflow that takes X hours to execute worthwhile?

The way a lot of people think about this question is by asking "Do I have X hours to spend on this or would I rather spend it on something else?"

The question people should be asking contains another variable - the number of hours they will save overall through this change. Let's call this number of hours "Y". The question is: "Do I have X-Y hours to spend on this or would I rather spend it on something else?" When the number of hours saved (Y) becomes greater than the switching cost (X), the cost associated with a workflow change becomes negative.

I actually switch tools quite often, so my estimate of the total productivity gain for a given tool is necessarily limited by a short time horizon and my tolerance for switching costs should be correspondingly lower, but I still find that a switch is of tools is justified for a pretty small daily productivity gain (even 5 minutes saved per day makes a tool a clear winner).

If Google Reader shut down tomorrow and I had to switch to a different feed reader, would I come out ahead in productivity over the last year or two as compared to the next best solution? I have no doubt in my mind that I would. As such, I have no problem "entrusting" this part of my workflow to the web, as long as the switching costs (X) are less than the productivity gain.

I find that the "web-iness" of a tool doesn't factor much in the estimate of switching costs. The OPML export from Google Reader happens to make the switching cost very low, which makes my decision to use Google Reader very easy.

Original article: http://www.inquisitr.com/15368/so-you-want-to-trust-your-workflow-to-the-web-good-luck-with-than-plan/.