Next Monday is the Memorial Day holiday here in the US, and I'll be at the O'Reilly Fluent conference for a few days after that. So I'll be taking a short break from posts during that time. See you soon!
When developing apps, appdata is normally preserved through code/debug iterations. If, however, you change the manifest, the app is deployed anew and app data will be lost, because manifest changes trigger an uninstall and redeploy.
You can manually preserve the appdata, however, by simply copying the contents of your folder out of %localappdata%\packages\<your package>, making your manifest changes, rebuilding and running the app once, then copying the appdata back over. If you expect to be doing this a lot, it makes sense to write yourself a little batch file for the process; otherwise, consider making a copy of the app data, then doing whatever work you need to in your manifest (and testing those iterations), then copy the app data back.
Do note that this is a different situation than updating an app from the Windows Store or side-loading an update. In those cases the deployment engine does not uninstall the previous version, so appdata is preserved. The uninstall happens only when Visual Studio redeploys after manifest changes.
Using Semantic Zoom (in WinJS), by Adam Barlow: http://channel9.msdn.com/Series/Introducing-Windows-8/Semantic-Zoom. 5 minutes, 50 seconds.
(Thanks to Brendan Clark for this explanation)
If you have a XAML app in snap view that starts and animation, and then switch to another view state while that animation is running, elements like a Shape can become very blurred. The reason for this is that Shapes are realized/rendered at a specific scale, as is text. Recreating these realizations at new scale can be very expensive, so the XAML framework chooses to avoid creating any new realizations during animations. This reduces the chances of producing much more serious visual glitches during the animation.
When changing view states, then, a shape that's been realized for a smaller scale will be used when scaling up to the larger view, resulting in blurriness, until the animation ends and the shape is realized at the final scale. It's not a concern in the other direction, however, because a larger realization would get scaled down to a smaller, which works just fine except perhaps for other visual artifacts. (So the final realization after the animation will look better.)
The best workaround for this at present is to simply stop animations when an app gets resized, then start those animations again after the size change has finished. The XAML framework then has a static frame to use when resizing, which should produce better results.
Although swapping out language resources is something that happens somewhat automatically when the user changes system language, sometimes you want to know that directly.
There are a number of APIs in WinRT that relate to this (thanks to Erik Fortune for this):
- Windows.System.UserProfile.GlobalizationPreferences contains all of the languages requested by the user, in priority order. This list is the user-specific set from the “Languages” area ub control panel, and might include languages that any given app cannot support.
- Windows.Globalization.ApplicationLanguage.ManifestLanguages lists all languages that the application supports, as defined in the app manifest, and might include languages that the user does not understand.
- Windows.Globalization.ApplicationLanguage.PrimaryLanguageOverride is a persistent single language setting that can override user and app defaults. Because this is persistent (and expensive), it should not be used for temporary overrides.
- Windows.Globalization.ApplicationLanguage.Languages is the list of languages actually used to display the app UI. It’s constructed from the User Language Profile, the Manifest Languages and the Primary Language Override.
That said, you'll notice that none of these just say "this is the language that's in use across the system." What a number of developers have done, then, instead of trying to infer this from the above APIs, is to simply include a language tag in your localized resources. Because one set of resources will be loaded for the current language–assuming there's not an override–you need only retrieve that string and you know the language in use.
Do note that all of this applies only to language; if you want to know where the user actually is, always use Windows.System.UserProfile.GlobalizationPreferences.HomeGeographicRegion. That is, people can be using any language in a system regardless of where they're located in the world, so you need to use the specific region instead.
Last week I shared a series of thoughts about monetization of Windows Store apps, and today I have one more–not about monetization, per se, but about this idea of an app store in general.
I get the impression that many developers have looked upon app stores as a way to easily make money with whatever apps they care to submit. That is, there's an idea that app stores, like the Windows Store but also those on other platforms, will somehow bring customers to one's app with less effort than it has in the past.
In my opinion, the real truth is that app stores are simply a different kind of distribution mechanism that just so happens to also handle transactions. On the web, which was the primary distribution mechanism before app stores (and still remains one), you typically had to incorporate some commerce engine into your own web site to conduct sales. But this is now built in.
That said, most apps have the same challenge as before: customers still have to find your app in the Store, just like they had to find your site on the web. With tens of thousands or hundreds of thousands of apps in a store, and search results showing maybe 30-50 at a time, I don't really think this part of the picture has really changed that much.
Furthermore, the mistaken idea that its easier to make money with an app in an app store has led many a developer, I'm sure, to imagine that they can cobble together something that will pass Store certification thinking that it will suddenly earn them a comfortable living. It reminds me of a friend who thought that all she had to do with her home business was put up a web site and people would find her. I'm sure you laugh at that thought as absurd–and so too should you laugh at the thought that simply being in the Store is going to produce business. Maybe you'll get some, but as the app count increases, discoverability in any given store becomes harder and harder.
This really means two things. First, you have to write good software to be successful, plain and simple. It's really amazing to compare the experience offered by top-line apps and those that are produced by a hobbyist. It's essentially like the difference between a professionally-crafted movie and something you've shot in your backyard with a $99 camera: there's simply no contest. In other words, if you expect to make good money with an app, you should expect to really invest in it. And this has always been true in the software industry.
Second, you can have the best software in the world but it won't matter if people dont' know about it. This means making another investment in marketing, plain and simple. This too has not changed in all the years–promotion matters! Think about it: if you were to set up a small brick-and-mortar shop in your home town, you'd immediately engage in promotional activities of some kind, because the business will quickly go under otherwise. And you'd never question that need especially because you've invested so much in getting the business started, and the cost of failure is losing that investment. With apps, you can get something in the Store with a much smaller up-front investment, and so there's less of a perception of risk of failure. As a result, developers aren't as invested in the success of that app as they might be with a real business. But if you want that app to suceed and not just exist, then you really do have to treat it the same way.
What's also true in business is that when you start to generate revenue from your initial promotions, you need to dedicate part of that revenue to continued marketing as well as expansion of the business. In other words, some portion of every dollar you earn with an app should be earmarked for marketing activities, because that's how you'll begin to build a sustainable flow. By also earmarking another portion for further development, you're investing in the sustainability of the business when revenue from the first product begins to wane.
The bottom line, then, is that although apps stores have brought a new distribution method with built-in commerce, running a successful software business requires the same dedication and investment as always. Have a great product, and invest in the effort to let people know about it.
To complete this series from part 1, part 2, part 3, and part 4, the last topic is thinking about multiple apps together. In the Windows Store, apps must stand on their own (suites are not supported), and yet if you are selling more than one app it certainly helps create marketing relationships between them. In other words, you can build upon the idea of lite and full apps, and think about how a diversity of apps and monetization models can help you build your overall business.
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.
Continuing from part 1, part 2, and part 3, let's now talk about using in-app purchases. The technical details and some useful design thoughts can be found on How to support in-app purchases on the Windows 8 developer center. What I want to add to that discussion are some observations from a few other apps.
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.
Continuing from part 2 of this series, the next topic is about using ads for monetization. This is one of the most popular methods, especially with free apps, but you should also consider using them in trial versions of paid apps. As described in part 1, trials should frequently (but appropriately and respectfully) remind the user of the app's trials status and invite an upgrade. Ads really serve the same purpose when you have a paid app as well: just as you might feature-limit a trails, having ads in a trial is a feature that many users would like to remove! In other words, running the app ad-free is a "feature" that's enabled with purchase of the full app.
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!
Continuing from part 1 of this series, the next topic is using trials of a paid app vs. free demos of those apps. There are distinct differences between the two.
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!