<%@ Page Title="" Language="C#" MasterPageFile="~/SiteMasterPage.master" AutoEventWireup="true" CodeFile="PDC2011Day3.aspx.cs" Inherits="_2011_PDC2011Day3" %>

Day 3 - Let's talk about Windows 8

Technical content of this issue - 4 out of 5

Today I focused on Windows 8 sessions, as you will see when you watch below. I should give a shout out to Pete Brown who pointed out on his web site that if you watch the video online the player has an option to play it at 1.4x speed, which allows you to see more videos in less time. Of course the session then sounds a little like an Aaron Sorkin script on speed. Pete has published his list of "Must See Videos" from the conference on his web site.

Designing Metro style: principles and personality

This session was led by a designer representing the Microsoft Design department. Ya know, these guys just don't think like developers. It was very interesting, but some of the ideas he was discussing I could see when he pointed them out, I could never come up with a way to implement myself. Perhaps his best advice to me was work with a designer. I enjoyed the talk and certainly see its value, but it's also so vulnerable to mockery - I'll try to control myself...

Rather than diving right into the rules for a Metro style app, he began by giving some background and inspiration for Metro style Design. Metro design style is a new language or aesthetic really made popular with the Windows Phone release (I assume he is defining popular as 2% market share...). With the Windows 8 release they're "taking it to the next level." He began by giving the three key influences on Metro style (warning - this is the part that sounds like an undergraduate art class)-

So how do these concepts translate to actual Metro style Design Principles? One key thing to know is that there is not a giant book of design rules that very few people will read, rather design is "enforced" by having a framework for how to think about some things that everyone shares. Then you have the freedom to make your own decisions, but the net result of 1000s of independent and disparate decisions is something cohesive and harmonious. This framework is defined by 5 principles.

Principle #1 - Pride in Craftsmanship

He described this with the following list-

He expounded a little more about the grid, stressing that Tthe entire surface is envisioned as a grid. There are expected constant areas, but within areas you're given great latitude to display as you wish, but stay a grid. This consistency and clarity goes back to Swiss Design - we're busy, hurried, we need our info quickly.

Principle #2 - Be fast and fluid

What's this mean? Here's what he said-

Whether I or a run of the mill developer would be able to create something that met these guidelines is highly questionable.

Principle #3 - Authentically digital

People have come to expect things in the modern world, there are ways things are supposed to work and when we don't we surprise them and that's never good.

He piled on icons again here - now tiles are digitally authentic (I guess icons are digitally counterfeit)

Principle #4 - Do more with less

These aren't new, those readers who have seen the Jim McCarthy video that I show all my teams and clients will recognize some of these-

Principle #5 - Win as one

By this, he's really getting at two ideas - if the environment and its apps cohesive the environment will be more likely to succeed, and your app is more likely to succeed if you fit in. Perhaps your app fills in a spot on a workflow, but if it doesn't "fit" then it can't take advantage of that opportunity.

Here's his rules to win as 1-

All in all, an interesting session. If you found the writeup interesting, you may want to invest the time to watch the whole thing, I can't possibly due justice to his explanations. It's as if his talk was a beautiful, alive tile and my writeup is a dead, uninteresting icon.

Create Metro style apps quickly with built-in controls

This session went lots of different controls available to Metro style apps. To just describe them all one after the other would probably be more boring for me than it would be for you (OK, if you made it through that last column your boredom tolerance is pretty high), so I'll just list the key aspects of Metro controls in general.

Fundamentals of Metro style apps: how and when your app will run

Everyone is familiar with the lifecycle of a Windows 7 app - although some don't even realize it. Essentially, the user is responsible for the entire lifetime of the application. The user starts an app and it stays in memory and runs, along with any other apps the user starts. When the user is done with an app or wants to improve performane or memory space, the user stops that app and the apps lifecycle is complete. User starts the app, the app runs, the user stops the app.

Windows 8 uses a different model. If you think about it, with similar environments (phones, other pad computers that might have preceded Windows 8, etc.), it's never really clear if an app is running. You go to the visual representation of the application and launch it. When you launch another app, does the first one stop? You may not go back to it for days, perhaps only minutes, either way you pick up where you left off. What's it doing in the meantime? Are all the apps on your device running all the time so they are always ready? It's a puzzler!

In Windows 8, the system controls when apps run. It focuses on the foreground app because that's the one that's most important. Here's a rundown of all the events in the lifecycle of an application under Windows 8. It starts with the app not running-

  1. Application is activated - The code for your app is loaded and executed and an handler for the activation event is called. This event includes arguments including why the app is getting activated (in this case it would be "Launch", but the app can be started for other purposes like "Search") as well as any context. When launching, the system will display a splash screen with an image specified by the developer while the Activate event is being handled. If your event takes more than 15 seconds to handle the launch event the System will assume it's dead and crash it.
  2. Application runs - User interacts with the app, it stays in the foreground
  3. User Starts another App - The user decides to do something else and another app moves to the foreground.
  4. App receives a suspending message - After a short delay, your app will receive a message that it is being suspended. This is the app's last chance to execute any code before it is terminated. After this, your app is in the Suspended state. The app is completely inert in this state-
    • It's not scheduled by the NT Kernal
    • There's no CPU, Disk or network consumed
    • All threads are suspended
    • Apps cannot be suspended in a critical section
  5. Resuming - If the user brings your app back to the foreground, it immediately resumes. Because the app is essentially frozen in it's last state, resuming is nearly instantaneous. The app receives a Resuming event so it can refresh time sensitive displays.
  6. Termination - If the system needs resources, mainly memory because that's all the suspended app is consuming, it can terminate the app. There is no termination message (which the app is not alive to handle anyway), the app is just vaporized from memory.

During a demo where he was using the new Task Manager to show the state of the applications, he collapsed the start screen where all the tiles for Metro apps reside and underneath was a conventional desktop with these lifeless, antiquated, uninteresting things that I think we used to call icons.

Let's go back to that 15 seconds to load thing - what if you've got an app that takes longer that 15 seconds to load? The weather app is a good example of this, it uses what they call an extended splash screen. The activation event itself puts up it's own splash screen with the same image and location as the default, then the app finishes loading on its own. The neat thing here is that the extended splash screen is under complete control of the app - so it can do things like display a progress bar (probably a good idea if your app takes that long to load).

So how can you make your app look and feel fresh when it's not really running all the time? One thing to worry about is how to smoothly handle the transition between running and suspended state. Things that help here are-

To make your app appear to be running even when it is not, you can use live tiles. There's two ways to do this-

Finally, there are certain situations where apps need to run even when they are in the background. He went over a few of these scenarios-

Letters! We Get Letters!

JR from MD ponders-

Hmmm...
Didn't have multi-touch first
Didn't have tablets first
Didn't have gestures first
Didn't have app store first
But we don't have those plain icons like the iPad! We have Tiles! Hammer the one place there's a distinction?

JR, that is an extraordinarily cynical observation of the Metro style. That's the kind of negativity that pretty much gaurantees publication of your letter! Tiles are alive, they're beautiful, they're fast and fluid, they're an extension of your app, they're not icons...

Vishwas Lele of Applied Information Sciences responded to my challenge to explain JavaScript executed in a dedicated local app. Here's what he has to say-

I will share my two cents:

Hmmm, gonna have to think about this for a while. I'm not familiar with development for Droid and iPhone - if they are HTML5/CSS based I can see the benefit in making your app available across all phones - be nice to have access to more than 2% of the phone market. In the meantime Vishwas, you're in print - feel free to send this link to all your friends and family!

The End

Looks like this is going to wrap up the newsletter this year, hope you enjoyed it. We probably won't be doing remote newsletters in the future, it's just too hard to do it right without devoting full time to it. Hopefully we will have the opportunity to return to doing it live in the future.

Biff
Remote Reporter, Biff's PDC Newsletter