Month: May 2013

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.