You must have heard about it. Windows 8 will all about Metro. Sure, you can run ‘old-school’ applications on the platform, but most attention these days is about the new user interface. The UI is based on the design language Metro, a design philosophy we first saw in Windows Phone. Nowadays you see more and more of Metro. The Microsoft website is loosely based on it, the Zune mediaplayer uses it and so on. So it wasn’t a surprise to see that Windows 8 is all about Metro.
In this screenshot you see the Start Screen of the Developer Preview of Windows 8 that was handed out at the Build conference in September 2011. Now, I cannot stress enough the importance of the term ‘Developer Preview’. It’s a preview. It’s not even an alpha version, so we’re miles away from the first (public) beta of Windows 8. Even the name Windows 8 isn’t official yet; although everybody expects that that will be the name. Since it’s a preview version of the new OS we can expect changes in the system. Still, this version gives me a rather good idea of where Microsoft is going with the interface.
Now, I am not going to talk about the disadvantages of the ‘two-shell’ system (you can switch between Metro apps and Classic apps). There is a lot of debate on the internet about this and I think we will have to wait and see how things work out in the future when the next version comes out. No, instead I want to talk about the merits of Metro itself.
Touch is a first-class citizen in Windows 7. This means you can write applications for that OS that will work when used with your fingers instead of a mouse and a keyboard. That being said, there were almost no applications that took advantage of that functionality. And let’s be honest: standard applications aren’t meant to be used by touch. Standard controls do not work well with fingers. Let’s take a RadioButton for example. They are represented on the screen by tiny circles. Circles, that are actually too small to be used by your finger; the changes are you will be touching other controls. Usually the controls on a standard application are placed quite close to each other. This isn’t an issue when you use a mouse: with a mouse you have almost pixel perfect control. Fingers on the other hand are quite big and clumsy, so you have to make a special user interface when you develop touch based applications. Something that isn’t done right now, 99% of the applications out there aren’t oriented towards touch.
Now, placement and sizing of controls is one thing, the behavior of the controls is another. Let’s take a look at a button. A button can be made bigger, so the issue of it being to small is easily circumvented. Now, image you have a screen in front of you with a big shiny button on it, one that beckons to be touched. So you put your finger on it. This of course generates an event, something like TouchDown (which is the same as the MouseDown). Actually, the button is so big and shiny, you can’t resist putting a second finger next to the first one. So we’ll get another TouchDown event in our application. Now, the first finger is removed.
Think about that for a while.
What does that mean? If we were to use a mouse-based application, the MouseUp event would trigger a MouseClick event. So removing the first finger is the same as generating a MouseClick and you have to take some action. However, in the real world things work different. If I see a piece of machinery with a big button on it, doing what I just described would mean nothing: there is no Click until ALL touches are removed. Our standard WPF buttons do not work like that, we need to have a special kind of button for this. Unfortunately, the buttons in the current version of Windows 8 don´t support this (in contrast: the Surface SDK which you also can use to write Touch enabled applications for Windows 7 and 8 DOES do this correctly).
There are some other challenges. Think drag and drop. Once you start a drag operation in a mouse based system you’ll always know what to do when there is a Drop event. After all, you only have one mouse so there can be only one source that initiated the Drag and Drop. With multi-touch, things aren’t so clear: you have to make a distinction between the different sources. Again, the Surface SDK solves this, in WinRT things need some more work.
That being said, Metro applications should be designed to be used by Touch. Touch enabled hardware gets cheaper everyday. The whole tablet market is getting a lot of attention from end users (iPad anyone?) and people want that same kind of ease of use from their next Windows system. And tablets aren’t meant to be used with mice and keyboards…
Metro Design Principles
I want to make something clear. ‘Metro’ is a name for a design language. It’s a philosophy. A lot of people, including myself, make the mistake of calling the UI Metro. Although this is incorrect I will do the same, but in this piece I want to use Metro in the way it was meant to be. It’s a design language.
Now, be warned: I am a developer. I am not a designer. Still, working with Surface in the last couple of years have made me aware of how people respond to certain user interfaces. Next to that, I have been giving a lot of talks about this subject and talked to a lot of people who are designers about Metro so I have been able to make a coherent picture around Metro.
Let’s go through the principles, what they mean and what I make of it.
Clean, light and open
- Feels fast and responsive
- Focus on primary tasks
- Do a lot with very little
- Fierce reduction of unnecessary elements
- Delightful use of whitespace
- Full bleed canvas
Now, what does this mean? This is rather hard to explain, it’s best that you see it in action. However, the focus is on the task at hand. The screen should be focused on that task and not on other things. If you look at the Windows 8 screenshot you see tiles of the tasks that are available. And that’s it. There’s no clock, no menu bar, no Start Button. It’s focused on the task at hand. Take a look at the next screenshot. This is the new control panel. Once you open it you see the different categories of items you can change. And that’s all you see. Once again, it’s full screen and nothing else besides what you need to see is there. And when it comes to ‘delightful use of whitespace’, well, there’s enough of that as well!
- Type is beautiful, not just legible
- Clear, straightforward information design
- Uncompromising sensitivity to weight, balance and scale
Fonts is more than just a nice looking character on your screen. Fonts convey a message. They can get attention to parts that you want to call out. We have to be careful not to overdo it of course but using more than one font in your application can really make it stand out. You just have to make sure they are the right fonts but Microsoft has some very nice ones that fit with the Metro philosophy, i.e. Segoe.
Alive in motion
- Feels responsive and alive
- Creates a system
- Gives context to improve usability
- Transition between UI is as important as the design of the UI
- Adds dimension and depth
Screens aren’t static. Neither is the transition from one screen to another. When you move from one screen to another, consider doing this in a very short and fluent animation. Nothing should just appear or disappear. Give your users the feel that everything they get to use comes from somewhere instead of appearing out of thin air. This way you create context, and that will make the user feel at home in the next part of the system.
Content, not chrome
- Delight through content instead of decoration
- Reduce visuals that are not content
- Content is the UI
- Direct interaction with the content
It’s about the content. That’s basically it. The content is what it is all about. I can’t make it any clearer than that. Don’t clutter your userinterface with items that aren’t needed and actually distract your users. The eyes of the user are automatically drawn towards items that stand out on the screen; that item should be something they need to use instead of some nice picture of your dog.
- Design for the form factor
- Don’t try to be what it’s not
- Be direct
Well. This is a no-brainer. Don’t design a full screen application with a lot of buttons for a Windows Phone application. And of course: when you know you have more screen resolution, use it (wisely! don’t forget the whitespace!). Don’t try to be what it’s not. A phone application is usually simpler in appearance than a PC based application. Be honest about this and be direct.
These are the official items from the language guide. Of course, what you make of it is up to you: there isn’t a rulebook that says you SHOULD do this, or SHOULD NOT do that. They are guidelines, principles that should be in your head all the time when you design your application. But they don’t tell you that a Button should always be at least 124 pixels wide, for instance. Nor do they tell you that you cannot use an icon on a button. They do suggest that you minimize the use of icons (content, not chrome).
Let’s face it: chances are you are a developer just like me. And developers usually don’t care that much about user interfaces. After all, we take pride in writing great algorithms, right? But we do spend a lot of time on our software and it would be nice if people who use it love it as much as we do. Let’s be honest: it’s a great compliment when a users says you’ve made their live a little bit better. And they best way to do that is to present them with an application they not only CAN use but LOVE to use! The guidelines help you reach that goal. If you follow these guidelines chances are that you are making a very attractive user interface that will appeal to the user.
Next time I’ll show you how to achieve this and you’ll be surprised how easy it is to make typical developers kind of interface into something you actually might use yourself.