Barriers, Robert Hamilton, Google

Why we need to be open in the way we design and do things. People think mobile is open. (asks how many people have SIM cards).

If mobile was created by Internet folks, there'd be no SIM card - you'd just login from anywhere, on multiple devices, like on the web.

SIM is supposedly great for identity, but is that really necessary for security purposes, given what most people buy using username and password over iTunes, Amazon, etc?

(Shows picture of a ticket gate in Japan)

There's no barrier here. It only closes when someone tries to get in without a ticket - it presumes innocence. This saves electricity, wear and tear, and avoids penalising people who aren't doing anything wrong.

Japanese built a transport network to move people, not to create queues. Don't hinder people who are trying to use your service correctly.

Consider ebay: you're buying from a total stranger. That's fine. Drop £10 in a bar. You'll usually be given it back. This is the world we live in, and it's the world we create.

Put barriers in the way and you force out a different sort of product. Twitter didn't consider "people might want to make Tower Bridge tweet" - they're just open, and people use them in interesting new ways.

"Build a climbing frame, not a cage" - it's the same structure, just a different mental model of what you do with it.

Look at app stores: some people pick winners (e.g. Apple). The web wasn't built this way. Another example: network operators wanted to charge 10c per lookup. People didn't want to pay, so it sat there. Google decided this was fundamentally useful to users and have released a location API, Google Gears, WebKit, etc.

Our philosophy: build things people want to use. Google Wave is a bit weird - we want other people to come onto this.

Q: Where does Gears for Mobile fit?

A: We're more about standards in the browser than getting Gears out there. We're now getting geolocation APIs in W3C standards. Gears got us in there, but has done its job now.

Q: How do you see widgets fitting into the web?

A: Define widgets. The Palm Pre is all widgets - the dialler is written in Javascript. Widgets have a place because users don't think about using a browser. Showing things in a browser isn't the end use case of everything. They let users build their own climbing frame, rather than going to a full web experience. Widget platforms will become browsers.

Q: Should I be worried that all my passwords are the same?

A: SIM is solving a problem that doesn't exist.

Q: Why not do away with passwords?

A: You still have to authenticate. You have to have reasonable barriers for privacy and reputation. Larry says "the internet is too anonymous". If you can authenticate more easily then this might be addressable. The SIM is not the answer.

Q: Should I have to login to execute a google search? Even creating a username is an intolerable overhead.

A: No.

Q: I agree with the philosophy of open. It's great for users, but lots of businesses aren't making money from it. So what's the future of it?

A: It's a truism that people will pay for good things. We don't have micropayments. It's hard to do things at that level. We had 10c payments with AOL but got rid of it. It's easy to do it with a good product. Small app developers will do well. There were lots of mom'n'pop shop writing Newton apps and doing quite well. If you don't have to do distribution, you can make a living selling things for $5. Recurring payments is a key one - most of us are too lazy to hit cancel on that.

Symbian? What's that? Barbara Ballard

Nokia has 6% penetration in the US, maybe lower.
60% of US subscribers now text, but email a lot via Blackberry - because we like email. But we do more mobile web than European. In the 90s we stayed online all day using dialup, so email was always available... but not 2-way SMS or operator interop.

RIM put together an ecosystem for email as sophisticated as Apple's for music: consumption, servers, Exchange integration, fast setup, works well on 2G. Some US people call any candybar phone with a keyboard a Blackberry.

By comparison, it takes 77 clicks to set up email for Nokia.

Until recently BB had no Javascript, CSS or stylesheets activated.

30% of US iphone users were carrying a second device last year, frequently RAZRs (still). The whole federal government carry BBs. So our mobile web world is Blackberry, iPhone, RAZR...

So, Internet vs Telco: a framework for understanding company behaviours. Not here to slag operators, most problems are a result of silo thinking.

When SV and Bay area companies approach Little Springs, they want iPhone stuff. It used to be they wanted to run anywhere. Nowadays, if it's not Android/Palm/iPhone it's irrelevant. But Internet thinking like this misses 96% of other devices.

Telco thinking: Sprint is not a bad telco from a UX experience, hiring UX since 2007. AT&T hired their first one in 2007!

Telcos tend towards device-specific design... which made it expensive to get content providers involved. They're big on customisation and feature phones. They don't do anything to support smartphones, much - smartphones are the bastard stepchild generating 50% of data revenues. Content providers have to support everything, though, back to 4 years ago.

Hybrid thinking, now: thematic consistency. Not the same web everywhere; tweak slightly for devices. Avoid accesskeys on QWERTY phones. Add padding around buttons for touch devices. Dynamic number of results (5 on RAZR, more on others).

One or more versions (of page, sub-site, or site). Graceful degradation. Page "tweaks".

Q: How's Android affecting the US market?

A: It's on the 4th largest operator. We're expecting to see more.

Q: What about device APIs for things like WRT or Qt?

A: I'm anxiously awaiting data in large enough volumes for me to play with it.

Q: What about applications?

A: If the dev teams are silo'd, I give them separate specs. If they're more sophisticated, I use this approach. With J2ME Polish they can do 1 build a day (seems slow - Ed.).

Gestural Interactions, Younghee Jung & Joe Macleod

Joe: air-kissing is a headfuck.

YJ: We don't remember our first encounter with human beings, but we do remember our first interactions with computers. How do we interact with technology more naturally.

(shows photo of electronic cats)

YJ: Technology is poor at mimicking natural expressions. Verbal communication is only a fraction of how we talk.

JMcL: We fight over videoconferencing suites at work. We have good ones, but they're no better than iChat.

YJ: I pick up new body language easily.

JMcL: The gesture of fingers on lips travels well...

JY: ...but some are very specific.

(I had difficulty taking useful notes of what was an excellent presentation containing oodles of gestures).

Modelling the mobile experience, Bryan Rieger

Started out doing lots of animation, motion graphics. Worked with Buxton. Getting into Processing more recently.

"My journey playing cognitive connect the dots through a road in hell"

Wireframes are "layout, behaviour and flow" - that's a lot of stuff to be putting in a document.

Let's just deal with flow... you've written a wireframe for a screen. What happens next - you imagine what happens and your mind interprets, filling in the blanks.

What happens between the "frames" in wireframes?

Clients require more detail... too much detail.

End up in UML. Bryan shows a standard UML diagram for a light bulb. Standards require literacy. Now we're shipping huge wireframes and literary references... which are hard to manage, get less feedback, are never updated, are hard to change...

So it's too much. So we build a prototype.

Paper is lovely but limited. Requires interpretation, is hard to share. This leaves us with HTML/Flash/Python/Java - requiring programming. HTML works well for web projects tho.

Prototypes are challenging - need development resources, get hijacked by development, fail to find right level of abstraction, unwillingness to iterate from dev team, and suddenly: development is happening in design.

Iterations are opportunities for design. But what's the software equivalent of the cutting room floor?

Demos beautiful little modelling tool.

(Thoughts: is it an issue of trust? wireframes are a tool for communication. within a team, face to face communication is high bandwidth, warm, works well. if a small team can work together and do it... we're ok. Problems come when we need to communicate or validate outside the team. In particular i've seen this when you're haing a client sign off... or when QA is involved to validate your work (whether external or internal))