Metro UX Design Guidelines. This class gave somewhat less technical perspective on all things Metro. According to the new religion, full screen is actually good for you. Show content, not decoration. Celebrate typography. Be responsive and fluid (whatever that means; well, if you want to be ‘immersive’, fluid kinda follows, it would be too cruel to immerse the user in a solid). Use active “tiles” (a.k.a. “charms”) instead of static icons. Embrace touch-screen gestures. Rethink your UI – while you technically can copy your XAML from Silverlight or WPF, you shouldn’t, as the UI paradigm is different now.

Use simple apps that do one thing well (sounds familiar eh? I wish they found a holy grail and came up with graphical equivalent of UNIX pipes, but alas). E.g. there is no Outlook Metro, there are three different (albeit somehow connected) apps for mail, contacts, and calendar instead.

BTW, contrary to popular belief context menus are allowed in Metro (so that myself), and there is even a gesture for them, but the presenter did not remember what it was 🙂

Again, we got a not-so-subtle push to publish cool apps to Windows Store. Also, this was the only demo so far that used VB.NET. All others used either C# or JavaScript.

I am starting to think Metro platform would not be to bad if it were positioned as a stand-alone mobile OS. It would be even better if metro apps could be run in a window on the desktop environment. In fact, Visual Studio has this capability: they shy away from calling it an emulator, saying it uses a combination of RDP and something, etc. etc. So, there is a technical ability to run multiple Metro apps in regular, not full-sceren windows. Instead, for whatever reason we, the desktop users are led into a medieval darkness of Windows 1.0 where windows could not overlap, and they are trying to tell us this is for our own good.