MEX: Appstores and their consequences, Hampus Jakobsson, TAT

TAT: licenses UI software, does inspirational design. Kit ships on 10% of all devices 2008. 140 people, Sweden, US, Korea.

Apple and Palm are arriving and doing impressive things - this is frustrating for incumbents, but empowering.

How could it be improved?

• Context: location, time could be used to funnel users towards appropriate applications.
• Discovery is like Digg - the top apps get loads of traffic, it's hard for others to break in.
• No try before you buy.
• No tell-a-friend.
• No recommendations or discussions.
• Less uber-control by one player would help. How about co-branded stores (the MEX store)? There's no transparency.
• Categories should be premium ($4.99+), standard ($0-4.99) and free.
• Get What's Hot from derivatives.
• Measure and rate by value = price times volume
• Sort on ratings not volume
• Add 25% with few ratings to improve discovery of new apps.
• Why not friend-to-friend sales?

App stores will be just the start of advanced personalisation. When Apple released their phone there was no app store - the first ones were hacked-in.

History of personalisation: started out with contacts and SMS, then pictures/videos/music, now apps and bookmarks. Phones have infinite uses once you add applications.

We have to make the UI more dynamic (cough, says vendor of dynamic UI solutions). Apparently UI should be experience based and match the real world, anticipate your needs, etc.

Mobile phones "steal us from one another" in their attention-grabbing.

A lot of Apples innovation was around the payment experience, and is amazing.

MEX: Achieving great tactile experience is a subtle art, Christophe Ramstein, CTO Immersion

Gets us to take one anothers' pulse.

As person taking the pulse, you were able to perceive something invisible and engage on another level. Haptics is an invisible experience we're trying to bring to the computer.

What is it?

Cutaneous sensors - skin is 2 square metres! Kinesethesia (positioning of body parts). Proprioception (integration of sensing with self-awareness?).

You can't feel if you don't touch - it requires proximity and contact. Haptics is intimately related to motor control. Touch reinforces sight and sound and needs to be consistent with them. "Touching is believing".

Hardware vs digital?

We have new types of UI enabled by haptics, and enhanced UX. And it might be realistic (simulation-based) or interactive.

How does it enhance UX?

Pros: direct/natural manipulation, maximise ergonomics by combining output and input, reconfigurable UI.

Cons: typing, visual occlusion, lag, sensing thresholds. Mechanical keyboards are still better.

Samsung and LG have quickly replaced their UI with touchscreens, and are now moving to haptics.

How can we leverage it?

Touchscreen navigation/typing is a big problem. Tangible messaging and communication is an opportunity. Things become emotional when we touch them. What if we could hug remotely (ahem - you can - CuteCircuit). Non-verbal communication.

Haptics improves typical WPM and accuracy, "except when you're sitting on a Jackhammer".

You can type on a mechanical keyboard without looking at it. There's a rumour that some car UI will be forced (by regulation) to have haptic feedback to make it safer.

What are the design guidelines?

Design tools for haptics: synchronise with sounds, shape parameters (amplitude, frequency, etc.), design effects and experience in real-time. Today we're talking about "button confirmation".

Q: We know haptics is important, but there are so few tools to experiment with it... how can designers begin to prototype?

A: Look at the ones on our web site.

Q: How do you see gestures combined with haptics?

A: It's about enaction. There's lots of room for gestures, for creating or manipulating content. How do you get the perception that what you did was accepted. (Knocks on table). This is a gesture, the sound, vision and feel gives feedback.

Marek: when you engage with people on an emotion level, you connect with them more deeply. Does this make them more likely to spend?

Foliage has sprung up across Firefox. I burn it here:

• 10 lessons in bootstrapping from the founders of UrbanSpoon;
• ViaPost looks interesting: redefining the whole of the postal service as "the thing that sits behind a printer driver" tickles and terrifies me equally;
• Control/capability charts on Kanban: interesting, I think, though I'm finding that for me personally the challenge is not in gathering and visualising data, but in working out what to do with it;
• Six questions with Jack Schulze, who I suspect is so Ri it hurts. It feels a bit hypocritical to blog it, but I found myself nodding furiously to his advice that "talking about your work does not directly improve the actual quality of your work";
• Harrowing board games;
• Karl on Kanban, flow and cadence;
• The iPhone home screen can't scale, apparently. Personally I suspect that uptake of applications on this device has something to do with the fact that they're *not* hidden at the bottom of a folder hierarchy - and if users are anything like me, they sometimes disable or delete apps they've once purchased, so the assertion that they need to easily navigate 40+ is balls. Flat home screen is a feature, not bug, IMHO;
• Transitions on Nokia, if nothing else a nice guide to where and how to use these wee beasties;
• 10 things I have learned by Milton Glaser. Number 1 seems to have unpleasant implications for me;
• Why text messages are limited to 160 characters - a bit o'history;

I'm camped out at UX Brighton, which tonight is hosted at the rather splendid offices of iCrossing. Topic: ethnography, "the antithesis of lab research" as Harry puts it - or "stalking with permission".

Simon Johnson of Flow

Simon's a usability consultant for Flow Interactive, presenting a project for the environment agency on "flood risk maps". The site launched and was a disaster - people sued, lots of bad press, etc. 10 years later they decided to redevelop it.

The data was iffy - poor maps, uncertain models for coastal erosion etc - but they wanted to reassure the public without getting appalling press, worrying insurers or mortgage companies, and so forth.

Scope of the project: work out what the map should look like, and what information should accompany it. They wanted to go out into the field to get context for their findings, so they interviewed 8 professionals, 6 members of the public in high-risk Norfolk, and 6 in low-risk Hastings.

They discovered that "our coastline is an institution, our history and it evokes strong feelings". Surrender goes against our national character. Ethnography is to take these passions and to bring these stories out of the community. The people making decisions need to feel the pain of the public.

Implications: the environment agency needed to communicate that they care, avoid being clinical, explain that adaption is part of our history, and show what's being done.

Three big issues: people trust locals not government. They're alarmed by coastal erosion maps. There's lots of ignorance and myths - e.g. the government is deliberately sacrificing Norfolk to save London. The mistrust was a shock to the Environment Agency, which spends millions each year protecting the coast. The locals didn't feel engaged by the EA.

"The public don't define their communities in terms of cost/benefit".

Bigs up Clearleft and Silverback :)

They used it to record people using Google to look up coastal erosion data. Zoomed-in data was the only thing they found useful. They don't care about regional abstractions, they care about their house. The professional perspective, which was on general trends and geomorphology, wasn't relevant - even for those whose homes were strongly at risk. Professionals think of the coast as an object, science, career. Everyday people think of it as a place where they walk their dog.

This study completely changed their idea of what usability was. They thought it was asking the user what they wanted and giving them it... but realised it wasn't just about technology.

Part of their ethnography was looking at other places that might have done this stuff - but no-one has because "it's complicated and a stupid idea".

They discovered that users wanted simple, straightforward language - not "weasel words". They got their findings up onto the walls as posters, invited the client back and walked them around the room - "like they walked into the data".

They found most of the country is protected. Millions of people don't have to worry about this stuff - and don't want to be scared by "erosion", or "risk maps". A minority (maybe a 1000 houses) who really do have to worry - and need to know how much they should worry.

The EA has a duty to represent risk proportionally. They shouldn't focus on risk and erosion, but support, defence and nature - a significant change in the orientation of the site.

Practically, the scale of maps wasn't sufficient for representing this data (which constantly changes). Users didn't want jargon, alarmism, exaggeration. They wanted local news, sympathy, and summaries.

They took all the questions they had from interviews, did affinity clustering to group them, A structure emerged over time, leading to a site map.

When presenting data, users wanted a simple draggable map - but the EA had divided the country into discrete areas, meaning they couldn't support this - it was a design problem that was impossible to solve. They cut down text and got rid of expert jargon from geomorphologists, etc.. They could have users click through regional maps down to a 1:50000 scale. On this scale, large changes can occur - 16 foot of coast lost overnight (rare but possible). They overlaid keyed visualisation data onto these coastal maps, explaining what was being done on a piece of coast. Maps included enough detail for viewers to orient themselves - monuments etc., but not all streets.

With erosion: the science is rubbish; the data is rubbish; and it's out of date. They abstracted data away from the map, using indicative colour rather than scale-diagram projections.

The EA pointed out that the findings from this Flow project didn't match the scope of it. They had to get approval from Hilary Benn to get approval for this approach to go forwards. But they weren't a difficult client, they were very open. Heartfelt personal testimony from members of the public (made homeless by coastal erosion in some cases) counted for a lot here.

Q: (James Page) How long did you live in St Leonards for?

A: Spent 2 weeks there, as much time as possible outdoors. The attitude from some of the pensioners was "I don't care who takes care of stuff or why - it's someone else's problem".

Q: Is that enough?

A: It's better than nothing. How much can you have? Some people have lived there for 60 years. When people shout at you that you're from London and don't care about them, you've heard a strong message. Comparing plans from DEFRA to what I was hearing from people, there was a mismatch.

Q: I'm sceptical as to whether this is ethnography. But how confident are you that agencies will deliver the volume of content needed, and what will happen if they don't - will it be useless?

A: They already had a mandate to gather this data - this gave them more of a reason. All the local authority people wanted to get involved - they get little money, work long hours, and they're passionate about what they do.

Q: How long did you spend on each stage of the project?

A: Felt like years! Whole thing was about 5 months. I've been asked to speak another 6 times at DEFRA and various committees.

Q: How many were on the project?

A: I did the research and report, Claire sanity-checked it and structured my time. She was a really good editor.

Q: Is this ethnography at all? It sounds like lab-based study from the seaside, not watching people use the product in the environment. It's doing user interviews in their context.

A: The second time definitely, the first time there was no product so I was in their environment talking to them.

Miles Rochford, Designing for the Rest of the World, Nokia

This is based on a 6-month project on Nokia Life Tools, and Rapid Ethnography. Miles works 2-3 years out on a team in service design. Previously worked on the National Public Toilet Map project in Australia, visited the World Toilet Forum in Shanghai. Amusing project, but actually impacted peoples lives.

Team is 40-50 people split between SF, London, Helsinki: 14 nationalities, 10 languages. This project had India, Singapore, UK and USA.

Life Tools was announced November 2008, began 8-10m beforehand. It's about services in emerging markets: agriculture, education, entertainment. What opportunities were here? Using very low-end devices retailing for 25-30 euros. Initial release used SMS as a data bearer, meaning it can work on low-end device and has a degree of cost control.

Miles' team was brought in for research and "colouring in". The project needed more than this. The motto of life tools was "inform, involve, empower" (sounds suspiciously BBC-like!).

Rapid ethnography: design ethnography, qualitative validation ("colouring in"), quantitative validation (more around business models).

The team went to India, Nigeria, Brazil, and Egypt. It was challenging for some designers because it was the first time they'd done this kind of research. There were security concerns; on arrival at Lagos their designer was met by an entourage of bodyguards, who fortunately stepped back when he was doing research and interviews :)

They interviewed a Nigerian pig farmer, using the first entry in his address book to store his income from the last 6 months.

90 participants in 6 countries, over just 2 weeks. Not a market research-driven approach, but rather looked at individuals involved in the various areas (farmers, farm produce purchasers, etc.)

Aim was to understand needs, aspirations and behaviour: how they behave, not how they say they do.

Nokia work with research agencies and put designers out in the field, to ask questions and understand things on a very personal level.

8 simple observations: people are time rich, money poor; it's not what you know but who; order through chaos; no private space or things; context is king; culture of fixing everything; expect the unexpected; stay on the beaten path.

Approach was constrained by the timeline; after the field trip they had 1 week brainstorming, 2 weeks visualising, 2 weeks subsequent fieldwork, 2 days filtering.

Shows project room for brainstorming.

3-frame illustrations for each concept: show problem, solution and outcome. Representation of money across cultures was strange - some (e.g. Nigeria) don't have coins. Some have notes but don't deal with them day-to-day because they're so high-value. Clothing in illustrations was a problem (e.g. exposed sleeves of women).

To relate deliverables back to people in the field, we used "design cluedo": "Would this work for person X in place Y at time Z?".

Most people working on this project had fallen into this from Multimedia Design - doing cameras, gallery interfaces, etc.

Speaks about design styles, referencing this article from Jared Spool.

Another approach: Doug Bowman from Twitter talking about data becoming a crutch for every decision. When Amazon went down this path before, they ended up with a muddled design where individual decisions made sense, but the whole didn't - and they've improved now. What's the answer? Let designers listen. Empathy is the best tool for designers, not sketching - unless you're designing for yourself.

Q: In the intro Harry referred to ethnography as "expensive but effective". Miles talked about rapid ethnography being a 6-week project. One of the things which I remember popularising usbility was an essay by Jakob Nielsen on "discount usability" - simple tactics for realising many of the benefits of a usability study cheaply and easily, potentially in a day or so. Is there an equivalent "discount ethnography" or is this a discipline only available to those with more time or money?

A: Use ex-pats in the locations where we have offices. Do interviews like the examples from Flow's talk for local projects - just spend an afternoon with users and listne to them. There is no such thing as mobile design, its all mobile - everything needs to be mobile-aware nowadays. Look at other old research. Adaptibe path releasing India research under Creative Commons licenses.

Q: Before Melonovsky came up with the idea of ethnography, researchers visited locations but didn't live there. Is what you've done ethnography?

A: Jan Chipchase did some research a few years back, living in slums. There are lots of challenges with this - Westerners aren't built for doing this. One researcher last year became ill with an unknown malarial virus as a result of this. It's hard to get people to engage with you and let you into their lives for this period of time. Using local researchers helps break down barriers between you and the community.

Q: Do we call it ethnography because it's the closest term we have, or should we have a new term?

A: It's a form of design research, ethnography is a field not an activity.

Q: One benefit of using the term "ethnography" is that it sells better than "field research". It's expensive to get empathy. Does Nokia have any plans to leak out ROI details on this project?

A: One nice thing about working with emerging markets is scale - it's not a narrow area where ROI needs to be greater. This can be multiplied across markets, so is easier to justify. We're looking to work with tourists too, to keep costs down.

Q: Why are Nokia interested in emerging markets where there's comparitively less disposable income?

A: Emphasis is shifting from hardware to software. People have the lumps of plastic and metal, how do we make money from them?

Q: Could you move your whole team abroad to develop a product?

A: Nokia Research has facilities in many territories. Sometimes we collaborate with universities in say India or Brazil. Maybe in the late stages more than early.

Q: Have you any sense of being involved in this research? Has it changed your perception of how mobile will be used?

A: Definitely. I was surprised at how people used mobile as just another tool - e.g. a fisherman who dropped his phone into the water, but kept retrieving it. Phones may be expensive but owners aren't precious about them in the way we sometimes are in developed markets. Mental models of digital space is interesting - in emerging markets, wider shallower hierarchies work better than narrow deep ones. These cultures aren't as attuned to deep hierarchies. There are obviously issues around literacy etc too.

More presentations from Miles here.

There's an easter egg in our implementation of Scrum at FP: we call it "gold cards".

Summary:

1. Regular time for R&D benefits our business and our staff;
2. The system isn't abused; if anything, we have to persuade staff to take advantage of it;
3. Running the business in fixed timeboxes and tracking velocity is what lets us do this;
4. Why restrict it to designers, developers and QA?

Effectively, they're a watered-down version of the Google "20% time" scheme: in every sprint, everyone at FP gets to take a day working on something of their own devising; with 2-week sprints, this works out as 10% of our time spent on R&D. We factor the time they take into our velocity calculations, so these days are included in our planning and accounted for.

Doing this as a service business is something I've found tricky before, both at FP and in my past life at Good Technology. It's really hard to justify "taking a day" out when there's paid work to be done, and even under our current scheme we see gold cards being taken far more often at the start of sprints (when the pressure is slightly less) than at the end. Far from being a drain on resource, I find myself actually having to remind our team that yes, gold cards are still something available to them and yes, you really ought to take one this sprint. Even so, they're skipped more often than they're taken. Duncan, the agile coach who helped us introduce Scrum, warned us that this might happen: what do you know, people have a conscience and feel they ought to concentrate on "the day job" :)

Not only does it feel good as an employer to be able to put my hand on my heart and say we have, and actively promote, such a scheme... but providing an explicit time for playful experimentation scratches lots of itches, is good for morale, lets folks show off a little (in much the same way as a Hack Day), develops new skills, opens up possibilities for collaboration between folks who may not have worked together on a "live" project, and has resulted in all sorts of goodies, including:

• Our first Android and iPhone experiments, where we first started playing with these devices;
• A suite of simple, skinnable Android games which we're doing some experiments with - more on that soon;
• GPS tools which let us track paths and generally get familiar with co-ordinate systems and location technology - in the name of assisting a couple of keen geocachers, I suspect;
• 3D J2ME apps!
• A Faraday cage, still passing through QA;
• Dougie's entry into the 5k app competition;
• A couple of company-wide talks (on context-driven testing techniques and UI design for the iPhone);
• The worlds first accelerometer-powered spirit level for J2ME phones :)

We don't direct what a gold card day can be used for, but we do prefer to end up with something demonstrable yet sketchy, as opposed to "1% of something that will be amazing one day, but can't be seen yet". To steer in this direction, we make a habit of gold cards being demonstrated during the sprint review meeting at the end of sprints. We don't allow gold cards if you've taken holiday during a sprint or if you work part-time, and we've only explicitly cancelled them just once, during our trip to China earlier this year: it seemed a bit rude to be flown to the other side of the world and then take time out for R&D :)

I'm happy with the results. We have a flow of "new stuff" which is learned and shown around every couple of weeks, some early prototypes which we quite often end up demoing to prospective clients, and we've managed to accommodate all this alongside paid work for clients. I don't know how we would've justified the time without having fixed timeboxes and regular re-planning days; when we've tried to do this pre-Scrum, it's never seemed possible... there's always been a good reason not to take today for R&D.

Next steps? So far it's only designers, developers and QA who've taken advantage of this scheme; I'm curious as to what some of our commercially-minded folks might make with it. And I'm digging into what the tax implications of this scheme might be, in relation to the legendary UK government "R&D tax credits" scheme...