I spent yesterday camped out at the Googleplex in Victoria, taking part in a hack day Rewired State were running to support UK Online centres.

UK Online is an organisation with a straightforward remit: there are many practical and social benefits to being online, and there's a significant number of folks in the UK who never get these benefits - either because they've never made it online, or because they're net.illiterate. It's not just about lack of access: 10% of these people live in a household which has an internet connection.

The goal of the day was to improve and drive usage of the search facility which the UK Online site provides, letting visitors find their nearest centre, and to get the data underlying this search improved. Mr Thorpe and Sym Roe had prepared for the day by providing APIs onto the centre data, and this made a huge difference to our productivity: everyone was immediately able to poke around and start building on top of their great work.

I ended up working on a couple of things: making the search facility accessible by text message and by a telephone call.

In a team with Premasagar Rose, Daniel Morris, and Sym, we produced a mobile-accessible version of the search facility: text in your postcode to a shortcode and get some info back on your nearest centre. We used the excellent Taykt service to put this together, and you can give it a go by texting "UKONLINE BN14EW" (or whatever your postcard is) to 82958. There is a 25p charge for each time you text in; it's best for UK Online if the cost of this is carried by the end-user.

I hadn't done any real development for some time, and wasn't feeling too confident when I fired up Eclipse... so I opted to work on a teensy little piece of this app which was pretty simple, and pressed a few buttons for me.

It really bugs me when you text into a shortcode and get back lumpy, unhelpfully worded responses which clearly have been spat out of a database. We've known for a while now that people treat computer systems as though they were people, and I've seen this first-hand when trawling through records of text messages people have sent in for mobile services that we run. There's an awful lot of conversational stuff in there from folks who clearly think there's a human being sitting at the other end of that shortcode.

And if your users think you're a human being and will treat you like one, does it not make sense to act like one? If someone texted me to ask for the details of a nearby pub, I might give them a little more than "Park Crescent, 01273 604993"; I might mention that there's no parking nearby, that there's amazing Thai food available until 10pm or that there's a rather nice lemony beer there. I wanted to try and bring a sense of this to the results that anyone texting in to find their nearest centre would get back.

With a single text message topping out at 160 characters, and with a huge variance in the lengths of names and addresses of the centres, the content of messages was going to vary. A short conversation with the UK Online folks revealed that the most important stuff, by far, was the name of the centre and its telephone number. The full address was less necessary: centres would rather have people call up before popping in, and many local visitors would know the centres by name. Equally, opening hours (which we had previously thought might be really important) were not so useful, mainly because of a lack of confidence from UK Online as to how up-to-date the data was.

In the end I managed to drag together a small Groovy script which took a CSV of the centre data, cleaned it up a bit (capitalising names properly, removing centre names duplicated in addresses, etc.) and spat out the best-possible-message for each. Sym then took this and merged it back in with his RESTful API. This "best possible message" could include the centre name, full address, instructions to find it, car parking details, creche and cafe facilities - it depends what we have available and how long the entries for each are. Best case you'll get a result like "Oaks Millennium Technology initiative (OMTI), 105 Farm Rd, Barnsley. Housing estate. Limited on street car park. Cafe. Call 01226 215 829". Worst case, it'll be something like "Shirley Library, Church Road, Solihull. Call 0121 744 1076". Zero rocket science involved, but it scratched an itch for me.

I had a couple of hours spare between finishing this off and the hack demos deadline, plus I was feeling a bit more upbeat, so I turned to a service Chris had mentioned early on. Twilio is a nice webby API for scripting voice systems; you bind a phone number to a URL and can then script the messages someone dialling that number hears, gather audio recordings or keystrokes from them, and so on. I decided to plug this into the search API which Sym had produced, and was shocked at how straightforward it was: within about 90 minutes I had a simple app on App Engine which would welcome callers, prompt them to type in a city name, search for it and read out the results.

Twilio and their API was very simple to work with. The only icky bit was turning a phone keypad into something suitable for entering letters, to let callers type in a town name: the Twilio APIs tell you what digits someone has typed ("53937" for Lewes, say), but no more. I can't decide whether the approach I took was elegant or disgusting: I grabbed a list of UK city names from the Geonames site, then then wrote a bit of code which takes this list plus a sequence of digits, and removes all the city names which couldn't have been typed by that sequence. So, if someone has typed in the digit "2" as their first letter, we know the city name must start with A, B or C - and all others can be removed. Repeat this for all digits, and you very quickly whittle through all possible cities. It's like predictive text, but made out of cardboard boxes and sticky-back plastic, and I was pleased to get a chance to do a miniscule bit of TDD when putting it together.

You can try out the service by calling +12052898881; sorry, Twilio only do US numbers so far, but I think you could hook up a Skype forwarder to them. The voices definitely need improvement, I think - the text-to-speech engine Twilio currently uses is frequently hard to understand.

The demos were good fun. I was particularly humbled at the polished presentation which Chris and his team had given to their web app, designed to give net.illiterates who might find the open blankness of the Google search page intimidating, a good "first reason to go online".

All in all, a good day. I stumbled back onto the London/Brighton line, tired but happy.