There is more to Metro than sharp edges and clean typography. Metro is a design language based on real design concepts, principles, and theory. Most of the documentation on the internet is explaining “what” Metro is – they are specifications. But there is very little on the “why”.
In a recent discussion with a colleague, we were discussing this. He started from a design point-of-view, understanding Metro’s core intents. I was trying to explain why engineers (like Microsoft developers) don’t necessarily understand why Metro is advantageous.
I suggested this
The following mock dialog is to a user group, a conference of developers, a classroom of students, a CTO. Whoever it is, they are considering Metro. Whoever it is, they need to be sold. I say:
“Let’s start with Affordance.
“Affordance is an important software design concept. It measures how much something digital (like a button) resembles its physical counterpart. When an onscreen button looks like a real, physical button its Affordance as high.
“Affordance is good. It allows users to understand what to do. What is its “intent”? It’s a button, you push it. We refer to this as immediate usability.
“But, Affordance is also bad. Research shows (and so does experience) that high Affordance causes users to tire of an interface. In other words, Affordance is quickly “out dated”.
“Office and Windows are great examples. They both have traditionally had high Affordance. Older versions of Office and Windows look outdated.
“With every new version, controls and gradients and icons had to change for us to feel like it was an upgrade. After our minds approved the UI, we turned our attention to features.
“Metro has very, very low Affordance.
“This is good. It means Metro applications inherently have longer shelf-life. They maintain a modern look long after being published – simply because they have lower Affordance.
“But what about immediate usability? Does a Metro square really say “this is a button”? It does not. But, does that matter? No – and here’s why:
“In one instant, a user can be instructed what that square is. Then, they know. Affordance’s benefit is erased in an instant. And, Affordance’s detriment is never introduced.
“As Metro becomes ubiquitous on Windows, it will gain more and more immediate usability without suffering from Affordance. The ecosystem is enabled by Windows’ consistency.
“Affordance is important. Metro avoids it in favor of a truly “digital” user interface. Sure, Affordance has its edge cases. But, Metro’s “digital” guidance is future-focused.
“Metro teaches developers how to make long-lasting, modern, every-day software. That is revolutionary. And, Affordance is just a part of Metro…
Affordance is a lie
Here’s a drop more on Affordance. Specifically, why the lack of Affordance has only an initial problem in usability and discoverability. In the scope of software as an industry, these issues are moot as new interface conventions are standardized consistently across systems.
In the image above: There is automatic usability in the left image. It has high affordance. By the way, the right image is also a panic button. Did you guess? Now that I have told you – do you still need the gloss? Affordance is when you don’t know. But once you know, Affordance is baggage.
Old MSDN recommends affordance
To be fair, this guidance tracks back to Visual Studio 6.0. Remember InterDev? I used to love InterDev – but, as you will recall, this was before .Net was invented. Let’s look back in time:
MSDN: A user interface also makes use of affordances. For instances, the three-dimensional effects used on command buttons make them look like they are meant to be pushed. If you were to design a command button with a flat border, you would lose this affordance and it wouldn't be clear to the user that it is a command button. There are cases where flat buttons might be appropriate, such as games or multimedia applications; this is okay as long as you remain consistent throughout your application.
New MSDN doesn’t recommend affordance
This guidance
MSDN: While lack of affordance and discoverability may sound discouraging, note that drop-down menus and context menus—other mechanisms for initiating actions—suffer similar problems. For a given object, users may search through the menu bar to discover relevant commands or try to right click to find a context menu. Also, there is nothing about the visual appearance of a menu that suggests how it is used—that knowledge is also learned though experience. However, individual menus items don't require affordance to suggest their use because a menu as a whole suggests its usage. Consequently, users understand what to do with a menu of relevant commands once discovered.
My monologue
It seems to me that this helps explain the logic behind Metro – not its specification. For example, consider this link. It has considerable resources for developers to build applications that comply with the Metro guidelines. But doesn’t really “sell” Metro.
You might say “the aesthetic of Metro sells itself” and I would say that is insufficient. It is not wrong. But, it is not enough to change our industry and change our hearts.
To me it is hard to get behind something and support it with all my heart without first understanding that it is good. I understand Metro is good. But until we communicate its value (not its implementation) to our developers, it seems there are fewer hearts-and-minds besides us.
Question
Are we (Microsoft) sufficiently explaining Metro to our developers?