Google Mini by bizkit@tw on Flickr

Some days ago I was searching for some XSLT templates to turn my Google Mini search results into JSON formatted data. I couldn’t find any so I’ve rolled my own.

I was surprised that there aren’t more of these posted on the web, so in an effort to save someone else a day or so of development, please have my Google Search Appliance templates.

You can find in the github repository templates to return results in XML, JSON or JSONP wrapped in a callback function of your choosing. Templates are released under Creative Commons Attribution-ShareAlike 3.0 Unported.

Download the Google Search templates.

Golden Gun by Duncan (Flickr)

Russian Roulette and usability aren’t usually two concepts that you might put together, so let me tell you a little story. It involves toilets. In order to protect the innocent I’m not going to say where these toilets are. Sorry.

Long story short

It is possible to design a toilet where all the necessary parts of a toilet are present but arranged in such a way as to leave me unable to find the toilet paper, lead me to spread toilet seat sanitizer all over my face and then be unable to dry it off. Don’t worry, it all worked out fine in the end for both me and my dignity, so let’s set that worry aside.

This is a real story that happened to me a few weeks ago. A set of toilets I regularly use was recently refurbished, and they look very nice indeed. At the same time the disabled toilet was refurbished, but unfortunately this wasn’t done so well. And this is where I enter the story.

How can a toilet be so badly designed as to make it unusable?

Let’s look at the basics of what we need when we use a toilet. We need:

• a toilet
• some method of cleaning ourselves (toilet paper, a bidet or a futuristic Japanese-style toilet)
• a way to clean our hands
• a way to dry our hands

Yet just putting these together does not make for good user design. There are expectations and affordances, some of these cultural, that dictate the form and placement of these elements. For instance, it’s reasonable to expect that the toilet paper be in a dispenser or roll close to where you are sitting on the toilet; that the soap dispenser be obvious and above the sink, and so on.

The toilet paper issue

Lacking a dispenser for toilet paper

The builders forgot to install any kind of toilet paper dispenser. Yeah, that had me confused for a good while. Of the basic things to have in a toilet this would be number 2 after the toilet itself.

Where was the paper? It was hiding in sealed packets on a shelf just out of reach of the toilet itself. Remember, this is a disabled toilet.

The soap dispenser issue

Soap dispenser Russian Roulette

Take a look at the image of the sink just to the left and you’ll see there are two silver dispensers above the sink. The one on the right looks like you press it and something comes out. The one on the left looks like, well, I have no idea, it says ‘Torx’, the name of the manufacturer, and nothing else. The one on the right has some pictograms that, due to the reflective surface and me having taken my glasses off to wash my face, I didn’t see at the time.

I had no idea what the left one did but the one on the right bore a resemblance to soap dispensers I’d used in the past, and due to it being placed above the sink I intuitively thought it must have some connection to washing. This being a hot day I wanted to wash my face. I dispensed the liquid out of the right dispenser onto my hands and rubbed it into my wet face. I quickly realised my mistake when my face started tingling then stinging.

It was in fact toilet seat sanitizer spray. I’d lost at Soap Dispenser Russian Roulette, a game I hope to never have to play again. So why was the sanitizer spray over the sink and not near the object it is intended to be used with?

‘Mr Torx’ is an automatic soap dispenser. You hold your hand under and it dispenses a dollop of foam on your hand. This probably wouldn’t have been an issue had the sanitizer dispenser been situated somewhere away from the sink. With only one dispenser over the sink its purpose could be inferred.

The hand drier issue

Spot the button?

Third-time lucky? No chance. I’d washed the sanitizer off my face with a huge amount of water and now needed to dry my face. The plus point for the disabled toilet is that it at least has normal hand driers. Had I been in the gents I might have had fun trying to dry my face with the Dyson AirBlade. Except, no, they’re not ‘normal’ hand driers – they just look like them.

Attempt number one: I swivelled the nozzle up to my face and put my face to it. It didn’t do anything. ‘No sensor’ I though, must be button activated.

Attempt number two: I saw a bevelled part of the drier, in the position I would expect to see a button. Convention told me this must be a button. I pressed it. Nothing happened.

Secret sensor revealed

Attempt number three: I looked around the drier to find a way to turn it on. It turns out in order to dry my face I had to swivel the nozzle up and cup my hands underneath as if I was drying my hands.

 A Conclusion?

If there’s any conclusion to draw from this it is that good design of ‘anything’ requires effort, understanding and care. You can’t just throw all the elements together and expect it to magically work out. In this instance my story was the result of poor industrial design coupled with poor architectural design. Some of the elements in the toilet looked like they had standard affordances – the ‘button’ on the drier for example – that turned out to just be industrial design artefacts. Other problems arose from the poor design of the space, such as the lack of toilet paper dispenser or the crazy placement of the toilet sanitizer.

The experience has certainly made me more aware of good design interactions in everyday life and how even basic actions need good design to allow them to become seamless and something we can take for granted.

Negative Space.. Positive Energy by Yogendra174

‘Nothing’ has value. Or rather, there is value in the absence of ‘something’.

I had a six hour conversation today that felt part journey, part experiment and part self-discovery. It was a conversation that had rules, written rules, which were enforced. The conversation felt different, it sounded different and it was different.

I have Lloyd Davis to thank for today’s journey. I’ve known of Lloyd through his involvement with UKGovCamp and his role as the father of the Tuttle Club. Until today, I’d not had a conversation with Lloyd. Until today I’d not had this sort of conversation with anyone. What’s most remarkable about it is that it took place in the middle of the most dense gathering of techies from UK government, not the kind of people you’d peg for a social experiment involving conversations.

Rules

Our everyday conversation are defined by unwritten rules:

• Societal rules: such as the drive to be polite by appearing to be interested in what the other person is saying, usually by asking questions or interviewing.
• Fear rules: such as wanting to impress, desperately trying to think of something highly intelligent or insightful to say while the other person is talking, so as to not appear to be stupid; or trying to sell or validate your viewpoint by forcing an argument and trying to win it.

These rules in their various guises prevent us from actually listening to and concentrating on what the other person is saying. Today’s session(s) replaced these unwritten rules with a set of rules designed to increase the overall value of the conversation.

• No more than 6 people in a circle.
• No interviewing.
• No arguing/disagreeing.
• Avoid circumventing rules with body language.
• Remember it’s a game, no-one will die if you break a rule.
• Try not to interrupt. Let people speak until they’ve completely finished.

It was challenging at first. There were lots of natural pauses. I would previously have said ‘awkward pauses’ but as time went on they felt less awkward. The rules felt less like constraints and more like foundations.

As you might expect, the conversation spent some time exploring the rules themselves. and exploring whether the supported a better quality of conversation. I keep referring to this as one conversation. To me it was one conversation, separated by lunch, albeit with different people at different times.

One of the themes that kept recurring was that of ‘nothing’. How the natural pauses became less awkward as time went on, how we strip pauses and filler noises such as ‘um’ and ‘err’ out of a conversation when transcribing it. How ‘efficient’ communication makes no place for gaps, and how much information is contained in the gaps between words; how silence in a song can add an undefinable quality; to what extent our self-image is defined by others’ opinions of us, creating a space within which our self-image exists.

Primarily though, the real value in nothing was to be found in the spaces between each speaker. These rules allowed more time between each speaker to consider what has just been said and to think without feeling the pressure to fill the gap with more talk. The stretches of nothing gave us all the space to properly listen to each other and with that there was more respect and greater understanding.

I really suggest you try these rules next time you want to have a proper conversation with someone. You’ll both benefit.

PS Thank-you to everyone I heard and spoke to on Saturday and over the course of UKGC12

Pink Piggy Bank by kenteegardin

I want to be able to present a piggy bank to my computer and have it open up work’s expenses policy. Sound weird? Maybe not.

Ok, maybe a pig isn’t a good example, perhaps a book-shaped object. I could put an RFID tag into the book or put a QR code on it so that if anyone wants the latest copy of my social media policy they take the ‘book’ off my desk and scan it to get the latest version. No searching in the dark in SharePoint to find out.

It’s a physical permalink. A RESTful object in the real-world sense.

Why?

We have reams of documents being produced and stored electronically – very nice for the trees – but I don’t have time to dig around in someone else’s esoteric Sharepoint file structure to find the ‘unknown unknowns’ contained deep within its underbelly.

It’s a problem I’m sure you’ll know as well as I do. Something needs to be produced – it might be a help document, a template or database of some kind – but it’s something worth you taking hours or days to lovingly create and tell the whole office about. Then you find out that someone else did the same thing a couple of months ago, but you just couldn’t find it.

This point was raised recently at a meeting I was in. The discussion was around how to synchronise paper copies of a  huge manual. One argument was that we shouldn’t be producing paper copies as we all work electronically anyway. Another argument was that printed copies are useful as it’s hard to argue against the existence of a physical printout of something. The conversation bounced around these two points of view for a while, and strayed into the territory of how to surface a team’s ‘important documents’.

The concept fluttered around my head for a little while. The impact and immediacy of a physical copy is undeniable. That an electronic copy is always up to date is a huge advantage. How can we link the two?

The physical artefact that demonstrates the existence of something doesn’t have to be the thing itself. Link your toy train to the train booking form.

If you do produce physical copies of content, provide a permalink on the physical copy so people can get the latest copy electronically.

From TORIMBC on Flickr

This week I caught up with a team I did some work with last month. They invited me along to a team away day to help them tighten their tone of voice and find a way to deliver consistent messages as a team.

I initially thought I’d be doing an hour or two on it but was asked to facilitate the whole day which was quite an honour and also at least as daunting a task to me as standing up and belting out a karaoke classic. I needn’t have worried as in the end all I needed to do was set the premise, choose a few facilitation tools (thanks Gamestorming!) and redirect focus a couple of times. The team themselves did the rest. Anyway, that’s not the point of this post, I’ll go into that at a later date.

One of the throwaway, possibly glib, comments that I picked up on the day was about how ‘management’ only ever seem to focus on issues or things that have gone wrong. I’m sure this isn’t specific to this workplace and I’ve certainly seen it at many of the places I’ve worked over the years. It is only natural for those in charge to want to focus on fixing things that haven’t gone well. The problem comes when all the focus is on what went wrong and there is little time for recognition of what went right.

To paraphrase the way it was put to me, “we make tens of decisions every week, yet it’s only the one decision that is challenged that is ever mentioned and that really hurts the morale of the team.”

That got me thinking of ways that you could represent the amount of good work a team does with real visual impact. What if for every decision/action/feature your team make, take or implement you inflate a balloon (red of course for maximum impact). For every decision that is challenged, you pop a balloon. I’d bet that by the end of the week you’d have more balloons than you started with.

Who needs a weekly dashboard report when you have 99 red balloons floating on the ceiling?

To me, at it’s most basic level, Agile (specifically SCRUM) tackles the issue of making best use of capacity when faced with a large backlog of work, changeable priorities and multiple business teams with conflicting priorities. Which is a challenge I face at work, but not with software development.

Two years ago my team processed (edited, proofed, published) around 90 distinct pieces of work. Last year that had risen to around 160. This year to 290.

That’s a large backlog of work.

Given school holidays, party conferences and exams season are all unavailable for publishing and you can soon see that there are less days available in the calendar than items that need publishing. On average an item will take two weeks to go though the editorial process and we have one person to manage that process. This is a definite capacity constraint.

Priorities change as a result of being a reactive organisation. Most of the time, if things are going well, you won’t hear of us. This leaves us responsive to external factors and the changing priorities that go along with that.

Finally, we are a business support team servicing multiple internal clients. Each of whom is trying to publish work that is important or time sensitive to their area.

Backlog, capacity, changing priorities, multiple clients. The factors are the same but will the process fit?

In short, I think parts of the process aren’t so good a match. There is no appetite for returning publications to the backlog if they cannot be edited in time.

Other aspects seem like they should work well. That the business prioritises what is important for the coming sprint being one of the most important.

However, the concept that I’m going to try and sell into the organisation is Release Train Management.

One of the constant asks of my team is “when will my report be published?” The usual response being along the lines of, “when can you get the final draft to us?”

Release Train Management will allow us to set publication dates (the departure time of the train) in advance without needing to know what is being published.

Authors can then book slots (seats) on a release (train) and be given a deadline by which they have to pass over their final draft for editorial (be on the train before the doors close.)

The analogy works as you dig a little deeper down. If a senior business partner insists that a train had to be held for a late final draft then they will have to take into consideration delays to the current train and all following trains. The consequences are clearer than previously.

All in all I think applying a SCRUM methodology will be a hard sell as the concept will be completely alien to the business, but it will be one worth fighting for as I can see few other processes that take regard of the capacity of the delivery team.

I’ve created a Prezi on Release Train Management for Publications to help try and get the concept across to those who’ve not used it before.