Category: Uncategorized

OK, how may of you have ever even heard of Shintaido? None of you? Yup, that seems about normal. If you want to find out more about it, google is obviously your friend – or if not your friend, at least your tolerated acquaintance who you can’t not invite to events of importance. You can find out about Shintaido by reading up on shintaido,co,uk or even shintaido.org.

Why I am mentioning a little-known, barely practised non-martial art on what is supposed to be a blog about user experience? Well, I went to the fortieth birthday celebrations of Shintaido in Great Britain this weekend, and realised that I hadn’t written much about experience.

We talk about experience as if it was all the same thing. There is the sensory experience – visual response, haptic feedback, aural stimulation etc. etc. but we don’t really use experience in the old way, in the sense of getting of wisdom. We don’t talk about the experienced user as the concomitant of user experience. Someone with experience might be someone who knows better than to pursue a path to the end. The experienced user might now when it is best not to bother. When we talk about dealing with the elderly, we are willing to consider their motor skills, their eyesight, or their cultural background, but we don’t value the experience that may help them make the decision not to do what we are asking of them.

Shintaido is about changing your experience of life. It’s not an easy thing today, you don’t particularly get transferable skills from it; although there are moments of pleasure, they are embedded in moments of severe embarrassment and occasional pain. You may make friends, but you may also meet people who you like and then never see again. In other words, it is like life, compressed into a weekend. You hope it has a purpose, but there isn’t an obvious one. In that, it is unlike most other pastimes.

If we are offering users experience, is it something they want to have? Often what we are offering is to make the drive to the supermarket or pleasurable, or faster. We talk about peak experiences as things that you can guarantee, without giving due consideration to the fact that people might arrive at the waterfall in tears, or with cancer, or too busy kissing to look at the view.

I honour the fact that most user experience professionals want to help people live their life. After a weekend of struggling with Shintaido, I would like to occasionally find a way of helping people make sure their life is worth living.

We have now reached the exciting stage of pre-release procrastination known as testing. This is, of course, a vital and money-saving period, full of return on investment and this and that.

There are several ways to test:

1. The developer tests their own code. They don’t want to break it, so they treat it the way that it is supposed to be treated, much like a museum curator unpacking the latest Ming vase on loan from China, with extreme diplomatic and personal repercussions if anything goes wrong.

2. The customers test. This stage can follow immediately after 1. The customer attempts to do all the strange things that they used to do with the previous software, and immediately breaks the new version. In doing so, they may also lose their own work, ideally something that took several months to achieve and which they did not back up before upgrading.

3. The software is tested before release, according to a pre-arranged test plan. This plan usually consists of going through all the things that broke it before (using examples provided by customers), plus checking that any new functionality does what it is supposed to. The problems with pre-release testing are that the examples of failure may have been provided years ago, and that part of the code is as solid as a rock, so you are tempted to skip – always forgetting that code may have been re-factored, and, like the river chewing its way under wharves, large chunks may collapse into the spaces that have been newly undermined.
The other problem is that when you are testing new functionality, you need to know what it is supposed to do. And quite often you discover that there are large chunks of let us charitably call it “undefined behaviour”. Ie, the developers made it up on the fly because they couldn’t get a sensible decision out of anyone else, did not document it, and have forgotten what they did. For best effects, you need several developers who have all implemented the undefined behaviour slightly differently in different areas of the software, but sometimes you can achieve quite good effects with one developer, working on different bits of code with long intervals in between, so they have plenty of opportunity to forget what they did last time.

I have spent today working through the test plan. It has been an exciting and rewarding experience. Obviously we have loads of dummy data in files so that we can automate the tests as much as possibly, feed it in automatically, write out the log, but for various bits of interface testing, we have to sit there and run the test by hand and see what happens.

And as always, I discover that it has been tested that it behaves correctly if someone puts in the correct information, but not if someone puts in the wrong information.

All I can do here, is offer you the joy of http://xkcd.com/327/ on the matter of dirty data. Yes, you happy folk out there, people can be malicious, or merrely drunk, or just lost. Be prepared.

So I have filled out all the little boxes in the spreadsheet and logged several more bugs.

Personally, I think it’s all to do with the user experience. Much like watching people have forty-seven cats put down their trousers – they do it so that you, dear reader, do not have to.

I am so tired of living in a culture where everything appears to be about grabbing as much as possible. It feels as if we are being encouraged to act all the time, that any action is better than no action, and the idea that goodness might be expressed in refraining from action is just seen as weird. So, in the spirit of Zen Buddhism, I will suggest some things not to do before you die.

Don’t try and get a tan. It’s much more relaxing to read inside. If you want to sleep, why do it in public?

Don’t wear a bikini. It’s not a great look, even for men, and the bits come off when you dive in.

Don’t get wound up by your boss. They’re going to die too. Maybe with more money, but it doesn’t  save you.

Don’t watch any of the amazing, highly-recommended TV series. Wait until they come out on box set and then don’t buy them.

Don’t put up shelves in your house. You’ll only put stuff on them.

Don’t write lists of things to do, or not to do. You end up padding them out with rubbish,

This is an obvious substitute for actually writing up anything about the software release. Jiri currently has three half-empty bottles of Diet Coke underneath his desk. This is not a good sign. Mr Grumpy has decided to sell his house and move into a caravan in his sister’s drive. I’m not sure if he actually means this or not. He claims that it is the only way he can get away from the badgers that are building a sett in his garden. GandD are spending most of their days closeted in the conference room. Can you in fact be closeted in a conference room? Caballing in the conference room? Anyhow, they are busy, either having meetings with each other or with a set of lovely lovely doctors who are very enthusiastic about the possibilities of Jeremy Hunt and the NHS reforms and how our software could do just they wanted if only they tweaked it a bit. I have a terrible feeling that this won’t be a case of feature creep but a case of explosion in the feature factory and there will be a massive recruitment drive shortly, swiftly followed by a massive redundancy drive. But hey, I’m cynical.

I’m still trying to work out how to stop Gavin coding. Well, not how to stop him, just how to lock him out of other people’s work. There was a very bad scene a couple of days ago when Ian discovered that some of the stuff that he had checked into the code management system had been checked out by Gavin and horrible things had been done to it. Basically it wasn’t a case of his ewe lamb being taken, it was more it being taken, dyed pink, dismembered, and then returned attached to the back half of a leprous rabbit.

I think I will draw a veil over the coffee room conversation.

We are limited by the time and attention available to perform tasks. As the old saying goes, you can have X that is good, fast and cheap, but you can only choose two out of the three.

In the real world, you don’t even get the choice of fast very often. Some things just take the time they take. If they can be delivered quickly it’s because you have a lot of skilled people giving it their full attention for a short space of time. If they’re not skilled, it doesn’t matter how many people you put on the job, they will a. waste their own time and b. waste each other’s time.

In fact, I started this post last week, but I have been giving it neither time nor attention, so it’s sitting exactly where it was. I’ve been removing dandelions from the back garden now that the sun is out.

You will now claim that there is a third point to the triangle, which consists of rsources. I’d agree with that. Good tools can make an enormous amount of difference, but they do this – no, I wanted to say, either by reducing time or by focussing attention, but actually I can’t quite do that. Of course, they make the job easier, or sometimes you just can’t do the job without them, you can’t make bricks without straw (well, you can now – I assume that saying goes back to the days when the bricks would fall apart if they were only made of mud – can I be bothered to look it up? No, there’s google out there, I’m not that interested. It’s not a vital reference. I’ll just not bother, and, as it were, leave it as an exercise for the reader).

Anyway when designing interfaces, the two things that you need to think about most are time and attention. Do you have the user’s attention? More important, do you need to have the user’s attention? The user is going to be sparing with those two resources, she doesn’t want to waste them, you only have a limited amount of either, and somebody else’s crap interface that wastes your time and makes unnecessary demands on your concentration is the last thing you need.

So in appreciation of you having got down to the bottom of this post, I’ll give you a free joke.

Where does a general keep his armies?
Up his sleevies.

I never said it would be a good joke.

Let’s tick off the Easter rituals carried out:
1. Member of the household in bed with flu? Check.
2. Feeling sick after eating too much chocolate? Check.
3. Brisk walk in icy wind while strange dog inspects your groin? Check
4. Loud and entirely justified row in which I am totally, completely and utterly in the right at all times (apart from an occasional fact)? Check.
5. Bottle of champagne chilling for celebration that does not, in fact, occur? Check.
6. Search of internet for exciting event to take part in over bank holiday weekend which ends up as a serious gogglefest of 1960’s St Trinians films? Check

OK, I admit the last one isn’t quite traditional. They were actually quite entertaining. I could possibly have gone for the Carry On… series to drop down a notch in the non-blockbuster black and white left-field arthouse option. Or the relentless replay of incredibly bad Hollywood blockbusters aimed at five year olds. Or climbed up through the arthouse credibility stakes by claiming to have watched the entire Studio Ghibli season. Mock not, I lost the family copy of Spirited Away before my daughter hit her teen years and may never be forgiven. As far as I am concerned, a video/DVD/bitstream shelf that does not include Some Like It Hot, Casablanca, Die Welle, M, The Battleship Potemkin and the original Wicker Man is the mark of a family that is not giving enough cultural attention to its children. Before you know it they’ll be skipping the Suzuki violin practice, forgetting whether Pride and Prejudice was written before or after Northanger Abbey, and omitting hashtags on twitter.

Anyway, I am proud to feel that I have done my duty. Easter baking took place – with the traditional drop of the cinnamon jar lid into the mixture, thus enabling all products to have a deeply intense cinnamon flavour. Easter egg trails took place. Suffice it to say that I wish they could have more unexpected anagram solutions than either “Happy Easter” or “Easter Egg”. We spent some time trying to convince the children that there was a small but real possibility it might be Faster Dog, but they didn’t believe us.

Next year I plan a complete set of clues leading to a small soft-boiled egg lurking in a handwoven nest. Disappointment should be rife.

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.

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?

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.

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.

Did I say that we’re heading for a release? This is always an exciting time in the office. (Especially when one crucial member of staff was off for two days after an after-show party. I have my suspicions about whether said tin man was in bed with a hangover or something else, but I hope he had a lovely time either way.)

It’s especially challenging at the moment as David came in looking somewhat stressed and very excited.He has made a massive sale (he hopes) to a whole group of GP practices, but (there’s always a “but” isn’t there) they have an extra set of financial issues. They have been using some other package, and want to be able to export all the current data from package X and put it into our package (hitherto not given a name but let us call it “VAT’s up Doc”). And their database and our database have some differences of opinion.

Now Ian, lovely Ian, treasures databases as if they were his third child (and more than his five-a-side football team). He is happy when thinking of such things as efficient sorting tables and effective queries. I don’t talk to him much about it, but occasionally I hear snippets as I go by. Apparently incorporating this other system means a total restructuring of the data tables (whatever that implies). I, of course, want to get my filthy, little hands on the interface and see how their work method compares to our work method. But I won’t get a chance. They are pulling Ian out of the development push to the release date so he can restructure his tables. Worse than that, if he restructures the data tables every other transaction that we use on the data will have to be checked, tested, and possibly rewritten. So there are some heartfelt meetings going on as to how they’re going to organise the development effort and what features are going to be cut so they can squeeze in the restructure and whether the sale is absolutely guaranteed with a signed contract with plenty of exciting trailing zeroes.

And I know that they will cut it and hack it and do whatever it takes and it will require some front end re-design to make it work and no-one will have the time or effort available to ensure that the re-design is going to be user-friendly because what matters is that the transfer is going to work first time.

Oh well. At least I know it’s doomed and I understand why. And at least there’s something fairly stable there for them to hack about with. And looking on the really bright side of life, this does mean that David won’t put any other featurettes in.