Communication of Requirements: Incorrect and Correct

Zero to Agile part two: Distributed Scrum

Is your team co-located? It's funny that we needed a new word for a way of working where people are in the same place. Not so long ago, the new words were offshoring, outsourcing and remote. Now it's co-located, meaning in the same location.

As I mentioned in part one, my first Agile project was with a team that was not co-located. Not only was the team not co-located with the product owner, the team was not co-located with itself.

Three quarters of the team were Chinese. They lived and worked in Tianjin, in China. The rest of the team and the product owner, me, were British. We worked in London, in the UK. Although the project started with no marketing involvement, see part one, there was soon a marketing stakeholder, who was American. He worked in Redwood Shores, on the West Coast.

The sun never set on our project. Tianjin to London is eight hours, in time zone difference. London to Redwood Shores is also eight hours. Deduct those from the twenty-four hours that there are in a day, and you'll find that it's also eight hours from Redwood Shores to Tianjin. We were about as widely distributed as a team could be.

Many proponents of Agile seem to have a blind spot about distributed teams. I put that down to nostalgia. Let's look at that before we get stuck in to how to work with a distributed Scrum team.

Nostalgia

There seems to be a widespread misconception that Agile is a return to the old ways of programming, and that returning to the old ways of programming is a good thing. Firstly, it is not a return, and second, returning would not be a good thing.

Back in the old days, programming was not well understood by those given the job of its management. A colleague of mine was once told by his manager: “The program runs too slowly. Can't you put in more if-tests?”

Back in those days, when asked why everything took so much longer than estimated, we would explain that programming was a very young form of engineering, when compared with, say, building bridges or pyramids.

Despite our facetious attitudes to authority, programmers continued to be employed. This was because the world needed software. What the world needs, the world gets. But what the world needs, it also tries to get efficiently, and in a controlled manner.

The first attempt at controlling the delivery of software was to use what are now known as waterfall methods. Waterfall methods are so called because they start at the top, then descend in an unstoppable way until they reach the bottom. At the top of the waterfall are the marketing requirements, at the bottom is the executable software. It sounds simple, but there is one problem: Waterfall doesn't work.

Even so, waterfall methods were widespread. This is because, as stated above, the world needs software. Waterfall gave the world software, albeit often the wrong software, and inefficiently produced. That is why we now have Agile methods; because Agile methods are better and more efficient than waterfall methods at giving the world the software it needs.

Incidentally, the idea that Agile represents progress is not heard often. More popular seems to be the view that we have Agile methods because programmers have risen up and thrown off the yoke of management and the market. Well, programmers do tend towards romantic narcissism, so it's understandable that this view has been expounded. I'm happy to let my coders live in the fantasy that they gone back to the good old days, so long as they code what we need, code it well, and code it efficiently.

The drive for efficiency is the reason we now have Agile methods. The drive for efficiency is also the reason that American and British companies are now working with software developers in China and India.

China and India

It is apparently cheaper to live in China, and India, than in the UK, and USA. This means that it is cheaper to employ coders that live in those countries. How much cheaper is a matter for conjecture. I've been told that the ratio of what a coder in the UK costs to what a coder in China costs used to be three times. I've also been told that the ratio is now nearer two and a half times. I don't care what the correct ratio is. I also don't care about whether and why it is cheaper to live in China and India.

This brings me to a commandment that you must follow if you want to work well with a distributed Scrum team. As you'll see if you continue reading, this is not my only commandment. This is the first of five commandments, and the most important.

Commandment one

The first commandment of working with a distributed team is: Get over it.

Chances are, if you are working with a distributed team, you are not the person who decided that a distributed team would be a good idea. The chances are that the decision was made by somebody else in your company. That other person did their maths and worked out that a team all in the US or UK would cost more than a team partly in China or India.

The maths may have been wrong. The decision may be wrong. Get over it.

(This may be being read by somebody who did make the decision, or did do the maths. The commandment still applies. You may have made a mistake. Now get over it.)

However you have ended up working with a distributed team, it is not your job to complain. It is your job to make software happen.

Following the next commandment will help you to do that.

Commandment two: Reply today

When you are the product owner for a distributed team, you must reply to every e-mail today. If you cannot reply properly today, at least reply today with an apology and a commitment to get a proper reply.

No member of the team is going to drop by your desk to chat about the issue, nor will they see you in the corridor. This is because they are in a different continent. That might seem obvious, but I have worked with people who very clearly didn't get it.

Your team won't wait for you. They are mailing you a question because they need an answer. If you don't provide an answer, they will go elsewhere. Think of them as nodes on an intelligent network. Think probe, not process.

The structure of the modern corporation is fundamentally opaque. Workers within that structure cannot rely on process to tell them by whom questions should be answered. Hence, they probe. If your team asks you a question, and you do not answer, they will conclude that the question should not have been addressed to you. They will then ask somebody else.

The top candidates for that somebody else are: the Scrum Master, and line management. In a small organisation, those may even be the same person. Designing software products is fun. More fun than doing burn-down charts or annual reviews certainly. Bored Scrum Masters and line managers will be happy to step in and pick up the fun when the product owner slacks off.

Keep the design fun for yourself, and answer every mail from your team today. If that seems like a tall order, remember commandment one. Anyway, answering e-mail properly is not only a good habit, it is also an example of following the next commandment.

Commandment three: Use the written word

A few years ago, I used to work in a technical support department. One day a fax came through (that'll give you an idea of how many years ago) from my employer's Japanese reseller.

The reseller was pretty much a one-man operation. Nevertheless, he was making good sales, including Nihon Keizai Shimbun. That's roughly the equivalent of the Economist and the FT in Japan, and is the source of the Nikkei index that they tell us about in the news. He sent a fax about a problem he was having with the software.

He had tried our recommended troubleshooting steps but had been unable to, in his words, “shoot the trouble”. My boss's boss, a director, took it upon herself to read that part of the fax out loud and mock the man's English. Ha ha, we don't say shoot the trouble, even though we do say troubleshooting. Personally I thought that this was quite a creative extension by him. I also thought that it was my job to solve his problems, not mock his English.

I had to read his fax slowly and twice before I understood what he was trying to do. Round about then is when I realised the value of written communication in scaling the language barrier. Understanding what another person says is a form of data processing.

In data processing terms, spoken conversation is real-time. If I didn't understand what you said when you said it, I'm unlikely to do so later. Fax, and now e-mail, is batch. If I didn't understand it when I read it first, I can read it again, and again, until I do understand it. Or at least until I understand part of it and send you back a request, also written, for clarification of the rest. (My request will contain evidence that I have read and understood part of what you wrote, and not just say “I don't understand; ask again.”)

I replied to my Japanese contact by fax. He then had the assistance that he needed, and which it was my job to provide. He may well have had to read my fax slowly and twice, but then he had time for that because I had used written communication.

If that story was happening now, the medium would not be fax. The medium would be e-mail, instant messaging or some other form of written communication. (Instant messaging? Yes, even IM gives the participants more time to work out what each other is trying to say than spoken conversation.)

But the written word is not only a ladder for scaling the language barrier. The written word is also a means to live by the next commandment.

Commandment four: Exploit time zones

Don't force people's working hours to overlap. Instead, make time zone differences work for you.

There is a time zone difference of eight hours between Tianjin and London. This means that there can be an easy overlap of one or two hours in their working days. That is enough for any necessary daily meetings, such as the stand-up that we have in Scrum, and is therefore all the overlap that you need. There's no need to fight the time zones for more overlap. It's better to exploit the lack of overlap.

Exploiting time zone differences is not difficult. All the team needs is a simple schedule, as follows:

End of day in Tianjin:

Summarise issues and tasks, by e-mail.
Hand over issues and tasks in the Scrum stand-up.

Start of day in London:

Get to work on the issues and tasks.

End of day in London:

Summarise conclusions, by e-mail.
Summarise new issues and tasks, also by e-mail.

Start of next day in Tianjin:

Get to work on the new issues and tasks.

End of day in Tianjin:

Here we are again.

In a twenty-four hour period, a single task could receive fifteen hours of programming effort, from two members of the distributed team. The co-located team could only contribute seven and a half hours in the same period. OK, I've assumed the task can only be worked on by one person at a time, but I believe many programming tasks are like that.

Example one: An engineer in London can do their day's work coding, and then have it tested by an engineer in Tianjin. “Get your code tested WHILE YOU SLEEP.”

Example two: The team in Tianjin might code all day but then hit a snag where they need a decision from the product owner, me. They give me the options at the end of their day, and I can take my day to get the answer right. If necessary, I can even pass the question up to my sponsor in Redwood Shores. I would do that at the end of my day. Even if the sponsor takes all of his day to answer, the team in Tianjin has not had to wait, because they were asleep or at home while we deliberated.

Both these tasks are less efficient in a co-located team: The tester has to wait for the coder to finish coding before they can start testing; The product owner has to make a snap decision, or “gate” the team.

(Now, there will be times when you need more interactive communication than the above and it has to be outside the overlap. The first thought may be to use the phone. The problem is that talking on the phone is quite intrusive. Picture an engineer sitting at home watching TV with their family. That engineer cannot take a phone call. Now add a laptop, or just a smartphone, to the picture. The engineer could quite easily write an e-mail or take an IM conversation, without disturbing their family's TV watching.)

Another time-zone exploit is what we called the off-line demo. This replaced the normal end-of-sprint demo. In a normal demo, the team and product owner get together and the team demonstrates the software to the product owner. In the off-line demo, the team provides a version of the software that the product owner can install and run themselves. So, I as product owner would run my own demo. I would check the completion criteria in the sprint's user stories, and give an official statement as to which stories were done, and which were not done.

Using the above exploits is particularly satisfying if, like me, you work with calendar data. If you work with calendar data, you hate time zones, and you really hate daylight saving time. Increasing productivity by using time zones is getting one back on them. It's also quite easy, unlike the next and final commandment.

Commandment five

The fifth commandment is: Don't body shop.

The members of the team in Tianjin had the same status as members of the London team: they were employees of the company. Now, legally, that may not be exactly true; I believe they actually worked for a joint venture between my employer and a local Chinese company. Technicalities aside, the point is that they were not working for an outsourcing company.

I am not a fan of outsourcing, be it co-located or offshore. When a company outsources, it creates a dependency on people that do not understand its business, and have no stake in its success.

I once worked at a company that had outsourced I.T. and outsourced facilities management. Both provided terrible service to their “customers”. Outsourcing of these functions was done, I suppose, in order to please the bean-counters. Did it please them? It may have, in the short term. In the long term, the bean-counters themselves were outsourced. I'm guessing that didn't please them.

Outsourcing I.T. support, facilities management and bean-counting are minor errors. It's shortsighted to remove those functions from your company, but not suicidal. Suicidal is going to a body shop for the people that create your product.

For some companies, this will be the most difficult commandment to observe. That's OK, it's not the most important of the five. To recap:

Commandments for successful distributed Scrum

1. Most important: Get over it.
2. Reply today.
3. Use the written word.
4. Exploit time zones.
5. Don't body shop.

Those are my commandments, based on my own experience. Other people have different views, and some have made them available to the internet.

Response to the Distributed Scrum Primer

The Distributed Scrum Primer is professionally produced, thought-provoking, free to download and can be found here: http://www.goodagile.com/distributedscrumprimer/. It is well worth a look.

Read what follows as an incremental patch to the primer's content. By that, I mean I'm going to skip over the parts with which I agree, and focus on the parts with which I take issue.

Communication is too easy a scapegoat

“Communication is always the problem.” That's a true statement, but in some ways has the same utility as the statement that “Communication is never the problem.” Get me? No? What I'm saying is: There is no point in calling attention to a factor that is a constant.

One might as well call out that engineers need to sleep, eat and breathe. Communication will continue to be a problem until there is a planet-wide illumination and we merge into a single hive-minded entity. (Ewige Blumenkraft!)

But seriously, corporate failures are put down to communication far too often. Failure to communicate seems to be an acceptable failure. To test this on yourself, try reading the failures in column A and column B in the following table:

A	B
Company strategy was not communicated.	Executives had no strategy, or the strategy that they did have was wrong.
Requirements were not communicated to coders.	Coders didn't bother to read user stories during the sprint.
Technical limitations of the operating platforms were not communicated.	Product designers didn't concern themselves with what is practical.
Test results were not communicated.	QA engineers did not test the whole product.

Ask yourself how you feel about the column A failures compared to the column B failures. Then ask yourself if your organisation is making any column B failures and passing them off as column A failures.

But still, communication

If you promise you have read the previous section, and done the reflective exercise, then you can read this section.

Genuine communication problems exist; I admit it. I also admit that these will tend to be worse when the product owner and Scrum team are remote from each other and do not have the same native language.

The Distributed Scrum Primer says that the solution to these problems is high-quality video conferencing. I say that the solution to these problems is not hardware. I say that the solution is words.

Yes, you can make your communication effective at a distance by using words. Avoid subtle intonations, body language, and other non-verbal communication. Use words, and use the right words.

When communicating at a distance, the right words are the simple and direct ones. As reference points, I suggest Mr Spock from the original Star Trek, and the PostScript Language Reference Manual (the best technical documentation that I have ever read, by the way.)

You may be concerned that emotions and feelings cannot be conveyed when talking like Mr Spock explaining beta splines or colour spaces. Don't be. From experience, I can say that this communication style conveys emotions easily, and effectively. Here's an example. At one point in a project with a Chinese team, I was quite angry that a particular item of work had not been started. How did I communicate that? I sent an e-mail that said: I am quite angry. No body language, no subtle intonations, no need for a video conference.

As a side note, if you seem to need a high-end video conference for your daily stand-up, then you're doing your daily stand-up wrong. The team with which I worked used a basic conference call facility for the daily meetings. I joined the meeting from my mobile phone, usually when I was outside, walking across a busy city.

Sure, subtle intonations were probably lost in the aether. But remember that the daily stand-up is only supposed to highlight issues. It is not intended for detailed discussion. All we would resolve on the call was who was going to send an e-mail to whom in order to progress towards resolution of the issue. See above for the commandment about written communications.

Kick-off events

The Distributed Scrum Primer advocates a kick-off event of some kind, possibly including travel by the product owner to see the team. I have two objections to that.

First, big kick-off events seem to me to be fundamentally non-agile. Agile practises are all about doing whatever is most important now. They are not about committing to spending a long time on the project in question. And if there's no commitment to the project, there's no justification for spending money on a big party and trip abroad.

Second, and this applies to Agile and non-Agile projects, my observation is that the bigger the kick-off event, the less likely the project is to deliver anything of value. (I've observed a similar phenomenon with executive hire announcements. The longer the announcement, the lower the impact the person will have on the company.)

Having said that, there is one other consideration for the kick-off party. By the end of the project, everybody will hate each other. Have the project party before the hate starts.

See them as people without seeing them

If you cannot think of a colleague as a person until you've seen their face, then you will have a problem working in distributed Scrum. Actually, I can reduce the qualification of that statement. If you cannot think of a colleague as a person until you've seen their face, then you have a problem. I product-owned a successful 6 month effort without ever seeing the Scrum team.

If you cannot think of a colleague as a person unless you understand their culture, then you have a problem. Let me tell you, I don't always understand English culture, and I'm English.

The Distributed Scrum Primer suggests that I would need to immerse myself in Chinese culture in order to work with a Chinese team. My contact with Chinese culture has mainly been watching the films of Run Run Shaw and Liu Chia “Pops” Liang, reading Jademan English-language comics, and having trained in Chinese martial arts in my twenties. Hardly an immersion. (Should you wish to achieve the same level of culture as me, you could now start by watching the whole of the Shaw Brothers classic Five Element Ninjas on youtube, for free. In my day, you had to sit all night in a fleapit art-house cinema in one of the dodgier parts of London to do that.)

If you refer to your colleagues as resources, then you have a problem. Your desk is a resource, so is your computer, so is your budget. People are not resources, not since we abolished slavery. Read commandment five again.

If you have these problems, you need to change your attitude, not take an all-expenses-paid trip to wherever your team is located. Observe commandment one.

Conclusion

Nostalgia is almost an anagram of “is not agile”. Scrum and other Agile methods represent progress, not nostalgia. The distribution of teams across countries also represents progress. These forms of progress are compatible, if the product owner follows the distributed scrum commandments:

1. Most important: Get over it.
2. Reply today.
3. Use the written word.
4. Exploit time zones.
5. Don't body shop.

Distributed scrum throws up a number of challenges, some more difficult than others. Getting your employer to pay for a business trip half way around the world is a challenge, but not as difficult a challenge as changing your communication style. Organising a kick-off party is a challenge, but not as difficult as changing how you think about your colleagues. Justifying a video-conferencing facility is a challenge, but not as difficult as changing your attitude. Overcoming the difficult challenges will have more positive impact on your projects. Get over it.

Copyright © Jim Hawkins, 2011

From Zero to Agile in six months, part one

A couple of years ago, I worked on a Scrum project as product owner. It was my first Agile project. It was also my employer's first, and the first for the members of the Scrum team. All parties concerned are now committed to Agile methods.

The original team members wouldn't work any way other than Agile. The company runs every project using Scrum. I'm writing a blog about how great these methods are.

Doing one project Agile transformed us into Agile enthusiasts. We experienced how Scrum works, and we liked it. Here's how we got started…

Zero: The wall of questions

The company was, and is, in the business of mobile phone e-mail and PIM synchronisation. At the time, we offered a “powered by” service, that was sold by mobile phone operators. Our operators were asking us to support a new phone platform, called Android. We already supported a number of other platforms for them, such as old Windows Mobile, Symbian S60, and J2ME.

The company's product has a client-server architecture. So the decision to support a new phone platform is, at one level, no more than a decision to port the mobile client to that platform. But at a deeper level, the decision being made is how to transform the client for the new platform. That decision needs to be informed. The decision-maker, in the product management department, needed information, and asked all the following questions:

• What kind of user interface do applications on this platform have? Should our application be like native applications, or be like our application on other platforms?
• What PIM integration capabilities does the platform offer? We can produce a sandbox client, that has its own e-mail, contacts, calendar and tasks applications. We can also produce an engine client that synchronises directly to the native stores, with minimal user interface of its own. Or we can produce a hybrid, with some of its own sandbox applications, and some integration. Which of these could we do? Which should we do?
• Can we pre-install our client “on-deck” so that customers can start using the service as soon as they take their new phone out of the box (OOB)? Our customers want this, but will it place restrictions on our client? Who would have to sign off the application in this case? The manufacturer? Google themselves? If we can't pre-install, what are our deployment options? The existing product can be downloaded from the service operator's website. Can we do that on the new platform?
• Does the platform support background execution? We run constant synchronisation of changes to the user's PIM, not a foreground download-now service.
• Our operators set up specific packet data routing and billing for users of our service. We also integrate with their AAA, LDAP or equivalent service for automatic identification of users, by MSISDN. This typically requires selection of Access Point Node (APN) at the device. Can we do that on this platform? Can we stop the user synchronising over WiFi, where we cannot identify them?
• What do we need to do to optimise battery life? Half of this is in the Network, but the other half is on the device.
• The platform has native synchronisation capabilities, with Gmail. Can we block that? How can our service integrate with that?
• What kind of intrusive notifications or alerts can be played to the user, for example when they have new e-mail or a calendar appointment?
• If our application is integrated with the native PIM stores, for what kind of change notifications can our application register? If there are no change notifications, and a user has say 1,000 contacts on their phone, is it feasible to poll the PIM stores?
• What built-in encryption and data compression capabilities does the platform offer?
• Are handsets available? Interaction design, and final testing, is best done with physical handsets, not emulators.
• Is the platform mature enough? In other words, should we port now, or should we wait?
• What is the commercial value of supporting this platform? Is it ever going to sell enough units?

These are all reasonable questions, but to whom are they addressed? Who will provide the answers? If there were a project team, then they would be answering. But we haven't decided to do the project yet, so there is no project team.

One: The decision

With no project team in place, what product management did was to ask around. They persuaded a developer to find the time to install the Android SDK. The developer had a look and told product management what they thought. Product management installed the SDK themselves. They tried out some things on the emulator, or on such pre-release devices as were available. They googled. After doing that for a week or two, they made the following statement about the decision to make an Android port of our client:

“This is not a decision that a SCRUM can deal with … This is a decision process that needs to be driven by product management and get executive level sign-off. These are non-trivial investments.”

It's true that it would be a non-trivial investment to dedicate a team to porting the client to the Android platform. The other two statements were false, or at least I believed them to be. I approached the head of engineering, directly.

(I should probably point out that I was in neither engineering nor product management, but in a separate product design group.)

The head of engineering was receptive. He had already anticipated that he would be asked to deliver an Android client sometime soon. He had assembled a team: coders, testers, even a Scrum Master. The team had been waiting a month for product management to assign a Product Owner. When I offered to be the product owner myself, he said: Yes.

Two: Agile answers

So the team got the go-ahead. Great. But the go-ahead to do what? Where should they start?

Well, the questions posed by product management still needed to be answered, so the team should start there. Product Management were right with the questions they were asking. Where they were wrong was thinking that a Scrum could not give them answers. True, the main delivery of a Scrum team is usually software, but it is also possible for a Scrum to answer questions.

A Scrum works from a product backlog, comprised of user stories. A user story has a title, a list of confirmations, and some conversation. (When using cards, the conversation is what is written on the back of the card.) For the Scrum to give product management answers then, the questions need to be rewritten as user stories. Here is an example of a question rewritten as a user story, from the team's first sprint:

ID: 20027

Title: Use service that is integrated with native PIM applications

Conversation

Proof of integration capabilities with native PIM applications
This story could be met by a small stand-alone test application
Support for recurrent calendar items was part of this but is now a separate story

Confirmation

Engineering assessment written
Try each of the following operations: Read, Create, Edit, Delete on each of the following native stores: Contacts, Task, Calendar
Try non-recurrent calendar items only

As the story says, at the end of the sprint, the product owner will have run a test application that demonstrates the operations. The product owner will also have read an Engineering assessment. Only then will the story be marked as Done.

The question will have been answered, and the answer will be objective. The product owner could show the assessment and test application to their colleagues. Compared with the pre-Agile asking around, this approach relies less on what was said or googled, and more on what can be shown. The cost is higher, but the process has created concrete evidence, not hearsay.

All the functional questions can be rewritten as user stories. They may not all be answered in the first sprint but, week-by-week, the Scrum team will work its way through the product backlog. On this particular project, the Scrum had answered all but one question after two sprints. The remaining question was one that actually could not be answered by a Scrum team, at least not a software development Scrum team.

This was the question that related to the commercial value of doing the work, and is addressed by Scrum in a different way.

Three: Agile commercials

Scrum does not answer the commercial value question directly, but it does represent a resolution to the issue of commercial value.

Implicit in Scrum is that we might re-assign the team at the end of a Sprint. The work done in that sprint could be wasted, if the project was cancelled at that point. Our Sprints were three weeks long, so the company stood to waste 3 weeks of the team's time by cancelling. With a team of ten, that's 150 person-days. Does that sound bad?

Under the pre-Agile process that the company used to run, the team would have been put on the project for six months. With the same team, that represents 1,300 person-days. This means that the question being asked is: In six months time, will it have been worth spending 1,300 person-days on this project?

Under Scrum, the question being asked was: Is it worth spending 150 days right now? Then, in three weeks time, the question will be: Is it worth spending another 150 days?

So, although Scrum does not address the issue of commercial value explicitly, it does make the commercial questions easier to answer.

Conclusion of part one

The evidential approach of Scrum lends itself well to the investigation of new product areas. The length of a Sprint represents a cap on the amount of effort being risked. But …

Did Scrum deliver? After the investigation, and assuming the effort did get risked right up to the end of the product development, did the company end up with software that could be sold?

Yes. Six months after the decision to wait had been ignored, the client was in the Android market place. Everybody had learnt a great deal, including Product Management. They described the project at that stage as:

“a tremendous job … the process … in place has returned us the best client we’ve ever done.”

That turn-around in attitude, and the profitability of the software, was a success for Agile methods.

A side point is that sticking to procedure will not always ensure that your employer takes the right action. Sometimes you need a personal network, and a personal reputation, to be effective.

The next post will be about the use of Scrum in a geographically distributed team, specifically: China, UK, USA. Included in that post will be my response to the Distributed Scrum Primer here http://www.goodagile.com/distributedscrumprimer/. I agree with about half of it.

Copyright © Jim Hawkins, 2011. All rights reserved.

Badge and Gun

Which devices would you gather for an extended period away from home, if given only fifteen minutes warning?

That is the question posed by Blogger, Mobilist, and now Stroke Survivor, the Mighty @Reyes here . My first response was: phone and laptop.

Phone and Laptop

My phone is a Nexus One. It's a pretty old device, although it's now running 2.3.3 Android, which is around 0.3.1 more than when it was new. My employer offered me a later device: the iPhone 4. Quite soon, I discovered that iOS still won't run my preferred secure e-mail client in background. I went back to Android.

My laptop is lenovo X201, running the pointless Windows 7. It's fairly new. I put in for a small laptop after I moved house last year. My previous machine was big, barely able to be called a portable. The fifteen inch screen intruded into the space of neighbouring train passengers. The battery didn't last for my one hour commute. Since trading up to this tiny chap, I'm not only open and running for the whole train journey, but I tend to keep the thing at my side more at home. We all need to update while we watch the TV, right?

As you may have gathered, these devices are not mine in the sense of ownership. They are mine because I use them, by choice. You may say that not having paid for the devices reduces the value of my opinion. It's true that price is not a factor in my selection of laptop and phone, although it is a factor in my employer's selection. Then again, by not having paid, I am not entrapped into playing the iGame. I don't have to continually tell myself that these are great devices in order to drown out the persistent whisper that they cost twice as much as the iQuivalents that do the job almost as well.

Explaining my first response, phone and laptop, seems unnecessary. Nobody reading this needs to be told why, given fifteen minutes, I would grab my phone and my laptop. They might wonder why I didn't reach for a tether or MyFi (?sp), but only if they had not seen the specs of my grab-devices. Both N1 and X201 have WiFi. Each also has its own SIM card for GPRS, 3G, mobile broadband or whatever other packet data service is available from my cellular phone service. I don't need anything else to be connected, but then that's me.

I guess I'm pretty fortunate to have access to such devices. To quote a favourite film of mine and Reyes: Always first class, Same old Roper. Another quote, from countless films and television shows, is also my second response.

Badge and Gun

AMERICAN TV COP (ATC):
    You can't take me off the case! I made the case! I am the case!
    
AMERICAN POLICE CAPTAIN (APC):
    That's just it ATC, you got personal. Now hand them over.

ATC: Hand what over Cap?

APC: C'mon, ATC, we been here before. Badge and gun.

Now, I don't wear (or is it carry?) a badge, and I wouldn't know how to shoot a gun, and I'd like to think I don't have any misplaced machismo issues, so why badge and gun?

Because each of those symbolises something else.

The badge is what identifies the cop, personally and authoritatively. My equivalent, for the purpose of the fifteen minute gadget grab, is my SIM card. I could add my debit card, I think. The other day my contactless card arrived through the post. Add that to the chip & pin that was already on-deck, and my debit card now has enough micro-circuitry to qualify as a mobile gadget.

The gun extends the cop's physical capabilities. My grabbed equivalent is the mobile phone. It doesn't enable me to shoot people, but it does enable me to photograph them, talk to them wherever they are, send them messages by e-mail or SMS, and read their blogs. There's even ammunition, 8 gigabytes of it, and all in the spout.

Since my SIM is generally fitted in my phone, when I grab it, I have both badge and gun. It seems like I don't need to grab my laptop. If I was the American TV Cop in the script, I wouldn't need that either. As has been seen many times, ATC doesn't need his badge and gun to solve the case. He has something much more powerful.

Technology

That's right, technology is what the American TV Cop has, even after losing his badge and gun. It's also what I have, even without my phone and laptop. Technology is not hardware.

The Web 2.0 is technology. Roper's martial arts is also technology, and so is the cop's "nose". These may seem like odd assertions, but they are consistent with the dictionary definition, as supplied by Chambers, the foremost on-line dictionary, here.

The English word technology comes from the Greek word techne, meaning art or skill. The English word technique has the same root.

It's ironic that, these days, technology often refers to stuff you can buy. But does owning a smartphone, or other piece of geek-bling, make you a mobile technologist? No, it doesn't; a chimp with a bible is still illiterate.

Conversely, what happens if you take the iPad, Blackberry and Kindle away from Reyes? Does he become a mere mobile monkey? I say no, although he is kind of hairy. It is skills, not stuff, that makes the man.

Copyright © Jim Hawkins, 2011

Dissection of a user interface

A little while ago, I was arguing with my interaction designer about our application's Contact editing screen. To argue his side, he invoked a couple of native user interfaces. To counter, I dissected those user interfaces. The dissection was a useful exercise in itself, as well as being a form of banishment of what had been invoked.

I say dissection because I flatter myself that there was a level of precision in my analysis. Also, when the analysis was done, I felt that I had exposed the workings of the user interface and gained understanding by doing so. When you read my analysis, you may say that I simply wandered about, slashing unmethodically. And that I rendered the pretty flesh of the user interface into a gnarled stew of sinew and tendon. Either way, what follows is not a glance at superficial beauty, but a dig into the functional depths.

But first, a preamble covering my interaction designer's side of the argument …

Invocation of the native

Invocation of the native user interface (UI) is an incantation that is often effective. Mobile software developers are probably already familiar with the incantation:

Abracadabra! If iPhone does it, it must be right.

Or you may have heard an alternate form:

Abracadabra! If Android does it, it must be right.

You may even have heard the most powerful abracadabra:

If iPhone and Android both do it, it must be right.

(iPhone is a trademark of Apple Inc. Android is a trademark of Google Inc.)

I'm being facetious, because I didn't agree with my interaction designer. There is actually some sensible analysis behind these mantras.

When designing a user interface, we sometimes need to make it like the user interfaces of other applications that are used in the same context. In other words, if it's running on iPhone, make it like other iPhone applications.

The counter analysis is that we shouldn't make the same mistakes as other applications in the same context. We also need to make our UI best so that we can be proud of it. So if we can do better than, say, the Android native Contacts application, then we should. To establish what the mistakes are, and how we can do better, we need to take the native UI in question and examine it closely, by which I mean dissection.

Bring out the bodies…

Subject of Dissection

Here are a couple of screenshots. These were the subjects of my interaction designer's invocations, and therefore the subject of my dissection.

Native UI A

Native UI B

The screenshots are of the native Contacts applications of two different mobile phones. To avoid potential issues, I've designated them UI A and UI B, rather than use their branded names.

Superficial Analysis

(In anatomy, superficial means near to the skin. The opposite is deep.)

At first glance, the UIs both look fine, and quite similar. Both have pretty, designery graphics. The two screens have quite similar layouts. Both consist of a list of fields with values. In both cases, the list is presented vertically, with each listed item occupying a single row. Both contain a feature that my interaction designer wanted in our software, but which I did not. (We will come to what the feature is, but later. For now, patience.)

Cutting through the surface, however, will reveal that there are differences between the UIs. Hand me my scalpel.

Dissection

My first cut reveals that one UI has a glaring shortcoming

A Glaring Shortcoming

In native UI A, not all of the Work e-mail address is visible. Quite a bit of horizontal space is occupied by the controls, and this has squeezed out the field with the value. If the Work button were narrower, and the minus button absent, then there would be enough horizontal space for the field to display the whole address.

Native UI B has roughly the same controls but doesn't have the same functional shortcoming. The whole of the address “e.gadsby@wooster.com” is visible.

How can this be? Dissect and discover…

On the device with UI A, the field would be edited in place, on this screen. This means that the font has to be large enough that a cursor in the field is visible, and that a user could tap within the field to place the cursor.

On the device with UI B, the field would be edited on a separate screen, opened when the user taps the field. The font on the separate editing screen must be large enough to be tapped, as with UI A. But the font on the screen under dissection need only be large enough to be legible. So UI B uses a shrunken font on this screen, compared to the editing screen. Not only that, but the shrinking is dynamic. There are two e-mail addresses in the UI B screenshot. The longer address is displayed in a smaller font than the shorter address. The result of all this is that more information fits on this screen, and hence function is improved.

(Also in its favour is that te device showing UI B probably has superior screen hardware. With UI B, the hardware manufacturer and software developer happen to be the same company. This is not the case with the device showing UI A. On device A, the software is open source and must be able to run on a range of hardware. The designer of UI B didn't have to worry about whether the UI would work on screens of lower resolution, for example.)

For whatever reason, this is a problem in UI A that does not affect UI B. But, there are problems that affect both UIs. For starters, what's with those minus buttons?

Minus Buttons

Both user interfaces have a column of minus buttons down one side. In UI A, this is on the right. In UI B, this is on the left. Tapping a minus button deletes the adjacent field's value. This was the subject of my argument with my interaction designer. He liked the minus buttons; I didn't.

His case: Without the minus button, in order to delete the value, the user would have to select the field and then tap backspace as many times as there are letters in its content. I agree that this would be tiresome, but…

Why facilitate deletion of a field's value?

Deletion of an individual phone number, or e-mail address, must be an infrequent task. Consuming precious screen space with a control that facilitates a task that is only infrequent seems like bad design to me.

I'll go further. Infrequent actions that are destructive, such as deleting a field, should be … whatever is the opposite of facilitated. It should be difficult to destroy data. This is what we're doing when we add an are-you-sure confirmation dialog: making the interaction more difficult. Facilitating destructive actions only facilitates the user in making mistakes.

The real reason for the minus buttons in UI B may be that there is a need to fill space. Using a smaller font is good because more information is displayed. But it's bad to show a lot of white space on a screen, especially a small expensive one. The user feels cheated. But this solution is not good. Padding out layout with function is the tail wagging the dog. And speaking of layout …

Layout

The visual layout of UI B is not perfect, for me. I find the alignment of the labels to be a little jarring. The field labels (mobile, iPhone, home, work) should be set further to the left. The “add new …” button seems not to be aligned with any other element. The button would look better aligned to the right, next to the chevron. The button would also look better with its left side aligned to the left side of the field values, or to the left side of the field labels.

But the functional layout of the values and buttons in UI B is good. The “add new” button is placed at the end of the list. This is better than having the plus button at the top of the list, as in UI A. It's more intuitive at the bottom of the list, I think. Suppose I am given a phone number for a contact, perhaps by the contact themselves. I read down the list to see if I have the number already. I reach the end of the list without having found the number. Now I know I need to Add New. So the bottom of the list is the right place for the Add New button, not the top.

Both UI layouts seems to have been designed with attention paid to the consumption of vertical space. UI A consumes vertical space with the headings for the type of detail (“Email”, “Phone”) and then saves space by putting the plus button alongside the heading. UI B only consumes vertical space with the “add new …“ button. There are no headings, as such, in UI B, but the button's label includes the type of detail (add new phone, add new email). So the button is doing double-duty, as the Add New control, and as the heading.

So, in both UIs there is one row of vertical space that is consumed by something other than data. Vertical space is scarce on the phone, so it's good to minimise its consumption.

This seems like a good time to mention a non-layout point: Translation. I expect that UI A is easier to translate than UI B. The headings are not sentences but only single words. The words (Email and Phone) probably occur in a number of places in the UI, so the localisation is simply re-used. That benefit seems marginal though.

(Sorry, I said that translation is not a layout issue, which is something of an over-generalisation. Translating between, say, English and French, probably doesn't involve layout issues. But translation between, say, English and Arabic, might well do. A user that reads right-to-left probably expects that the label is to the right of the value.)

Another aspect of layout is visual grouping. Native UI B has a stronger visual grouping of the fields under each heading than UI A. In UI B, visual grouping is achieved with rounded corners, a different background, and a vertical gap. In UI A, there is only a horizontal line. Stronger visual grouping may be necessary in UI B because the “heading” is not at the top of the list, where the user's eye expects a heading to be.

I prefer the visual grouping of UI B, but I don't think it could be used in UI A. UI A has an extra button on every row. These buttons, like all buttons, need dead space around them so that the user can tap with confidence. If a button is surrounded by other buttons, or active space, then the user has to be careful, and may become anxious. To paraphrase Steve Krug: Don't make me care. These buttons are doing double-duty too…

Click-able Type Labels

In UI A, it is obvious how I will change the type label on a value, by which I mean change “Home” to “Work” for example. I see the type label is a button, so I know that I'll tap it to change it's value. In UI B it's not obvious, although the method used is common throughout the device: fields and labels are edited on a separate screen.

Conclusion of Dissection

The big drawback of UI B is the lack of in-place editing. I'm told that even its fans think this. But, having done the above dissection, I can see the validity of the approach. Editing is relatively complex. Having editing in-place, on the same screen, adds to the complexity of the screen. Moving editing to a separate screen results in two simpler screens. Also, the separate screen approach is tied in with a number of other design decisions. Changing to in-place editing would mean changing those decisions too.

So, what we have here is a compromise. There's nothing wrong with compromise, although many designers think of it as a dirty word.

Here's a statement that would annoy such designers: Beauty is optional, function is mandatory. We've all seen uncompromising design and loved it. It just wasn't on a product that's successful in the market.

Conclusion about Dissection

Dissection is interesting, and reveals how everything is connected to everything else. If you don't believe me, ask an anatomist.

The mobile user interface is smaller than the desktop UI but, ironically, stands more dissection. You'd think that cutting up smaller things would be more difficult, and it is. But it's also more important.

So should everything be dissected? Should dissection become part of the everyday mobile design process?

Simply: No. Dissection should not be applied to incomplete software. Let the thing live before cutting it up, I say. After all, when does something that has been dissected get up afterwards? Apart from anything else, it's discouraging for designers. Designers like pretty things, and the UI stripped bare by her programmers is anything but pretty.

As to the presence of minus buttons in the UI, I can tell you that I didn't win the argument. I can also tell you that the interaction designer was made redundant, and I miss him.

Thank you for reading and if you're looking to hire an interaction designer, please comment on this post.

Copyright © Jim Hawkins, 2010

Earlier Unmethodical Analysis

Earlier unmethodical analysis blog posts are here, on posterous http://unmethodical.posterous.com/.