Petro Salema.

Their pilots were dropping from the sky like fruit flies.

And it was the job of the engineers to do something to save their lives.

The British Royal Air Force in World War II were suffering such massive losses of their bombers that they gathered a team of engineers on what was essentially a technical rescue mission.

They had a problem, a usability problem.

Is this mic bothering you as much as it's bothering me? Is it OK? If it's OK just nod really loudly.

If it's not I'll get some tech to sort me out.

It's OK? I think it's my coat.

Can we take a moment to just sort me out? Because it's bothering me a little bit.

I can take off the shirt, it that's OK.

It's all right? All right, let me-- OK.

I'm going to do a wardrobe change.

OK? So hang on.

So their bombers were dying in ridiculous numbers.

And the engineers were going to be the ones who will save their lives.

The RAF gathered their smartest engineers.

And this technical mission was going to be to solve a usability problem.

You see their bombers, marvelous pieces of engineering that they were, terrible weapons of destruction that they were, fantastic pieces of engineering.

But under enemy fire they had crippling security vulnerability.

And so they called in the engineers.

When your users are dying on your systems, you've got a usability problem.

So the engineers came in, and these engineers came up against what is a common restraint of all airplanes.

You see in order to better armor the airplanes, essentially what they would have to do is add weight, armor.

But the more armor they would add to these airplanes, the worse they would fly.

And so there was a delicate balance that they had to play.

How much armor were they going to add, and how would they add this armor in such a way that the planes were both capable to do their destruction and able to be prevented from being destroyed? It wasn't revenue on the balance.

When they lost a user, they lost a countryman.

If they lost this enterprise, if their team failed, they lost a country, and they lost Europe.

But these engineers, they had a plan.

They had an approach, analytics.

What they did is that they gathered data.

All the planes that came in, they looked at everywhere where there was flag damage, everywhere where there was bullet damage, anything that was wrong with the planes that came back from the front.

And they gathered all this data, and they did a statistical analysis.

And a pattern began to emerge.

It was obvious where these planes that were coming back from the war were getting hit the most.

And with the information being so clear using analytics, the answer and the solution just answered itself.

It was obvious.

What they had to do is not have to armor the entire airplane.

They didn't have to armor up everything.

What they just needed to do was to cover those areas which were most susceptible to enemy fire, and their airplanes would be minimally armored, but perfectly secure, or at least better secured.

The answer, through analytics, was given to them.

And it was obvious.

It was obvious, and it was dead wrong.

There was a statistician a mathematician on the group, however, a man by the name of Abraham Wald.

Abraham Wald seeing these exact same figures, these exact same charts, and exact same data came to the exact opposite conclusion.

He argued and reasoned like this.

He said, these airplanes made it back from the fight.

That means it doesn't matter how full of holes these airplanes are, those holes were not enough to take these things down.

He argued that if you see an airplane wing that is full of bullets, what that should tell you is that bullets in an airplane wing are not fatal.

He reasoned thus.

He says, it is exactly those areas in our statistical models that are pristine that are pure and perfect, it is those areas of planes which must mean that when both airplanes were hit in that area they never made it back home.

And thus, they never entered the statistical model.

It was so counter-intuitive, it just happened to be correct.

What you see at play with these engineers is something that is called accessibility bias.

Accessibility bias is where the things that you've experienced in hindsight limit and effect and set boundaries on the things that you're able to foresee in the future.

So your hindsight limits your foresight.

Why is this so important? Well, as engineers, as designers and developers, our core task is problem solving.

Yes.

Design at its core is problem solving, using form and balance to bring about a solution.

And we solve problems by asking questions.

An accessibility bias limits the questions you can ask.

You won't get a better answer than the question you can ask.

Innovation happens when you stop looking for answers to the questions you've been asking, and you start asking the right questions.

Innovation happens when you stop looking for solutions to the problems that you've been running in circles about, and you finally start solving the right problems, and solve all the things that we have to deal with, of all the burdens and all the things that come against this as we're trying to essentially bring about a future, a user experience.

I think nothing is more limiting, and nothing harder to overcome than accessibility bias.

Why? Because you can't escape your experience.

And your experiencing is limiting your perception, and it's limiting the questions you can ask.

Accessibility bias, you can't ask a better question than what-- you can't get a better answer than the question you can ask.

Have you ever wondered why it is that when we think and talk and hype about the next big thing that next big thing is usually an extrapolation or an exaggeration of the last big thing, accessibility bias.

Have you ever considered how it is that the biggest client, the gorilla in the room, the guy with the loudest voice, it doesn't matter how awkward, how idiotic that feature request is, it will somehow find its way in that roadmap, accessibility bias.

It is those bugs which have the most complaint that will get the urgent treatment, even if they're not critical to improving your product, accessibility bias.

I recall our team leader, our CTO at Gentex, the company I work for.

He once was in a stand-up meeting which we do every morning.

And he basically told us this.

He said, just because you're not receiving bug reports in that feature or that product, is no indication that that product or that feature is working properly.

In the worst case scenario it just may mean that you built an irrelevant feature.

So we have two roads.

This road is the one that we architected.

We planned, had coffee, argued, bickered, and we architected and astronauted this road.

We mapped it out.

We paved it.

We paved the way of the future.

Users will walk here and bless us.

This is what they did.

And so we got no complaints about how sucky our road was, about how horrible it is to walk on our pavement, because it was like slushy and it was uneven, and there was things to trip you up.

We got no complaints.

But we built an irrelevant product.

But we're smarter than this.

So what we do in software is we booby-trap everything.

We're in war.

So those engineers will use analytics, so we can detect when users run errant, and go doing weird things.

And this way we can discover our product, rather than try to just invent it.

But we're still subject to our experiences and our biases.

We will be optimizing, arguing, and working on aligning our architected path with this organic development that we've been able to discover with data.

And we'll be doing this optimization until one day we will turn our heads and look to the sky, and we'll see people flying with jet packs.

And we completely missed that boat.

Analytics in themselves will not save us.

Analytics do not invent the future.

We need more than data.

You see, it's not that we don't see it coming.

It's just that every time innovation really, really arrives it always seems to catch us off guard.

It's part of the thrill of actually what we do.

We're always being surprised.

It's like, oh innovation in the future just caught up with us.

And it snuck on us by surprise.

Why is that? Well I think it's because real innovation doesn't happen in these well-articulated grand visions and dreams of the future.

It actually happens in the back waters, in the dark room where the hacker is hacking away on a dream, and solving what seems to be like idiotic problems.

So if you want to know, and you want to be on the crest of the invention of the hoverboard, don't go to hoverboard fest, or flying machine conference.

Go find the guy who's making the best leaf blower.

We can dream of hover packs, hoverboards, time machines, holograms.

It's not that we lack a vision of the future.

Innovation happens when we're able to bring capabilities to bear.

We continue and we must dream big.

But to be practical and to realize a future, we have to think small.

We all know of a lot of companies, a lot of the titans who made this consumer technology world that we live in.

And we all see their sordid history of all the mistakes and misfortunes that they left behind.

There are few times in technology revolutions where something comes that is such a paradigm shifter.

The desktop GUI was one of these moments.

But the story of the desktop GUI is also a story of Xerox's missed opportunity.

Because it was in Xerox's part where they invented the desktop GUI that became so prevalent.

And it was the desktop GUI, the desktop system that motif, which basically was the killer app of the PC revolution.

And it was the desktop which gave birth to the internet, and the browsers, and the browsers to the apps.

Xerox had this capability, but dismissed it.

They dismissed the capability as an errant hacker's experiment in the lab.

And they continued making copiers.

And along came these two nerds, Jobs and Gates, and they changed the world.

We've got to have big dreams, but we can't miss those small things.

I don't know how many of you know of DEC.

But they paved the future as well.

But this is a true statement.

This is what the founder of DEC said.

He dismissed PCs.

They saw the capability.

But it didn't fit into their accessibility bias, into their perception of how things were going to work like.

What they couldn't imagine was how this capability will affect the user experience.

That is where-- that is where the divide was, and so they dismissed it.

But don't think that the man was an idiot.

He also had keen insight years later, and into the world that we'll be living in today.

Now you see this quote by him.

"People will get tired of managing personal computers, and will want instead terminals, maybe windows."

He was seeing a vision of the future.

You see the DEC conglomerate was making mainframes.

And so that's how they missed the PC revolution.

But here, years later, he's seeing of this vision of the future.

And he's saying, people will get tired of these personal computers.

OK.

We missed that boat.

They're going to get tired of these personal computers.

And what they're going to want is these terminals and these windows.

And we're like, well that's not a-- no-- that's not what we're doing, terminals and windows.

But, OK.

I'm going to change some words a little bit here, and see what happens to this sentence.

People will get tired of managing personal computers, can't carry them around.

You have to reboot them every time you want to check your email.

Instead they'll want mobile clients.

And their windows to the world will be their browsers.

You see he was able to envision the future.

But there's no way at that time that he would have a roadmap for the future.

It is this great man who made this quote.

And he said, "the best way to predict the future is to invent it," Alan Kay, a brilliant man.

There are a few people who can probably get away with a quote like.

That but this guy invented object-oriented programming, whether you like it or not.

He's the guy who actually also pioneered the desktop GUI.

I also hear that he's a professional jazz guitarist.

He can lead an orchestra.

And he plays something like a pipe organ.

So he's probably a better version of a human being than most of us.

And he says, you can predict the future.

You've just got to invent it.

But what I see in history is that these companies invented these capabilities, and they mispredicted the future.

It's like they missed it.

But they had the capabilities lying there until hackers and nerds came by, and took it.

We've got to dream big.

But we can't miss the small things.

And so what I would like to say, what I would humbly challenge us and have you interrogate, is the notion that it's not our job to invent the future.

That is far beyond your pay grade.

But it is our job, and it is within our grasp to enable it.

We do that by harnessing capabilities, inventing capabilities on top of capabilities, discovering capabilities, and using capabilities and exploiting them to the purpose of developing the future, future user experience.

Because whenever we're building a user experience for our future, we're imagining a future that will be replayed by thousands and thousands of users, hopefully millions of users.

So we take capabilities.

We look at what is small.

We solve these small problems, and we deliver them to enable the future.

Inventing the future is beyond our pay grade.

I think a pretty good example of this is the fruit company in California called Apple.

This is a quote by the late Steve Jobs.

And he basically said early on, he says, when we came up with these personal computers, we had to wait on them.

Watts and I we're having fun.

We built these things that we loved.

But we couldn't imagine what people were using these things for.

We couldn't imagine owning up.

We didn't have a roadmap of the future.

But here we are, we enabled it.

But what he did see, his insight, he said that he recognized that something special happened the moment the computer was not being used by a group of people, but was used in a personal way.

When the computer became a personal computing tool, he said that he recognized it in that moment something special happened.

And it was this capability which he built his company around, and innovated on, and experimented with, the personal computer.

We dream big, but we don't have a roadmap for the future.

We just have capabilities lying all over the place, and tools for which we can build better capabilities.

We build these capabilities.

We see what happens.

We enable the future.

So one thing, a couple of things I just want to get across with my message today.

Number one, the goal of all technical innovation is always, always, always, always the human experience.

It has been said, computing is not about computers.

Computing is about people.

The end goal is a human experience.

And you've got to bear in mind how complex the human experience is, especially how complex it is in group dynamic.

Innovation is about harnessing capabilities.

It is more so about harnessing capabilities than articulating grand statements about the future.

Dream big.

We must.

Revolutionaries demand dreams.

We need to dream big, but we've gotta think small.

Google's mission statement is to organize the information of the world, and to make it universally accessible.

That's a big dream.

How did that dream become a reality? It was the World Wide Web.

I don't see how Google would have been able to execute on this mission statement had there not been a capability to basically essentially do information organization through crowd-sourcing.

With the internet, the computers were connected.

With the World Wide Web we were given usability to connect to this internet, and to share information.

And so what Google didn't have to do is knock on every one of our doors with their street car parked outside our gates, asking us for us to share our diaries, to share our emails, our letters, to share our company reports.

No.

Because of the World Wide Web, we offer these things up into the cloud.

And what Google had to do was gather this and organize it, using computational power.

Who would've road-mapped that a military experiment followed by scientist and genius, but I would argue small protocols that he developed in Europe, would enable such a big dream where the information of the world can be made accessible? I want to see a show of hands.

Who here knows of m-pesa? All right.

I see some hands up.

I see some hands up.

That's good.

I thought I'd see some more hands up.

Well today you'll know a little bit about m-pesa.

My parents traveled to Tanzania, my home country, and they basically paid for their flights.

They were going all over the country.

And they were just paying for flights and buying things, not through a bank, not through ATMs, but just through their mobile phones.

m-pesa is peer-to-peer money transfer.

And it's really, really viral and popular in East Africa.

And now it's going on to the Middle East and other countries.

m-pesa brings the dream of a cashless society and peer-to-peer money transactions into a reality.

How did this happen? What was the road map to this? It was SMS.

And who would have seen that coming? m-pesa works with SMS.

So when you exchange money, you're essentially exchanging information the same way you do SMS's.

What they had discovered, actually, the same way that you discover a path when you have built a pavement and you discover a path on the grass, is that they had discovered that people were actually sharing with each other their air time.

Air time is expensive in East Africa.

They haven't set up all the infrastructure and it was expensive.

So people were sharing air time with their less well-to-do cousins or friends.

And so they saw that there was already an economy that had developed out of this capability, a new user experience was happening, and a whole economy had been formed.

And so they actually, what they did is they harnessed this economy, and they actually protocoled it.

And they developed this thing called m-pesa.

This is a grand-- this is kind of like a grand dream.

In the developing world people are doing peer-to-peer money transfer with their mobile phones.

I'm still waiting for that here.

Don't die on me.

Wake up.

When I was growing up in Tanzania, in high school that was about the time when cellular telephones came out.

And so some of the rich kids in the school, not I, had these mobile telephones.

But then after-- in a short period of time, everyone had mobile telephones.

And something really, really great happened, something that was just such an instructive moment for me to experience, something which we called beeping.

I want another show of hands.

Who knows what beeping is? What? OK.

That's interesting.

You guys know what beeping is.

For those who don't know what beeping is, beeping is hacking the capability out of-- hacking the heck out of a mobile phone, hacking the heck out of like the telecom, and the air time, actually.

What you do with beeping is you do miss-calling as a way of communicating.

It's kind of like-- you know how Chinese characters are like dense with meaning? And beeping is like Morse code.

But each beep is like dense with meaning.

You've got to like decode it based on your relationship with the person who miss-called you, and what's going on, and what's your context.

You decode the beep, and you figure out what's going on.

So this is how it would happen.

This is how it would play out.

Me and my friend, we're going to meet up somewhere.

And we all got very little credit on our phone.

We may actually not have any credit on our phone.

Somehow cell phones got cheap, everyone got one.

But air time is still expensive.

So we got these mobile devices with this capability to basically signal to each other.

But we got no money.

So what are we going to do? We're going to hack the heck out of this thing.

What we're going to do is when he arrives there, whoever is first to arrive at our destination, miss-calls the other guy.

And when the other guy sees the missed call, in this social context, with this relationship I have with that guy and in what we're about to do, I recognize that what this guy is telling me is he has arrived.

It's only one beep, right? And so the unofficial protocol is that how I respond, I send an affirmation, an AK, and that is a return beep, just one, one return beep.

One return beep signals to this guy that oh, I got your message.

I'm on the way.

Everything's OK.

If I send two beeps, it means I'm on my way but I'm running late, man.

So just chill.

If I send three beeps, it means I'm having trouble.

But I can't call you.

So if you've got credit, call me, or we have to re-plan this thing.

The cellular companies, after a while, started seeing that these anecdotes were all over the place.

And so they must have looked at their analytics and their data, and been thinking Tanzanians, are they so impatient? They give you like three seconds to pick up? And so I learned from my friends who were still back home that what they did is that they have now commodified this.

So you have to pay even to beep.

It's become a feature.

They did not roadmap this user experience.

They could not envision a user experience where people invent their own signaling language using mobile telephones.

You're supposed to speak through our mobile telephones.

Text messaging is a hack in itself.

Beeping, how do you road map that? How do you predict a society would develop that kind of frugal way of communicating on this platform? All they did is they gave us the capabilities.

We decide what the human experience is like.

They fortunately were able to capitalize on it.

Just one quick short story.

I had these friends, an English guy and a Danish guy, Danish or Dutch.

And we were together in Tanzania and then we went to university.

And when the World Cup happened, or some English football match, they still had this-- this culture of beeping one another.

Because they were cheap.

And so when someone scored a goal, they would beep the other guy, like a kind of way to spite them, like an elbow to the rib.

But what the other guy would do to spite the other guy back, is that when they saw a goal happen and it was their side that got scored on, they would basically be on the ready with their phone.

And as soon as that guy rang, they would basically answer to get the guy to incur international call cost.

So that's where you have a hack on a hack.

All right.

We live in a world that is like never before mediated by the technology.

This is like never before buzzing, blinking and beeping, ever on, ever present, and ever connected.

There hasn't been a time like this.

I believe that it will be written in the history books that it was the 21st century that every company became a tech company, computers and human beings, user experience.

We no longer do computing in computer rooms.

We do computing all the time.

I'm computing right now with my mobile phone.

It's supposed to be keeping track of my time.

But I forgot to switch it on so, the 10-minute guy? I got 20 minutes.

Excellent.

All right.

But we're computing all the time.

It's no longer a matter of productivity.

Computing mediate our lifestyles.

And then not only does it mediate our lifestyles, it's mediating and shaping our culture.

That leads me to ask a couple of questions.

But there's one thing I want to point out first.

If more of our life is being mediated by technology, what does it mean for those who do not have access to these capabilities? What happens to those who by their misfortune or by physical difficulty or mental handicap, don't have access to this bounty? I believe it's one of our-- it's part of our moral duty to actually bring capabilities and usability and accessibility in such a way that the most will benefit.

And I think, in part, that is why we are here, to share idea, to speak into our biases, and hopefully to bring this thing to more people.

But it also means something else.

Culture, culture is an extremely difficult thing to put your finger on.

None of us here can pull off Pharrell Williams' hat.

We're not culture makers like that.

Culture is a very difficult thing to put your finger on.

So if you thought it was hard in the past when people had to walk into computer rooms to predict the future, how are we supposed to predict culture? How are we supposed to program culture, codify culture, algorithm culture? We're supposed to reason about the technical difficulties we have with algorithms and programs? We're supposed to reason now about people's lifestyles? OK.

Designers, we're already onto this.

Lifestyle and all that sort of stuff, designers are clued up about this.

But now this is going full stack, engineers and developers as well.

Not only are we supposed now to reason about lifestyle in computational terms, we're supposed to reason about culture in computational terms.

We got memes and LOL-ing, and all manner of texting.

The dream gets bigger.

But it also becomes, in a sense, more fragile.

Because technology mediates so much more of our lives that rubber is meeting the road so much more often, and friction becomes felt much more.

If I'm using your piece of software, your future user experience that you developed, and this experience is cumbersome, but I need to use it every hour of my life that's starts to be a real problem.

So the challenge and the burden of getting it right is critical.

UX is mission critical.

It is innovation critical.

It is future critical.

Getting the human experience right in computation is very important.

I can't leave the computer room and escape your horrible design.

It's in my pocket all the time.

What this does is it makes capabilities not something that we do so that we can just enable the future.

But it becomes something that we do as a feature in itself.

We no longer-- well, users are no longer interested in your product or your massive framework or your application or your applications.

What they're interested in, is a superpower.

When I install that app, or when I download that browser extension, I'm shopping for a superpower.

I'm shopping for an augmentation to my life, to my lifestyle.

The manner in which I use the technology and these capabilities, however, is up to me.

And so the job of UX is to fine-tune the capability and bring it and deliver it to the user in the most fine-tuned and human-friendly way possible.

It is not our job to bring the user to us, and have them do time-sharing on our big mainframe program.

What we do is time-sharing within their life.

So my phone knows to dim itself at night.

It knows to ring less loudly at this particular hours of my day.

It makes it much harder to solve our problems.

But we've got to solve them right.

We see this happening now all over the place.

Apps are fragmenting and focusing on their features.

And we see some of the best apps that we have, and some of the best-- and some of the best softwares on the web, are those which focus on delivering capability.

Dropbox is a fantastic example.

One of the titans of our-- one of the greatest industrialists of our times, he dismisses Dropbox as a feature, and not a product, but man what a feature.

It is the capability that I need.

And I will shape my lifestyle.

I don't need a product.

I need a feature.

So we don't build capabilities and harness capabilities only to invent these big monolithic systems.

Those capabilities are our products.

It is what we're doing.

So I want to close and explain to you a little bit what my experience has been with our vision of user experience, and the challenges that we had.

And it's part of the things that shaped my thinking about this problem.

I've been working for a couple of years in the esoteric realm of the web called content editing.

Content editing is a hot mess.

Browser vendors, I'm looking at you.

Much of the web is images and text.

But the capabilities to edit those two things together, to work with those two things together, is horrendous.

But we have a big dream about building capabilities for people to make great things for the web, to marry text and images and content in a way that is really compelling.

You see, images aren't going away.

They're so visceral and powerful, and say a thousand words.

But text isn't going away either.

Language isn't going away.

Symbolic systems are not going away.

And so our vision, our mission, is to bring capabilities to the web that will allow people to basically create editing experiences that will allow people to basically make great content.

But we had a problem in contenteditable, because contenteditable, like I said, is a hot mess.

And we spent a lot of time working on this space.

And this year we had a breakthrough.

We were finally able to rethink whether we needed to use contenteditable, which is a-- who knows what contenteditable is? It's actually a-- OK.

Very good.

Thank you.

It's actually-- its an attribute in HTML which allows you to basically transform your element into something that is writable, not just readable.

Wake up.

Stay there.

OK.

So we had this breakthrough.

But it requires us to really think small.

And the thing that we had the breakthrough with-- and this is just a small example of capabilities coming in unexpected places.

The breakthrough came with the caret positioning.

And you see here I've got this wonderful, not blinking but dancing, caret, just to bring home a point.

We wanted basically to lift the capabilities of content editing, and bring them to the user space, so that we can build a better API.

So that we can build capabilities, so that people can build their own editors.

One of the big problems we had-- and for a long time we thought it was impossible to escape contenteditable, and we thought we were trapped in it.

Because we could not have control of the selection and the caret.

We looked at Google Docs with envy, because they were able to style the caret how they wanted.

They threw away contenteditable.

And for Google Docs they're using the Kix engine.

They can style a caret, color it.

They can have several cursors on the screen, with people's names on it.

And it also gave them great usability capability.

Because if, for example, you're in an italic font, you can slant the caret to give hint to the user where they're about to edit.

Or if they've got command overrides, when-- when they press Command bold, you can make the caret thicker.

So that they know that the next time they're going to type characters, they're all going to come out thick.

And so we looked at-- we looked at that and we said, why don't the browsers give us capabilities so we can use them? And so we thought it would be so great if we could do what they do, and just have a div, and basically write an API that will allow everyone to basically build their own editor, and they can use their own carets, and they can have as many as they want on the screen, and they can to telepointing and all that.

And we thought it was impossible.

In fact, I had a dream of having, writing WYSIWYG Vim editor in the browser.

I love Vim.

And I thought the greatest thing I could do is write this WYSIWYG Vim editing command-like thing on the browser.

But it would be impossible.

Because I didn't have this control with carets.

I could go into all of that, but basically caret positioning very difficult.

But we had a breakthrough.

And it came when we discovered some really, really weird APIs in the browser, just hidden in there, really, really hidden in there.

And they were like awful.

Like they were-- each one was buggie, like in a weird way.

But cobbling these together, we were able to actually solve this.

And we were able to basically get rid of contenteditable altogether by being able to control the caret positioning, all of it.

So we can do WYSIWYG editing, everything-- everything is in user space in JavaScript.

And this is now delivered as a library to users.

And so what we thought is that instead of just building an editor, what we want to do is build capabilities, and build the tools that others can build editors and editing experiences on.

We don't invent the future.

We do have a big dream, a dream where the web is writable, a dream where the web is rich, and a dream where creating content for the web is natural.

But we don't have a roadmap for that future.

What we now do have is just the capability.

And what we're doing, is as fast as we can, is we want to put the capability right there and see what people do with it.

We can't invent the future, but we can enable it.

Usability, accessibility, capability; these are key in user experience.

But it is the capability that affords us the other two.

It is capability that gives us breakthrough in accessibility.

It is capability that short-circuits our accessibility bias, and our perception bias, and allows people to enable the future.

As I was sharing these ideas with a colleague at work, I was just talking about and reasoning this with him, and he just had a great comment at the end.

He looked at me, and he said, Petro I know exactly what you're saying.

You're saying, don't start the resolution.

Enable the resolution to start.

And I was like, awesome.

So shout out to Christopher Sugnig.

Don't start a revolution, but harness capabilities, develop capabilities, ship capabilities, and enable the revolution to start.

Dream big.

Think small.

Thank you, guys.

Wow, come over to the chill lounge for the last time.

I'm going to miss this place.

It's been lovely.

(petro salema) I'm leaving death on the screen.

Hang on.

Don't leave death on the screen.

Well I thought it was really interesting that we opened the conference yesterday with Hayden telling us that the important thing to remember is that we're all going to die.

And you closed the conference with death as well.

So if that's-- that's something we can all take away from the event.

That was absolutely incredible, by the way.

And I feel-- I feel like I can't really do it justice with questions.

What do you feel about the ES6 Promises API? No, seriously though-- is there-- is there actually-- how much value is there in innovation? I mean take your Xerox example, or even the iPhone.

When the iPhones hit the scene, everyone thought, wow.

This touchscreen is incredible.

But touchscreen wasn't new.

Like, it had been around for ages, just not done very well, and same with like Windows, who's taken what Xerox did and just made it better.

What's-- is there-- is there value in trying to innovate wildly, or is better to look at the things that have kind of not quite got there, and just take that the extra mile? I think both.

I recall reading that a lot of the consumer technologies that we actually-- the foundation of a lot of the consumer technologies that we use today, a lot of that core technology actually came out from a project, a military project in America during I think World War II, where the government just invested tons and tons of money.

And for like years nothing came out of that.

And these guys were literally just doing sci-fi stuff.

But sooner or later, they came up with things-- innovations in radar and in all these other things.

And actually Silicon Valley was born out of that sort of-- that sort of experimentation.

And those things actually did lay the groundwork for a lot of the things that we built on top.

So there is definitely value in wild innovation.

But what actually happens is that oftentimes it's the hackers that have a breakthrough.

But it is the mainstream or the-- those who wear suits and are more representable, you know, who dismiss it.

The breakthrough, I think, that happened with the iPhone was not in-- was not necessarily in the touchscreen.

Of course they had-- they really fine-tuned it.

They really did id really well.

But what they did is that they took multi-touch, and married it with a really, really fantastic user interface.

And so they made it very usable.

At the end, it made the human being-- it empowered the human being.

It wasn't like, oh yeah.

This is an incredible capability.

But we'll need to train you like an astronaut before you can use it.

And so on the one hand, wild innovation is-- is really great.

But it is important to find a-- basically a practical way where you can take that innovation, and really just ship it.

Bring it to a human being in a way that is actually manageable.

Don't shoot a rocket at them, and tell them to eat it.

I guess-- sort of a historical example would be the laser.

Like some scientists invented the laser.

Look, look.

We invented the laser.

Well, what does it do? And it wasn't until many year later that we saw all of the actual, I guess, products being built with that in mind.

What are we seeing that happen with now? I guess-- I guess the Oculus, I guess-- is that? Are we seeing VR sort of being done correctly now? Or are we extra steps away from that? What else is almost there? Well, I actually think-- I don't know.

We don't know.

I think that's the point.

We really don't know.

But I think our duty is to build things which we can actually get to users, and not to dismiss them.

I don't know.

The thing is that the future always catches up to us, and it just does a peek-a-boo on us.

So we'll be looking, Oculus, we're saying we're nearly there.

We're nearly there.

But somehow I just keep puking.

And then someone-- and then someone comes in and says, you know what you're missing.

You forgot to squeeze a lemon on top of-- on top of the device.

And all of sudden it cures it.

And we're like what? And that's the way it happens.

So I don't know.

But this is the part of the thrill of what we're doing.

I think what we need to focus on is delivering these capabilities, and not just hoping to build this massive Superdome, where we then will control the whole virtual reality experience, but give it to people.

And give to developers so that they can actually build something with it.

Give something that's smaller.

Because you don't know how virtual reality-- what virtual reality will be used for, medicine, shopping; we don't know these things.

I suppose-- when you were talking about accessibility bias.

I think that sci-fi movies are a great example of that.

I mean you were looking at "Back to the Future."

Someone went, what's the future have? It's got a skateboard, but without wheels, right? That's the closest thing.

That's right.

I forgot that.

A great example was "Minority Report."

And it was something that there for a while, the interfaces were amazing.

Because you can just control things with gestures as long as you put on some gloves.

And then Microsoft released the Connect.

Like you do not need the gloves.

What kind of element of UX do you think is tying us down currently? What bits of legacy are holding us back? Oh, good question.

Well you know that "The Minority Report" thing didn't work, right? I actually tried this at home.

I actually tried to build my own thing.

And I got that whole thing to work.

I put these colored tabs on my fingers.

Because I love UX.

And I was just doing all things.

I could control.

I could do double-click.

But do you know what happens when you do that for like five minutes? Gorilla arms.

You know, you can't do the whole Tom Cruise thing where he had a cut every five minutes, and hat is dusted off, and he had a drink.

So that doesn't work.

But-- but exactly, that's accessibility bias.

We envision all these things.

But to get to really work for a human being is really difficult.

What are the things that are holding us back? You know, I don't want to make a political statement.

But I've been really, really interrogating this thought, and I've been thinking.

The mobile revolution has brought us a lot of things.

It's actually a really significant thing that happened.

Computing is in our pocket.

But I really see that there is a tension, and perhaps a problem, where we've lost some of the openness of the web.

Some of the maybe-- I don't know-- flexibility of it.

I mean I got into this thing because I was finally-- we had these great programmers at school in Tanzania.

But they thought I was a jerk.

So they would never let me-- I was a little kid.

And I was like, just show me what this awesome equation is.

How do your-- how do harness these powers? And they just brushed me away.

And then they made these awesome games on their computers.

But when I do view source that was it for me.

And that was like the blue pill or the red pill or whatever, in the Morpheus where the lightning bolt happened, and I went one way.

And here I am.

And with an open web, we had a lot-- we have a lot of opportunity for us to basically take what we need from the native system, and build on top of it.

But I feel-- and the way I've said it is that it feels like mobile is actually like a padded cell.

You know, it's really-- It's really tricked out with awesome things.

But you're kind of trapped in there.

And it's very cumbersome to develop for it.

And it's brought us really far.

And it's even spoken into the web and how we build software.

But I really wonder whether it will allow us to innovate as vigorous as we were able to do on the web.

So it could be that there is a curse in that blessing.

I think-- especially sort of going back to "The Minority Report" thing, the idea of the interface not quite working, due to sort of stress on your arms.

I remember I was-- I had appendicitis, and I went to hospital when was I think 13-14 years old.

And my friend loaned me his Game Boy.

But being in a hospital bed and playing Tetris, and I remember I could only get to level nine before it would just slowly hit me in the face.

Because I had no blood left in my arms.

Let's talk about Windows 8.

I mean they tried some pretty incredible stuff in terms of UX innovation.

Like, it was probably the most radical change we've seen from a mainstream OS as far as, I guess, until Windows XP or Windows 95 even.

What did they do wrong? Or is it just a matter of time before we realize they were right? Another good question.

I don't know.

But I think the verdict that came out was it just surprised people in the wrong way.

And it really surprised me.

I did use Windows 8.

And I was trying to find out how to quit.

And I'm not like nube.

OK? And I was using control alt delete as like-- as a default way of quitting.

And so something there is not right.

You know? Somehow you didn't serve the human when you forced him to basically pull out the hacker on him.

So I think it's where you marry the technology with human beings.

It's not just about making it, you know, clean design and thinking, and astronauting-- astronauting a system.

Eventually it's really got to work with human beings.

I wonder if you want to do something as radical as that, like what Windows 8 tried to do.

Maybe they should have taken more of like the Facebook approach, where they-- they change a feature.

And everyone goes, I don't like this.

And they're like, you'll get used to it.

And they just keep pushing the platform like that.

They do do that.

They do do that.

I think what they-- I think ultimately when we use computers for the features.

And so we don't really-- I'm not interested in the whole operating system as such.

I'm really interested in the programs.

For example, I have a Mac there.

But the thing I use it for mostly is for the browsing and for Vim.

OK, those are the things I use my program most for.

And I can do that any, any UNIX system.

I think you've got to work on highlighting the features, and bring-- and building great-- just great capabilities in the system, and not so much on astronauting the whole system in itself.

I don't know.

Maybe less is more.

Less things flying around at you, and less changes there, and just building greater products within the system.

I don't know.

But that's just a guess.

That's absolutely amazing.

A huge round of applause for Petro Salema.