Why has Microsoft's Metro design language captured the essence of modern interface design? 5 key elements.

What is Metro?
Metro is a typography-based design language. Metro style is guiding a new unified experience on Windows 8, Xbox, Windows phone 7, and can even be experience on Windows 7 in the form of Zune, and Windows Live. A design language, such as Metro, is used to guide the architecture of a group of products by capturing the principles and elements of a design approach into a single concise set. Metro gets its name from way finding systems found in metropolitan areas such as airports, subways, and urban areas. Metro gets its inspiration from modern design (reductionism), Swiss design (clear, honest, and beautiful), and motion design (the force of time—the way we experience the world).

In my view, great interface design gets out of the way and Metro gets out of the way by focusing on the content. Metro has captured the essence of modern interface design based on five key elements. 

The 5 key elements

1. Typography
Metro is founded upon clean beautiful typography.
Proper color, weight, and size can help eliminate all of the chrome, color, and graphically over manipulated design elements. Even hierarchy can be easily and cleanly shown with just typography. It is not just about typography, it is about the content.

2. Authentically Digital (Inversion of Focus)
With Metro, the user is not focused on the chrome elements such as menus, buttons, panels, and color images with in the chrome that are shaded, the user is focused on the content.

With Metro, there has been an inversion of focus. Great interfaces get out of the way.

Metro is not just about typography, it is about content. By removing all chrome, it helps put the focus on the content whether it is text, images, or video.

With a modern interface, we do not need chrome to indicate what can be pressed or manipulated. Now, the content can be manipulated. After 40 years of WIMP based interfaces, we all know how to use a computer.

3. Spacing with thoughtful reduction
Spacing is important—and made possible with the removal of all of the chrome and over-manipulated design elements. Even if there is room for another button or feature, it certainly does not mean that you should add it. In fact the opposite, you should challenge every element. It takes focus. From a visual design perspective, no longer do we need chrome on top of chrome nested in chrome.

4. Motion (fast and fluid)
Motion, used properly, can create a fun fluid interface. It brings the experience to life. In my view, motion is more important than graphic design. Metro uses animation in the right places and for the right reasons:

     Delight the user
     Simplify the task
     Hint towards interaction
     Provide a feeling of moving forward
     Respond to user behavior
     Teach the user how to interact

5. Asynchrony and intelligence
It is easy to overlook the importance of this element just as Steve Jobs admittedly missed object-oriented programming when he visited Xerox Parc where he became inspired to produce the Mac. It is easy to miss Async Programming in the same way.

Asynchrony helps make an experience fluid.

Closing
Originally developed by Xerox over 40 years ago, the traditional desktop metaphor is a bit tired at least from a design and metaphor perspective. In addition, analog design elements and metaphors are not what digital design needs today. We know that live elements can be tapped or swiped. We do not need 10 pixels of shading and blasted with color inside of a box that is further shaded wrapped in a panel with indentation—you get the idea.

There is a design revolution at Microsoft. In my view, Microsoft is leading Apple at interface design—I know sounds like heresy. Metro and Windows 8 are not perfect, but the direction is game changing. It is easy and safe to jump on the Apple design bandwagon because mostly their designs are great. But I am not afraid to point out that Apple is not the only company that is doing great design and appreciates great designers. Now, it seems that almost every company cares about great design. Design matters.

In my view, the Metro design language has captured the essence of modern interface design. Metro is modern and clean—fierce reductionism, simple, and fluid. 

Enjoy the pursuit. 

5 Reasons to use the "Feature" pattern in your product

A design pattern is a formal way of documenting a solution to a design problem.

The "Feature" design pattern is a simple yet powerful mechanism that enables you to rollout features based on configuration settings. It provides the ability to turn these high-level features "on" or "off" by changing the configuration parameter values. The basic idea: use a simple mechanism to control the features that are presented to the end user.

5 Reasons to use the "Feature" pattern in your product

1. Reduces the need to branch: The longer your branch remains unmerged, the greater chance that it will never make it. By being able to not turn the feature "on" until ready in production, but continue to work in the main or trunk branch is valuable.

2. Partial rollbacks (isolated): A single new feature will not hold up a production deployment, it can be turned "off" until ready. It keeps progress moving and a feature rollout does not have to necessarily coincide with a code rollout.

3. Different features for different folks: Will make it easier to turn a feature "on" for testing in a particular environment, but "off" for your production environment. It can also help with partial user and A/B testing.

4. Helps reduce risk: With the ability to turn features "off" until ready, it can allow you to increase development velocity without necessarily increasing risk.

5. Used by #winners: Facebook, Amazon, and many others. Today, Facebook has many new features that are not yet turned on yet but deployed to their production environment. Although not an intended reason, Facebook has even turned on features in production to react to new features from Google+. Features ready to be turned "on."

My hope: the "Feature" pattern will help you for the same reasons.

For more details about the Feature pattern, see the somewhat terse pattern description below along with the source code. There is not much to this simple yet powerful pattern.


Pattern Name: Feature

Intent
Provide a simple yet powerful way to turn features "on" and "off" via configuration. This enables certain environments to have certain features turned "on."

Also Known As

Motivation (Forces)
Demand for high development velocity and the need to mitigate risk.

Applicability
Web apps, freemium business models, mobile apps, services, etc.

Structure
The pattern structure is simple and consists of the Feature class. 

Participants
Feature: Represents a Feature that can be turned on or off based on an app setting. You can take an action if it is on, off, or both.

Collaboration
Here is an example code fragment that interacts with Feature:

           Feature.BasedOn("Product.Feature.IsOn")

                .IfOn(() =>

                {

                    // do the feature

                })

                .IfOff(() =>

                {

                    // do the alternative or not

                });

If the the configuration parameter "Product.Feature.IsOn" is set to "true," then the IfOn action will be invoked; otherwise, the IfOff action will be invoked.

Consequences
Be sure to get granularity right.  Be wary of adding features at too fine of detail. Complex feature interaction can also complicate testing. Although a more general discussion, make sure that each feature is justified. However, even in a design world driven by YAGNI and KISS principles, you still need some flexibility—just make sure that it is justified.

Implementation
Here is a simple implementation of the Feature pattern in C# below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Configuration;

namespace Product.Support
{
    /// <summary>
    /// Represents a Feature that can be turned on or off
    /// based on an app setting. You can take an action if it is 
    /// on, off, or both.
    /// </summary>
    public class Feature
    {
        /// <summary>
        /// Based on this app setting. 
        /// </summary>
        public string AppSettingKey { get; set; }

        /// <summary>
        /// Create a feature based on the given setting.
        /// </summary>
        /// <param name="appSettingKey">The app setting that determines whether the feature is turned on or off.</param>
        /// <returns>Newly created feature.</returns>
        public static Feature BasedOn(string appSettingKey)
        {
            if (string.IsNullOrEmpty(appSettingKey)) throw new Exception("setting key cannot be null or empty.");
            Feature feature = new Feature();
            feature.AppSettingKey = appSettingKey;
            return feature;
        }

        /// <summary>
        /// Whether the feature is turned on; that is, if the app setting
        /// has a value of true; otherwise, false.
        /// </summary>
        /// <returns>Whether the feature is on; that is, if the app setting
        /// has a value of true.</returns>
        public bool IsOn()
        {
            if (AppSettingKey == null) return false;
            string value = ConfigurationManager.AppSettings[AppSettingKey];
            return (value != null && value.ToLower() == "true");
        }

        /// <summary>
        /// Performs the given action if the feature is turned on.
        /// </summary>
        /// <param name="action">The action to take.</param>
        /// <returns>The feature</returns>
        public Feature IfOn(Action action)
        {
            if (IsOn())
                action.Invoke();
            return this;
        }

        /// <summary>
        /// Performs the given action if the feature is turned off.
        /// </summary>
        /// <param name="action">The action to take.</param>
        /// <returns>The feature</returns>
        public Feature IfOff(Action action)
        {
            if (!IsOn())
                action.Invoke();
            return this;
        }
    }
}

Sample Code
As sample code, here are some unit tests that interact with the Feature class:

using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Product.Support
{
    [TestClass]
    public class FeatureTests
    {
        [TestMethod]
        public void Feature_IsOff_Success()
        {
            // arrange
            bool isPass = false;

            // act
            Feature.BasedOn("Product.Feature.IsNotOn")
                .IfOn(() =>
                {
                    isPass = false;
                })
                .IfOff(() =>
                {
                    isPass = true;
                });

            // assert
            Assert.IsTrue(isPass);
        }

        [TestMethod]
        public void Feature_IsOn_Success()
        {
            // arrange
            bool isPass = false;

            // act
            Feature.BasedOn("Product.Feature.IsOn")
                .IfOn(() =>
                {
                    isPass = true;
                })
                .IfOff(() =>
                {
                    isPass = false;
                });

            // assert
            Assert.IsTrue(isPass);
        }
    }
}

Known Uses
Facebook, Amazon, and others.

Related Patterns
For a couple more previously unpublished patterns (Instrumentation and Service Protector), check out this article that I wrote for the Microsoft Developer Network last year, WCF Decision Framework:
http://gregcowin.blogspot.com/2011/08/why-use-decision-framework.html


Enjoy the pursuit of great design.

What geeks do during the holidays?

Just so you know: geeks have a bright inner spirit that is just hidden beneath a few layers of logic and critical thinking. Although not comforting to think about, geeks even require a bit of love.

In this spirit, here is my workstation.

Moreover, here is the other side sporting some Windows 8.

Happy Holidays! Do great work for people that you care about and it will lead to happiness. 

One last thing: don't forget to treat your geek right.

Why is the next major paradigm shift in software design about to happen?

What is the next major paradigm shift?
In my view, the next major paradigm shift in software development will be asynchronous (or async) programming and design. It is our next paradigm shift because it helps alleviate pressures and follows a surprising progression. Only when we change the way that we program, does it change the way we design. When we significantly change the way we design—a major paradigm shift occurs. This change has been brewing for over ten years, but only now is it about to happen.

What is async programming?
Async programming uses asynchronous method calls instead of synchronous calls especially for potentially long-running methods. The idea: you make an asynchronous call and then provide a mechanism to run code when the result returns. Async programming is necessary for responsive browser, mobile, and upcoming Metro style apps that are mono-threaded as well as for intensive multi-threaded server applications. When all components are async, it can be fluid, natural, and resilient.

Why is async design the next major paradigm shift?
The main reason is that it helps satisfy a strong and growing need: to make use of multi-core processors and to make mono-threaded user interfaces highly responsive. In-browser apps allow only one thread.  Async programming makes both possible. New mechanisms for async programming in upcoming .NET 5.0 make it much easier. Asynchrony dramatically affects design.

The shift also follows a surprising progression. Realize that for the past 50+ years, we have had stable high-level programming elements: data, functions, and threads; although combining them was a challenge.

Even though structured programming and design (SP/SD) techniques are still used today, before the mid 90's, it was the conventional or mainstream way to build applications. The problem: structured design treated data, functions, and threads as complete separate abstractions.

Today, object-oriented programming and design (OOP/OOD) techniques are the conventional way to build applications. Object-oriented programming and design combine data and functions into a single mechanism: the class or object.

Async Programming and Design (AP/AD) gives us a simple way to combine all three into a simple unified mechanism. An async object or agent consists mostly of asynchronous method calls. New mechanisms in async programming make it easy to combine data, functions, and threads.

These paradigm shifts (structured, object-oriented, and async) have gradually combined these high-level programming elements. Each paradigm shift has always started with changes to programming, and then to our designs. Only when it moves to design do we realize that a paradigm shift has occurred.

High-level programming elements in relation to paradigm shifts.

If this is truly the progression, then async programming will lead to async design. It might also hold true that async design is a natural evolution in computational thinking. Moreover, it provides an easy way to map to multi and mono-threaded applications and to avoid deadlock, latency issues, and race conditions.

Why is it about to happen?
It is about to happen because great mechanisms for Async Programming are about to become mainstream that will make it much easier. And once async programming becomes mainstream, then so will async design. Our designs are about to significantly change and a major paradigm shift will follow. This has been brewing for over ten years. Just as with structured design and object-oriented design, it took over ten years for it to evolve and become mainstream.

What are the implications?
Today, best of breed architectures consist of a directed-acyclic graph (DAG) of object-oriented components. Fully async objects or agents can help flatten this DAG of components reducing overall dependencies. Realize that most of today’s software architectures are probably not the best of breed.

Looking back, structured design led to some of the least desirable forms of cohesion and coupling. OOP/OOD led to much more desirable defined shapes of software. For me, the revelation at a time of uncertainty for the OOP/OOD paradigm shift was that it naturally led to more desirable forms of cohesion and coupling.

One of the key benefits of Async Design is that it leads to even better shape, and reduces overall dependencies. Flattening the DAG will be the required for ever-increasing architectural complexity. Great software design will, eventually, require software intelligence.

Asynchronous systems are radically different and will require new patterns, architectural viewpoints, mechanisms, and education. Unlike synchronous systems, asynchronous systems will not be halted like an assembly line due to a single point of failure or delay. Asynchronous systems will be even a truer reflection of the way a real company operates—like an organism—not an object-oriented an system.

A new category of software patterns will emerge. These new patterns will help us deal with more autonomy and system intelligence.

We will begin to design fully autonomous objects that consist primarily of async methods that leverage mono and multi-threaded environments.

Where can you go from here?
Change the way you program and it will change the way you design. Check out some of the resources below for more information on async programming for .NET.

You know you are close to crossing this chasm within your company or team when the last objection is performance. Unbelievably, functions were thought too costly for structured programming and dynamic binding was thought too costly for object-oriented programming. Once people overcome the performance objections of asynchronous methods, we will know that the industry is about to shift.

Soon, great designs that are fluid, intelligent, natural, and resilient will be async.

Whenever we go, make the most of it. If you do not enjoy programming and design, then you are probably doing something wrong.

Additional Resources
Async CTP (can be used with .NET 4.0)
Metro async/await 
.NET 5.0
C# Specification

Why should you read "Steve Jobs" by Walter Isaacson?

Read it, if you want to feel inspired, surprised, sad, confident, spiritual, or compelled to build something great. You will enjoy. Steve Jobs by Walter Isaacson is a great read especially for the 2011 holidays. The book is authentic, compelling, inspiring, informative, surprising, and even sad.  So sad, that you will likely cry.

While the book is over 600 pages, it was not enough. Steve's life was messy. He was petulant and took credit for many others work. Johnny Ives, one of Steve’s best friends, admitted that it hurt deeply when Jobs took credit for many of his designs. At times, he was unusually cruel and rude. Even though he could be a jerk, he deeply admired other great designers, spiritual leaders, and “A” players.

There are many surprises in the book such as he knew that his cancer had metastasized and would likely kill him. At times, he thought that diet and magical thinking could overcome it. He should have opted for surgery nine months earlier. Ironically, it put him in overdrive to produce the iPad. Steve was obsessed with the pursuit of great design.

I was surprised and oddly comforted that Steve was often unsure of his decisions, direction, designs, and leadership. Bad reviews would devastate him. He was human.

Walter Isaacson took an honest, authentic, and interesting look into Steve's life.

In typical Jobsonian manner, the last chapter is a "one more thing", that is mostly in the words of Steve Jobs instead of traditionally the Biographer. The words are from one of the last interviews that Isaacson did with Jobs.

Steve: you are one of the crazy ones. You definitely were able to quiet your lizard brain to consistently produce great designs.

Does video playback flicker on your new Windows 8 Samsung 700t1a tablet that you got at Build a few weeks ago?

Over the weekend, I got the following recommended update to Windows 8:

Intel Corporation driver for Intel® HD Graphics Family (Microsoft Corporation - WDDM 1.2) (Recommended) Windows Update

It started causing flicker during any video playback including backgrounds such as in the Weather app.  If you are having the same problem, there is an easy fix.

Rollback to the Intel Corporation driver for Intel® HD Graphics Family (Microsoft Corporation - WDDM 1.2) to 8/3/2011 v 9.16.10.2472

I used the Driver rollback feature but did not work remove the flicker even after reboot, so, I loaded the driver from the USB drive that was given to us at build. It fixed this issue.

Hope this helps some of the attendees from Build. It was the best conference ever.

What is the key to developing great mobile apps?

The key is focus. You must find the essence of the product. You must deliver the key features needed—not all of them—just the essential ones. It requires focus because that is what people want and expect. People want the NUI (Natural User Interface) experience to be better, simpler, and to satisfy their goals in a simple natural way. Just because there is room for another link, gadget, button, or ad, does not mean you should add it. The friction that is created, conceptual weight, and maintenance usually don't justify it. It is just a different way of thinking. Simple, minimal, and beautiful—the attributes all apps should have. By focusing on what is important, you could even change your whole company. Focus leads to great design.