Intent and execution in Go's dep tool

I'm starting to understand how the golang dep tool works, especially in terms of adding constraints to a dependency.

Taking the sample case from https://engineering.pivotal.io/post/go-dep-intro/, if we wanted to specify that we were using the dep-changes branch of github.com/fatih/color, we have two choices:

• manually add a line with branch = "dep-changes" to the entry in Gopkg.toml, followed by a dep ensure to update Gopkg.lock and the vendor directory.
• assuming we weren't already using the package when we did dep init or our most recent dep ensure, then on the command line enter dep ensure -add github.com/fatih/color@dep-changes, ensuring we add the code reference before we execute our next dep ensure.

Notes from UKUPA talk on UX and ROI

An excellent evening at Sapient Nitro, herewith some notes and a few thoughts. There was also a good Twitter stream for #UXROI, and @yahnyInLondon did beautiful sketchnotes.

There were four speakers. First up was Joe Leech (@MrJoe) of CxPartners in Bristol (slides here), who pre-emptively trumped all the numbers to follow with a figure of $3.6 billion, the money that flows through the systems he's involved with, each year. He pointed out that the climate for UX practitioners was much more competitive now, with easy wins being a subject for nostalgia, and also mentioned the idea of MVT (multi-variate testing) as "a threat to UX", an interesting idea which coloured my perception of the rest of the evening.

Joe distinguished between Visionary Metrics ("what and why",- emotional, attitudinal factors such as Net Promoter Score) and Strategic Metrics (operational stuff such as conversion ratios, as provided by MVT / AB testing).

His checklist for metrics to be useful, rather than just analysis paralysis:

1. Does the metric have a timescale?
2. Does it have a benchmark?
3. Does it have a reason to be reported?
4. Does it have an associated action?

He then gave us two key metrics to think about:

1. Net Promoter Score: asking how likely a customer is likely recommend your product, site or service to a friend of colleague, in order to judge their overall perception of quality. Very popular with management, in some cases included in personal targets.
2. Conversion Ratios: important to attach a dollar amount to drop-outs at each stage, makes it easier to justify work on that area. What's a good conversion rate? Really hard to answer in general - it depends, but likely to be between 2% and 7%. How much can I expect conversion to improve? It depends, but "by about 0.25% to 0.5% for a full end to end UCD process"

The Day I Learned to Chill the F*ck Out

One of my friends from last week's Keith In London workshop wrote the following reflection on her experience:

The Day I Learned to Chill the F*ck Out
Keith Johnstone in London 2012 

The last six days have been life changing. I came on the 'Keith in London' workshop to learn about improvisation. There are certain times in life where you go to learn something; you go to be told and to be taught. Sometimes you acquire information and very occasionally you are given the gift of a piece of enlightenment. 

In September 2012 I thought I was pretty contented and lucky to know the secrets of life like doing what makes you happy; being open to opportunity and believing in your dreams and goals. What else was there to know?

It took me the full six days to realise that I was terrified of failure. I had no idea. It was a revelation. Standing in front of the group a few different times had paralysed me with fear. My heart was racing and my head was blank. I had a whole lot of theories of why this was happening.

Five days had gone past and the thought of getting up and improvising was now making me want to cry. In fact one time after I thought I had made a complete fool of myself in front of the group I sat for twenty minutes trying not to burst into tears. 

Then the turning point came. As with all lessons learned the advice was simple. 

“Trying too hard is stage-fright. If you are a good improviser I suppose this may terrify you, but if you’re a normal person it will be fine.” Keith Johnstone

Eventually the penny dropped. Stop trying to be a good improviser. The whole ‘be average’ thing started to mean something to me. It felt like the weight was slowly rising from my shoulders. 

I felt better instantly. I was happy to go on the stage, and happy to mess it up – because nobody had actually cared anyway if I got it right or not – except from me. 

On the way to the airport I was singing along to the radio in the car. The words ‘be average’ came into my head. I then enjoyed singing more than I had in years – and it sounded much better too. No pressure. 

Fail happily: the simple lessons are always the most powerful. 

My free ride on a Heathrow Terminal 5 ULTRa Pod

I've been following PRT and the ULTRA project at Heathrow in particular since 2005, so I've been getting rather excited by the prospect of trying it out.

Eventually I got tired of waiting for an opportunity to use the Terminal 5 business car park where the first loop seems to be in a Google-like extended beta, so I just took a bus from work to Heathrow, followed signs to the business car park via level two of the short term car park, and there it was.

(If the image above is at right-angles to reality, use my Google+ version instead)

(Sorry the video is totally un-edited - I'll update it to something shorter and snappier once I've got on top of the necessary file conversion and editing tool stack)

There's a lot to like about this form of transport:

• The pods wait for you, not vice-versa
• They're comfortable - there's no need to stand because you were the last aboard
• They take you straight to your stop without stopping at anyone else's stops
• They take you closer to your destination than a tram or rail line, and aren't scared of a little gradient either
• They're more wheelchair friendly than the bus (though wheelchair users - and suitcase stackers - might benefit from a warning of any gradients)
• Reduced greenhouse effects and zero local air pollution

Were there any negatives?

• The ride was a little bumpier and noisier than I expected, but totally tolerable
• The Door Open and Door Close buttons are familiar from lifts (elevators) and commuter trains, but in neither context is there a separate Start button - I don't mind it, but I really can't see its purpose
• I'm pleased to see that you can go from any one of the three stops to any other one, but I'm really looking forward to seeing the scalability I mentioned in my 2005 post, and we won't see that until you have multiple linked circuits

So overall, the experience was everything I'd hoped for. Sadly we won't see it at the London Olympics, but I look forward to seeing it rolled out to airports, campuses and town centres all over the world.

Reflecting on Central St. Martin's Service Design Short Course - day 2

This morning Vincenzo asked if there were any product designers on the course - I'm not one, but as I mentioned in my introductory video, always wanted to be an inventor, so stood by with interest and was invited to knock up a door wedge to keep the doors open, which I did with creativity and enthusiasm. But when I finished my wedge made from coffee-cup holders, not only was it too big to fit, but as Allan pointed out, both the doors already had handy wall-hooks to hold them open.

Moral of the story? Use research to refine the brief...

Thinking of briefs, I'm on the green team, with a client brief from Camden Council's cycle training scheme. We were asked to review a selection of design methods, and come up with a plan for researching and creating a design over the remainder of our two weeks. We came up with something based on the Design Council's double-diamond approach:

I really want to deliver something good, and I'm itching to narrow the aims of the project down to something that will be do-able but still impressive. But I have to remember that we're still in the opening, divergent, phase of the first diamond, and where I want to be is the end of the second, convergent, phase. I have to hold myself back from jumping the gun.

In other words, I have to trust the process, Francis. Use research to refine the brief...

Don Norman's Living with Complexity - notes for #uxbcldn

I'm reading Don Norman's Living with Complexity for a UX Book Club London meetup, but I am also trying to prepare for the Service Design short course at Central St Martins that I will be taking next month, so I'm going to focus on his comments on Service Design - especially since this is the first Don Norman book I've read where he discusses this topic.

In many ways the book is something old, something new. The old bit - and none the less true for it - is his job description for designers:

The designer's job is to provide people with appropriate mental models.

[ch 2, p29]
The official new element is the complexity of the title, and his view that many devices and services involve an irreducible complexity which cannot be magicked away, as he expresses in a quote:

Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it, the user or the developer (programmer or engineer). (Tesler and Saffer 2007)

[ch 2, p46]

Chapter 6, Systems and Services, and chapter 7, Waits, are the most directly relevant to service design. He discusses the relative immaturity of Service Design compare to Product Design in characteristically IxD terms:

The world of services is different from that of products, in part because they have not been studied as much as products. Although one would think that service providers should also adhere to the standard themes of good interaction design, that is, good feedback along with coherent conceptual models, in practice it is not that simple. Services are often complex systems, barely understood even by the service provider, with multiple components spread across many geographical locations and divisions of the company.

[ch 6, p144]
Don Norman has respect for the challenge: services are described in terms of complexity, back-stage and front-stage, recursiveness (a customer's back-stage may be a clerk's front-stage) and the systems thinking required.

Amongst other case studies, he describes IDEO's re-design of Amtrak's Acela Express: how IDEO declined an RFP for redesigning train interiors in favour of redesigning the entire service, starting with "learning about routes, timetables, costs" through 10 stages to "Continuing the journey" (how true - I would use UK long distance train services far more if I could hire a car at my destination as simply as I can at an airport), and Apple's iPod and iTunes, both illustrating roads to commercial success that involve thinking of the offering as a system and its delivery as an extended service.

I found an equally coherent but somewhat contrasting perspective in Journey to the Interface, a pamphlet published back in 2006 by Demos and Engine Service Design.

They take a more humanist approach:

Service designers do not see service as something that can be reduced to a commodity. They focus on how people actually experience services, in order to understand how large service organisations can create better relationships with their users and customers.

Experiences and relationships are the recurring themes of this pamphlet.

This model is not necessarily incompatible with the Don's - early on we get a little BUPA case study, which ends:

A tangible change that has emerged from doing this exercise regularly is that customers calling to discuss their hospital visit are now offered a checklist of things that other people in similar situations have asked. This was introduced after BUPA realised that people often didn’t know what to ask when the call finished with the question ‘is there anything else I can help you with?’ Alison, again: "You have to do as much as possible to manage getting into people’s shoes – psychologically, emotionally, physically"

Although the terminology is different, this example fits right in Don Norman's emphasis on ensuring that the user develops a mental model which includes understanding the most relevant future options.

Two things that distinguish the Demos / Engine Service Design approach from Don Norman's are,

[1] the emphasis on relationships, eg

The picture of service is no less complex from the interface as it is from a systemic perspective. What is different, however, is that the interface focuses on how people and services relate, not simply the shape of existing services.

and [2], the emphasis on co-production, eg:

Service designers focus on a specific kind of engagement:
engagement at the interface. Deliberation has to take place at the point of delivery to create the kind of engagement required for co-production – that where people are mobilised, coached, and
encouraged to participate in the ‘common enterprise’ of generating positive outcomes.

A point shared by both publications is the difficulty of measuring (and thus funding) the value of services which are designed to provide long-term or preventative outcomes - I would like to have seen some discussion of Social Impact Bonds here, as one apparently appropriate mechanism.

All in all, I'd say Don Norman's book is an excellent overview of various design issues from an Interaction Design perspective. There was a common feeling at the UX Book Club London meeting I was at (IG Index - thanks Jane and Chris!) that it would be most appropriate to an interested non-designer, and in fact the Service Design chapter was found by many to be the most interesting, perhaps because we weren't, in the main, Service Designers.

On Service Design specifically, I found it a helpful snapshot, if conservative in vision. The greater ambitions of Journey to the Interface are somewhat focussed on a specific British context, but I find it entirely plausible that changing the relationship between service users and service providers could have more radical effects than changing the relationship between consumers and their products or programs, especially when achieved by techniques like co-production.

The uses of magic

Being a dad can be frustrating sometimes. Johnny now watches CITV more than the BBC children's channels, and I've been getting polite but continuous requests for the much advertised Bey Blades. And he brings back reading books as homework from school every day - plus two for the weekend - and that's been turning into a mutually dreaded ordeal.

So I was thinking I needed to take a step back and come up with a better way. So I drew a pentagram on a scrap of paper, numbering arms from one to five, and inscribing the initials "BB" in the middle. I then explained to Johnny that each time he read his homework book without flopping or wailing he'd get a sticker on one arm of the star, and when he'd got one on all five arms, we would go out and buy a Bey Blade. He was horrified by this quandary and resourcefully suggested several alternative ways he could earn the stars, which I politely declined.

I would just like to record that by the time we got to the fourth and fifth homework sessions he was snatching the book out of my hands, refusing to let me read it through first, and confidently and proudly reading it aloud. (And today will be shopping day)

Am I proud of stooping to bribery and succumbing to commercial advertising? Not really, but I don't care about that. Johnny's education, and our relationship, are more important, and I'm pleased I worked that out. Could I have come up with a smarter solution? Well, yes, I'm sure and any suggestions gratefully received. Meanwhile, I will gratefully continue to learn whatever it is those who teach learn from those they teach.

#AgileUX Agile Safari to MindCandy.com

AgileUX Agile Safari to MindCandy

Yesterday MindCandy were kind enough to host the Agile UX Meetup group for an Agile Safari where they showed us round their offices and discussed how they have combined User Experience Design with Agile development as part of their current success story.

MindCandy’s original hit product was PerplexCity, but they are now best known for MoshiMonsters, a games, virtual pets and social site for children aged 7-12 which has been described by some as the Facebook of kids, especially now that it has 50 million users worldwide. The product is directly funded by subscriptions, which not only provides a solid business model but gives immediate feedback on the success of new features.

What MindCandy gets from Agile

The story goes that before MoshiMonsters, MindCandy raised $10m, burned down $9m of this on waterfall-style development for PerplexCity, then, 2 months into their final 6 month plan, decided something had to change and introduced agile to make MoshiMonsters. From their perspective, the rest is history, and agile is seen as a core component of the company’s culture, from the top down.

MindCandy's Christmas Party, 2010, with the Big Board in the background

As MindCandy's main product is aimed at kids, and already has high penetration in many markets, they need to keep it fresh by adding features in order to [a] avoid letting their users get bored, and [b] avoid leaving a window of opportunity for their competitors.

How Agile works at MindCandy

A product board meets regularly and signs off projects, basically at a one-line level of abstraction eg “Add MiniGame Fun Park”.

Each project gets a team, some of whose members will be “ring-fenced” for that project (presumably others are shared as needed). The team works with a full-time scrum master (so developers can get on with development), and have their own four-column (Not Started / In Progress / In Test / Completed) section of the big board. There are some kanban-like features too, each team member can only put his name on two tasks. Teams deliver user stories in two-week cycles, the product manager (Dharmesh, in agile terms, the product owner) will focus on delivering something for each user story. Features are may be delivered as several user stories over several sprints.

MindCandy staff see themselves as being triumphantly team-focused in working practices and reporting structures. Co-location is seen as important and all UK staff currently sit together on one floor of Tea House in Shoreditch - they hope to keep the vibe as they expand to another floor.

They don’t do the “we will commit to two the following two weeks worth of work” thing, preferring to simply prioritise whatever’s still on the Not Started list. Likewise they don’t see themselves as deadline driven, though external deadlines such as school holidays are naturally part of the landscape and will help focus as decision time nears - “to ship is to choose”.

How UX works at MindCandy

Yael is the User Experience designer and works with Axel, the visual designer. They sit side-by-side in the middle of the development area. UX work is done within 2-week sprints as part of user stories. User stories are often implemented in two passes, the first (the first week of the sprint) concentrating raw functionality, the second (the second week) allowing for the UI to be optimised.

MindCandy don’t go in for big up-front research, nor do they currently use personas. They do have a good understanding of their target market from long  exposure to it, and from community managers.

Challenges overcome

MindCandy also work with an off-shore team who are fully agile and work on non-game focussed projects to allow the internal teams to work on the core games. MindCandy do company-wide sprint reviews (with team-level kick-off, stand-up and retrospectives), and the off-shore team takes part in these.

Off-shore teams are not part of the big-board but they use Acunote as a light-weight Scrum tool which allows them to do Scrum their way.

They do a lot of Skype - messaging even more than calling - and most desks (apart from marketing) just don’t have phones.

Looking forward

Their current agile and UX processes have clearly served them well so far. As their market gets more mature, MindCandy feel the need to get even more agile, both developing faster and learning faster.

They plan to introduce UX personas in order to target variations in their age 6-14 user base better, and hope to fit more regular user testing into the time and space available.

They now have a full-time business intelligence analyst to identify areas of concern which might otherwise be masked by their overall success, and are extending their use of analytics.

On the productivity front they have a full-time tools and environment expert who describes himself a the “force multiplier”, and who looks for areas of friction which he can automate and / or accelerate.

Finally

I’d really like to thanks Martyn, Raph, Axel, Yael and Dharmesh of MindCandy for a fascinating and exciting Agile Safari, and of course Johanna Kollman and Agile UX for organising it.

What's wrong with: garlic presses?

The garlic press is a classic of redundant-from-birth gadgetry. What's wrong with it?

1. It's pointless. I use the flat of a knife to crush cloves of garlic, followed by a quick bit of chop-chop, to produce more ready-to-cook garlic in less time than finding and fiddling with a press.
2. It's inelegant. I loved being a French neighbour's kitchen while he cooked some supper. He happened to be a professional chef by background, and promptly demonstrated the truly minimalist approach by flattening the garlic with a quick press of his hand.
3. It's slow and yucky. As soon as you take into account the time spent cleaning the garlic press (and the horrors of the incompletely dish-washer-cleaned press) you realise that the manufacturers of this device have stolen your time as well as your money.

I'm never going to live in a state of uncluttered minimalism, but I think I have found a use for my garlic press - as a pungent prophylactic against gadget-buyer's remorse.

Conflicts in quality for a London Man-and-Van Company website

This afternoon I moved half a garage full of books from Hampstead (in North London) to Earlsfield (in South-West London), a process that was made much simpler and less painful by using a prompt and helpful Man and Van company specialising in small moves.

Naturally I got them off the web, and since my work clients are typically rather large banks or building societies and my entrepreneurial friends tend to be in technology or information, I was delighted to find that Leonardo, the nice Brazilian driving me and my books across London, was in fact the founder of the company, and I asked him about his web site design.

From a design perspective their web site is a slightly bizarre mix of truly helpful and innovative stuff, like the fact that you simply book a 3-hour slot (for £40 - where do they get their profit?) from an online calendar, together with somewhat distracting Google-optimised content targeting the different London regions.

For me, as a budding UX designer, this was a bruising encounter with commercial realities. If they kept the site small and focussed, the usability, and indeed the whole user experience, would be improved. But their site has to appear in the first page of search results, and they pay good money to someone to ensure that it continues to do so.

I know very little about SEO, so the only suggestion I was able to make was to suggest they invite satisfied customers to review them online, in order to reduce their dependency on more artificial methods which [a] confuse the site, and [b] might be vulnerable to a Google re-interpretation.

Lesson [1] for some sites, you have to treat the Search Engine as one of your key users.
Lesson [2] even white-hat search optimisation can conflict with other UX goals.

Narrative considered dangerous

An Australian report on responsible reporting of suicides summarises two key findings as

• Reports of suicide deaths can influence copycat acts in some cases;

• The risk of copycat behaviour is increased where the story is prominent, is about a celebrity, details method and/or location or glorifies the death in some way.

Leaving aside for the moment the human implications of all this (and if you and your family have never been touched by suicide or attempted suicide, please accept my congratulations) - from a storytelling perspective, the first point confirms the power of narrative and the second point endorses the methods of narrative.

I'm currently reading Storytelling for User Experience for the London UX Bookclub, which I think is an excellent and useful book (indeed I was one of the early suggesters)

But I've also ordered Storytelling: bewitching the Modern Mind which appears to offer a counterbalance against the misuses of storytelling as a substitute for, or distraction from, concern with truth.

All of our great advances have had fatal consequences. Fire, medicine, electricity and vehicles have all left deaths in their trail as they moved us forward, and have required social and legal regulation as a result. Now, it seems, stories too can kill.

As Spiderman discovers, "With great power comes great responsibility".

Some Reflections on the Mirror Problem

[retrieved from a long-lost backup of a 1998 proto-blog - I think it still makes sense]


Introduction: Reader, meet Problem


If you are human, there is a pretty good chance that you will at some point have looked at people or writing in a mirror and wondered why they are reversed from left to right but not from top to bottom. If you've ever discussed it with friends, you may have come up with ideas ranging from fact that our eyes are side by side to the fact that left and right are relative whereas up and down are absolute.

I recently read an explanation for this phenomenon in an otherwise excellent and best-selling maths popularisation book, and came away with my head hurting and a feeling of dissatisfaction. This wasn't, perhaps, surprising - some years ago a letter about the mirror problem provoked a extraordinary cascade of correspondence in the New Scientist  - everyone appeared to have an answer, but no one had an answer that was so obviously correct that people couldn't help but agree with it.

After reading this book I started thinking about the problem while running. I began to feel that the answer was in some senses rather simple, just terribly counter-intuitive. What a good solution would need was an excellent metaphor, so that you not only ended up knowing the explanation, but knowing that you knew the correct explanation, so clearly that you might even end up wondering why it was ever a problem. I eventually reached such a state - I now clutch the memory of the recent book, of the way-back correspondence, as proof that the problem was ever un-obvious enough to be worth solving.

Here's my solution in three simple steps, with a bit of help from some Friends. And some virtual illustrations. I hope you find it as compelling as I do.

Step 1: Twos and Threes

Width, height, depth. We live in three dimensions. And we have an orientation in each. Picture yourself standing on a giant compass symbol. Your head points up, your face looks North and, should you raise your arms, your right hand would point East and your left West. Turn around, 180 degrees. Your head still points up, but you face South instead of North and your right hand now points West instead of East. Hmmm.. so you've changed your orientation in two out of the three dimensions. OK, back to facing North. Since this is just a thought experiment, let's gently do a cartwheel next, but stop once we're upside down... well, we're still facing North,  but this time our left-right and up-down have been reversed. Back to where we were, and now a simple forward headstand. Now our left-right remains the same, but up-down and front-back have been reversed. So each of the turns involves changing your orientation in two dimensions while you spin round an axis in the third dimension.

The funny thing is, in the real world it doesn't matter how many turns you do, on which axes, in which order, you always end up reversed in exactly two of them, or back where you started and not reversed at all.
Suppose we're chatting at a party and we're standing face to face, and compare our orientation in the three dimensions. Both our bodies are head-up, but my front-back is pointing the opposite way to yours, and my left-right is also reversed compared to yours. It's the same difference as if you had simply turned round in the first of our compass manoeuvres.

In fact, think about anything with a front and a back, a top and a bottom, and a left and a right. A person, a book, even a car. If it's facing you then it will be pointing in the reverse direction to you along not one but precisely two of its dimensions. Front-back (by definition since it's facing you) and either of the two remaining dimensions, up-down or left-right.

Step 2: Ones

Picture yourself in front of a mirror. Compared to you, your image is reversed in just one dimension, front-back. The head still points up, the right hand still points to the East. Right? Mirrors reverseone dimension at a time. It doesn't have to be the front-back dimension, of course, so you can have two mirrors side by side to give an image that looks as if you had just stepped forward and turned around.Is this the answer? It seems simple enough, but why are left with this deep conviction that left and right have been reversed but up and down haven't? Is up-down in some way different from left-right, or is there another explanation?

Step 3: Planet Fussball

Do you know those table-top football (soccer) games that you get in French bars, British student unions and on the US TV series Friends (from where, I must admit, the image popped into my memory in my hour of need)? Where each player stands on one side of the machine spinning the rods with their team's model footballers to score or save goals? Look at the goalie. He is the only figure on his rod, which runs from his right (where you grasp its handle) to his left. We're going to forget about the fact that you can slide him right and left, and just note that the only spin he can do is round his left-right axis, as if he was doing forward or backward somersaults.

Right, now you are a fussball figure. Even weirder, you are in orbit around planet Fussball. (Being moulded from solid plastic, the vacuum fortunately has no ill-affects on you.) You are not alone. The planet is ringed, like Saturn or Jupiter. You are part of a ring, consisting entirely of fellow fussball figures, all of them (like you) born facing in the direction that the ring spins, with their feet towards the planet. Being fussball figures you can, naturally, spin head-over-heels around your waist. Equally naturally you can't spin from left to right, or do cartwheel type spins.

So how do you chat to your friends? You slide up to them and then spin till one of you is upside down (and back to front) relative to the other. In other words the only way you ever see another face is if it is upside-down compared to you, but with the left-right the same as you (unlike this planet where we normally see people's faces  with the top and bottom facing in the same direction as us, but the left-to-right reversed compared to us). Now someone hands you a mirror, and you look at yourself. Being a smart and inquisitive fussball figure you ask yourself "Why is this mirror image reversed top to bottom, but not left to right?". Maybe you wonder if it has anything to do with the fact that up and down are absolutes whereas left and right are relative, or to do with the fact that you have two eyes side by side...

Conclusion: tying it all up

So what does it all prove?

We've established that there's a universal law, that any time you look at something solid face to face, not only is its front-back axis pointing in the opposite direction to yours, but its orientation in one of the other dimensions, either left-right or up-down, will be reversed relative to yours too.

We've noted that on this planet almost anything that turns round, turns round its up-down axis. (Apart from fussball figures, I simply can't think of another example of something with a distinguishable top and bottom, left and right, and back and front that turns, somersault style, around its left-right axis.) So on this planet anything you look at face to face will have its left and right reversed compared to your left and right. In fact this is so common that we don't really think of them as being reversed.

We've noted that we can imagine a planet Fussball where, unlike this planet, it is more common for things and people to turn around their left-right axis than round their up-down axis. We've assumed that people there would take this up-down reversal equally for granted.

We've established that mirror images are only reversed in one dimension, front-back.
Therefore the left-right orientation of your reflection is the same as your left-right orientation, but the opposite of 99% of what you see face to face on this planet, and therefore notable. The up-down orientation is also the same as yours, but being the  same as everything else that you see, not notable.

The simple and complete answer to the mirror problem is that the mirror doesn't mysteriously reverse left and right (or up and down). We reverse left and right on almost everything we see face to face, by spinning it or ourselves round the vertical axis. That's where the mysterious difference between up-down and left-right comes in.

Appealing to my MP to oppose the DE bill

                                        Tuesday 16 March 2010

Dear Sadiq Khan,

I am a published technical author, software developer and interaction
designer with a family - my wife, a freelance accountant, and a four
year old son, Johnny.

I am deeply concerned by the disconnection provisions of the Digital
Economy Bill, which it appears is about to be waved through the house
of commons in a sadly undemocratic "washing up" process.

Both my salaried work and my writings depend critically on having a
full bandwidth internet access, for example when I remotely access my
work desktop from home.

My wife's livelihood as an accountant also depends being able to send
and receive both reports and (occasionally substantial) databases of
financial records.

As an immigrant, she would also suffer a loss of family connection if
she could no longer use video skype to talk to her elderly and
otherwise inaccessible parents.

And Johnny is an enthusiastic on-line follower of the BBC's finest
children's programmes and games, such as "AlphaBlocks" (which is
helping him learn to read) and "Relic: Guardians of the Museum" which
so interested him in the British Museum that I had to take him to see
the Egyptian galleries last Saturday.

The prospect of losing these essential services to an automated process
without judicial appeal is frankly terrifying.

As a software professional, I can tell you that my PCs at home are as
secure as I can make them while staying on-line, but even so I have no
idea if anyone has installed illegal file-sharing software, or if
anyone is making illegal use of legal file-sharing software (such as
the first version of the BBC iPlayer, which I didn't even realise at
the time was a file-sharing server as well as client).

You have a strong record of opposing terrorism. You must be aware that
bad people can be inventive and persistent. It seems to me that the
possibilities that such a process of automated disconnection can raise
are endless.

What is to stop political hackers targeting political opponents? Will
you - as an MP - have any special right to appeal against disconnection
that would be denied to others whose jobs are equally depend on
connection?

Think about the commercial world. We already have well-established
cases of click-fraud (http://en.wikipedia.org/wiki/Click_fraud) being
used to "to harm a competitor who advertises in the same market by
clicking on their ads. The perpetrators do not profit directly but
force the advertiser to pay for irrelevant clicks, thus weakening or
eliminating a source of competition". Will people who are willing to
commit click-fraud hesitate to target the offices of their competitors
with fraudulent copyright fraud allegations?

And finally, consider the implications of legitimising collective
punishment. Other countries believe in bulldozing the houses of people
whose family member are believed to have committed terrorist acts.
Maybe we could take the middle road, and simply disconnect the families
of licence tax dodgers from power, water and sewage?

The music business didn't die from home taping (whatever they said at
the time) and they won't die from on-line copying. Only our liberties
are at serious risk here.

Yours sincerely,

Francis Norton.

Deeply shallow - why Intelligent Design fails the test of Abraham (and Evolution passes)

I was listening to a discussion on the train last week, involving someone talking to his friends about some kind of alternatives to evolution event he'd been to. The people talking obviously had some feel, some care, for truth; and they were clearly inclining towards a view that while Creationism wasn't very convincing, Intelligent Design was at least interesting and maybe it should be given more equal status with Darwinian evolution.

While I kept my mouth shut all the way until they got off at Wimbledon (I am English, after all), I would really like to talk to people like them - reasonable people of faith, who might be considering the pros and cons of Intelligent Design, and offer them a line of argument which may in some ways make more sense to them than to the average evolutionist.

Some years back I was reading a Danish writer who was talking about God's test of Abraham, when he asks him to sacrifice his first-born son Isaac. Now, even as an occasionally resentful second son, I've never liked this episode - in fact I suspect it contributed to my departure from religion. But some - probably misunderstood - memory of his interpretation of the story as a challenge to choice or commitment stuck in my mind, to resurface from time to time.

Another idea that had stuck in my mind was a quotation that had also taken up long term residence there:

"If it could be proved that any part of the structure of any one species had been formed for the exclusive good of another species, it would annihilate my theory, for such could not have been produced through natural selection."

(Charles Darwin - The Origin of Species, 1859, Chapter 6 - Difficulties On Theory, page 201)

Think about how western culture saw nature up to the moment when Origin was published. The general approach was to seek - and find - examples of Divine Providence in the ingeniously helpful disposition of nature. As Darwin continues in the next sentence, "Although many statements may be found in works on natural history to this effect, I cannot find even one which seems to me of any weight."

A few pages earlier, he does something similar:

"If it could be demonstrated that any complex organ existed, which could not possibly have been formed by numerous, successive, slight modifications, my theory would absolutely break down"

(ibid, page 189)

This is just as challenging - an entire strand of Natural Theology had been built on the basis that this was simply not true, including William Paley's well known Watchmaker Analogy.

So Darwin is going out of his way to give opponents a chance to "annihilate" or "absolutely break down" his theory - if they cannot, the world must be very different from what they think. And this is not any old "theory", this is his life's work (it is 28 years since his voyage on the Beagle started him on this road) which, he must have realised, could more or less immortalise his family name. This theory is, almost literally, his baby.

Eventually I made a illuminating connection between these two ideas. Darwin's invitation to his readers to "annihilate" his theory takes similar courage to that of Abraham offering to sacrifice his son - each is offering the destruction of their life's greatest achievement, and of their nearest hope to immortality in this world. And each is driven by a greater love - Abraham's, of God, and Darwin's, of truth.

Now, let's look at Intelligent Design. Whereas Darwin said, in effect, that the natural world we live in is totally different from how we thought it was, proponents of Intelligent Design say that it is almost identical but somewhere, somehow, there is something that will demonstrate Irreducible Complexity or Specified Complexity - but it appears that they do not even seek proposals for actual research.

Frankly, this reminds me an ancient TV sketch where Rowan Atkinson parodies a famous science fiction theme by explaining, over a cup of tea, that he comes from a parallel Earth on precisely the other side of the sun, where everything is just like this earth - except that the gearknob of their Mini Metro has little dimples in it.

Prove me wrong - show me one sentence anywhere in Intelligent Design which shows such courageous love of truth as Darwin's clear and self-imposed tests, and I will revise my views.

But until then, I firmly believe that ID has as much relationship to a brave and beautiful scientific theory as Caligula's horse Incitatus had to democratically elected leadership.

Notes on using WebSort.net

I recently had to design a top-level topic structure for a company-internal wiki. This wiki is intended to replace a predecessor which by now has a poor signal-to-ratio, being cluttered with obsolete articles and hindered by the absence of any kind of lifecycle-management, tagging or rating features. (The new wiki is being implemented using KwizCom's Wiki Plus, but that's not what I'm reviewing here)

But designing a good top-level structure for the mixed bag of topics found in a typical wiki is, like "go forth and sin no more", one of those tasks easier said than done. So I decided to try my first card sort, using 90 page titles from the old wiki as input to an open sort. I initially considered printing the list out and cutting it into physical cards, but this turns out to be alarmingly hard to do productively, especially to any level of quality, so it was time to check automated options. I came to WebSort.net from comments on a great card sort article, and, since it was free, and looked plausibly polished and complete, decided to use it.

Creating the test was simple - I registered for an account, gave the test a name, and simply copied the list of items from a text processor and pasted them into WebSort.

Running the sort was also simple - simply send a URL to your candidate card sorters. (And, if you want to learn from my mistakes, give them a more compelling reason to perform the task than the fact that it's convenient for them and helpful to you). When your users visit the link you've sent them, they get the instructions you left (I stuck with the default wording):

Performing the card sort is slick and sweet. WebSort provides a drag-and-drop interface for sorting the cards, and randomises the card order for each sorter. Unfortunately the slick interface is provided in Flash, and there are some gaps between the safety, transparency and reversibility of direct manipulation and the overall user experience - there was no way for users to print screens, or to save and resume. These are irritations, I'd say that the primary function here has been very well delivered.

Reviewing the results is slightly less polished. You see a list of all completed sorts, keyed by the sorter's email address. You select one or more names and hit "Reload" to load that particular data set. Once loaded the data set can be downloaded as a spreadsheet or in various text formats. The default display is "Category Summaries". This, along with "Categories * Items" is of limited usefulness in an open card sort where users invent their own category names, since each user typically invents different names. WebSort have helpfully provided this view with a "Merge categories" button to merge selected categories, but with no "Undo" or "Save-and-resume" functionality, I found this phase frustrating (of course category merging is only an issue for open sorts, not for closed sorts - WebSort supports both types).

There is also the mandatory tree diagram (aka dendrogram) which I found surprisingly unhelpful - this may have been a consequence of the low number of responses I was dealing with, but I have seen similar reactions from others.

All in all, I'd say that WebSort.Net is an excellent way of conducting and capturing a cardsort, with adequate analysis, but let down by weak category merging.

Learning, understanding and storytelling

An interesting post in Zen Habits on how to ace exams without studying explains and illustrates the difference between learning by rote and learning by "making connections".

While Scott Young includes "storytelling to remember facts and numbers" as one of five connection-making techniques for non-rote learning, I'm interested in a deeper connection, partly in the hope of understanding my own strengths and weaknesses in this area. Metaphor (his first technique) has, after all, some kind of implicit narrative. There has to be some kind of context in which the "stage" and its "players" and their "entrances" and "exits" mean something, before I can add that meaning to my understanding of "men" and "women". The same is more or less obviously true of his other techniques, like "Explain it to a five year old" (how would you do that without telling stories?) - read it, you'll see.

So the way to learn something is to make sense of it, to connect it to the things in our life which already have meaning for us. That's what stories and metaphors do.

This raises an interesting question - can I do this for my life as a whole? Is there some connection between, say, my interest in Metaphors We Live By, and my activities in Impro, does it all fit together?

I don't know yet, but I'll keep wondering.

And wandering.

Open Letter in Support of WIPO treaty for People who are Blind or have other Disabilities

Dear Judit,

I would like to support the open letter in support of the WIPO treaty, without hesitation.

My credentials for signing this petition are as the co-author of three Wrox books

• Professional XML Schemas (http://www.amazon.co.uk/Professional-XML-Schemas-Programmer/dp/1861005474)
• Professional XML Web Services (http://www.amazon.co.uk/Professional-XML-Services-Programmer-programmer/dp/1861005091)
• Professional XML for .Net Developers (http://www.amazon.co.uk/Professional-NET-Developers-Dinar-Dalvi/dp/1861005318)

and have also had magazine articles published, eg http://www.simple-talk.com/dotnet/.net-framework/implementing-real-world-data-input-validation-using-regular-expressions.

Francis Norton.

M364 - lessons learnt

So, I did my M364 Fundamentals of Interaction Design exam yesterday. I've got to the end of the course, and it's a good moment to look back and take stock.

First, I discovered that I can actually study something properly. I remember my academic career as process of scrabbling through tests and exams despite having dreamed my way through classes and prep, until coming a cropper at uni. For this course I sat down and read the scheduled materials and scribbled away in the margins and attended the tutorials and got good marks on the assignments. That was very satisfying (to use a User Experience goal).

Second, I can do something about my wandering attention. I've taken to using the Pomodoro Technique, and I feel I've come a long way, even if I still have a long way to go.

Thirdly, I've developed a good way of organising my notes for something like this - I used the free mindmap option at http://www.mindmeister.com. The good news is that this is a very effective way of reviewing material which forces you to resolve all those niggling little questions (what's the difference between ubiquitous computing and wearable computing?) that you can so easily skate over when merely reading. The bad news is that I didn't take up mindmapping until the revision phase, and didn't complete this activity in time to move on to the next, which would have been to extract hand-written revision cards from the mindmaps. So, next time, mindmap as I go through materials for the first time!

So, what next? I hope to find ways of using what I've learnt about Interaction Design at work, which was supportive about the course. No luck so far, but having made this investment I also hope to find a mentor through, perhaps, the IXDA, or, more informally, through the UX book club. I'm also considering whether I can do some IxD on the side, getting involved with friends or an open source project.

I'd like to build on what I've learned. Now I've finished the course I'd like to use some of the time this releases to do some Google analytics, and also to do some Arduino hacking - very different directions, I know!

Further down the line, I'm considering taking the Open University's Design Diploma. It seems pretty practical, and I suspect that the various digital design labels (Interaction Design, User Experience and Information Architecture) are going to end up merging with an updated version of Product Design, many of whose wheels we are probably re-inventing. And, above all, I like designing things. This is probably what took me into software development, and as the process became more and more productionised, and involved less and less design, it may be what took me out of it too.

Enough reflection, now for action...

A thin line between triumph and tribulation

Johnny needed a bath yesterday morning - but he wasn't in the mood. At all. So I (ready to catch my train) got called in, and found him sitting on the sofa, uninterested in either persuasion or authority.

My efforts simply make him whine and wave his fists, but he holds off from hitting me (good start). I resist the probably futile and counterproductive temptation to drag him upstairs and offer him a hand to thump instead, providing some helpful martial arts grunts to add to the action. Several thwacks later and I see a smile, then hear a little "OK", so light I almost miss it.

Parenting, eh? Memo to self - rule 1: be there. Autopilot won't hack it.

And let's celebrate the occasional triumph - the tribulations can look after themselves...

M364 Block 1, Unit 4, Activity 1

[Please complete the assignment on page 337 of the Set Book]

1. Reconsider the HutchWorld design and evaluation case study and note what was evaluated, why and when, and what was learned at each stage?
2. How was the design advanced after each round of evaluation?
3. What were the main constraints that influenced the evaluation?
4. How did the stages and choice of techniques build on and complement each other (ie triangulate)?
5. Which parts of the evaluation were directed at usability goals and which at user experience goals? Which additional goals not mentioned in the study could the evaluations have focussed on?

Reconsider the HutchWorld design and evaluation case study and note what was evaluated, why and when, and what was learned at each stage?

There were several rounds of evaluation. The design was evaluated in terms of usability and scope. Evaluation of the first two prototypes, including the first series of usability tests, led the team to learn that there were problems with the initial scope of the project, so they changed the scope, limiting the 3D virtual world to just Reception, but adding support for asynchronous messaging, games, and locating approved medical sites. When the application was redesigned as a portal it was re-tested and further refined, allowing the team to learn about more specific usability issues. One goal of the new testing was to ensure that the system supported multi-user interactions. 

In general evaluation seems to have started with requirements and scope, then moved on to usability and user experience, in other words from whether the project had the right aims and goals to whether these goals were being reached.

How was design advanced after each round of testing?

There were two main rounds of testing. The first round of testing led to a fairly radical advancement of the scope of the design, from an intensively 3D virtual reality experience to a portal with support for email. games, medical queries and rather limited 3D functionality. The second round was  more focussed on detailed usability testing and led to incremental improvements in the design.

What were the main constraints that influenced the evaluation?

The team found it difficult to arrange testers rapidly for reasons inherent in their choice of user group - the potential users were sick and had limited energy and availability.

How did the stages and choice of techniques build on and complement each other (ie triangulate)?

The evaluation techniques ranged in nature from quite open and general (interviews, focus groups) to very specific (scripted usability tests). The more open evaluation techniques provided aims and scenarios which provided the context and goals of the more specific evaluation techniques

Which parts of the evaluation were directed at usability goals and which at user experience goals? Which additional goals, not mentioned in the study, could the evaluations have focussed on?

The initial interviews and resulting scope analysis were largely expressed in terms of user experience - one over-arching requirement, for example, being to reduce the social isolation of patients and care-givers. The formal tests were more focussed on usability, but some of the results are again best described in terms of user experience - for example, the problem with the purely synchronous early prototype never reaching critical mass is most simply explained by the fact that it is no fun being in a chat room on your own. Similarly there are UX explanations for the patients' preference for online games (fun), the search for recommended medical sites (helpful) and email (emotionally fulfilling). In addition to the carefully scripted usability tests in each round, there was a short questionnaire which asked both usability and user-experience type questions.

I think that the project could have focussed on the user-experience goals of motivating and satisfying, since these would highly relevent to socially isolated users suffering from energy-sapping conditions.

M364 Block 1, Unit 3, Activity 9

How user-centred was the approach taken by Tokairo? Start by listing the main stakeholders - beneficiaries, decision makers, gatekeepers and workers - and discussing their roles in the development process.

Then analyse Tokairo's approach against each of the five principles of user-centered development given on page 286 of the Set Book

The main stakeholders in the project were, at a corporate level, Excel plc as parent of Tankfreight and Shell, the project's client. Shell were responsible for allowing Tankfreight and Tokairo access to their depot. Tankfreight were probably the main beneficiary since they commissioned the project, and automating the delivery reporting process should reduce costs and increase accuracy.

The more immediate stakeholders were Tankfreight project management (Hugh Rowntree and Rachel Darley), Tankfreight's account manager for Shell, the driver foremen, trade union representative and the drivers themselves.

Hugh and Rachel were gatekeepers to the drivers and Hugh was presumably a decision maker in commissioning the project, and, together with Rachel, signing-off design options and prototypes.

Tankfreight's account manager may have been a gatekeeper for access to the Shell depot, and would have had some involvement in high-level project decisions.

The driver foremen and union representatives are not only gatekeepers to the drivers but possibly themselves users of the system, as workers, and possibly beneficiaries, either as users or because it makes the drivers happier.  

The drivers themselves are the primary users of the system, possible beneficiaries (if the forms are more accurate and they get fewer forms being returned to them) and are involved as workers.

Presumably others are also involved, either as workers or beneficiaries - those who used to enter the drivers' forms manually, those who manufacture and sell the kiosks, and those who service them.

Now let's evaluate Tokairo's approach to the five principles of user-centered development.

Users' tasks and goals are the driving force behind the development

Tokairo's initial input comes from Hugh Rowntree and Rachel Darley, who know the drivers, their tasks and their environment well, and Tokairo had already had access to the users before the project even started. They appear to have a good understanding of users' tasks and goals. But satisfying the drivers' tasks and goals is probably a necessary rather than a sufficient condition for the project's success, the final criterion presumably being that the system reduces costs and increases accuracy. 

Users' behaviour and context of use are studied and the system is designed to support them

As part of the system audit, "Treve actually went initially to the oil terminals and depots. Treve met the drivers and the driver foremen". The team appear to have a detailed understanding of what the drivers do, and of where they do it, in the cab and at depot reception, and it is clear that design decisions directly reflect these factors.

Users' characteristics are captured and designed for

Once again the team appear to have a detailed picture of their user group, of what they have in common (being literate, non-academic males, short of time, primarily interested in earning a living and going home) and where they diverge (level of interest in computers). And again, this is clearly reflected in the team's account of how they made design decisions. 

Users are consulted throughout development from earliest phases to the latest, and their input is seriously taken into account

This principle was defintely observed during the requirements phase of this project. It is clear that Tokairo would normally prefer to consult users during the design and implementation phases but felt that there were specific reasons they shouldn't do so in this case, although the form did get some early testing, which is a kind of user-consultation.

All design decision are taken within the context of the users, their work, and their environment

This principle seems to have been observed very thoroughly. In fact it seems that the team ascribe the success of the project to this factor.

Given that the project followed at least four of the five principles, and that the remaining principle was partially missed for specific reasons rather than lack of interest or lack of user focus, I would say that the approach to this project was quite highly user-centered.

M364 Block 1, Unit 3, Activity 8

Describe the approaches taken to user involvement in the Tokairo case study and discuss these using the issues you identified in Review Question 5 [List the (eight) issues you need to consider when deciding on the appropriate level of user involvement]. What alternative approaches might they have taken? You should refer to the case studies in Section 9.2.1 of the Set Book as examples.

What advantages and disadvantages might these approaches have had?

The set book lists the following issues that needed to be considered when deciding the appropriate level of user involvement:

Can you identify the users, or are they the open market?

In this case the users were already identified, as being the drivers.

How many users are there? Tens or Thousands?

We don't know exactly how many users there are, though common sense suggests it might be tens or maybe low hundreds. In any case, given that the users are, by the nature of their job, never in the same place at the same time, it's too many people for them all to be consulted easily or cheaply.

How long is the project expected to take?

Again, we don't know how long the project was estimated to take or how long it actually took, but in terms of user involvement the answer is probably that it was going to take too long to consider co-opting a real user for the duration, but not so long that any significent user practices or requirements would change before the project was completed.

Do you want a major contribution from users, or just advice and guidance?

There seems to have been a clear assumption, initially from the client but accepted by Tokairo, that the real users' main contribution should be to the requirements process, to alpha-testing the form and to beta-testing the entire system. Rachel, the systems analyst, acted as a proxy user for reviewing the design, but her contribution (apart from suggesting that the buttons be colour-coded) seems to have been mainly evaluation. 

How many users do you want involved with the project?

The team didn't want all users to be involved but consulted user and stakeholder representatives widely during the requirements phase. For the main design options, design and evaluation activities they mainly used Rachel, the user proxy. The notable exception is that they tested the form design on one driver area before beta-testing the entire solution, presumably having identified this as being at higher risk of failure (eg due to the driver's environment when filling in the forms) than the kiosk design.

Is consistency of user input important?

There was no continuous user involvement apart from that of Rachel, the user proxy, so consistency of user input does not seem to have arisen as a question involving the drivers. The consistency of Rachel's involvement is likely to have been helpful to the design process.

How important is familiarity with the system?

Given the general non-involvement of the drivers, familiarity with the system under development does not seem to have been a significent issue. Rachel, as the sole proxy user, was familiar with the system as it was designed, and this would have helped her contribution.

How important is it for involved users to be in contact with the user group they represent?

As there does not seem to have been any change in the drivers' environment or practices during the project, this was probably not an issue for Rachel with respect to the drivers. 

Comparing this approach with the Microsoft or OU case studies in the Set book, Tokairo could have co-opted a driver to work with the team, presumably part time. This would have been useful if the team had worries about the correctness of their scope and requirements (as the Open University appears to have had) but would have involved disrupting the availability and working practices of the driver in question, and would have risked inappropriate feedback due to lack of appropriate user motivation. In fact the team seem to have regarded this as tightly scoped exercise with well-understood requirements (especially given the comprehensive requirements phase), so the advantages of this step would have been low. 

They could also have conducted workshops and prototyping sessions, as the OU did. This would have had the advantage of reducing the risk of "requiring more changes during the prototype ... and even [the] pre-live stage", but it would have been disruptive to operations, the drivers and their management, and premature exposure would have risked "destructive feedback".

They could also have performed lab-based usability testing, as Microsoft does. This would have reduced the risk of the overall system proving unacceptable during beta-testing but the team seem to have felt that the risk of this failure was not sufficiently high to warrant the required level of disruption and expense. 

M364 Block 1, Unit 3, activity 7

Look back through the previous sections. Describe Tokairo's approach to design. How these map  onto the ID activities and characteristics of the ID process?

Having established the user requirements, Tokairo bought their own experience into the design process. Some of the major decisions - such as the choice of touch-screen input and the choice of a "big lottery ticket" form - were made rapidly, after consideration of alternatives, but not necessarily after much iteration. In the case of the basic form design, rather than the ID activity of "Developing alternative designs" they evaluated alternative existing designs, to similar effect but presumably at rather lower cost. The use of the team's professional experience seems to have provided a similar short-cut for the kiosk design, and might be seen as a greater difference from the ID method. 

The form design was tested in the wild (in "the most militant driver area they could find") and maps to the ID activity "Building interactive versions of the design".

There was explicit evaluation of both the Kiosk and Form designs and this corresponds to the ID "Evaluating designs" activity.

The ID characteristic "focus on users" can be seen in the whole requirements stage, and in thepre-beta  field testing of the form, though less so in the implementation of the kiosk design where the client preferred to provide a user proxy.

The "Specific usability and user-experience goals" ID characteristic is arguable "absent but unnecessary" due to the short lines of communication and clear implicit focus in this area.

And the ID characteristic of "Iteration" can be seen in mainly within activities, in the refinement of the kiosk and form designs based on the feedback from users, user proxies and field testing.

M364 Block 1, Unit 3, Activity 6

Look back through the previous section and list the characteristics of the approach that Tokairo took to the requirement activity. How do these map onto the ID activities and the characteristics of the ID process (as discussed in Section 6.2.1 starting on page 168 of the Set Book)? 

What is their attitude to stakeholders?

Tokairo have a methodology with a first stage being the Site and System Audit. They try to identify "logical group[s]" of users by business function, who have characteristic concerns and requirements. Having already talked to the drivers and driver foremen, they went on to talk to the systems manager and systems analyst, and union representatives. This maps to the ID "needs and requirements" activity, and the ID characteristic of being "focussed on users".

The ID method has the characteristic of being "iterative". The Tokairo approach in this case appears to involve more iteration within the requirements activity than between activities when compared to the ID method, but they describe this as being due to the success of the requirements activity, and both are in fact present.

The results of the initial requirements activity were communicated verbally rather than as written deliverables, and the usability or user experience goals were probably set implicitly, in terms specific to the project (eg "suitable for well-motivated, literate drivers with big fingers who are in a bit of a hurry") rather than in the more general terms of the ID method, which may represent a departure from the ID characteristic of "Specific usability and User Experience goals".

The Tokairo attitude to stakeholders is open and respectful - because "if you just talk to the managers ... you will have a whole lot of surprises".

M364 Block 1, Unit 3, Activity 5

This activity builds upon Activity 6.4 on page 182 of the Set Book. Compare the two electronic calendar designs using the following usability and user experience goals:

• Efficiency: In particular, which design enables the user to find a given date most quickly?
• Learnability: which design will be easiest to learn?
• Aesthetically pleasing.
• Enjoyable.

Which design do you prefer, and why?

Efficiency: The desktop design appears to be very inefficient for finding dates since you have to "leaf through" the diary, so the time required to locate a date page is proportional to its distance from the currently opened date. The phone version requires keystrokes instead of mouse clicks but since you're entering a date the number of keystrokes is not large, and does not increase with calendar distance. The desktop diary is probably more efficient for viewing dates within the same week, the phone diary is probably more efficient for navigating to more distant dates.

Learnability: The desktop diary is probably easier to learn, especially given its limited date navigation and graphical rendering, but the simplicity of the phone diary makes it no harder to learn than necessary.

Aesthetically pleasing: The desktop diary is able to use a clean, helpful graphical rendering which offers hints about its further functionality (tabs for the notes and address book sections). The phone diary is written for a visually restricted environment, which means that any comparison is almost as much a comparison of the environments as of the designs. So I would say that the desktop design is more aesthetically pleasing, while noting that this more helpfully addresses the question "Which design would a user prefer?" than "Could the phone design be made more pleasing?"

Enjoyable: The cross-referencing possibilities of the desktop design might generate some enjoyment. Assuming we can click on "John" in an appointment, get taken to his address page, and then see all his appointments (in the same way that we can see all people listed for an appointment), this cross-referencing, together with the ability to read notes from previous meetings, might give a certain bookish enjoyment. The phone design offers less prospect of discovery, so I think scores even closer to a neutral zero.

Assuming that both designs are equally available (for example, that I have gone out and bought an iPhone) I would prefer the desktop design for its greater efficiency when dealing with nearby dates, its slightly greater enjoyability and its better aesthetics,  though I might find its lower efficiency for distant dates frustrating.