Lessons learned from a book collaboration

A new book is out: Social by Social, "A practical guide to using new technologies to deliver social impact". It's available as a free PDF download as well as a non-free dead tree version.

At a quick glance it seems full of useful stuff, along with some familiar things if you've followed blogs with the word "social" in the title.

The bit that grabbed my attention was the stuff in Chapter 9 about the making of the book. As someone whose job it is to make sure people can use the tools provided, some things struck me about their choices and the problems they had. (It's good to see such honesty in the first place too!)

The group was, as a whole, pretty technology savvy – or at least that was the assumption. This assumption led to the first major mistake [emphasis theirs]: not enough thorough evaluation of each participant’s level of social media competency and experience.
...
We ended up defaulting to e-mail quite quickly for two reasons:
firstly, because everyone was definitely using it; and secondly because we trusted it to give us our own record of what had been said that we knew we could rely on.
...
The project wiki was useful for collating content together, but it became cumbersome and ineffective for editing the final document together: it was too text-focussed and wasn’t useful for showing layout and graphics to the designer, and also it wasn’t appropriate for delivering to the client at NESTA and inviting formal feedback and signoff. We ended up collating the final handbook in Microsoft Word and using e-mail and tracked changes – which worked very efficiently but broke our collaborative approach in favour of getting the job done.

I'm not surprised they ended up using email. Even though it's not very good for collaboration, there's no obvious replacement (I wonder how they would have got in with Google wave?). Wikis are very text orientated, so you can see why they wanted to use Word for layout. But multiple copies of a document with track changes is still a bit clumsy. There must be a need for a good tool to do that sort of thing.

It's worth reading that chapter to hear what the other three major mistakes were.

Bug fix to blog post - a meta post

It's not often that you write a blog post to report a bug fix, but I put one on the Wycliffe Bible Translators UK blog recently. The bug was amusing, but probably not many other bugs I found would be even vaguely interesting to anyone.

Weather forecast via twitter - wycombeweather

Ages ago I thought it would be handy to have a local weather forecast delivered to my phone, for free. Then twitter came along and it looked like that might provide a possibility. By this time I'd come across the BBC weather RSS feeds.

I tried a couple of "RSS to twitter" services and both worked once and then never again. Google app engine looked like a good way of finding a server to do the stuff to join RSS to twitter. So I cobbled together bits of Python code and came up with this. (Update: September 2010 - updated to use oauth library. You'll need to register your app via dev.twitter.com to get the four keys below. )

(Paste in code from feedparser.org. Comment out the main program stuff.)

(Paste in outh stuff from http://github.com/mikeknapp/AppEngine-OAuth-Library/blob/master/oauth.py)

# Cobbled together from

# http://highscalability.com/using-google-appengine-little-micro-scalability

# http://pydanny.blogspot.com/2008/04/feedparser-does-not-work-with-google.html

import wsgiref.handlers

import urllib
from google.appengine.api import urlfetch
import base64
import feedparser
import StringIO

from google.appengine.ext import webapp

def getWeather():
      content = urlfetch.fetch("http://feeds.bbc.co.uk/weather/feeds/rss/5day/id/2111.xml").content
      d = feedparser.parse(StringIO.StringIO(content))
      if d.bozo == 1:
           raise Exception("Can not parse given URL.")
      return d['entries'][0]['title']

class WeatherText(webapp.RequestHandler):
def get(self):
     self.response.headers['Content-Type'] = 'text/html'

     self.response.out.write(getWeather())
     self.response.out.write('
supported by backstage.bbc.co.uk')


class UpdateWeather(webapp.RequestHandler):
def get(self):
     self.response.headers['Content-Type'] = 'text/plain'

     message = getWeather()
#      self.response.out.write(d['entries'][0]['title'] )
#      message = datetime.now().ctime()
     payload= {'status' : message,}
#      payload= urllib.urlencode(payload, True) Removed when switching to oauth client
# Get rid of degree marks because they turn out as question marks in the final tweet
#      payload = payload.replace('%3F','') degree marks work on twitter, appear as "deg" in txt, still wrong when main URL viewed
#      self.response.out.write(payload)

# Your application Twitter application ("consumer") key and secret.
    # You'll need to register an application on Twitter first to get this
    # information: http://www.twitter.com/oauth
     application_key = "im_not_telling_you"
     application_secret = "nor_this"
  
    # Get these from http://dev.twitter.com/apps/your_app_number/my_token
     user_token = "this_is_a_secret"
     user_secret = "this_is_definitely_a_secret"
  
    # In the real world, you'd want to edit this callback URL to point to your
    # production server. This is where the user is sent to after they have
    # authenticated with Twitter.
     callback_url = "%s/verify" % self.request.host_url
  
     client = TwitterClient(application_key, application_secret, callback_url)
     result = client.make_request("http://api.twitter.com/1/statuses/update.xml", token=user_token, secret=user_secret, additional_params=payload, protected=False, method=urlfetch.POST)
# Removed when oauth implemented
#      base64string = base64.encodestring('%s:%s' % (login, password))[:-1]
#      headers = {'Authorization': "Basic %s" % base64string}
#
#      url = "http://twitter.com/statuses/update.xml"
#      result = urlfetch.fetch(url, payload=payload, method=urlfetch.POST, headers=headers)
#
     self.response.out.write(result.content)


def main():
  application = webapp.WSGIApplication([('/', WeatherText),
('/updateweather',UpdateWeather)],
                                       debug=True)
  wsgiref.handlers.CGIHandler().run(application)


if __name__ == '__main__':
  main()

 You can see the results at twitter.com/wycombeweather and wycombeweather.appspot.com. If you want to do it for your local UK weather you'll need to change the figure 2111 above and use your own twitter account.

Presentations and Powerpoint

My colleague, Phil Prior, and I did a session this morning on presentations and use of Powerpoint. He has written up his thoughts on presentations.

We did a more advanced course last week. On that one I covered a number of steps to ensure things go smoothly. I hadn't practised what I preached (run through it on the actual equipment beforehand), and when I opened up clip art the PC froze so I had to borrow a laptop from one of the participants and carry on from there!

My 1.5 seconds of fame

The BBC Digital Revolution people (putting together a 4 programme series on the web and stuff) asked on Twitter if anyone had questions for Shami Chakrabarti of Liberty.



Her answer:


Original blog entry: Tim Berners-Lee and Shami Chakrabarti interview clips (Video): web privacy and obsession

(cross posted to my personal blog)

A picture of a radio programme in the making

I don't often point to other blogs, because you might as well just read them, but this one was worth highlighting. David Ker has put a photo on one of his blogs showing him at work producing a radio programme with Bible material. Click on the picture to see what the numbers in the stars mean.

Expedia no longer supports Passport/Windows Live id

I've searched blogs and looked on techmeme.com, but I can't find any reference to this. I got an email today from Expedia saying they no longer support .Net Passport aka Windows Live id.

When you click on the "Why?" link you get this. Which isn't really a satisfying explanation.