Norman was bothered by his analysis and tried to find examples that refuted this conclusion: he failed. Every radical innovation he investigated was done without design research, without careful analysis of a person’s or even a society’s needs.
— Norman D., Verganti R. (2012) Incremental and Radical innovation

The metaphor used in the paper is a common and very effective one: incremental innovation is like being on a mountain and trying to reach the top of it. Radical innovation instead is like jumping to a new mountain with the hope that it’s higher than the one you are on.

Understanding this is very important because it shows you the advantages and risks of both approaches. The incremental approach is very effective when grounded in research and is the one leading to the top, step by step. On the other side the radical approach isn’t usually grounded in research and has a quite high failure ratio because you can’t predict on which mountain you are going to land.

However, you can clearly see that:

Radical innovations seldom live up to their potential when first introduced. At first, they are often difficult to use, expensive, and limited in capability. Incremental innovation is necessary to transform the radical idea into a form that is acceptable to those beyond early adopters.
The bottom line is that both forms of innovation are necessary.

I think that you can see this clearly with startups. A startup by itself is usually an attempt in doing radical innovation, but in the principle it’s very very rough and requires lots of work to start growing and showing the full potential. Plus, if the idea isn’t delivering – the mountain isn’t as high as imagined – the startup usually pivots.

The paper goes on showing the two main dimensions where innovation can happen.

We conclude that human-centered design, with its emphasis on iterated observation, ideation, and testing is ideally suited for incremental innovation and unlikely to lead to radical innovation. Radical innovation comes from changes in either technology or meaning. Technology-driven innovation often comes from inventors and tinkerers. Meaning-driven innovation, however, has the potential to be driven through design research, but only if the research addresses  fundamental questions of new meanings and their interpretation.

And this is the most interesting part: technology and meaning, as two dimensions where innovation can happen. The two are related, and as such there’s always a bit of each in every innovation. The accent is where the main shift happens.

Let’s see briefly a few examples from the paper:

1. Market-Pull Innovation: any user centered design approach.
2. Technology-Push Innovation: the introduction of the color TV, the Xerox copier, the electronic calculator.
3. Meaning-Driven Innovation: the shift of watches from tools to fashion accessories, the invention of the mini-skirt in 1960s as a symbol of women’s freedom.
4. Technology Epiphanies: the Wii, using a new technology to change the space of video games.

Clearly, the Market-Pull Innovation is safer, while the Technology Epiphanies are way more difficult, also due to the resistance of the users to change.

You can find the full paper in PDF on this page. It’s worth a read. Norman and Verganti do a great work in detailing these two dimensions with some excellent examples and models.

Despise and deride it all you like, but the business card remains a growth market. How has this 17th century technology not just survived but continued to flourish? [...]
Bump was fast out of the gate, reporting 53 million users since its March 2009 launch, but a recent internal evaluation surprised its founders. The deep dive revealed that despite its design as a business product, it was primarily serving an after-hours function as a social tool.
— Bennett R. (2012) How Business Cards Survive in the Age of LinkedIn

“Surprised”? To find the survival of the business card surprising means not understanding human behaviour and interaction design as well.

Giving a card has many meanings: from the physicality of the card itself (have you ever played with one in your hand?) to the ritual of the handover (a strong social ritual), to the speed of doing that (handover, done!), to the visual design of the card itself (that’s a cool design!), to the collection part of it (did you ever flip through the cards you got after a day?).

If you want to “challenge” business cards with your product:

1. it needs to be faster, or as fast as.
   Test it. If I can give a business card and take your faster than your app, I already win.
2. it needs to be visually designed, branded, colorful, not just a line of data.
   You need to allow people to design their cards. There’s pride and “wow” in that.
3. it needs to create a sort of ritual.
   This is more subtle, but you need to avoid technicalities. Create some kind of gesture maybe. An interaction. Bump does this pretty well, but maybe something less awkward would be nice.

Notice that “having to install the app” already hits 1 pretty badly. Yes, it’s fun at the beginning to try the new app and see how it works, but when the novelty goes away, you’re going back to cards again.

Technology alone can’t help here. Promising that aggregating the cards afterward in a better way, organize the data, setup the reminders and the call isn’t enough to balance out the three factors above. Promising a better long-term outcome over a higher initial investment is something difficult as human beings, otherwise gyms would be the best business ever. ;)

Nothing surprising.

And yes, it’s again about Proximity Interactions.

Q: What makes design different at Apple?
A: We struggle with the right words to describe the design process at Apple  but it is very much about designing and prototyping and making. When you separate those, I think the final result suffers. If something is going to be better, it is new, and if it’s new you are confronting problems and challenges you don’t have references for. To solve and address those requires a remarkable focus. There’s a sense of being inquisitive and optimistic, and you don’t see those in combination very often.

[...] When you make a 3D model, however crude, you bring form to a nebulous idea and everything changes — the entire process shifts. It galvanises and brings focus from a broad group of people. It’s a remarkable process.
— Ive J. (2012) Sir Jonathan Ive: The iMan cometh by Marc Prigg

Design is inherently connected with prototype and make.

There isn’t much to add.

Responsive Web Design

• If you want layout adjustments across devices.
• You can live without complete optimization for specific devices.
• You don’t have access to server-side solutions.
• You really don’t trust device detection.

Device Experience

• You want maximum optimization for each type of device.
• And the ability to serve completely different user experience & features to each class of device.
• You’re comfortable with device detection.

— LukeW (2012) Which One: Responsive Design, Device Experiences, or RESS?

LukeW takes a completely technical perspective: devices, optimization, server-side, detection. It’s true, it’s important, but in the end, is it really what’s that choice should be about?

What was not implicitly said in Luke’s article (and I think bears discussion) is that choosing responsiveness, as a characteristic shouldn’t necessarily define the wider implementation approach. Device Experiences (i.e. standalone sites, aimed at a group of devices) can also be responsive, providing the flexibility to support a much wider range of devices.
— Stephanie Rieger (2012) Responsiveness is a characteristic

We’re getting there. Her addition is as valuable as LukeW starting point, but unfortunately it’s still missing the point in my opinion, the most important, critical and difficult decision. She has the answer between the lines, but she still talks about devices.

The user journey is the most important decision, not the technology. The discussion about technology, devices, optimization, etc, comes after you do your research and you verify if your users want to do exactly the same things in exactly the same way when at the laptop, when on the couch with a tablet and when around walking with a smartphone.

That’s the first decision.
The user journey.

And then, the two approaches might well converge. It’s not so strange as Stephanie was saying that you develop a mobile/tablet interface and you make it responsive, while having a completely different one on the desktop.

Once you start thinking about the journey, you see also clearly that when you say “No” in the decision tree above you might as well decide to go native instead of providing a website with device experience. It might be a wiser business decision.

The examples can be from the more extreme to the more obvious. If you are making a photo service, the focus of the device will be all around taking the photo and editing it, while the web counterpart on desktop and tablet might be focused on the fruition of beautiful galleries. It optimizes the flows, it reduces costs and creates better experiences.

Instead a news website probably will fit better being responsive since the objective and journey is very similar both on desktop and mobile: getting the news.

In a recent project I worked on the mobile experience was more focused around reporting and notifications, and the desktop about collaboration and interaction. It’s clear what was our choice there: a desktop website focused on facilitating the discussion and the interaction between people while the mobile website was focused around giving you at a glance the single update you wanted and the person to contact for that. It wasn’t possible to be built as responsive: not only the pages were different, but also the flows and the actions were different.

So, step back from the technical details at first, make the right decisions based on real user needs and activities, and then you can dig into all the technicalities you want.

As early as the 1950s, IBM programmers were working on software for things like submarine control systems and missile tracking systems, which were so complex that they could not be conceived and built in one go. Programmers had to evolve them over time, like cities, starting with a simple working system that could be tested by users, and then gradually adding more function and detail in iterative cycles that took one to six months to complete. In a 1969 IBM internal report called simply “The Programming Process”.
— Dave Gray (2011) Agile development

A small history excerpt from Dave Gray. This excerpt shows how much Agile isn’t – as many think – suited only for small projects: it was born in IBM and it was created specifically to cater a problem bigger than the actual planning possibilities with lots of variables and moving parts.

Another interesting detail that’s often overlooked is that even in its inception the release is not an option. You have to release to the final users, otherwise you aren’t really iterating. If you release only to your client, you aren’t really iterating, because you aren’t measuring and planning against the real world, but only against the fiction of the working team.

While, I agree, at the beginning you shouldn’t probably release (as you read above, a “cycle” could have lasted up to 6 months) it’s critical to test the platform with real users to really achieve the objectives of Agile.

There are about 489,000 YouTube videos that say “no copyright intended” or some variation, and about 664,000 videos have a “copyright disclaimer” citing the fair use provision in Section 107 of the Copyright Act.
— Andy Baio (2011) No copyright intended

Finally, with mock exasperation, I said, “O.K., let’s try one that’s a little less complicated: You want a movie or an album. You don’t want to pay for it. So you download it.”

There it was: the bald-faced, worst-case example, without any nuance or mitigating factors whatsoever.

“Who thinks that might be wrong?”

Two hands out of 500.
— David Pogue (2007) The generational divide in copyright morality

These are excellent articles about a very interesting cultural shift: the perception of copyright. The problem here is that people have a natural inclination in sharing and manipulating and here they’re just doing that.

I’m not trying here to write extensively on copyright, but I’d like to point out some interesting details that sometimes are overlooked.

Copyright started as a protection for authors, and accordingly to Wikipedia it started with the printing press in 1662 first and 1709 next in England. There was no copyright before, because it was the printing press that made duplication easy. Copyright rises at the same time as a simple and cheap way of duplicating is born. This doesn’t mean that it didn’t exist before, the author always had rights, but copyright is explicitly tied with the problem of duplicating.

Today, copying is easy, and copyright is a very challenged law, not because there are people that like to pirate (even if, of course, there are) but because it harms not only them, but also the natural inclination of people of sharing and manipulating.

From a certain perspective, the kids that are posting these manipulated works are understanding copyright better than the people that made the law: they understand that the author must retain authorship and revenues and at the same time they can’t see a problem in sharing and manipulating.

The problem of duplications started only because at some point duplication become easier, simpler and cheaper, but payment to authors didn’t. Quite the opposite, from a certain perspective: paying an author in the 15th century meant just taking some coins and giving them to the author, today you have to pass through complex online payments systems, while copying is still just one click.

When you balance in these three factors:

1. natural inclination in sharing
2. simpleness and cheapness of copy
3. complexity of payment to authors

You see today’s copyright struggle clearly.

And you’ll see also another thing.

Today, you can change only one of these three variables. ;)

This is not how things work, right?

But it’s exactly how it works on the web. You have to type a password before using your laptop.You have to login before you can access Twitter, you have to login before ordering anything on Amazon, you have to login before using Facebook. And then, if you work in an office and don’t like to mix your job and your personal life in a single identity, you need to log out of all your accounts and log in again to your professional ones.

This is because the web today is based on logins. We are more then 10 years into the internet age and still we are identifying ourselves with usernames and password, a method that has already demonstrated to be incredibly difficult to manage for everyone, because the “good password policies” are too hard to apply for a normal person that just wants to send a photo to his grandmother.

Is the login paradigm a failure? Yes, and you’ll find plenty of evidence online. One of my favourite is this report form Trusteer (PDF) that shows how 73% of people share the critical banking username with other online services and 47% of them share both username and password. From a completely different perspective there are recurring discussions on where’s better to put the registration, because that boring detail hugely influences adoption. Check this excellent presentation by Joshua Porter on this very topic. Of course, this model served us well up until now. But this is not enough anymore.

I believe we should move away from logins, and embrace identities. Or, without getting too philosophical, move towards an interaction paradigm that looks more like real identities and less like cypher codes from Mission Impossible.

I’m surely not the first person thinking and talking about this, and even more there are lots of people out there working directly on this specific topic, taking one stance or another on how to solve the problem. There are products like 1Password and Passpack and there are also big companies like Google trying to push forward solutions, plus efforts like Mozilla BrowserID that are headed in this very direction.

This indicates two very interesting things: first this is a huge problem that’s felt by almost everybody; second, there are a lot of problems to solve before reaching our end.

What I’d like to do here is to connect all these different approaches together under a single umbrella, to help everyone head in the same direction. And this vision is excatly the shift from logins to identities.

Identity

How could we do that? Well, one step at time. The first step is quite simple, and requires an incredibly simple interface in your browser. That’s what I want to propose today, and I’d love to start a discussion, in order to create a better web for everyone. I don’t have all the answers, but I believe that this is the right way to go.

This is how I think identity should appear on your future browser version:

Did you notice the top-right corner?
This browser window, knows who I am.

There isn’t much more to add, that’s what the user has to do to login. Nothing. This browser window is logged in with your personal identity and will instruct any websites you visit accordingly.

It’s so simple that the part about the basic user experience ends here. It just works.

What’s great about this way of managing identities is that you can easily switch from one to another. Plus, you can have multiple windows open, each one with a different active identity.

Private browsing will be just another identity, not a special mode anymore, giving a clear signal that you can still browser without disclosing anything at all.

Switching from one identity to the other might be locked with a password, and it might be possible to add an option to automatically logout to Privacy mode after some inactivity time.

For convenience, let’s use a name for this identity-based approach. Identity 2.0 is taken by OpenID. So, instead of Identity 3.0, let’s use the more meaningful Seamless Identity.

How does Seamless Identity work?

As it often happens with transparent interactions like this, there is a hidden complexity underneath. There are technical challenges that connects with two topics: privacy and security.

While I know a bit of both, I’m not expert enough to have a definitive answer for a service that could potentially work for every person in the world. That’s why I’d love to have feedbacks on the model I’m describing here and build together a solid standard.

One of the API could be a JavaScript API, and could work like this:

1. By default, it exposes a low security identity token generated for a specific domain. So any website will be able to associate data with you and you alone, without any risk to lose it, since that token will be stored with the identity. I imagine that this token will be generated with a cryptographic algorithm in order to be both secure, unique and not sharable between multiple domains. In this way, nobody will be able to track your movements even if your identity is active, because each token will be unique and different (and possibly, revokable).
2. If the website wants to know more about you, it has to ask. It’s not much different than a waiter asking your name to take your booking, and it will be available at the push of a button. I think that the next level up is “email”, since too many services right now need it for things like notifications. Notice however that there could be a service attached to this identity module creating special emails that could be invalidated, protecting in this way your real email address.

It’s interesting to note however that most online services will be able to provide most of their features with just the first level token, since the important thing is to uniquely identify you. The need to provide an email address is in many cases just a byproduct of the login paradigm and its compulsory registration. Think about it: you would still be able to access the whole of Twitter, Facebook or Flickr even if they didn’t have your email, right? The important thing for these services is to know that you are really you, in order to grant access to your data.

PROS:

1. Transparent user experience.
2. Increased safety against phishing: since you never have to type anything or disclose twice your credential to a website, they can’t ask you twice without looking suspicious.
3. Your data will be inputted only once in the Identity Manager provided by the browser, and you’ll never have to type this information again. So, nobody could steal your password, email or credit card, since you’ll never type these details again. This would also allow automatic detail change the next time you visit the website. The browser runtime will protect the data for you (this is an important point of course for the browser implementation).
4. A new class of services will be enabled, and the adoption barrier will be lowered to almost zero. There will be no registration process to slow you down: you’ll open a website and you’ll be able to start using it immediately.
5. Facebook, or other identity providers, won’t be the gatekeepers of your data anymore. They could instead be cloud services offering more services on top of this identity mechanism.
6. It will allow peer-to-peer authenticated exchanges, since the identity is now in the device and not in the service you’re registered with.
7. No website will have to store your credit card data anymore, since it will be provided ad-hoc by the Identity Manager when needed.

CONS:

1. You will still have one password, the one protecting your device(s).
2. The identity will be a cryptographic information stored somewhere: if you lose it, it’s gone with all the accounts you ever created, and you’ll have to retrieve them with site-specific requests.
3. The identity needs to be transferred to every device you own.
4. If you don’t have your identity with you, there’s no way to login by default. Exactly like if you don’t have your identity you can’t buy alcohol, or you can’t get on a plane.

However the cons aren’t so bad and can be easily mitigated:

• Points 2 and 3 might be mitigated by a backend based on a standardized cloud service to store the identity. Data would be encrypted before being stored so that not even the company providing the service could access it (see Passpack as an example of how this has already been done transparently). The service would allow retrieval in case all your hardware is lost. If you think about it, it’s in some way what already happens with Android/GoogleAccounts and iOS/iCloud.
• Point 4 might be a problem for some users, but it might be less relevant since there’s a growing number of users that uses smartphones, and well, a feature like this could be ported to non-smartphones as well.
• Point 4 can also be mitigated by the services themselves, enabling different login mechanisms to allow non-identity based authentication (i.e. sending you an SMS with a token). This isn’t new, and it’s usually well developed in the best password recovery systems.

It’s worth noting an interesting detail: a lot of people are already using the browser built-in feature of Saved Passwords, or systems like 1Password. WIth these you get basically all the cons above, with a minimal advantage compared to what would be possible with Seamless Identity.

Use cases overview

What’s even more interesting is that while SeamlessID is intended and works as a replacement of logins, certain services such as banks might still require additional security systems and ask for nonce passwords. Also, the “password recovery systems” of today, will be “identity reconnect systems” just in case you need a one-time access from remotely or reset your identity connection. These will be provided as today by the services, because they will store different data (a recovery for a bank will be different from a recovery for Twitter).

That’s entirely fine. This is just a first step.

This diagram shows at a glance different use cases and how SeamlessID solves the problem easily.

As it’s now probably clear, there’s no way logins can help you in having the very first level of identity. That’s missing, because it’s too slow. It’s also one of the reasons why a lot of systems like Facebook are closed gardens: once you’re in, that first sight identity is granted. Once you’re in.

All the middle ground of identity is covered by logins as well, however SeamlessID will be simply quicker, by providing information at the click of the mouse and in a more secure way.

Seamless Identity API draft

This is a draft I thought that might enable this kind of service. It’s worth noting that while this is a JavaScript API, it’s possible to suppose that the browser could send the token inside the HTTP request header as well, thus providing this feature on systems without JavaScript. But that’s an advanced topic for another time.

It’s also worth noting that there are a lot of similarities with the Session API from Mozilla BrowserID, even if the Session API is still based on a login model instead of an identity model and seem still delegating the identity management to the website.

window.id.token

This property will provide the unique token to initiate the first level of identity exchange. As said before, this is unique within a domain.

The token could be an alphanumeric string like a md5 hash.

If the domain is blacklisted, or the user is in Privacy mode, the token property will return false.

As you can see this is similar, technically, to what already happens today with cookies, but the difference here is that now is the browser that generates the token from a private key and not the website.

This is huge, because it means that the identity doesn’t expire and the user has control over that identity.

Effectively, it means that you can trust any data created with the token, because it’s already you, and you can at a later time decide to keep that data, reset the token, upgrade the registration with the website or else.

window.id.get(<required>, <optional>, callback)

This will be a function to request the user to explicitly disclose these information. The application can request one or more fields, each one identified by its name.

For example:

window.id.get(['name', 'nickname'], callback);
window.id.get(['name', 'nickname'], ['avatar', 'country'], callback);
window.id.get(null, ['avatar', 'country'], callback);

When this request is issued, the user will see an overlay generated by the window chrome (not the page – for security reasons) asking if they want to allow that domain to access these details from that moment on.

window.id.getOnce(<required>, callback)

This function works exactly like window.id.get, with the same ability of ask for one or more fields from the Identity profile, and the same popup.

The difference is that these informations are returned to the web app only once, and every request needs to be authorized again.

Certain class of values, like credit cards, might only be available under the “getOnce” call. It might also be that this function will work only if the website is under HTTPS.

window.id.<field>

Once requested at least once with window.id.get(), each of the details will then be available directly at API level. This is useful also to handle updates: if for example the nickname changes, the system will be able to lookup it and verify it changed, updating its internal value automatically or after a confirmation.

This works well because we are talking about identities, and when some detail about you change you expect anyone you are in touch with to automatically get that update, or at least ask if you want that update to happen.

Notice also that I used “window” instead of “navigator” because the idea is that each window can use a different identity and this would make it cleared. However this is really just a detail managed by the browser engine itself. It could be “navigator” as well.

Native support

Another important thing about this approach is that identity will switch from being just multiple logins to memorize to being an operating system level feature, like the KeyChain feature in OSX.

In this way, once ready, Firefox, Chrome, Explorer, Safari, Opera and the other browsers could just provide an interface to that identity system.

This is even more relevant because for security reasons it is important to have all the interactions with the Identity Manager to be outside the website part of the screen: in this way they couldn’t fake any interaction with it (even if, as stated, you’ll have to push just one button, not type private data directly in the website).

This last thing is easy on a computer, but it’s hard on a smartphone where most of the screen estate will be used for the website. In this scenario, it will probably need to slide away like happens with the multitasking bar of iOS, in order to show the controls outside and maybe showing an image that you setup, and that a phishing website couldn’t know.

What will it mean for developers

Think about what happens today: you are developing an idea to help people do something. Today, you can’t really start if you don’t have a registration system of some kind. Even if you use a library, you have to take it into account.

Even worse, you will have to find ways to motivate enough your user to overcome the registration barrier and use your service, or create a smart system to allow your user to demo the system before registering, with all the complexity that it might mean.

With Seamless Identity the registration barrier disappears.

For your earliest prototype, you might even just take the token and work with it, without any registration or any additional detail. You will be able to test the platform and build only one code path. There’s no split between app and demo, it’s all app, working, without any barrier.

And all of this will cost you a single call to window.it.token.

Wouldn’t that be amazing?

Could you imagine all the services that could exist thanks to this?

Adoption

While I was writing this article Google published a very similar idea to handle multiple Chrome users. You can see their solution here. This is a good early confirmation that this approach is good, even if I’d put the login on the right corner because it’s where we usually expect it to be and I don’t want it to be confused with the app itself. However Google Chrome’s solution vision is limited to Chrome. What we are talking here instead is a new layer for the open web.

I think that Mozilla has the right culture, technology and freedom to move forward this shift to identities and create a standard that will be adopted by all the other browsers… and hopefully operating systems as well.

Mozilla is already working on BrowserID, and this could potentially be the backend for this kind of identity shift, and after reading this article by David Ascher now I’m even more sure of this.

There’s of course a risk: the risk that each browser manufacturer will try to create walled identities, forcing users to use only one browser forever, with no ability to switch. You can clearly see that this will basically kill this concept, and will delay the adoption of an improved identity system for more years.

It’s important, if not critical, that the identity is easily transferrable, with a one-click way to do it: “Do you want this browser to use the Identity X?”, done. Even better if it will be a OS-level library. And BrowserID is again already trying to solve this problem by federating the concept of identity.

Otherwise… it will be just a way to trade one kind of fragmentation for another. Let’s work together. This should be a standard foundation for the future web. Identity must be in your hands, not in the hands of some external entity.

Even if I believe that Seamless Identity is the correct next step, I’m not focused on this specific implementation, just on this specific user experience and the fact that the code usability needs to be excellent, but even that is open for discussion. I believe that identity needs to make a step forward in being seamless and transparent, and that’s what I want to see. If it’s delivered in a different way, that’s still great.

~

If you think about this, the switch from logins to identities will also close another gap between native applications and web applications. Today you don’t have to login to an app you downloaded on your Android or iPad, and why should you if it’s local?

Moving from logins to identities on the web will allow this seamless experience for web apps as well, everywhere, on mobile and desktop. And on mobile it will be even more powerful.

I see a huge potential.

Do you know any browser developer? Participate in the discussion (on Twitter we are using the #seamlessID tag), link this article to them. I’m sure they will be interested, and you’ll help to change the web. ;)

Updates from the comments

1. Storage: what wasn’t clear enough probably is that this system by default stores everything in a secure space on your device. There’s no need to sync or put it on the cloud, you are in complete control. This already happens with Password Managers. If you want to think about this in a different way, SeamlessID simply makes transparent and more secure your Password Manager.
2. Device-less access: on the completely opposite side, there might be situations where you either don’t have your device, or you can’t access one. In this scenario, it’s also simple, because SeamlessID doesn’t mandate any restriction on the fact that the account might also be synced remotely. You might be able to log-in temporarly with a remote account, like a special privacy mode. The stress point here is that the browser should handle this layer of complexity, not the user. This already exists: OpenID logins, Facebook logins, Twitter logins, Google Account logins are all doing this.
3. Is it a replacement? No, not at all. Yes, this idea is designed to completely replace logins for normal usage, but logins will still be available as an alternative. Consider also that with SeamlessID in place you might still need a way to access a service without your authenticated device with you. The way will be the equivalent of the current “password recovery”, with the difference that will generate a one-time access instead of resetting the password.
4. Identity vs Identity certification: the fact that today we are using logins means that when someone says identity they often refer to “identity certification”. However, that’s a different thing: one thing is the neighbour that knows you by sight, another thing is the airport check-in that asks for your passport. That’s why SeamlessID has different access levels and doesn’t mandate any certification: it might be added, or not. The important part is automating the task so it’s not anymore the user that needs to remember that, but the Identity Manager in the browser or operating system.

In 2006 the rumors of Apple making a phone were ramping up again and one day I had an idea by reading of the LED screens powering devices like the Sony NW-A3000: a phone that will have a full touchscreen surface, with a under-the-skin screen. I wasn’t really thinking of the “iPhone”, but I decided to give the mockup that title to get into the discussions.
A few months later, trying to make a better render with the help of Cristiano, I inherited however an element from the iPod: the wheel, because I thought that it might still be a good way to go through a long list of items.

In hindsight, it’s clear that with just a little more thought I should have dropped the scroll wheel as well like I did on the first mockup. Still, I think that given the timing it’s strikingly similar to the Apple patented prototype and I got also right the most important feature of the final iPhone: the full touchscreen surface with an ad-hoc interface.

However, while the other mockups now feel old, I still find the following rendering very fascinating with its glowing logo and its seamless screen, reminding a bit Space Odyssey.

To me, claiming that Pictures Under Glass is the future of interaction is like claiming that black-and-white is the future of photography. It’s obviously a transitional technology. And the sooner we transition, the better.

With an entire body at your command, do you seriously think the Future Of Interaction should be a single finger?
— Bret Victor (2011) “A brief rant on the future of interaction”

I don’t think I have much more to add to this excellent article, even if unfortunately he’s downplaying a bit too much touch interfaces that are really here at consumer level since a few years ago.

To his point, I’d add that I don’t expect things like bendable devices, the kind of interactions that I expect in the future aren’t about making strange things to objects in order to perform arbitrary actions. If I pull something, I expect it to grow, or get longer, or open, not surely do some action on the screen.

As I often stated, the limit of today’s computing is in input-output, and even more in reality while we have lots of outputs (mouse, keyboard, touch, wiimote, camera, etc) we have very few inputs. When they ask me what screen I do want, I answer “I want as many pixel as possible”. The reason is simple: stand up now, make a few steps backward, and have a look the percentage of your field of vision that’s taken by the computer screen, compared to the whole space you’re in.

That’s why.

It’s tiny.

That’s also why another field I’m interested in is the internet of things: because it’s a way to make everything around you an input/output device that could interact with any part of your body… and maybe your mind as well.

Today there was a really well thought article by Joe Hewitt regarding AirPlay and the Apple TV. Here a few excerpts:

Not nearly enough of these analyses have talked about AirPlay. It’s clear to me that AirPlay would be so important to the Apple TV, you might as well call it AirPlay TV.

If I were an iOS developer, I’d start investing in AirPlay right now.
— Joe Hewitt (2011) AirPlay TV

Joe did an excellent summary. While I was noticing as well how little AirPlay was discussed and all its potential for both business and games, I never did a structured article as he did. It’s probably time. :)

For me, AirPlay has a huge potential, but let’s make a step back. The problem today is that most of the time there’s no proximity detection in our digital interaction.

Think about it: try to send a message to the person near you. You’re probably going to write an email and send it. That email then wirelessly connects to the WiFi access point, gets routed to a server somewhere maybe in the USA if you use a service like GMail, then there’s some server-to-server talk around the world and the email is sent back to the device. If it was a physical object, its gas consumption would be deemed as crazy, given that the person is right on your side.

Today, we don’t have any good tech to allow discovery and communication with a near device.

The one big technical hurdle for Apple to overcome is the unreliable WiFi connection between your iOS device and the TV.
— Joe Hewitt (2011) AirPlay TV

Or do we?

Well, it might not be perfect and it might not perform well enough, but Apple sneaked a really interesting piece of technology that, like AirPlay, looked nice but simple and got under most radars: AirDrop.

AirDrop is interesting because as Apple defines it works only on a few selected MacBooks, from 2008 onward, and there’s a reason for that: it requires a WiFi chipset (like the Broadcom BCM4322) that supports multiple streams. Why is this important? Because it needs to be able to stay connected to a WiFi network and at the same time use AirDrop. And it just works: you turn it on, drop a file, done. At a really impressive speed. I guess that the problem is power consumption, so AirDrop isn’t always on, a problem however that will disappear on a TV set, always powered.

I don’t know however if the answer is going to be AirPlay + AirDrop. There might be a problem of power consumption, given that even with iOS5 and iPhone 4S Apple requires you to connect to a power cord before syncing, but that’s might be just be something to avoid problems, given it’s syncing delicate data and AirPlay itself is WiFi.

What about the future?

It’s always very hard to make prediction, because there are lots of problems that involve also partnerships and politics between companies, but I’d like to think that:

1. One day I might walk into an office with an iPhone and start presenting without any cable, since I can do AirPlay to the projector, zero-configuration.
2. One day I could sit with a few friends on the couch and everyone could stream to the screen, zero-configuration.
3. One day I could send anything to a device that sits near to mine, zero-configuration.
4. One day, maybe, I might not even need any Apple device do do that, because everyone agreed on a standard.

I think that Proximity Interactions (PIx) are the near future of mobile. And these above are just the few things that could be possible with an AirPlay like solution, but proximity isn’t limited to that, think for example to NFC or what could be possible if we get a proximity technology that’s also able to get the position of the devices near you. But this is probably material for another topic.

But even with just this, it means that we don’t need “computer” anymore, just screens. A screen could be anywhere, without any controller, and just works. And I wouldn’t need to ask a WiFi password to stream something to some one near me, getting angry eyes from IT people from foreign companies.

And while this is somewhere Apple seems headed to, nothing avoids other companies to do the same. And this future scenario would be better with a lot of interoperability, since I don’t expect Apple to build things like projectors for meeting rooms. ;)

I really hope for a future with more Proximity Interactions, regardless of its form.