Work

Help!

  • Thursday, 15 March, 2007
  • By:

I created this blog a while ago. I installed wordpress in a directory called “blog” and left all the other content I’d created before I started blogging in other directories with the homepage sitting on the root. I used the wordpress style sheet across all pages. This was a bad move. I now want to use Worpress to handle all the content management on the site, so I can use the power of Themes and all the goodness that WP offers that is denied to me at the moment. My problem is this. How do I have an instance of WordPress in my root directory (so all content has a URL www.dancingmango.com/???? rather than sitting in www.dancingmango.com/blog/????)

I don’t want to loose any existing blog URLs or break any links in the blog. Does this appeal for help make sense? Can you help?

It gets worse…

  • Friday, 9 March, 2007
  • By:

The other day I wrote about how Surrey County Council had a “problem with their systems” and couldn’t tell us what school our daughter has a place in. We were supposed to be informed last Wednesday. They’d promised to “send the letters out” on Friday, today. Being impatient I rang them up; now the letters have been printed surely the relevent data would be available to give out on the phone to impatient parents.

Well yes and no.

Yes we should be able to give you the information I was told, but sorry we can’t. “Our database has crashed!”

I’m incredulous.

“It’s the EMS” I was told, “I can’t even log in to it. Today of all days”.

Is this Capita’s Extended Management System? Capita, the company whose chairman gave a £1m loan to the labour party? Suddenly, (much to my shock and surprise) the Tories are becoming ever more attractive. Partciularly with the Shadow Chancellor standing up and demanding a greater use of Open Source. As a tax payer this is great news! And as employee of a great company that champions Open Source even better!

I’m exercising my democratic rights next week and talking to my (Tory) MP about the farcical IT “solution” that is operating in his constituency, and will back up what his parties money man is saying.  And maybe my voting intentions may be swinging.

Rich fat client

  • Wednesday, 7 March, 2007
  • By:

Sometimes we use terms that we just assume everybody understands.  I was recently at at bank looking at how they manage their client relationships.  Conversation turned to the difference between applications that are delivered via the web and applications “on the desktop”.

“From what you are saying it looks like a rich fat client” the developer said.  The banker looked at him blankly.  In his world a rich fat client is someone he has a personal relationship with.

It’s not good enough to blame the computer. Blame the lack of tests

  • Friday, 2 March, 2007
  • By:

It’s education lottery time. Parents are receiving letters bearing good or bad news from schools telling them if their little lovelies have got places in their chosen schools or not. Choice being the big thing – although there isn’t really such a thing as choice, it’s more a preference. Parents have have three choices, ranked one two or three. Good schools have strict admission criteria, and will usually only accept “first choice” children. Don’t get your child into your first choice school and you are at the mercy of the local education authority – no good school will accept parents who rate their schools as second or third choices. It’s not an ideal system, but at least all the letters go out on the same day so you get to know where your child has been allocated a place.

Sadly we fall into the unfortunate category of parents whose first choice has not been honoured. Our first choice school has rejected us on the grounds of distance from the school. Their classroom quota has been reached and we didn’t fill it. That is not good for us! So will we be exceptionally lucky and our daughter get a place in our second or even third preferred schools? We don’t know. And Surrey Country Council can’t tell us.

We’ve got a week of anxious waiting before they send their letters out. They’ve got a problem with their “systems.” Well that is the message I get told when I rang them up. “We can’t tell you anything more because we don’t even know” I was told.
Frankly it is not good enough to blame the computer. If something so critical happens in the private sector, SLAs dictate a course of action; this is a severity one problem that will be fixed within hours. Not weeks. But this is good enough in the public sector where faceless bureaucrats can hide behind the computer, cosy outsourcing deals with little accountability mean that no-one really needs to take responsibility. Take responsibility for the pain and distress this is causing me and my family!
So I got their press office number from the website and rang the Head of Communications. She knew nothing of any problems with letters going out, but promised to have someone call me back to let me know what the problem was.

A little while later I got a call back and was told that there was indeed a problem with the computer, specifically in resolving offers, and in particular resolving offers where children have other siblings already in the school. I was also told that they’d earlier had problems in importing data into their systems.

Now the deadline for getting completed applications in is the end of October. That was four months ago. Four months to scan several thousand forms and process the data, and get it right. That is not such a hard task is it? OK, so the process changed for this round of admissions so changes would have been required to the systems, but even more reason to make sure you get it right. It begs the question, was there a test strategy in place? Did anybody do any testing? I believe that the system has been outsourced to Capita. Has anybody at Capita heard of test driven development? It strikes me that this sort of project is ripe for an agile approach to delivery; a business critical system that cannot fail, simple business rules… I wonder if my MP is going to listen to this story…

Zen and the art of sitting at your desk

  • Tuesday, 27 February, 2007
  • By:

We are creatures of habit. I was recently on a gig where we were helping a client innovate, creating a vision for a new product. When I wasn’t out talking to or observing users I was in our “war room”. Four weeks sitting in same seat; every day the four of us in the project team sat at the same place in the room. When our sponsors came into the room they sat in the same seats. Habit. Retuning to the comfort of our “spots”.

In organisations that promote hotdesking, people will still naturally move towards the same seat. People have their “spots” that others soon recognise. Same seat, same view. Can’t sit there, that’s Jacks desk.

In our room anything we produced went on the walls. I faced the processes. My colleague opposite me faced the personas and their descriptions. This view undoubtedly influenced our thinking. Reflecting on the four weeks, I was more process orientated, my colleague moew persona orientated. Because process was what I was looking at and personas what he looked at.

A long time ago I spent a while in the foothills of the Himalayas in India at a Buddhist retreat. When entering the meditation hall the natural thing to do was to go to the same place. The teacher said don’t do this. Returning to the same position every time was to become attached to that place. And of course in the Buddhist world all attachment is suffering. You get attached to where you sit; if you’re prevented from sitting “in your seat” you’ll be miserable. But what are you missing by never changing your view?

So why not try something different tomorrow. Sit somewhere else. It will feel uncomfortable (attachment is suffering; you were attached to that desk by the window, now it is gone you suffer). But maybe it will offer you new insights, to see things differently, to talk to different people. You never know, giving up that attachment may be the first step on the road to your professional nirvana.

This impatient monkey

  • Wednesday, 21 February, 2007
  • By:

I’m impatient.  I also expect technology to work.  When it doesn’t appear to be working, when I’m getting no feedback as to what is happening, I get frustrated.  I click-click-click the mouse button.  I hammer the enter key.  I repeatedly thump the keyboard.  “Work damn you!” I curse.

The technology was probably just creaking along, it may have got there in the end, but my hammering is the last straw, it breaks the application. Frozen out, frustration turns to user anger.

The developer tuts, “it’s your own fault” he says, “you broke it with your impatience”.  And that is why Dan North’s recent blog about Monkey Testing fills me with happiness.  Testing software for my monkey behaviour, so that it doesn’t break when I do things that I’m not supposed to do – because I am human.

blog style

  • Monday, 19 February, 2007
  • By:

My latest post resulted in a comment accusing me (in jest I am sure) of being a usability nutter.  The comment was a fair one.  But it raises a couple of questions about blogging;

1.  Should I edit the offending blog in the light of the comment?  Probably  not.  I’ve responded to the comment and I’ll leave it at that.

2.  More fundamentally, how should one blog?  I tend to bash out a stream of consciousness, usually using notepad on the train to work.  I then upload it and post it.  I’ve not yet put a spell-checker on WordPress so often publish with typos.  I rarely  proof read (beyond a cursory glance) what I’ve written.  I contrast this with other bloggers who refine what they write and only publish when they are really happy with the article.  Personally, I like the urgency of blogging, just getting stuff out.  And if every now and then I get stuff wrong, I’ll be humbled and move on.
(BTW, I’m not a usability nutter:) )

The Total Experience

  • Thursday, 15 February, 2007
  • By:

The customer experience doesn’t start on the home page and finish on the payment confirmation page. A compelling customer experience comprises of a number of factors with the different factors residing in, and owned by different parts of the business. This can result in parts of the experience being excellent, others being shocking, such as at the Early Learning Centre. Projects that are driven forward by “IT” rarely see the bigger picture; the project manager’s primary concern is with delivery. And this means producing a product that covers all the use cases or stories that were specified in the plan. Agile development practices often reinforce this; an agile team is (rightly) focussed upon delivering technical excellence according to the “customer’s” requirements. The trouble with this is that project success in the on-line world goes beyond just delivering working software. Success is all about the total experience.

I’m sure there are a hundred and one different frameworks for “e” success. The following works pretty well for me.

The Total Experience Model. Copyright Marc McNeill!

Compelling proposition
Any on-line offering starts with its proposition; what it is offering to the market place. Do we know who the consumers are (segment), how many of them are (market size) and their propensity to buy? What is going to attract them to the site, and what is the glue that will draw them back.

Findability
Well if no one can find your compelling proposition it’s never going to make you money. Do you have a strategy in place for ensuring consumers can find your proposition? This starts with search engine optimisation, but will extend to affiliate programs and making a noise about you (Product team blogging?). And then when they are at your site is navigation intuitive? Is relevant and wanted content findable?
Personality
What is the product aesthetic, what does it look like? Is it branded? Does it exhibit production values that reinforce the brand? How does the overall experience make me feel – how does it emotionally engage me?

Content
Content is king. But all too often it is a bit of an afterthought. It’s not just syndicated content, or articles that subject matter experts might write, it is all the copy, the words that appear on the site. Do they support the proposition, or are they just placeholders that the developers wrote and never got updated? Related to content, and maybe it should have a bubble unto itself is community. I think that increasingly, successful eCommerce offerings will include an element of community. Fulfilling the promise of the ClueTrain manifesto from several years back?

Technical Excellence
Working for a company that undoubtedly employs some of the finest developers in the market place, this is something I see a lot of. But it means nothing if the other elements are not realised. Technical excellence includes those “non functional requirements” that development projects talk about; reliability, performance, scalability etc etc.

Usability
Learnable, speaks the user language, memorable, all those old chestnuts. Probably the maxim is “don’t make me think”. Aligned to usability is accessibility; we don’t want to exclude potential consumers through sloppy implementation.

Operational excellence
So the on-line experience may be compelling, but what happens then. Is the fulfilment channel fulfilling? Is there a promise to deliver goods and is the promised delivered upon? What about support channels? Do they support or do they just pay lip service to the concept? Does the web experience go beyond the web and cross other channels? Can consumers start a journey on the website and seamlessly conclude the experience in store? My blogs on Early Learning Centre, Norwich Union and a seamless experience all touch on operational excellence.

Test – measure – refine
Underpinning these factors is the need to constantly test what we do. We can all learn from Test Driven Development (TDD); write the test first and only have the confidence to proceed when it passes. How do we know it has passed? Well we need to measure it; we can only know success if we can quantify it. Based upon the feedback we refine; test – measure – refine, a concept core to agile software development practices.

A lot of words and a picture that belie a simple concept. When working in the web world, always think about the total experience. Break out of your silo (be it technical development or marketing strategy) and think holistically. What will the end to end experience be for your consumers? A technically excellent website is not success. A polished, well branded look and feel is not success. Success is compelling total experience.

What if it began with UAT? (Agile and interaction design are compatible!)

  • Thursday, 1 February, 2007
  • By:

There’s an argument brewing that pitches the agile community against the interaction design community. (You get a feel for this here via here ). Personally I don’t get it. The two approaches are a natural fit. You just need a bit of pragmatism and an ability to say “it depends”.

The interaction designers argue for ethnographic research, lots of user research, and only when we have a thorough understanding of the users, their goals and the context of their usage should we start thinking about writing code. The agile developers will say the only thing that is worthwhile is “working software”. Get something out there, quickly, and see what the users think. The agile approach mean that the direction of the software can be changed at the drop of a hat… If you are working in an investment bank, with a small user base who want this approach may be valid. But if you are building a large public facing web site, diving straight into code with little consideration of the users (e.g. their demographics, itentions, motivations etc.) would seem to be somewhat misguided. It need not be like this. At ThoughtWorks we start many engagements with a “QuickStart”. We’ll work with the client to produce a vision of where they want to get to. We’ll listen to end users, sit with them, watch them. Then use models; financial, process and visual to gain concensus and understanding of what the project is aiming to achieve. We do this quickly, focussing upon the outcomes the client are looking for the project deliver.

The visual models are straight out of the interaction designers tool kit: wireframes. Pen and ink sketches of screens, maybe on paper, maybe in PowerPoint or Visio. Alongside this we’ll watch the users, spend time with them and experience how the software will impact their lives. This doesn’t take much time. We don’t look to produce formal documentation – output is scribbled on cards or on flipchart paper stuck on the walls. In two to four weeks we’ve got a good understanding of the as-is situation, and produced a vision of where we want to get to. The benefits of this? The users get a feel for what might be in the application, we can write better stories (requirements) that are more explicit on what is needed and the developers have something more concrete to estimate against. Finally, when it comes to release planning we can visualise what a cut down version of the application might look like (and thus begin to manage expectations that they are not going to get everything in one big bang, and that things will probably change during the journey). This is not big up front design. It is quick and dirty. It is interaction design (e.g. personas, ethnography, low fidelity prototyping, user testing etc) and agile (e.g. rapid, iterative, incremental, tangible… hey! it’s test driven development without code).

Ah! Test driven development? So on my current project we showcased the wireframes and a comment came back from one of the users (someone who will actually use the application, not one of the “business representatives driving requirements).

“What you guys are doing is great,” he said. “UAT at the beginning”.

I rather like this, but with a caveat. All to often the first time the users see an application is when it comes to user acceptance testing- UAT. UAT has always struck me as a bit weird because it is rarely about “acceptance” (even weirder how it is so well embedded in the IT development lifecycle whilst usability testing rarely gets a look in). It is more about testing for bugs that the developers may have missed. It’s not whether I, as a user “accept” that the product is any good. It is probably the first time I’ve seen it. Maybe I’ve got a test script to run through, I can play with the application, but it is so late in the lifecycle that if I don’t “accept” that it is any good, nothing is going to change.

Agile proponents will argue that with small, regular drops, users are able to raise concerns earlier in the software lifecycle. Regular showcases at the end of each iteration will bring to light issues around “acceptability” and acceptance of the software. But these showcases are usually with the “super user”, the “customer” who is feeding the team requirements. Rarely is it the little person who will actually use their application. And then, even in agile, you’ll often have UAT. It will come at the end of a number of iterations, before the first “release”. But already the direction of the application is set. There is less to accept (and therefore it is easier for the direction of the development to change – one of the benefits of agile) but there is still scope for users to dislike and reject what is being released. And that is why doing UAT at the beginning, user acceptability testing, rapidly, user the interaction designers toolkit is such a good thing. You’re getting the users involved. Your testing and refining the vision. And probably getting usability in there by stealth.

Here’s a paper I wrote about this a while ago: Agile and Interaction design paper

Would you humanise a hammer?

  • Monday, 29 January, 2007
  • By:

User. Male. 57. Bank customer. Usability test of bank website. “I hate computers. Why are they so damned difficult. They’re supposed to be so clever, and yet half the time I’m left clueless what to do next”.

Interaction designer: Humanise the interface. Speak the users language; be intentional not instructional. “I want to move money to another account” not “Transfer funds”.

Developer: “Bah humbug”. (Well he didn’t really say that. What he did say was…) “Would you humanise a hammer?” “I want to tell the computer what to do”. (I suppose you’d like a command line prompt then). “I don’t what the computer to tell me what I already know what to do”.

Moral of the story: you are not the user. What you want, how you do it and the way you (and also the person who is commisioning you to write your code) do it is almost certainly not the way the end user wants to do it. And unless you speak to them and watch them you will never know.

7 of 13
34567891011