Affective interaction: why feelings matter

Obviously feelings matter to people, there is at least one case study that shows that if you cannot feel emotions, you cannot make decisions, because you have no way of deciding what matters. But why do feelings matter to computers? Or rather, to how computers communicate with people or people communicate with computers?

It’s easy to think of people monitoring your feelings as frightening. For example, there’s one discussion of what would happen if the computer interpreted your voice, so you’d have to say “good morning” to your computer every morning, and your computer would thereby gather a stack of data about your speech and be able to respond to your emotions. Yes, this all does sound a little like the extremely irritating lift in hitch-hikers guide to the galaxy. And in fact, one of my favourite bits of research on computers and emotion is that people prefer talking to a grumpy, irritable computer than to a smooth ingratiating one. There’s a possibility that this is due to the person attempting to get the computer to be less grumpy. In other words, “Go Marvin!, we really do love you”.

But where computers responding to emotion is already important is in hospitals. Robots are used to take people around, and they need to recognise from people’s movements and expressions how important it is to get out of their way. We like that. Well, I do anyway. That’s robots avoiding us when we’re in a hurry. That’s the automated check-out at the supermarket noticing when it is being outrageously irritating and shutting up. That is the ATM that argues with you.

I think there is scope for developing a computer version of a teenager. That you could practice being irritated with and when it kept arguing back to it you could “SWITCH IT OFF”. Smugly.

The joys of failing tests

Did I mention that we had the opportunity of a massive contract if we could set up the interfaces between the system that is currently in use by a group of practices and our amazing easy-to-use fabulously intuitive (or not) new system?

Well, what has happened is that justintimeJack has been pulled off his bit of the development work so he can concentrate on working out all the interface code. JustintimeJack is going skiing next week. He’s very excited about it. Every time I pass his computer I see that he is checking the current snowfall in France. Oh I am so so sorry Jack, it’s snowboarding not skiing. You are sliding down an icy and cold slope on one bit of laminated fibreglass, not two (yes, I know it’s not fibreglass, I am merely giving all your cold-weather sports pedants the opportunity for a brief moment of superiority as you get a photo taken of yourself drinking marshmallows soaked in cocoa in your hot tub).

I, with my well-known talent for knowing what the user wants to do, am writing the test plan. I like test plans.

What does this one involve?

This one involves creating a massive number of spreadsheet records, containing every possible combination of hours and rates and holiday and part-timeiness and whether they’re a partner or not, and whether they’re claiming civil partnership adoption allowance and so on and so on and so on.
And running them through Jack’s conversion algorithm to see if they all come out in the right place with the right rates on them.

And then adding the record where it fails to bugzilla along with a description of how I managed to make it break THIS time, and assigning it to jitJack along with one of the highly-amusing states that the developers put on a bug.

These can be summarised as follows:
Not a bug
Can’t be arsed
Can’t recreate
Duplicate of xxxx
Only if they pay us more money
If we have time
Crucial
Deal-breaker

And of course, all the ones that people spend all the time on are the ones they find interesting and the deal-breakers, where smoke is emerging from Ian’s nostrils as yet again Nick explains why he did three of the “if we have time” bugs rather than the dull but crucial one.

And I get re-sent endless copies of can’t recreate – often with a “which version were you running it under” or “where’s the file”

to which my replies nearly always “the latest” and “It’s attached”.

Anyway, my skills at describing exactly what went wrong this time are going up by leaps and bounds. Let us celebrate. We nearly managed to complete a whole import export and re-import data cycle. Doesn’t that sound fun?

Why can’t life be more like the movies?

So why isn’t life more like the movies?

On film, boring moments are skipped. This period before a release would be covered in a few shots: Ian in earnest confabulation with Mr Grumpy, Justintime Jack throwing a juggling ball up and down, Gareth swigging coffee as he types , Jiri’s head resting on his desk. And that would be it. Perhaps a minute of screen time encapsulating the last desperate push towards the release.

In the perfect world, I would already be on the next project. I’d be out there in the world, researching, discovering, designing, exploring. My 3B pencil would be glancing swiftly over drafts in my sketchbook, which could be converted to mock-ups in balsamiq or Axure or…

But that’s a film fantasy, right up there with happy marriages ever after. Instead I’m testing testing testing. Let’s face it, a usability consultant is a wonderful thing, but even more wonderful is someone who will sit and write a test plan. And then carry it out.

Happy crashes and the world of risk analysis

There was a great conversation at work today, about what a real emergency is. Someone pointed out that a real emergency is something you haven’t planned for. In this case, it wasn’t the total system crash (that’s all in the disaster recovery plan) or the mirror server not being online when it crashed (because that’s not really a problem and it was only a couple of hours of data lost). It was that the crash happened at the end of the month, when pay normally is transferred into bank accounts, and the four hours recovery time would make a significant difference to how long the pay transfer took. And there were a couple of members of staff who had mortgages to service and credit card bills to pay and speed of access to their dosh was a bit vital. So the manager at this GP practice went round the car park and emptied all the parking meters. And with the fine collection of £1 pieces and other items of change, managed to procure enough cash to provide emergency tide-over to anyone who really needed it.

It was wonderful. I only heard about this second-hand, because our IT manager/support queen was out there  with tranquillisers, damp towels, caffeine tablets and the off-site back-ups. Apparently the manager told everybody what the situation was, and they all decided who really needed the money. Of course, that might be because it’s a doctors’ practice, and let’s face it, doctors are normally in the job (or at least started in the job) because they wanted to help people one way or another, so it’s not really surprising that that’s how they dealt with the problem.

Could the problem have been averted? I don’t see how. Even if we’d done a full model and considered the effect of different scenarios at different times of day or coinciding with crucial events, we probably wouldn’t have done anything about it. And let’s be honest, we wouldn’t have spent the time or effort modelling, what happens if … the crash happens during a royal wedding. We might have got as far as thinking, what happens if it crashes with someone in the office/no-one in the office, but I don’t think, realistically, we’d have considered what happens if the four hours downtime coincides with payday. And if we had, we would have decided that it probably wasn’t worth the effort of providing cash on the premises to tide people over.

So I might blog about risk analysis another day, but until then, I want to send many many thanks to the guy who saved our bacon by opening the parking meters. Or rather (because our bacon is absolutely fine, thank you very much) the guy who helped the staff members who would have been severely disadvantaged by the side-effects of a risk that had been assumed to be acceptable.