How not to do Metro, a lesson by Microsoft
12 October, 2011Yes, I'm perfectly aware that this post will make me sound like a nitpicking, arrogant, party-pooper.
Why is it so important that metro examples from Microsoft be polished? The All-In-One Code Framework may not be treated as "best practices", but it's at least treated as "pretty good practices" with the code samples. Likewise, the UI presenting these examples will eventually be released and non-developers may use that as a basis for their apps.
I am not an authority on metro design, but just because this example comes from Microsoft, it should not be treated as correct.
After BUILD, Metro is certainly the flavour of the moment in Windows UI/X design, and why shouldn't it be? As I said earlier this year, "if ever there was a time for Microsoft to standardise their many differing UI, it is now - or with the upcoming Windows 8". That is why when you do a metro UI poorly with all the current press, resources (such as Microsoft's own Cosmopolitan theme, DeviantArt, WP7 controls or even MahApps.Metro) and instructions (BUILD/other conferences), you're going to cop a bit of flak. Doubly so if you're within Microsoft committing such UI crimes.
Todays lesson in how not to do Metro UI's, comes directly from Microsoft's MSDN Community Team in their new version of the All-In-One Code Framework.
While we can ignore the gaudy gradient liberally applied to the start screen (at least for now), the real shame is how that team decided to ignore all the existing metro materials that Microsoft have released in one XAML form or another (such as the huge Cosmopolitan pack which MahApps.Metro is based on) and recreated the resources themselves. The irony that the UI of an all-in-one code framework that stops you from having to reinvent the wheel with your code, recreates/reinvents all the design resources, shouldn't be lost.
From small screenshots, it probably is hard to see what the specific issues are so I'll break it down a bit further.
Aero Chrome
If you look at the premier metro app (Zune), it has no Aero frame (ie, chrome). If you look at all the Windows 8 examples, it's all about the lack of chrome and all about the content. That can be added to WPF windows with a behaviour which requires just 3 lines of XAML.
<i:Interaction.Behaviors>
<behaviours:BorderlessWindowBehavior ResizeWithGrip="False" />
</i:Interaction.Behaviors>
This isn't the only way to do it, but one of the more preferable because it uses standard Windows API calls to create the dropshadow and allows full Aero-snap.
Buttons
TextButtons
Microsoft have probably been a little unclear on how buttons should be handled in metro, but the AIO browser misses the mark on all of them. The AIO browser hasn't restyled any of the standard "text buttons", and those stick out like a sore thumb.
Now, while it is clear that there can be a few interpretations of how "text buttons" should be handled, but of those styled only the Zune button is close to the "glass" button of Aero, and even then it is a soft, smooth gradient.
ImageButtons
Text buttons aren't the only type in metro - image buttons are common, featuring flat, simple icons surrounded by a thin circle. While the icons are simple and clear, there are a few "guidelines" worth observing for the overall button:
- make the button large enough that you can tell what each icon represents
- make the circle even larger so there is sufficient white space so no icon is cramped
- circle thickness is directly proportional to the size of circle, a good guidelines is thickness should be approximately 1/16th the diameter of the circle
- while hovering, the circle surrounding the icon should at full opacity, and when not hovered at ~75% opacity
Creating a clear, scalable, flat icon can be difficult, particularly for non-designers like me. So I don't create any of my icons - I use resources like The Noun Project or Some Random Dude's Iconic set which are free for personal and commercial use, and all vectors. Want to use SVG inside your XAML project? Use SVG2XAML to convert it.
For smaller buttons, I tend to use an icon of about 16-20px squared inside a circle at least twice that size (so 35-45px wide), which is a great balance between visibility and space used. The "twice the size" rule doesn't scale entirely, if you've got a large navigation button it could be a 40px icon (such as an arrow) in a 60px circle, but with 20px padding there is no concern of having a cramped button.
AIO Browser on the other hand, uses a 16px circle, with a 2px thick border, and the icon almost touches the circle. The button grows by 1px on hover (instead of opacity changing) causing the layout to shift down/across by 1px. No button, metro or not, should ever be a moving target!
So what happens when you need an icon a certain size to make it visible? You either enlarge the circle or get rid of it entirely.
More buttons?
While there other buttons to consider (min/max/close, settings, etc) most of them are fairly spot on, however the button in the "miscellaneous category" that stands out as incorrect is the "remove" button for each item in the search history. In AIO Browser, they're achieved by using the letter X in a textblock, which hasn't created a vertically centered button. Argh!
Text
Nearly every metro example is based on Segoe UI - (such as Segoe WP - the WP7 version, or Zegoe - the Zune version), the weight of the font is important based on the size and use of the text. Segoe and its derivatives have Regular, Semi Bold, Bold and Light. Generally the Light weight should be used sparingly and on larger text as it can be hard to read if not treated with respect.
Unfortunately, the AIO Browser doesn't 'respect' the limitations of the font/weight - the left side is Light, the right Regular/Normal.
Window Movement
In traditional OS chrome, be it Gnome, KDE, Aero, Luna or Aqua, the title bar is visually separated from the rest of the window indicating where you can grab it to move it around. While training over the years means we all aim for where the title bar would be, that's a poor way to handle it. That bright red rectangle on the left hand side which is also present in Zune is a visual cue for where to drag. Well, in the Zune software you can drag it, but not in the AIO Browser.
Images
This isn't even a "metro" UI flaw, as any UI language suffers just as much from this - low quality bitmaps. WPF will render any alpha transparency just fine, or better yet you can use a vector resource to create a truly scalable icon. Thanks to Snoop, I can confirm that AIO Browser uses PNGs that seem hastily copied from elsewhere, maintaining artifacts/aliasing evident on the "fullstar.png" icons.
Other issues
This is all tip-of-the-iceberg type stuff - there are more controls that aren't styled, icons that aren't flat (nor match the rest used in the app), animations trying to mimic WP7 incorrectly, and so on. It just isn't consistent with its own metro implementation, and the parts that haven't been styled at all stick out ruining the overall design of the app.
Should the source code for the AIO Browser be released, I'd be happy to undertake an attempt at getting a more consistent, easier to read and easier to use version of the shell.