Category: mobile

Text Adventures Via Text Message

Remember text adventures, eh? They were pretty nifty!

"You are in a maze of twisty little passages, all alike"
>Go East
"You have been eaten by a Grue. A dwarf starts singing about gold"

Smashing! Just like the pictures are better on the radio, so the graphics are immeasurably superior when they're in your head. Don't get me wrong, I love the 5.1 surround sound snarl of a rabid beast rendered in 1080p - but nothing is quite as good as using your imagination.

Text Adventures - or, more properly, Interactive Fiction - is enjoying a mini-renaissance at the moment. There are emulators for smart phones, computers, and consoles.

But for SMS? None that I could find. Think about it; SMS is close to the perfect medium for Interactive Fiction. Your commands are concise enough to fit into a single message, you don't have to worry about the speed of your response, everything is text based.

So, I present to you, Zork via SMS (with a little help from Twilio).

Twilio Zork SMS

Brilliant!

HOWTO

Although superficially a simple project, there are a few gotchas along the way. This documentation is mostly for me - but may be of use to you :-)

Let's start at the end.... Using Twilio you can send an SMS to a phone number, that is then POSTed to a webserver of your choice.

Twilio will send an SMS back if it receives a response such as

< ?xml version="1.0" encoding="UTF-8"?>
  1. <response>
  2.   <sms>You are in an open field west of a big white house with a boarded
  3. front door.
  4. There is a small mailbox here.
  5. </sms>
  6. </response>

Easy enough. (NB the free account prepends your messages with a trial message. Once you pay, that goes away.)

So, how do we get a text adventure like Zork running server side? There are plenty of client side emulators out there - but I only found one which was purely server side.

THCnet have a PHP interpreter for Zork. It's slightly cludgy - but it works. I'm checking to see if I can distribute it on GitHub.

The game library "dtextc.dat" must be installed in "/usr/games/lib/". The source code is available if you want to recompile it and place it somewhere more accessible.

A MySQL database needs to be created to keep track of users and sessions.

A temporary directory (which must be readable and writeable) will also be needed to store the state of play for each session. I've used "tmp/404/" but you can alter config.php to point wherever is convenient. You will also need to adjust index.php and functions.php with the new location.

Finally, the executable "zork" must be runable.

That's pretty much it.

When a user (or, in this case, Twilio) first makes a request to the URL, we check to see if they already have a session cookie.
If they don't, create one, and start the game by returning the opening text.

For every subsequent connection, we check the state of the game based on their cookie, then apply the body of their SMS to the game engine. Whatever Zork spits out, we return as an SMS.

By default, Twilio kills unused sessions after 4 hours, and all cookies will be lost.

Where Next?

It strikes me that the various forms of text adventures are excellent as a sort of mini-IVR. A nice little finite-state-machine which can quite happily run for years. Services like Frontline SMS are great for information sharing, but they're really not designed for this sort of work.

Could we use interactive fiction in places where SMS is cheap but other forms of entertainment are expensive? Could IF be used to augment existing media events? SMS is lowest common denominator - even iPhones can use it.

But, for now, all I have to worry about is someone texting me "Go west'); DROP TABLE ..." ;-)

A QR Specification For Mobile Payments

BitCoin and other crypto-currencies are gaining popularity at the moment - but I remain firmly convinced that they're too hard for the average person to use. I have, however, watched with interest as an ecosystem grows around them.

In particular, I like the way The Pirate Bay (and others) have used QR codes to facilitate easy payments and donations.
PirateBay BitCoin QR-fs8
The QR codes contain only three variables - the payment method (BitCoin), the destination, and a message. As this is a donation there is no value set. There is a full specification for a BitCoin URI scheme which I think is fairly well designed.

I envisage a day when, on asking for the bill at a restaurant, I am presented with a paper slip totting up my purchases with a neat QR code printed at the bottom. Scanning the code will pull up my banking or credit card app and allow me to make a payment. A verifiable receipt is either shown on screen or sent directly to the restaurant.

For example:
QR Payment

PAY:
 WHO:Pizza Palace
 IBAN:GB29NWBK60161331926819
 CUR:EUR
 VAL:27.35
 REF:123456qwerty
 TIME:1370886496

That's enough human readable information - and machine data - to ensure the correct payment gets from one person to another. I'm sure there are some other fields which may be advantageous to add; tax rate, specific location, etc. But it certainly all fit within a QR code.

QR codes can easily be printed out using the current infrastructure of mobile POS terminals. Those terminals already have mobile network access so can be alerted in real-time when the payment is made. IBAN means we have an easy(ish) way to uniquely identify payment destinations. And, in the UK at least, we have a fairly rapid payments infrastructure.

What's needed is a simple standard and mobile banking and credit card apps to support it.

Simple...

The Best Photographer Is The One You Have With You

The newspaper photographer is dead! Long live the newspaper photographer!

I remember - many years ago while I was still at school - being interviewed by BBC Radio. A nice man came in, set up a feindishly complicated tape recorder, positioned microphones, checked the tape, and - on his nod - gave the signal to the interviewer to begin her questions.

Nowadays an interviewer is likely to shove an iPhone in your face when talking to you. If they're very highly trained, they'll fit a spoffle first.

The newspaper's sub-editor has had half her job replaced by Microsoft Word's wriggly red and green lines, hours of airbrushing can be accomplished with a few minutes of clicking in Photoshop, video and audio can be edited on a tablet, and reports no longer need to be couriered back to a printing press.

Technology kills jobs. It always has done. There is a market for highly trained photographers - just as there is for artisinal bakers, coopers, and estate agents - but better technology means that baseline competence can be achieved by just about anyone.

Some people truly believe that vinyl records sound better than CDs. In truth, a high end, properly calibrated record player probably does sound better than a cheap CD HiFi. But most people don't have the time, energy, or money for a state of the art system. A cheap CD player sounds a million times better than a cheap record player. And so vinyl is reduced to an aesthetic curiosity.

The same is happening to photographers.

The best photographs of 2012 mostly look like they were all taken by professionals using high-end gear.

Now flick open a newspaper. How many stories are illustrated with covert snaps from people's cameraphones? How many stories really needed a separate photographer to accompany the journalist?

Journalists already carry a phone. They can write and file stories on it - why wouldn't they use it to gather other media?

On Swearing and UX Antipaterns

For the last few months, I've been curating a Tumblr of a very specific annoyance. I'll let Aral Balkan take credit for inspiring me.


Any modal message—full-screen or alert—that interrupts user flow to ask them to download your app suffers from #doorslam #ux antipattern.
@aral
Aral Balkan

First, a quick definition:

In software engineering, an anti-pattern (or antipattern) is a pattern used in social or business operations or software engineering that may be commonly used but is ineffective and/or counterproductive in practice.
Antipattern on Wikipedia

My tumblr is simply called "I Don't Want Your Fucking App".

It chronicles all those websites which - despite having a mobile web experience - are just desperate to get you to download their app. So desperate that they're willing to slam the door in your face.

Imagine, for a moment, that you are in a mall and decided to walk into a shoe shop. The assistant comes up to you and says "Good morning! Would you like to visit our website? It's so much better than our shop!"
How ridiculous would that be? And yet, that's what these websites do. They tell you to piss off and go elsewhere.

DoorSlam Collection

How It Should Work

Ideally, when a user visits your website, you should deliver the content to them in the most appropriate format. That's it.

If they're using Internet Explorer, you serve them up the correct CSS and JavaScript. If they're on a mobile device, serve them up the mobile or responsive version of the page.

If you do have an app, by all means let the user know - but don't take over the whole damn screen!

It really is that simple.

Apple have created an excellent way to create dismiss-able banners to promote your app.

When you throw up an interstitial, you're not only giving a terrible impression, you're also forcing the user to do more work than is necessary to get to the content they want.

The F-Bomb

Interestingly, the discussion on HackerNews focused mostly on the issue of swearing. Although I'm not usually one to swear for dramatic effect, I thought it would be amusing to have an over-the-top rant which over-uses swearing to the point of banality. It is, if you like, an exercise in over-reaction.

My sweary blog posts do seem to get the most attention. I wonder if it's because people are becoming too corporate. So worried about causing offence that their language becomes reduced to bland words that are calculated to be as emotionally neutral as possible.

I disagree with that mode of acting. I think it's perfectly acceptable be passionate and to let your language reflect that passion. Sure, the level of swearing that I've used is ridiculous - but it is employed to drive home the point. That's how I feel. That's how millions of us feel when we're confronted with repeated petty annoyances in our daily lives.

Swearing. It's not big, it's not clever, but it is authentic.

It's The Little Things Which Make An App

I've been a big fan of Ovo Energy since switching to them last year. They email me a PDF statement, pay me 3% interest on any overpayments, and have their call centre waiting times displayed prominently on their homepage.

So, when they announced their new app, I was expecting something a little bit special. And that's exactly what I've got.
image

An automatic torch to help you when you're rooting around in dark cupboards trying to read your meter. Brilliant.

So, not only does the app fulfil its main purpose (submit gas & electricity meter readings, see my bill, etc), someone has obviously taken the time to see how the app works in the real world. Sure, there are plenty of standalone torch apps in the world - but this is the first time I've seen one so thoughtfully integrated into an app.

Ultimately, this app is probably going to be used once per month. It needs to be simple enough to use that the customer doesn't have to relearn how to operate it every time. More than that - it needs to be delightful to use.

As much as we would all love our users to open our app several times a day, the reality is that they won't. That's why we need to concentrate not on beauty, not on overall UX, but on tiny moments of joy which reminds people why they should keep our app on their phone and keep coming back to it.