While I was preparing for my Alive with Activity talk at the //Build 2012 conference last October, I was thinking more deeply about the design of the Windows Start screen, live tiles, and why, exactly, the API for live tiles (as well as toast notifications), limits you to using a predefined ‘template’ for a tile’s XML update payload. Put another way, why didn’t Microsoft just allow apps to create whatever kind of tile updates they want to? Why shouldn’t an app developer have complete control over the appearance of their tiles?

The clearest reason, to me, is that the Start screen is the central piece of shared real estate in the whole system. As such, it really begs for a sense of unity across the whole experience, and works best when there is consistency between the tile updates that are happening for all the apps involved.

With this in mind, I’ve been reflecting on the Start screen experience as it relates to the three ‘qualities’ of energy, known in the Bhagavad-Gita and other Vedic teachings of ancient India as the ‘gunas.’ These qualities are something that one of the best-known modern masters, Paramhansa Yogananda, drew from extensively in his teachings. For example, one of his early writings, Psychological Chart (1925), identified many different psychological qualities as expressing one or more of the gunas.

The three qualities or gunas, as explained in Yogananda’s Autobiography of a Yogi, are tamas (obstruction, inertia, ignorance), rajas (activity), and sattva (elevating or expansive, sometimes written sattwa). These provide a way of understanding the predominant nature of human beings, and is, in fact, at the core of the Living Wisdom School attended by my son (a system that is explained in the book Education for Life, written by J. Donald Walters, himself a direct disciple of Yogananda).

Human psychology aside, my point in this post is to think about the ways that the start screen of an operating system can be designed, and how they related to these qualities.

One design is something we all know very well: a screen full of static icons, perhaps with a pretty picture in the background. Yes, this design has been around for 20 years or so now (can you say Windows 95), and while it works and can look beautiful, it’s actually quite lifeless. In many ways, then, this design can represent some elevating qualities (sattva) but by its static nature—if not its age!—represents inertia (tamas).

Another design would be to give apps a space on a start screen in which they can do anything they want—any kind of text and image content, perhaps video and audio, whatever kinds of animations they might choose, and so on. Certainly this is a step above the static, tamasic kind of experience, but the result is un-unified, undirected, and chaotic. This is rajas at its best, like when you’re busy and active just for the sake of being busy and active. Such activity helps remind you that you’re not dead, but isn’t particularly elevating in the sense that you derive any true joy or happiness from it. Indeed, what lies at the end of this road is exhaustion and a collapse back to the tamasic state. Put another way, if you designed a start screen like this and (hopefully) allowed users to turn off the noise, it’s likely that they’ll turn it off rather quickly, especially if multiple apps wanted to play audio and video simultaneously!

A third design is to allow for some activity, but in such a way that there is that sense of unification, coherency, and beauty without letting things get out of hand. This is both rajas and sattva working together—an activating+elevating experience.

And this is exactly what I think the Windows Start screen, through the tile update templates, achieves. There is activity, certainly (and still something that users can control), but that activity is coordinated such that tile animations and the update cycle happen in a way that’s actually enjoyable to look at, rather than an eyesore.

If you haven’t been on your Start screen for a bit, assuming you’ve been reading this post, hit the Windows key and watch what happens. When you first land on the Start screen, there’s a moment of rest where everything is quiet. Then a number of tiles will update more-or-less together (but a bit in a sequence too), and then everything gets quiet again. After a time, a few tiles will again update or animate, and then a period of rest.

It’s this coordination between the app tiles, combined with the period of quiet and rest, that makes the Start screen alive with activity, but not busy with activity. And as apps draw their tile updates from a choice of available templates, every update has a relationship with the others that also reinforces this sense of unity.

Personally, I think it’s a brilliant solution.


Recently I was scribbling out some for a ListView control and wrote out a WinJS.Binding.Template in default.html. I misspelled data-win-control, leaving off the ‘l’ at the end:

<div id=”entryTemplate” data-win-contro=”WinJS.Binding.Template”>

The result of this was a curious exception way down in WinJS: (for the benefit of search engines, the error text is “Exception is about to be caught by JavaScript library code at line 20074, column 9 in ms-appx://microsoft.winjs.1.0/js/ui.js … 0x800a138f – JavaScript runtime error: Object expected”)

Spelling data-win-control correctly fixed the problem, but I wanted to make a note of what caused this error with a WinJS.Binding.Template. Basically because I’d misspelled the attribute name, a template control never got created, thus the non-existent object.


If you have occasion to do a live demonstration that’s being projected onto a larger monitor or screen, you can change a setting in the desktop Control Panel to make your touch points show visual feedback. This allows your audience to better follow exactly what you’re doing.

That setting is in Control panel > Hardware and Sound > Pen and Touch > Change touch input settings, then check the “Show visual feedback when touching the screen” box (see below). You might also want to check the “Optimize visual feedback for projection to an external monitor” box as well. Note that this setting appears only on systems that are touch-enabled.


Thanks to my teammate Kyle Marsh for this one:

var freeSpaceProperty = "System.FreeSpace";
var applicationData = Windows.Storage.ApplicationData.current;
var localFolder = applicationData.localFolder;

localFolder.getBasicPropertiesAsync().then(function (basicProperties) {
    // Get extra properties
    return basicProperties.retrievePropertiesAsync([freeSpaceProperty]);
}).done(function (extraProperties) {
    var propValue = extraProperties[freeSpaceProperty];
    if (propValue !== null) {
        outputDiv.innerText = "Free Space: " + propValue;
}
}, function (error) {
    // Handle errors encountered while retrieving properties
});

Mozilla has introduced two simple methods to the DOM API for encrypting and decrypting base64 values. These are btoa, which converts binary (or string) data to a base64 ASCII-encoded string, and atob, which will do the opposite.  These APIs are being adopted by Internet Explorer 10 and are thus also available to Metro style apps written in JavaScript.

The basic functionality of these methods overlaps with the WinRT APIs found in the Windows.Security.Cryptography.CryptographicBuffer class, with the results being entirely interchangeable as you would expect. This means that base64-encrypted data created in one app using the DOM APIs can be passed to and successfully decrypted by an app using the WinRT APIs, and vice versa. This is shown in the code example below.

The difference between the two APIs thus rests in their structure and scope. As seen in the code example below, the btoa and atob methods are the simplest and most concise, but they work only with binary or basic string data, and cannot handle raw Unicode. As Mozilla’s btoa docs point out, Unicode strings will cause an exception in both methods and must be worked around with additional code. These methods are also focused solely on base64.

The WinRT APIs, on the other hand, are a little more complicated for basic usage but are much more flexible overall. For one, they handle Unicode strings just fine, with support for UTF-8, UTF-16LE, and UTF-16BE. Second, these APIs work with an intermediary buffer that can be created from a string, a byte array, or filled with random data. Finally, such buffers can then be encoded to base64 or hexadecimal, or copied to a separate byte array.

In short, the two can be used interchangeably for basic base64 operations, but developers might find it more consistent to use WinRT for other kinds of encoding.

Code example

This example simply shows the equivalence of the APIs and their cross compatibility. Create a new JavaScript project using the Blank template and drop in the code below. When you run the app and press the Run Test button, you’ll see the original string, the base64 encryption, and the decrypted values, using WinRT exclusively, using HTML APIs exclusively, then intermixing the two. As you’ll see, the results are entirely as expected.

HTML (body of default.html)

<body>
     <h1>Encryption Comparison</h1>
     <button<span >id="btnRun">Run Test</button>
     <p>Input Text: <spanid="txtInput">A text string for encyption</span></p>
     <p>Encrypted String (WinRT): <spanid="txtEncryptedWinRT"></span></p>
     <p>Decrypted String (WinRT): <spanid="txtDecryptedWinRT"></span></p>
     <p>Encrypted String (btoa): <spanid="txtEncryptedJS"></span></p>
     <p>Decrypted String (atob): <spanid="txtDecryptedJS"></span></p>
     <p>Decrypted String (WinRT using btoa output): <spanid="txtDecryptedCross1"></span></p>
     <p>Decrypted String (atob using WinRT output): <spanid="txtDecryptedCross2"></span></p>
</body>

 

JavaScript (entire contents of default.js)

(function () {
    "use strict";
    var app = WinJS.Application;
    app.onactivated = function (e) {
        if (e.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch) {
            WinJS.UI.processAll();
            var btn = btnRun;
            btnRun.addEventListener("click", runTest);
        }
    }


    function runTest() {
        var wsc = Windows.Security.Cryptography;
        var input = document.getElementById("txtInput").innerText;
        var buffer1a = wsc.CryptographicBuffer.convertStringToBinary(input,
        wsc.BinaryStringEncoding.utf8);
        var encrypt1 = wsc.CryptographicBuffer.encodeToBase64String(buffer1a);
        document.getElementById("txtEncryptedWinRT").innerText = encrypt1;
        var buffer1b = wsc.CryptographicBuffer.decodeFromBase64String(encrypt1);
        document.getElementById("txtDecryptedWinRT").innerText =
        wsc.CryptographicBuffer.convertBinaryToString(wsc.BinaryStringEncoding.utf8, buffer1b);
        var encrypt2 = btoa(input);
        document.getElementById("txtEncryptedJS").innerText = encrypt2.toString();
        document.getElementById("txtDecryptedJS").innerText = atob(encrypt2);
        document.getElementById("txtDecryptedCross1").innerText = wsc.CryptographicBuffer.convertBinaryToString(wsc.BinaryStringEncoding.utf8,
        wsc.CryptographicBuffer.decodeFromBase64String(encrypt2));
        document.getElementById("txtDecryptedCross2").innerText = atob(encrypt1);
    }


    app.start();
})();

 


New projects created from Visual Studio templates contain default tile, splash screen, and store logo images that just contain an X in a box. These are designed to be so ugly that you feel utterly compelled to replace them.

Unfortunately, some developers forget to do this. Until recently, these weren’t actually checked by the Store certification process, thus we see some apps in the Windows Store that still contain the default Store logo:

The particular challenge with the Store logo (that’s referenced on the manifest editor’s Packaging tab and not the Application UI tab) is that you never see that graphic in the running app. It appears only in the Store after you’re onboarded the app, which is why we see some of them make it into the Store.

Fortunately, the Store certification process (and a version of the Windows App Certification Kit from November 2012 or later), will fail you if you’re still using the default images.

Save yourself the trouble, then, by making sure to double-check your square tile, wide tile, splash screen, and store logo graphics before uploading to the Store.

While you’re at it, be sure to give your app a more interesting background color than the default gray. Such things are so simple to change and make a huge difference in your Store presence.


A while back one of my associates asked for an “ideal spec” for a Windows 8 developer on behalf of a partner who was looking to hire such a person. I won’t presume to have the ‘ideal,’ but here is a list that you might find helpful in your own recruiting efforts:

It would be best, of course, to find a developer with experience in one or more of the language/presentation layer choices for building apps: HTML/CSS/JS, C#(VB)/XAML, C++/XAML, and C++/DirectX. Experience in more than one is a big plus because of the platform’s support for writing mixed-language apps via WinRT components. And of these, DirectX experience is more specific to doing graphics apps vs. those with layout and data.

Other attractive qualifications:

  • Understands how to work with web services and web-based databases.
  • Strong testing skills and understanding of testing methodology. This will make a huge difference in delivering a top-quality app; those apps produced by developers who’ve never had to test much at all (e.g. many web-only developers) tend to have more bugs and fail Store certification more often.
  • Experience with Visual Studio a plus, as this reduces learning curve and helps productivity, though the tools can be learned, of course.
  • Experience in measuring and improving performance a plus, as again this will help produce a top-quality app, especially with web services.
  • Ability to learn and understand a platform, not just an app’s internals, which helps in understanding how to integrate all the platform features of Windows 8 into an app
  • Understands caching strategies for producing a mobile app that can operate with or without connectivity.
  • Respects the role of designers and enjoys working with them and maintaining a strong relationship–this will happen!
  • Experience with Windows Azure, Azure Mobile Services, and/or Windows Notification Service (WNS) a plus, especially for working with live tiles and notifications.
  • Familiarity with authentication, e.g. OAuth.
  • Mobile dev experience in general is a good thing.

Another place we’ve seen many apps fail Store submission is with 4.1.1 of the Windows Store Certification Requirements (v4.0). It’s title is “Your app must have a privacy statement if it is network-capable.” It basically says that if you declare any network-related capabilities in your app manifest, you need to have a privacy policy available from two places specific places.

To the point of being network-capable, the requirement states, “If your app has the technical ability to transmit any user’s personal information, you must maintain a privacy policy.” While you could interpret this statement to suggest that an app that doesn’t collect any kind of personal information at all, e.g. just downloads posts from a public blog, doesn’t need a privacy policy, it’s best to err on the side of a more general meaning. The phrase “if your app has the technical ability” means that whether or not you collect any personal information, declaring those capabilities in the manifest means that you do, in fact, have the ability. So you want to have a privacy policy.

The requirement then states where that policy must be accessible: “You must provide access to your privacy policy in the Description page of your app, as well as in the app’s settings as displayed in the Windows Settings charm.”

The short of this means that you need to have a web page somewhere with the privacy policy, preferably in every language that you support in your app, though this is not explicitly spelled out (after all, page translators can be used on your page). That page is what you link to in your app’s description. [Addendum: This is required because it allows users to check the privacy policy before installing the app, rather than after the fact.]

In your Settings pane, then, you can make the privacy policy accessible in one of two ways. First, you can just create a link to that same web page, which opens the browser to display it. No problem there. Second, you can create a flyout panel that contains the text directly, often by using an iframe that loads its contents from your web page. I use this latter approach in the Here My Am! app in Chapter 17 of Programming Windows 8 Apps in HTML, CSS, and JavaScript, where I do have localized versions of the policy on my web site and include those within an iframe (as shown below in German).

The bottom line: set up privacy policy pages in your supported languages on a web site, and be sure to link to that page in your app Description and through your Settings, and don’t risk failing certification for such a basic matter.


This is something we saw with a number of early partners. In the app manifest, in the Application UI section of Visual Studio’s editor, there’s an option called Show name with a variety of options:

By default, this is set to “All logos” meaning that the value in the “Display name” field (also on the Application UI section), or the value in the “Short name” field, if given,  will appear on the lower left of a tile as shown here:

As you can see here, the display name/short name text is redundant with the app name that’s already on the tile. To remove it, select one of the other options in the Show name drop-down.

It’s a good thing to double-check before submitting an app to the Store. Having a name show on a tile when the graphic shows a name too won’t cause the app to fail certification, but it does look a little silly.

When you support live tiles, there are situations where you do want the name or a badge logo to appear on the tile, even though you don’t show the name for the default tile. For these purposes, use the branding attribute in the tile update XML. See Chapter 13 of Programming Windows 8 Apps with HTML, CSS, and JavaScript, in the “Branding” section (page 585) for details.

 

 


With requirement 6.2 of the Windows Store Certification Requirements (v4.0), all apps must have an age rating. Be sure to follow the guidelines because they are taking very serious from everything I've seen, and many apps fail on this simple basis.

One of the key bits to pay attention to is the following statement:

If your app provides a user with uncontrolled: (i) access to online social networks, or (ii) sharing of personal information with third parties, including other gamers or online acquaintances, then you must assign it a Windows Store rating of at least 12+.  For such activity to be considered "controlled", your app must include parental control features that require parental permission to use such sharing features, and you must identify those and explain their functionality in the Notes to testers.

To make this story short, if your app uses the Internet, carefully evaluate your usage to understand whether you need the 12+ rating or not. Also see Giving Your App an Age Rating.

You also want to make sure that any terms of service you link to from your app indicates ages that are compatible with your chosen age rating with the Store. One partner I worked with a while back failed for this reason: their terms of service said something about a person needing to be 14 years or older to agree, but the app was rated for an age lower than that. This meant that a young user could acquire the app from the Store but wasn't technically allowed to use it due to the terms of service.

It's good to note that earlier versions of the Store certification requirements specifically called out manifest capabilities like geolocation and webcam as requiring a 12+ age rating in and of themselves. This has been refined to allow apps with a 3+ rating, for example, to use the webcam, so long as it does not allow uncontrolled sharing of pictures. So a 3+ app can take pictures from the webcam and let a preschooler doctor themselves up, no problem, but sharing the results via a social network would require parental consent in the app.