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.

But 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.

Even if I was speaking mostly about design, I added some elements of business, strategy and change management as well, because I thought they were relevant.

I admit, this is a quite dense presentation, I would have probably taken out some topics in hindsight at least for UX Conference, trying to be more focused. However, on the plus side, from the feedback I got it was really successful and lots of people asked more. I probably need to do more workshop and less speeches in the future. :)

One method, two tools, three business tips. This is how I organized the presentation, in order to be not too unbalanced toward design, even if that was the focus, but also not being too high for more hands-on people.

One method

The most important part of Social Experience Design is that it can’t be done without a shift from traditional, deterministic thinking to the different Theory of Complexity thinking. This shift is critical because it’s the only way to deal with complex systems, such as people and social dynamics.

That’s why I talked again of the Dot Loop, because it contains all the factors that needs to be built-in in any design – well, in any company – to be really effective. The Dot Loop is an effective abstraction to deal with complex systems without a banalizing approach to them. Every successful company work that way – even, of course, probably they don’t call it Dot Loop, even if I’m starting hearing about it more often. :)

Two tools

The first tool is the Motivational Diamond, a very simple comparative visualizations that helps anyone working with social dynamics to focus on the four Relational Motivations (Competition, Excellence, Curiosity, Affection) and compare different services or parts of the service.

The second tool is the Social Usability and its Checklist, prepared to simplify the approach to it and provides an easy mnemonic. Social Usability works on four factors, that are Relations (the other), Identity (you), Communication (the channel between you and the other) and Emergence of Groups (all the emergent dynamics, again a complex system behavior).

Three business tips

These are very simple, but are also a very important part of a real change management process:

1. Be in-the-flow. This is critical in any good design tied to any change management process, but also for startups that are launching a new product: you have to understand that the day of your user is already
2. Be a double-pyramid business. This is a very important aspect, and might be an article by itself. Luckily it is: I wrote about the double-pyramid some time ago. This means that social businesses needs to engage in a different structure and find a balance between hierarchy and socialization, because the solution is in that balance and not in building a full hierarchic company or a full flat company.
3. Be a double double-pyramid business. Plus, you can’t be really a social business externally if you aren’t internally. You might have a unit that does customer service or social media operations, but if the whole company isn’t aligned, the users will get that, and the rewards are going to be lower (not zero, but lower).

The workshop

The extra part I prepared for Digital Accademia’s workshop regarded a couple of exercises to allow people focus a little more on how to use actively Relational Motivations and Social Usability.

I prepared two exercises to stimulate thinking and discussions:

• In pairs, draw a Motivational Diamond
  This is very interesting because it helps clarifying the four Relational Motivations by discussing it with a peer, and then the public discussions allow to clarify even more. As often happens in workshop, I learned something also this time: I have to clarify better that we are talking about traits that trigger relational aspects. For example, when we talk about “excellence” we aren’t talking about an excellent content, but about how we are promoting people’s excellence… and narcissism. :)
• In isolation, pick an item from the Social Usability Checklist and design an interface for it. Then, merge it with your partner to create a new UI with the two you prepared.
  I liked this one a lot because it shows how very simple solutions and interface can trigger more complex behaviours. One of the participants was worried because her solutions looked “too simple” but actually… that was the value of it! :)

A small joke

At UX Conference I was the last one of the day, so I had to think of something. That’s why I started with a small design practical joke… but I won’t tell what it was, and I removed it also from the presentation above. You’ll see the next time, maybe. ;)

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.

“The inconsistencies in the interface between apps and the occasional lag doing simple things like scrolling in windows just screamed at me.”
— James Kendrick (2011) After the iPhone 4S, Android just feels wrong

“That having been said, it unfortunately remains the case that Android [Ice Cream Sandwich] isn’t as swift and responsive as iOS or Windows Phone (or even MeeGo Harmattan on the N9).”
“The subtle, pervasive lag that has characterized the Android UI since its inception is still there, which is not a heartening thing to hear when you’re talking about a super-powered dual-core device like the Galaxy Nexus.”
— Vlad Savov (2011) Galaxy Nexus with Ice Cream Sandwich hands-on

“Android, on the other hand, has always felt laggy to me.”
— Mike Rundle (2011) Android’s Touch Responsiveness Is Terrible

From an interaction design standpoint, this is a quite huge flaw in Android as is today and it’s one of the things that can be easily dismissed but in the end is that one able to create the magic of a perfect user experience.

I found a discussion on Reddit about this, here are some quotes:

“I’m not saying android’s touch responsiveness is bad, it’s just not as good and it’s very noticeable when playing games on it.”
“Scrolling a list of apps in the market, or doing absolutely anything in Reddit is Fun–are jerky nightmares.”
“However even compared to those parts that are not jerky, iOS still seems to be smoother. I cannot put my finger on what is actually different, but I’m not sure it is actually smoother/faster/better.”
— Reddit: Why is the touch sensitivity/responsiveness on android phones not even half as good as apple products? [Not trolling, honest question]

From the discussion and some good analysis there, it seems that the problem isn’t in the detection of the touch even, but in the response of the UI. Most of the responses seems to point out to the lack of hardware acceleration as the culprit.

I like this discussion because it’s very hard to show people this very problem: while its consequences are very relevant in the overall user experience, it’s often very difficult to make someone understand that “it should be 0.1 seconds faster” is actually a very important thing to do.

“The best clients, to my mind, don’t say that whatever you do is fine, they’re intertwined in the process. When I look back, it’s hard to remember who had what thought when. That’s the best, most satisfying work, whether a large building or a house.”
— Peter Bohlin, Architect (2011) A Genius of the Storefront, Too

Peter Bohlin is the architect that worked with Steve Jobs to build the Apple Stores all around the world. The article by James Stewart is interesting, but for me that sentence above is the most interesting one.

When working together people are able to communicate better, avoid communication overhead and create consensus quickly. It’s obvious right? But so often within companies and teams this is taken as granted, and this happens both when there’s a positive outcome or a negative outcome.

When it’s positive, it just happened, so we usually don’t think that the project went smoothly thanks to this. When it’s negative, we just don’t think it was a problem of creating the environment for the team to communicate and collaborate effectively, because we expect that part should just happen. The justifications in the negative case are often external, we blame other things: we communicated badly, the specs weren’t clear enough, the client didn’t approve this in time, and so on. However, to a closer analysis, many times the issue was a team issue, missing a good and healthy collaboration space.

A few questions that could help you to see if you have a healthy team environment are:

1. Do I find effortless to communicate with others?
2. Am I able to get a clarification even for tiny doubts?
3. Do I chat even about non-related things with my team?
4. Am I isolating my work from others?
5. Do I know what each other is doing?

It’s even more interesting because if you think to the effectiveness of Agile, Lean and similar approaches from this perspective you notice that there are many techniques that in fact are just tricks to facilitate the communication and collaboration within the team. Why is the product owner included in the team itself? Why do daily stand-ups exist? Why are kanbans so effective?

Does your team has a healthy collaboration environment?
From this perspective, why do you think it works?

You probably saw already this kind of interaction on YouTube ads. It’s quite simple: after a few seconds in, you can skip the video.

It seems quite effective, given what Bruce Daisley, sales director of YouTube and display at Google, said:

According to YouTube, for standard pre-roll (no choice to skip), users spend 48% of time highly engaged with the ad content.
For skippable pre-rolls (choice to skip) that have been viewed through, users spend 85% of time highly engaged with the ad content, resulting in 75% more engagement when the choice to skip is offered.

This is very relevant, because it tells us a lot how a simple interaction can influence behaviour. My thinking is that to skip an ad you have to recognize it and you have to actively take an action, something that requires a different attentive status.

But what’s the business perspective? Well, if you are a business seeing that your video is “skipped” isn’t a really good metric, also because given the analysis above, it’s better if they skip. What if, then, we could add the same interaction, but in a way that gives the user the power to tell something to the brand, at the same interaction cost – one click?

The idea could be as simple as this:

As you can see, in both cases you are able to skip the video with one click. But with this second interface, you are able to give an actually useful feedback to the business, something that could translate to some nice actions to improve the advertisement, make it better, less intrusive and at the same time more effective.

With no added interaction costs: one click. :)

Good writing conveys information more clearly, of course, but the reader isn’t the only beneficiary. Writing also makes us better thinkers. Even a talented wordsmith must first clarify his thoughts and eliminate ambiguity to make a convincing argument.
— Cennydd Bowles (2011) Editing tips for designers

This is a really good reading to… have some tips on how to write. He gives a few very interesting advice, and the article is a very nice summary of techniques.

Some good advice he gives:

1. Read lots: reading others helps build your skills, and even more helps to identify and study good writers (and UIs) and bad ones.
2. Make every word matter: or, in other words, remove the superfluous.
3. Cut adjectives and adverbs: this is a great advice, suggesting to use more descriptive verbs instead of generic ones.
4. Active verbs, not passive: this is a simple rule to put the reader at the center
5. Monster sentences: short sentences, to the point. Avoid lots of conjunctions.
6. Singulars and plurals: this is simple, you just have everything match.
7. Occam’s Razor: prefer simple explanations over complex ones, simple structures over complex ones, avoid buzzwords.
8. Vary pace: use paragraphs well, alternate their length and tempo.
9. Proof your work: reading aloud is very helpful.

This writing reminded me a very interesting and basic rule when you design interfaces buttons and interactors: always use subject and verb, at minimum.

This is very simple, and helps create a better understanding. To give an example, to you think it’s clearer to have a button that say “Add” or “Add post”? As any rule, when you master it you can break it, but it’s always important to keep it in mind.

Read Cennydd’s article here.

10 to 3 to 1
Apple designers come up with 10 entirely different mock ups of any new feature. Not, Lopp said, “seven in order to make three look good”, which seems to be a fairly standard practice elsewhere. They’ll take ten, and give themselves room to design without restriction. Later they whittle that number to three, spend more months on those three and then finally end up with one strong decision.
— Helen Walters (2008) Apple’s design process

The magicians say “Presto!” and we gasp in delight. But they deflect our attention from the back-breaking labor that goes into assuring a perfect customer experience, hundreds of times a day, at 300 stores around the world, and countless conversations on the phone.
— Adrian Slywotzky (2011) Steve Jobs and the Eureka Myth

It’s hard to find informations about Apple’s way of doing things, and as human beings our perception is biased in thinking that the most visible person does most of the work, exactly like it’s more probable that you’ll know the name of the lead singer of a band, but not of each member of the band itself.

These two articles are good because they are the rare ones that actually try to shed some light – real light – on the merits and ways of doing things. Some informations are from Michael Lopp, senior engineering manager at Apple:

1. Pixel perfect mockups: they do a perfect mockup to remove all the ambiguity (animations included, afaik).
2. 10 to 3 to 1: they do 10 pixel perfect mockups, then another iteration with the best 3, to design the 1 to be implemented. This, for each and every screen / feature.
3. Paired Design Meetings: they do two kinds of brainstorming sessions: crazy brainstorming forgetting about constraints, then another production meeting that nails down what’s possible. Designer and developers together.
4. Pony Meetings: since managers sometimes ask impossible features, or “ponies”, the process is reversed: the designs are prepared (10-3-1 and pixel perfect) and then shown to the managers, that will then point in the direction they want. This to avoid them to request ponies.
5. Business Design: the products are built upon intricate levels of business design.
6. Engineered Customer Experience: the experience is crafted in every detail, from the device to the store experience. I know a bit about the training process of Apple Store personnel, and it’s kinda amazing.

This is important to understand when people try to understand “genius”, “talent” and even when company try to replicate in one or another way Apple’s success, or if you want to improve/change the working approach of your design and development teams.

It’s even more interesting when compared with the usual “Apple doesn’t do user testing” claim. That’s true, formally, because nothing goes outside the company. But on the other side the process above means that Apple does a lot of work internally. I mean, 10 people working on 10 pixel-perfect designs? Then 3, then 1. Can you imagine what does it mean both time-wise and cost-wise? ;)

“In Holland, we have two words for design. One is vormgeving; in German formgeben. And the other word is ontwerpen; in German entwurf. In the Anglo-Saxon language there’s only one word for design, which is design. That is something you should work out. Vormgeving is more to make things look nice. So for instance, packaging for a perfume or for chocolate in order to make things fashionable, obsolete and therefore bad for society because we don’t really need it. While ontwerpe means, and the Anglo-saxon word, but its stronger, means engineering. That means you as a person try to invent a new thing—which is intelligent, which is clever, and which will have a long-life. And that’s called stylistic durability. It means you can use it for a long time.”
— Gert Dumbar (via Swiss Miss < Frank Chimero < BanquetHall)

Design by itself is something very difficult to define clearly, for many reasons, so while from one perspective I believe that design needs to be holistic, from the other I welcome definitions that help understanding the discipline better.

This quote made me think two things.

First, it made me wonder a bit about how the discipline evolved. Right now, I suppose that it evolved from a specific perception of the results of the design process. If you think about it, we can simplify by saying that any product passes through roughly three phases:

1. Functional, where the product does something, but that’s it (think about just wrapping a sheet of cloth around you)
2. Usable, where the product does something and it’s usable (think about a normal apparel)
3. Pleasurable (think about a great dress)

I think it’s normal for a new product to start at first with Functional, then Usable, and only then we evolve trying to make it Pleasurable. Think about clothes, houses, cars, and kinda everything. Design in its common perception happens when you reach the last phase (even if, clearly, you have to apply design to both the Function and the Usable phases as well, and that adds confusion). Also, a product, and a company, may choose to stop at just one of these phases, to reduce costs.

This theory explains a bit to me why design and “how it looks” – or vormgeving – is often perceived as the same thing: it’s because design have to do 1, 2 and 3 all together to be good design, and so great product emerge and will look good. And since being pleasurable is what everyone will perceive in the end, it’s why it skews the perception of what design is.

It skews it at the point that there are of course people – and companies – that say, do and sell products that are only Pleasurable without being Usable or Functional, and sell it as design. And that’s where the confusion begins. I won’t make examples here, but think about all these products made with poor or common materials, with poor or common functionality that are sold as “design products”.

Second, I think that there is a plus in considering the two aspects of design distinct as above, because it clarifies better the scope and the focus of two parts that are necessary in the design discipline. On the other side I think that a hard split between these two can be also a problem, because it creates a barrier between two things that needs to go together. For example, Niels pointed me that in Holland people that do “Vormgeving” are studying in Art schools, while people that do “Ontwerpe” are studying in Engineering schools. We need these, as well we need Design schools, that teach both – and how to do both together. ;)

I noted down all the interesting points – at least, the parts I was able to get – using a Griffin Stylus and Noteshelf, a really impressive iPad application.

You can download the dConstruct 2011 notes from here, in PDF format, about 40 pages like the ones below.

Debunking the bullshit

Do you remember in high school that poor kid that constantly had low grades in math but brush in hand will be able to blow your mind by drawing? And do you remember the kid that has excellent grades in math, but was incredibly awful in drawing anything, even just a straight line? And the other kid that looked all the time annoyed and had overall low grades, but everyone listened amazed at their stories? And that kid that everyone knew, that talked with everyone, all the time? Have you ever seen the difference between the kind of people that follow an Engineering class and an Art class? And between a nerd and a jock?

Do you know Howard Gardner? It was 1983 when he defined his Theory of Multiple Intelligences. He was able to define in a brilliant way that there are different kinds of intelligences, identified by their brain localization, their place in our evolution, the susceptibility to symbolic expression, a distinct developmental progression, the existence of savants and so on. The intelligences he found are:

• Spatial
• Linguistic
• Logical-Mathematical
• Bodily-kinesthetic
• Musical
• Interpersonal
• Intrapersonal
• Naturalistic

Then for the last 28 years, we read things like:

A designer who does not write markup and css is not designing for the web, but drawing pictures.
— Andy Rutledge (2011)

My short answer is “Learn code.”
— Frank Chimero (2011)

Honestly, I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs. No excuse.
— Elliot Jay Stocks (2010)

Designers must have a solid working knowledge of at least one modern programming language (C or Pascal) in addition to exposure to a wide variety of languages and tools, including Forth and Lisp.
— Mitchell Kapor (1990)

Do you get what’s wrong here? Coding and Designing tap into two very different kinds of intelligence – it’s even more complicated than this, and Gartner is just a widely understood example, but let’s simplify for a second. We even have different stereotypes and jokes to identify the two categories lifestyles!

So, please stop: this recurring debate is harmful to both professions.

It’s harmful because since it tries to create hybrid professionals, that by themselves are good, but maybe there were just exceptional specialist professionals. Because it forces young designers to learn coding, when they should study for example cognitive psychology and social psychology. Because it slows down designers in becoming excellent in what they are paid for. Because it creates the expectations that “designers should code, so I don’t need a frontend developer” (harming also frontend developer specialization).

So, please: stop this bullshit.

The ratio

But wonder what? It’s more complicated than that. People that suggest that designers should be able to code are suggesting a solution to a problem they see, before analyzing the problem itself. Once we look at it, we notice that there are two components of the problem:

1. Know what code does
2. Know how to code

Knowing what is very different by knowing how. This takes us to the usual questions: do architects need to know how to build a skyscraper? Do car designers need to know how to build an engine? Do a movie director need to know how to act? Does a surgeon need to know how to build a pacemaker? Of course not.

But yes, they need to know what these things do. How they perform. What are their limits.

And yes, learning to write code is able to build both these knowledges.

But not both knowledges are required for designers and that’s why the whole “designers should code” is bullshit. The sentence should be: “designers must know the capabilities and limits of their media”.

And wonder what? That’s exactly what happens in other kinds of design! A print designer that has never seen a type foundry will still be able to create wonderful prints. An industrial designer that has never seen a lathe will still be able to create wonderful objects. It happens every day.

And here we’ll reach the second point: teamwork.

Because how should a designer learn the limits of his media? There are two ways: use it and collaborate with people that build it.

The digital team

Let’s see what happens in a near industry. Around 1960, William Bernbach had an interesting idea: instead of having art directors and copywriters in two different departments, with huge difficulties to communicate, let’s create creative teams: one art director and one copywriter together working on the same design at the same time. His company went from $1 million to $40 million thanks to his creativity and these structural changes. Today there are almost no agencies that split art directors and copywriters. They are teams.

In this digital world – no, I’m not just talking about the web – there is another kind of team, and if you have ever met a situation when this team was able to live you know how well it works. The team of the digital era is a designer / developer team — well, not exactly, but let’s stop here for now. Also, the missing copywriter here is a huge problem in my perspective, but I’ll talk about teams and creativity another time.

The reason is simple: in this way they talk and collaborate. They learn the limits of each other’s profession without knowing anything about how actually do it. Because it’s not a requirement for either of them. It’s more efficient, and well… it’s healthier as well to have someone to talk with and get a different perspective.

Is it all wrong then?

If you read so far you should know my answer. Yes: it’s more complicated than that. ;)

There’s still a good point in suggesting that designers should code (“Why, it isn’t possible to do that? I’ve seen it done by Facebook!” – argh it looks simple but it takes ages with this platform here!). Exactly as there’s a good point in suggesting that developers should learn some design basics (“Stop asking me to do it pixel perfect” – argh it’s not pixel perfect what I’m asking!).

The reasons are simple:

• It’s way easier to learn the basics of how to code than learning how to build a skyscraper.
• It’s one of the ways to balance over-specialization and be a better professional.
• In small teams or startups it surely makes the difference if you know both.

And the reverse is valid for developers too.

In any field, if you expand your view to know all the ecosystem around you it’s beneficial. You can’t know everything, because even in a single discipline there is enough knowledge to fill a couple of lifetimes, but knowing a little bit more helps a lot. And I’m not talking just about designers and developers, but all the things that happens in a project. Knowing about budgets, timeframes, clients, market, advertising, SEO, health, food… all things that are able to increase efficiency, satisfaction in the client and quality in the final product… and satisfaction for yourself as well.

So: you don’t have to learn a bit more outside your discipline, but you could.

However, please, please, please: before coding learn some cognitive and social psychology! It’s more important for your profession!

If you want to read more, there’s a great post from 2009 by Lukas Mathias about this same topic: “Designers are not Programmers” (I told you it’s an old and recurring topic), and thanks to Mark, Chris and Mike for the excellent discussions we had on this topic. Thanks also to Sean McCabe for a nice infographic to explain better the concept above about know what/know how.

Once understood the difference between “have to” and “could” the next step could be then a good explanation by Mike Rundle on the values of both generalists and specialist.

Q&A from the comments

• “HTML/CSS is not coding” or “Neither markup nor CSS are exceptionally difficult to learn” [1]
  I know that formally HTML/CSS are a different thing from a language like JavaScript, Ruby, Python or C++. But it is only in the eyes of someone that knows code already. It’s a distinction that goes missing to someone that doesn’t get it. Here, please, you have to understand that there are different people, with different mind, skills, and talents. Sure, there are designers that could code and aren’t doing that, but there are also designers that won’t be able to code at basic level in any way. There are people that can be wonderful specialists, and people that can be excellent generalists or T-shaped generalists. We are different, please, try to understand that before getting into a crusade.
• “I think there is a semantic issue here on the definition of ‘designer’.”
  Yes. I kept the article vague, because that is a completely different argument, and I thought – but I might be wrong – that would have diluted the argument above. But YES, that’s another good point. There are very different kinds of design, but the overall criticism usually is triggered against any designer that works on the web, and that’s why I called bullshit. Working on the web doesn’t mean that you have to code, just that you could code, and that is valid if you are a “web designer” or “graphic designer” or “ux designer” or “ixd designer” that works on the web.
• “Gardner”
  A few people started arguing about the theory I cited. Yes, there are criticisms, but it’s not the point, it’s just a starting concept to frame a little better the article with the support of a quite widely known theory. As Domenico correctly suggested me, you can have a look at other researches as well, like the CHC Theory, the WAIS, the Hebbian theory or a more widely known author like Daniel Goleman. It surprised me that this was the central problem for a few people. :)
• “to really take art to the next level, you really have to learn to code.”
  Yes. To really take to the next level. Exactly like a painter can paint, but then can start creating his own paints, in every profession you can benefit for digging both deeper and wider in nearby fields. I can also argue that to take it really to the next level, you should learn cognitive psychology,  social psychology, gestalt theory, marketing, copywriting, information architecture, usability, economy, statistics, science of materials, architecture, and so on. Yes, all these things will benefit a designer. Actually, since we are talking about designers and not developers, I prefer to suggest first some of these other things than coding – some of them are HUGELY missing from design skillsets – but as you can see, there are lots of things that could take you to the next level. It just depends what next level are we talking about. The point of the article, however, isn’t that there are no “next levels”, is that you aren’t less of a designer if you can’t code. You are just choosing something else (hopefully!).
• “some example showing why designers should code”
  Most of the people that are using examples are showing problems in teamwork, collaboration and communication. It seems that lots of people think that by knowing better you’ll solve the problem of having “an arrogant designer telling you what to do”. Such a designer is bad, but if he learns coding it just get worse. Such a designer is bad because he doesn’t have the correct teamwork skills to cooperate properly, and the same problem could exists in the developer as well. So, improve teamwork skills before coding skills, and without such an ass in the team, the overall mood and productivity will increase for everyone. ;)
• “So, in the end, they should or shouldnt?”
  The summary, is that there’s no answer to this question. As I said repeatedly: it’s more complicated than that. The answer isn’t “yes” and isn’t “no”. The answer is “choose”.

Renzo Giust and Clément Delangue (Moodstocks)  pointed me to a few resources, some known or quite famous, and some others less so:

1. Layar Vision: the company that was building mobile apps to add layers to the camera input, now has released the Vision feature, where you can allow your customers to point the camera to any object you want and it will detect it. Form Android and iPhone.
2. Moodstocks Video SDK: an API to allow developers to add real-time object recognition in the apps “in minutes” with also an analytics platform. For Android, iPhone and Blackberry.
3. Kooaba Paperboy and DejaVu: two apps that detect images you shoot and links it to its digital equivalent. Detects books, cds, dvds, wines, etc. They also sell their tech API to do the same, Smart Visuals. For Android and iPhone.
4. LTU engine: an engine to detect images given a specific fingerprint. I wasn’t able to get more details about it from the website, but they seem selling the technology layer.
5. (do you know others?)

I think that these technologies are already a good alternative to QR Codes in some specific scenarios and they might be even more engaging because they feel even more like magic to the final user.

Studer (1970, The Organization of Spatial Stimuli) discussed applying operant conditioning principles to the design of environments (such as buildings), by treating them as “learning systems arranged to bring about and maintain specified behavioral topographies…What operant findings suggest, among other things, is that events which have traditionally been regarded as the ends in the design process, e.g., pleasant, exciting, comfortable, the participant’s likes and dislikes, should be reclassified. They are not ends at all, but valuable means, which should be skillfully ordered to direct a more appropriate over-all behavioral texture.”
— Dan Lockton (2011) Design and behaviourism: a brief review

The whole article is a really interesting read for both designers and people involved daily in the creation of objects and spaces that are going to be used by people. So… I think pretty much anyone. :)

Another good part is at the beginning when he clears a common misconception between positive and negative reinforcements:

It is important to note here that in Skinner’s terms (1971, Beyond Freedom and Dignity), positive and negative reinforcement do not imply ‘good’ and ‘bad’, and negative reinforcement is a different concept to punishment. Positive reinforcement is giving a reward in return for particular behaviour; negative reinforcement is removing something unpleasant in return for particular behaviour.

There are a lot of interesting details like the two I cited above, but another summary that you can find in the text is about the different social trapscategories (Cross and Guyer, 1980):

1. Time-delay traps, where the lag between a behaviour and a reinforcer is too hight for it to be effective (“the high school dropout who, avoiding the present pain and unpleasantness of school, finds himself later lacking the education which could have prepared him for a more rewarding job”).
2. Ignorance traps, in which people fail to make use of generally available knowledge when making a decision.
3. Sliding reinforcer traps, in which certain behavioural patterns continue long after the circumstances under which that behaviour was appropriate, producing negative consequences
4. Externality traps, where the reinforcements relevant to the first individual may not coincide with the returns received by the second (“if you spend a lot of time choosing your dessert in the cafeteria, you will not suffer anything, but all the people behind you will”).
5. Collective traps, in which reinforcements or consequences will be paid by a group of people based on behaviour by one or more.

It’s interesting for me because as you can see all these categories are in a way or another a mismatch between the action and the received feedback, a mismatch that can be on different scales: type (positive good, positive bad), intensity (nothing, not enough), time (delay).

Take 10 minutes of your time and read the article, it’s worth it. :)

(thanks to Gianandrea for the tip)

First of all, when I installed Lion and after a few discussions with fellow designers, I suddenly remembered the time when I was a freelance and I was also teaching to people that have never touched a computer: “Ok, now if you move the mouse wheel you can move the page up and down. Try moving the page down now”.
Can you guess what happened? — They moved the page up.

Then I found this comment by Larry Tesler (via Gruber):

Most (but not all) study participants expected to position the mouse near the top of the window to bring the content hidden above the top of the window into view. One reason was that they were looking at the top of the window at the time. Another reason was that they were more likely, as their next action, to select content in the upper half of the window than in the lower half. Consequently, we made the upper member of the arrow pair move the content down. With apologies to computer architects, I’ll call the majority whose expectations were met by this decision the “top-endians”.

As you can see, there’s a sequence of small, tiny details that set a standard:

1. People with some experience had probably already an experience in text terminals, where to move the page down you had to move the cursor up to the edge of the page, and then up again.
2. When the mouse appeared, we had no scroll wheel. So you had to move the mouse up, and click to reveal the content above.
3. At the same time the scrollbar was introduced, and inside it has a cursor moving up and down… in the opposite direction of the page, but in the same direction of the arrows at its edges. The message is then clear, and very consistent: the arrow moves the cursor of the scrollbar it belongs to.
4. This means that when you use a computer, your attention focuses quickly on the scrollbar: you aren’t moving the content, you are moving the scrollbar cursor.
5. This is why I noticed at times people at their first attempt scrolling in the opposite direction: they tried to move the content, not the scrollbar. Without a previously existing habit and with the mouse wheel disconnecting your attention from the scrollbar since you don’t have anymore to click it, the expectation was all about content.

This sequence of small changes: cursor, button, scrollbar, mouse wheel explains quite well the reasons and the consequences of the HCI choices we did in the early age of computers.

So, while I don’t know why exactly Apple decided to revert the behaviour, it becomes to me obvious that once you take the decision to remove the scrollbar, you lose the only remaining reason why you should scroll in that direction.

However, it’s not so easy.

Millions of people have already the habit of scrolling in the other direction, and it’s frustrating having it reversed. While it’s easier on the trackpad, on the mouse it’s a little harder. Habit is one of the strongest obstacle and one of the first things that anyone designing or building anything needs to acknowledge and address in some way.

So we have a solution that with modern computers works better, but it’s completely against our habit. If you are willing to experiment yourself, I can tell you that it took 3 days of daily usage to exit from the “frustration zone” and about 7 days to be comfortable with the new scrolling. It’s not much, but I guess that most people will prefer to switch the scrolling flag off (System Preferences -> Trackpad -> Scroll & Zoom -> Scroll direction) than change an habit for no real reason.

And about someone you know that almost never used a computer before and maybe has a smartphone… well, probably it’s better to keep the default scrolling direction.
It’s more natural. :)

I started thinking about how to organize my Google+ Circles very early, around 9 years old. It was the first page of my first try to keep a diary, and I thought it would have been nice to represent all the people I knew in a nice graph (you can say that I was pretty much destined to be a designer). I did a first sketch, but the connections weren’t right. Then a second. A third. Yes, I was very close to Tommaso, but actually my relation with Gianmaria was more rare, but stronger. A fourth sketch. And what about… A fifth sketch. Well, there was no way. Any criteria I tried failed to be accurate, and being a perfectionist without enough experience to handle failures I got frustrated quite a lot. I gave up… and with that I failed the first time to keep a diary, but that’s another story. While I never tried again to represent my relations with people, I kept thinking about these failures a lot, and years later I understood that this is actually a very hard task that is usually solved by simplifying it drastically, like for example counting the degrees of distance.

With the release of Google+ I wanted to use its hype to understand a little bit better how people were using Circles and try to help others to understand that too. So I started a small survey, that got a quite big response, with 176 people completing out the survey and more than half of them helping also to spread it.

The data is interesting in my opinion, so before entering in a few interesting details, here’s the now traditional graphic, feel free to share it:

Let’s see some details about the results:

1. Feature:
   As you can see it’s quite clear that the media perception was right: Circles are definitely the most important and interesting feature of Google+, followed in large distance by the Stream and Hangouts. Every other feature is almost irrelevant, even if they got quite a prominent space on the platform. It’s particularly interesting the position of Photos, that received absolutely zero votes, even if I can guess most of the users are fine in having them incorporated in the Stream itself.
2. Usage type:
   These categories aren’t mutually exclusive, so there is of course some overlap between Talker and Broadcaster, or between Talker and Commenter. However I wanted to make this distinction because I noticed that there are some users that have a more specific usage. For example  Explorers preferred that choice over the combined Talker & Listener, and It’s going to be interesting to see if that number goes up or down if I make a similar survey in the future. However it’s relevant to see that even if existing, there are very few pure Broadcasters, a number overtaken by the pure Commenters. It’s also interesting the difference in choice between Talker and Broadcaster, a subtle detail I used to check if the platform was more perceived as a social tool (Facebook) or as a communication tool (Twitter).
3. Are Circle working? Are you going to use it in the future?
   These two questions are of course different, but are also slightly correlated. For example it’s interesting to notice that there is a minority of people (2%) that while says that circles are working for them, then they aren’t fully convinced they are going to use it in the future. It’s also relevant to see that while the current satisfaction is high is still less then half (44%) and at the same time most of the people, even the ones for which it’s not working at all, have bright expectations from the future, with just a slight minority (3%) thinking it’s hype.

Many people know me an “the man who makes useless machines” and even now I sometimes get requests for those objects, which I invented and built around 1933. In those days, the Italian nineteenth century reigned, with all its solemn maestri, all its art journals that spoke of nothing but lapidary artistic displays, and I, with my useless machines, was a laughingstock. And what’s more, these objects were made from cardboard shapes painted in flat colors, and sometimes a ball of blown glass, the whole thing held together with fragile wooden sticks and silk thread. The structure had to be very light to be able to move with the air and the silk thread was perfect for dispersing the torsion.

But how my friends laughed, even those whom I respected most for the care that they put into their work. Almost everybody had one of my useless machines in their house, which they kept in their children’s rooms because it was considered a ridiculous and trifling things, while they kept the sculptures of Marino Marini and the paintings of Carrà and Sironi in the living room. Certainly, in comparison with a painting by Sironi, where you saw the lion’s claws, I with my cardboard and silk thread could not be taken seriously.

These friends of mine then discovered Alexander Calder who made “mobiles“, but out of metal painted black or in violent colors. Calder immediately conquered the scene and I passed for one of his imitators.

What difference was there between my useless machines and Calder’s mobiles? I think I should clear up this matter: apart from the fact that the material construction was different, the means of constructing the objects was also different. The only thing they have in common is that they are suspended objects that move. But there are many suspended objects and there always have been, apart from the fact that even my friend Calder had a precursor in Man Ray, who in 1920 constructed an object on the same principle.

— from Air Made Visible / Far vedere l’aria, Bruno Munari

I just discovered, thanks to today’s amazing Google Doodle dedicated to Calder, this very interesting book about Bruno Munari, one of the few translated in english. I now have to read it, since from what I see in the previews on the web it looks like very interesting with more than 400 illustrations.

This is just another good occasion to notice how three people in the same period worked on the very same idea at the same time, and also how different communication (maybe, triggered also from the material of the sculptures) triggered a very different perception of the objects: metal and vivid colors are sculptures, while cardboard and pastel colors are just a child toy.

If you are interested in Munari’s Useless Machines / Macchine Inutili, on MunArt you can find a great page about the them by Munari. It’s in italan, but with lots of illustrations.

Well, not entirely, and recently I found a good example.

The other day I stumbled on a nice article on Google+, this one:

I might be wrong (please point me to a good source if I am), but I don’t think that any designer in Google ever thought about this. But this nonetheless happened: Google+ (at least right now) is a good platform to publish comics.

Why things like this happen? Because design doesn’t exist in vacuum, but it has to confront daily with the users, and the users, both as individuals and as a group, are complex systems.

So, when you design something you can always predict the end result to a certain extent, and that’s exactly why testing is so important. So important in fact that you shouldn’t design without testing, it’s inherent in it, being that web design, industrial design or else.

This time, the platform turned out to be also very well suited to create online comics, a kind of “discovery” that was found by the users and emerged naturally from an interaction model that was born to support other uses. Things like this happen more often than thought, another recent example was the Facebook profile page pictures hijacking, and not always are good things.

Of course, this specific case might be just an enthusiast user and not a widespread understanding, however, it’s exactly the right kind of weak signals that can be correctly read and acted upon.

The important thing here isn’t to predict these emerging features, but to see that and encourage or discourage them through an iterative design process.