Metro Design Anti-Patterns

Metro app development is young compared to other environments.

It is not a browser app.
It is not a Windows desktop app.
It is not an iPhone or Android app.

Although it isn't one of those well-known environments, it is built on two solid presentation layers. XAML from Silverlight fame and HTML+CSS+Javascript from well, everything-that-is-useful-on-the-Internet fame.

The technology space underlying Metro is not hard to adopt. It's the world from a Silverlight or web perspective with design constraints.

I have reviewed around 30 Metro apps in the last month and I keep hitting the same learning hurdles from the early adopting developers.

To start, developers that are early adopters are quite fearless. They march in, sometimes as canon fodder and sometimes as knights leading a rush. With this comes an exaggeration of all the things that could happen. An amplification of the mistakes and an enlightenment of the amazing successes.

Here are the patterns that I have seen so far in Metro application development and what you should think about when you build apps in this brave new world. This also applies to mobile devices in general.

Obey the Rules

Stay within the bounds of your framework and design constraints. If you have to exert enormous amounts of effort to achieve something that you think should be available then you might be doing it wrong. The guide lines are there to ease your progression, not counter it.

Some developers have a tendency to solve the same problem with every solution. They change languages but still write code that looks like their default language. They construct interfaces (programmatic of visual) that satisfied a past problem domain but don't satisfy the current one.

If you are going to change then change. If you don't want to leave what you know then stay with it. Concepts and constructs can be taken with you. Concrete implementations can not.

Metro is a new presentation layer but its strong guidelines are walls that don't entrap you but instead hold you up.

Don't Isolate Yourself

In a world where there is one dominant thing on their screen, users do not want to be locked in to that one thing. A feeling of isolation within an application is a major reason that users dump your app.

Often a screen shot is the only way to share out information from a mobile based app and there is often no real way to bring data in to the application.

Metro has the idea of Share Contracts. You can implements different interfaces quite simply that let others treat your app as a Share Target that can pull data in to your app or as a Share Source that lets you push data out of your app.

You can provide a multitasking operating system but without enabling easy sharing, you might as well promote isolation.

Move in one direction

Working with phone apps really restricts the dimensions in which you let your users scroll. Often returning to the larger real estate of a tablet makes people lazy or 'laxed or carefree because they forget the rules of touch and fall in to their old desktop ways.

Think about how you use a touch screen or watch a child and you will observe flick motions and movement in one dimension. Introduce another dimension and watch the confusion.

Google considers a link unvisited if you follow it and then click the back button and then click the next search result. Navigation is bad if a user moves in a direction and then moves back quickly because they didn't mean it.

Consider all of this when you build mobile apps.

Metro won't stop you from using multi-dimensional scrolling but the design principals discourage it.

If content is your primary navigation mechanism then don't distract from your content and purpose with confusion due to scrolling.



Let the guidance guide you.