For example, having some great free apps can help build a solid reputation for your business, thereby encouraging users to check out your other paid offerings. Because each app in the Store can include links to your website, each app is a doorway to the rest of your business as presented on the web. In this way, free apps can serve as giveaways (also known as loss leaders) that many businesses use to get customers in the door where they can then experience additional products.

Although the Windows Store certification policy does not allow apps to be interdependent (that is, you cannot require the installation of a second app to install the first), you can make them interoperate such that having those apps installed together makes additional scenarios possible. One of the most effective ways of doing this is through the Share contract, where you can use custom formats to exchange richer information than the standard formats allow. Another powerful means is protocol activation, wherein you use a specific URI scheme like bingmaps:// to allow one app to delegate specific tasks to another. This is limited to one-way communication, mind you, but can still be a powerful way to have those apps work together and light up more features.

And you can certainly advertise these interop features on each app's description page in the Store. That is, while you can't require one app to be installed to use another, Store policy does not prohibit making mention of what's possible when you do. You can say, "By also installing the companion SuperApp, these additional features become available:…."

As a final note, I want to mention a growing opportunity that's really just in its early stages. Many apps have a backend service that provide much of their runtime data. If that data might be useful to other apps, consider making your web API available and monetizing access to it. This way you have another facet of your business to develop that is focused on developers as customers, rather than just end-users. And you can also use services like Mashape and Mashery to help you in the process.

And with that, we conclude this series. I hope it's been helpful and inspiring, and I look forward to any comments you have on monetization strategies.

First, with the obvious case, you can use in-app purchases to turn certain features on. This includes turning off ads, meaning that you use an in-app purchase for this purpose rather than converting a trial to a paid app as in part 3. Here, you're thinking about how a user can convert money (their money) into added capabilities.

Second is thinking about how to introduce another level between the purchases and capabilities. This is a strategy used in a number of games that have their own in-app "currency" (coins, points, etc.), with which you can buy extra capabilities. Often you can earn by playing the game for a long time, but if you're impatient you can convert real money into in-app currency and thus shortcut the process. In other words, you're letting the user choose between patience/perseverance and a little bit of their money.

Two of the most popular games, both by HalfBrick Studios, are great examples in this regard: Fruit Ninja and Jetpack Joyride.

Fruit Ninja offers the Dojo within the app where you can acquire different blades, backgrounds, and special (and temporary!) powers (like a bomb deflector). Some of these you can acquire by performing special feats within the game, like finishing with a specific number of points, slicing specific fruits in a certain sequence, and so forth. You can also acquire them buy exchaning "starfruit points" that are gradually earned by playing the game. But then you can also make an in-app purchase of extra starfruit points, allowing you to then purchase the add-ons with those points. So if you're not as patient as my six-year-old son has been to save up 9000 points for the King Dragon Blade, you can just spend a couple of dollars and get it right away.

Jetpack Joyride does something similar. By playing the game and completing missions you earn coins with which you can buy all kinds of extra gadgets, powers, fun clothing, and so forth. Again, you can earn all the points you'll ever need just by playing the game. But you can also just flat-out purchase coins with real money. Because the Windows Store does not yet provide for in-app consumables (an in-app purchase you can buy multiple times), Jetpack Joyride offers a number of one-time purchase options: 20,000 coins for $1.49, 50,000 coins for $2.49, 100,000 coins for $3.49, 250,000 coins for $5.99, and 1,000,000 coins for $13.99 (which would allow you to buy everything). So again, if you're willing to spend, you don't have to be patient.

Jetpack Joyride also offers a brilliant in-app purchase that I thought was well worth $1.49: the "counterfeit machine" which automatically doubles all the coins you earn when playing the game. This is totally worth it!

So for in-app purchases, I strongly encourage you to look at what other apps are doing, especially the most popular ones, as they offer good insights into designing around this monetization approach.

But let's talk more of designing around ads. This is one place where I see many apps being somewhat lackadaisical.

First, if your app is always going to be free, then the whole purpose of using ads is to not just display them, but to get uses to click on them which should increase your revenue. In this way they should be placed invitingly, but not obnoxiously. For this I think you can find quite a bit of guidance in researching best practices for ad placement on web sites, as those are essentially free apps themselves.

Personally, I think the use of ads is most effective when you also have a path to a paid app, even if the paid app's only added feature is removal of the ads. This way you give the users a choice of dealing with the ads, or ponying up a little cash for the privilege of removing them.

Here, then, is where you have many design approaches that could help increase your revenue (again, these are ideas and observations, not necessarily ones I've personally tested):

• With static placement (within the app's layout), ads needs to be visible, of course, and if you offer a means to get rid of them, you want to think about making the ads a distraction from the real content of the app. This encourages conversion.
• As I suggested for trial reminders in part 1, use dynamic placement of ads to break up the flow of the app–to again be just annoying enough but not obnoxiously so, as an encouragement to get rid of those ads. This is what TV shows excel at doing: build up to a near-climax, but then break away so that your attention is transferred from the program to the ad. I've seen this strategy often with web games where you're playing along and finish one level. You're looking forward to the next but then app tosses in an "interstitial" ad that makes you wait for 15-30 seconds for your next dose of the game. You can't make the user wait too long, of course, but a little wait makes them hungry and again more likely to upgrade.
• An app can build some more intelligence around frequency of ad insertion within the flow too: an app can keep track of total elapsed usage time, such that at first the ads don't appear as often, but as the user gets more and more involved with the app, you can increase the frequency of disruption. A friend of mine wrote a game that just displayed ads statically, and I suggested that he insert an interstitial between every 4 -5games, which meant about every 5 minutes of play time. It would not be difficult to say that after 30-60 minutes of total usage time, the ads showed up once every three games. After another 30-60 minutes, every 2 games, and then after another 30 minute have an ad show up after every game.
• And don't forget, when you show an ad, provide a link to your app's page in the Store with a reminder that you can get rid of ads with an upgrade!

More thoughts? I'd love to hear your comments!

A trial version of a paid app is either feature-limited or time-limited as noted in the previous post. What's distinctive here is that the trial gives the user the same experience as the full app, such that if they upgrade they can then continue on and deepen that experience.

A free demo, on the other hand, is a standalone app, which would, of course, invite the user to visit the full app's page in the Store. It must be noted that such a free demo app must deliver good value to the user in and of itself–it can't just be an advertisement. This is why you see "lite" versions of apps, because "lite" makes it clear that you can do plenty with the app, just not everything.

Lite/demo apps can typically be used for any length of time, but while being useful, think of them as a way to showcase features of the full app–like a teaser trailer–rather than providing a complete experience.

Here's an example I gave in Chapter 17 of my book: Let’s say you have a game with five distinct “worlds” through which a player would normally progress in the app's full version [if you know the game Switchball, I wrote this example based on it]. A trial version would allow a player to start working through those worlds but would cease to operate completely after some short period of time, say 30 or 60 minutes. In that time, a player might not progress past the first few levels in the first world, so the experience of the overall game is incomplete. A free demo/lite version, on the other hand, could be played as much as one wished but would contain only one level from, say, three of the five worlds. This gives the user a broader taste of the app and, because it can be played many times, serves as a continual advertisement for the full experience without giving anything more away.

When offering a lite/demo app, you can forego offering a trial of the paid version, or make the trial relatively short. In the end, you're always trying to use trials and demos to lead to purchase of the full app, so design a demo app with that in mind.

Other ideas? Please add comments!

With monetization, the Win8 Dev Center does have a topic entitled Choosing your business model, that really lists the different options and links to some helpful details on them. What I want to do here in this next series of posts is add some thoughts to those pages. I'm not claiming to be an expert on these matters by any means, but there are some observations that I think can be helpful in your app efforts, many of which, are really about speaking to a customer's emotional reality rather than their rational mind, as purchasing decisions in the one or ten dollar range (as with most apps) is an emotional matter. I think this is something that most product marketers will tell you time an again.

Our first topic, then, is offering app trials and converting trials into full licenses.

The Windows Store, as you may have already seen, allows you to offer a "try-before-you-buy" license for paid apps (see How to create a trial version of your app). When you enable a trial (which can be time limited), the user will see a "Try" button alongside the "Buy" button on the app's page in the Store. Clearly, this gives potential customers a chance to really know what they're buying, and because the app knows it's running a trial license it can disable certain features and take opportunities to encourage the user to upgrade.

What's surprised me about a number of paid apps is that (a) they don't offer a trial at all, and (b) those that do offer a trial don't take opportunities to remind me to convert to a full paid version.

So here's my short list of good practices for paid apps–again, I won't call them "best" because I don't have experience in how well these work, but they seem like common sense to me:

• If you set a price for your paid app, always always offer a trial. Otherwise you're asking users to buy the app either on reputation or your product page alone. Perhaps if the app is famous you can skip the trial, but until then, this feature is, in my mind, essential.
• Trials can be time-limited or feature-limited or both. Spend some time thinking about what your free/trial experience should be like. You want to give the user enough to really experience the app, but only enough to be a real teaser for buying the full app. Think of this like the movies. A feature-limited trial is like a movie trailer: you get a good taste, but not the full experience. Hopefully the trailer makes you hungry for the real thing! A time-limited trial, on the other hand, is like a movie rental: you get to enjoy the full thing for a time, after which you need to make a decision to own to continue the experience.
• Trials are different from demo apps–I'll talk about those in another post.
• The Store tracks time-limited trials by date, but you can certainly implement a time-of-use limit in the app itself, like games that allow 60 minutes of play time or such. This can be an effective way to focus the user's attention on the need to decide whether to buy.
• Trials should remind the user–often, but not obnoxiously so–that they are running a trial. Think through every opportunity to remind the user of the features they're missing, how much time they have left to enjoy the app, and the benefits of buying ('ve been surprised how many trial apps never remind me at all!). Put yourself in the customer's place, of course, to you communicate to their needs and sensibilities and not yours as the developer.
• With reminders, I think it's effective to use them to disrupt the flow of the app in key places (especially launching). You want the reminders to be just annoying enough that the user will want to get rid of them. In movie trailers, you build up energy but then leave the audience hanging, wanting to know the answer or the resolution. You can take the same approach here: let the user go through most of the experience of an app, but then break that flow near its climax with a little reminder. Again, play to the user's emotions, because app purchasing is generally an emotional decision.
• If the user runs the app after it's expired, don't just say "the app is expired" but remind them what they're missing and remind them of any state or history they've built up in the app. For example, a note-taking app can say "You've written down 150 notes and reminders–upgrade now to keep them" or "You're only 200 points away from <some achievement>. Upgrade now to earn your next award!" In other words, remind the user of the key experiences or connections they might have had with the app (emotional) rather than the mere fact of an expired trial (rational).

Do you have other ideas? Please share them in the comments!

Here's what to pay special attention to:

1. Make sure that all logos (logo, wide logo, small logo, and store logo) are all representative of your app. Avoid shipping an app with any of the default graphics from the VS templates. Note that the Store logo never shows up in the running app, so you won't notice it at runtime.
2. Double-check how you're using the Show Name option along with Short Name and/or Display Name. Go to the Start screen and switch your app tile between square and wide, and see if the tile appears like you want it to. In the graphics above, notice how the app's name is included on the tile images already, so having Show Name set to "All logos" will make the tile look silly (see below). So I'd want to make sure I change that setting, in this case, to "No logos." However, if my square tile, perhaps, did not have the app name in text, then I'd want to set it to "Standard logo only."
   
3. If you set Short Name, its text will be used on the tile instead of Display Name.
4. Be aware that if you're using live tiles, the XML update for a tile can specify whether the display/short name should be shown in the branding attribute. See my post on the Windows 8 Developer Blog, Alive with Activity Part 1, for details.
5. If you don't have specific scaled assets, reevaluate your choices here. Remember that if you don't provide a specific version for each given pixel density, Windows will take one of the others and stretch or shrink it as needed, meaning that the app might not looks its best.
6. Examine the relationship between the small logo, your specified tile background color, and any live tile updates and toast notifications you might use. Live tiles and toasts can specify whether to show the small logo, and the tile background color is used in both instances. If you have a mismatch between the small logo edge colors and the background color, you'll see an obvious edge in tiles and toasts.

Is there a backdoor, perhaps? Nope. Side-loading means there isn’t a record in the Store database for the app, so there’s no app identity to which to attach ratings and reviews.

That said, the goal of ratings and review for a side-loaded app is very different than for those in the Store. In the latter case, ratings and reviews are important for marketing and visibility of the app. For more limited distribution, that's not the case, and you're really looking primarily to collect actionable feedback.

With that in mind, there are a few incremental approaches you can take depending on how much data you want. For starters, just a simple mailto: link in a settings command will make it easy to email feedback. This takes only a couple lines of code (see Mixing links and flyouts in Settings (WinJS) for some examples of links).

With a little more work, you can set up a web page with a feedback form, show that in a settings flyout using an iframe or webview, and have that page email the results to you. Another incremental step would be to have the page save feedback in a simple database, so you could query it and save yourself the data-entry step from the email approach.

In fact, for a beta app, having queryable data like this is much more useful than the data the Store could collect, which you can only browse on your product page anyway. A web form, as described above, could also gather more specific feedback that you wouldn’t get through a simple Review text field.

With all this in mind, putting in the extra work to collect feedback is well worth it!

3.5 Your app must fully support touch input, and fully support keyboard and mouse input

Your app must provide visual feedback when users touch interactive elements.

Your app must not use an interaction gesture in a way that is different from how Windows uses the gesture. The Windows 8 touch language is described in Touch interaction design.

There are a number of things going on here that are worth thinking about more carefully.

The first sentence basically says that the app has to support multiple input modalities. To "fully support touch input" means that the app must be fully usable with only touch, which should be obvious given the increasing number of touch-only devices. This means that an app cannot have UI or features that are only accessible through a mouse or through a special keystroke. Usually this isn't much of an issue, because using pointer events lets you handle touch and mouse with the same bit of code anyway.

The second half of the scentence is a little sketchy to my mind. Depending on how you read it, it might say "the app must be fully usable with only keyboard, as well as with only mouse," or it can be read that "the app must be fully usable with keyboard and mouse together." From what I've seen, certification makes the latter interpretation.

At the same time, I strongly encourage developers to provide complete keyboard-only interfaces as well as mouse-only interfaces. In doing so, you make the app much more accessible for people with disabilities. That's really the reason why the UI guidelines for desktop apps that have been around for many years suggests things like keyboard accelerators for menus that can also be used with a mouse.

In this context I often think of a classmate of mine within the Electrical/Computer Engineering department at the University of Washington when I was an undergraduate there. Sometime in our senior year, he severed his spinal cord in a skiing accident and became a quadraplegic. But he still completed his degree, often using a computer keyboard with a rod that he held in his mouth. To this day I admire his determination to carry on despite his permanent injury, which means making a little extra effort of support full keyboard interactions and not rely on the mouse for some of it.

Anyway, the last two sentences of section 3.5 above apply only to touch interaction, and are pretty clear. The visual feedback requirement is important because it lets the user know that the app has detected the touch–a piece of glass, in other words, doesn't give the tactile response that a keyboard or mouse does, so the acknwoledgement of input has to be visual. For this, the pointer down and pointer up animations in the animations libraries provide standard visual responses.

As for gestures, the point here is to avoid forcing users to retrain themselves for the sake of your app, which ultimately lowers their efficiency across the rest of the system. It's a reminder that your app is not the only one running on the device, so be a good, cooperative player and avoid "innovating" in places like input where you'll just cause confusion.

The last thing I'll add regarding input is not part of Store ceritification, but also good to think about: sensors. As I wrote in my book, I like to think of sensors as another form of input, one that is a fresh area that's open to all kinds of innovation. And because there's nothing in Store certification related to how you use inclinometer, the compass, gyros, etc., you can be very creative here!

In JavaScript, doing a simple for…in iteration on a PropertySet will give you not only the properties in that set, but also its methods, which is often unexpected. For example, the following code:

var ls = Windows.Storage.ApplicationData.current.localSettings;
ls.values["property1"] = "value1";
ls.values["property2"] = "value2";
ls.values["property3"] = "value3";

for (var key in ls.values) {
    console.log("values[" + key + "] = " + ls.values[key]);
}

will not only output "values[property1] = value1" for each of the three values, but will also give you stuff like:

values[addEventListener] =
function addEventListener() {
    [native code]
}

This comes as a result of how the PropertySet is projected from WinRT into JavaScript. It sort of works like an array, but not really, so you get this kind of behavior.

Seeing this, one option is to use the iteration methods of the PropertySet, meaning to call its first method to obtain an iterator, then using the iterator's cumbersome current/moveNext semantics. This isn't particularly enjoyable code to write in my mind.

Fortunately, there's an easier way, which Luke Hoban provided based on an old blog post by Douglas Crockford, http://yuiblog.com/blog/2006/09/26/for-in-intrigue/, in which he points out that for…in includes all the keys in an object's prototype and not just those in the object itself. To prevent this, you have to use the hasOwnProperty method to check where the property is coming from. So this modification of the code above will produce the expected output:

for (var key in ls.values) {
    if (ls.values.hasOwnProperty(key)) {
        console.log("values[" + key + "] = " + ls.values[key]);
    }
}

Better still, in Windows Store apps we can rely on the more intelligent behavior of EcmaScript 5's forEach iterator, and just do the following:

Object.keys(ls.values).forEach(function (key) {
    console.log("values[" + key + "] = " + ls.values[key]);
});

This produces the same results with a simpler construct.

But also remember that as WIndows 8 runs on many different kinds of devices, there are many other ways that display properties can be changed.

For example, think of everything that can happen through the Display settings in Control Panel. The user can rotate a display directly (as when using a desktop monitor that swivels), which will change a view state to fullscreen portrait as well. The user can change display resolution, which clearly changes the size of fullscreen and filled views, as well as the vertical dimension of a snapped view.

On multi-monitor systems, the user can also change which monitor is assigned to run Windows Store apps, which potentially has the same effect as changing display resolution if those monitors are different.

A user could also plug an external display into a device: monitors, projectors, and so forth. Depending on how the user configures that display–duplicating the main device, extending the display, or switching exclusively to the external display–the screen resolution can change as well as the pixel density. For example, a Surface Pro has a 1920×1080 screen that puts the 140% scaling into effect because it's only a 10.6" screen. But plug it into a monitor with the same resolution and the scaling can revert to 100%. (This means that the app will see an effective resolution change from approxmately 1366×768 to 1920×1080.)

The bottom line is that apps really need to watch for the relevant resize event (such as window.resize in JavaScript) and update their layout both for window/screen dimensions and pixel density–and don't overlook the non-obvious cases when running some tests. It's good to try all the things described here.

Beyond this, two other software features could be cause for resizing the app: app bars and the soft keyboard. By default, these appear as overlays on the app's canvas, and with the keyboard Windows will also pan the app up automatically to make room. If you want more sophsiticated behavior, though, you can handle the events when these become visible and update your layout more precisely.