The topic is "Made in Munich with Love" - people from Munich will present their apps.
Das erste Treffen nach der Sommerpause beginnen wir nicht nur mit einer super Location am Marienplatz, wir hören auch ganz gespannt Derek, Georg und Till zu, die uns ihre Apps und ihren Weg dahin zeigen werden. Dabei geht es diesmal weniger um die Bits und Bytes und wie die drei die umgeworfen haben, sondern eher, was Sie an der Platform reizt, was ihre Geschäftsstrategie angeht (ob die überhaupt eine haben...), ob Downloadzahlen eine Rolle spielen und wieviel die Platform an (Werbe-) Einnahmen hergibt.
Natürlich wird es auch wieder genügend über Technik und Implementierungsdetails gesprochen. Die 3 können ja bestimmt doch nicht anders ;-)
Are you as surprised as I am when it comes to discoverability of available app updates on Windows Phone? As you read this blog I assume you know all available updates are announced through the marketplace app on the phone. When you pinned the marketplace app on your start screen or you are opening the app fairly often you will notice when an update is available. Imagine though you are one of the – you know – normal consumer. I bet only a tiny portion of all users have pinned the app on the start screen. So it’s damn hard for those people to even recognize an update being available. They will never – or only very unregularly – update your app. On iOS it all looks a bit brighter. “Notification marker” are displayed regardless of the icon size, although we have to admit there is only one size on iOS anyway. On the other hand that makes the story easier. A consumer does not need to know that an app can only show some sort of news/notification/update when it is pinned as a tile to the home screen. Do you get the idea? On iOS you can always tell by looking at the App Store icon if there are updates available. On Windows Phone you need to have the Marketplace App pinned to the home screen.
How can we fix that you may ask. We can improve the discoverability of available updates for actual users of your app through actions a developer can take when the app starts. All it needs is to check somehow if a newer version of the app is available, preferably when the app starts. If a newer version is available the user should be asked if he wants to go straight to the marketplace to obtain the update.
One place to check for the latest version is a plain text file stored somewhere on the interwebs that holds the current version number to check against. You may ask where to store that file. Well the easiest and cheapest way is a Windows Azure Web Site. Remember you get up to 10 web sites for free. A perfect place to store just a single txt file.
Setup a Web Site on Windows Azure
Sign up for a pay-as-you-go subscription on Windows Azure. That plan allows you to create 10 web sites for free. As this web site will only contain a single file, we don’t need any database setup.
On the details –> dashboard page for that just created web site, you’ll find the ftp hostname. For most users that use that tool for the first time, it is usually necessary to reset the deployment credentials in order to create a deployment / ftp user. Just click on the “Reset deployment credentials” and choose a username and password. Those are not related to your azure account.
In order to upload a file to the web site, open your ftp tool of choice (I use filezilla), enter the ftp hostname as server and your deployment / ftp user and password accordingly. Create a version.txt file that contains just the latest version number of your app and put that under root in order to access it under [yourwebsitename].azurewebsites.net/version.txt. Try in a browser to see if the file is reachable.
Check for the latest version from your app
As you’ve now setup an accessible file that contains just the latest version number as plain text, it’s time to check from your application to see if the currently running app is the latest version. To make things easy enough, I’ve created a component called “UpdateReminder” that you can use in your app that does exactly that. It’s open source and on GitHub. For ease of use I’ve created a nuget Package that you can pull into your app from nuget by the name WPUpdateReminder.
What it basically does, is retrieving a file from a specified location on the web and check whether the content is the same as a provided string. If they differ it’ll ask the user to go straight to the app page in the marketplace to update the app or dismiss the dialog. To avoid to have too much traffic on the site and bothering the user too much, you can specify after how many app usages it rechecks for a new version.
The setup is a peace of cake and only requires a couple of lines of code in your Main page.
You may ask how the app knows how many times it ran in past. That is done via a XML file. Every time the app runs that number is increased and saved in that particular xml file on the phone. Have a look at GitHub to see the implementation and please give feedback about what you (dis-)liked about the solution.
Every project needs logging functionality of some form. Logging in my case is the ability to persists information beyond the app lifecycle, a debugging session or even multiple app runs. The easiest way to persists information is to write them to a file. The file option makes the export and evaluation of the information easy and straight forward.
For the ease of use you can just call a static method to write to the log file. Like so.
Is that simple, or not?
Why talking and blogging about something that simple as that tiny library? Well, I’m working everyday with huge libraries like Spring.net, the Enterprise Library and the WPContrib. They are all great and offer a huge set of functionality. On the other hand, with many features comes a lot of overhead that is not necessary all the time. Sometimes you just need a logger, a converter or a json serializer.
Making it all Open Source
For the sake of collaboration and constant improvements, I open sourced the library and put it on GitHub. Have a look, create a pull request, when you need more functionality out of the box. Leave your concerns and ideas for improvements.
Putting it up on NuGet for ease of use
To make it even easier to use I also put it on nuget, so it’s only once click away from your project in Visual Studio. Just go to Project –> Manage NuGet Packages and search for “WPFileLogger”.
How to use the logger
Using as as simple as calling the static method like this.
In the last twoblog posts I explained how our app traXs was almost not existing in the Windows Phone Store as download rates were so super low that we were questioning the Windows Phone Store in general. In order to overcome the problems I outlined in the posts, we launched the JANUARY SALE and put the app for free in the store. Making a long story short: It went amazing and exceeded our expectations.
Download rates exploded
We launched the SALE on January 16th and download rates literally exploded from the 22nd going onwards until today. We were at 36 downloads on the January 15th. We are now on 3083. Yes. That is an increase of 8564% in just 16 days. It really took off at January 22nd.
The following chart displays the download rates sliced by countries. I find that chart kind of interesting as we are thinking about supporting more languages in our product. Apart from only having the app available in English, an Italian or French version might make sense after looking into those numbers. The US market is just big by nature. I’m wondering why Italy has such a huge number of downloads though? Has anyone any explanation for that? I still believe a huge corporation handed out Windows Phones to their employers. Or is it still a strong Christmas period for Windows Phone?
Reviews came in at a high rate
One part of walking up the ranks of the app store is by having good reviews. When we started the January sale we had 1 review from Germany. By the time of writing we’ve cumulated 28 reviews across all regions; 3 x 1 star, 4 x 3 stars, 9 x 4 stars and 12 x 5 stars. The Windows Phone Store only displays the reviews that have been written by user from your region. In our case the United States region has an average rating of 4,5 stars, where as in Australia and New Zealand the app doesn’t have a review at all. However the markets are similar as they all are industrialized, English speaking nations. In terms of ratings and reviews, they are different. That seems a bit strange. A Kiwi doesn’t see the English reviews from people from the UK or US. Microsoft, can you fix that? Please! Reviews based on Language may makes sense, I’ll give you that.
The overall ratio between downloads and reviews decreased from 1:30 to 1:100, which seems natural as the download rates were too small before for analytics.
In summary the reviews have been great in January. One technique to blame for the success might be the fact that we ask the user throughout the app for reviews. Once the user used the app for the 10th time, we ask him to leave a review at the marketplace with a button bringing him straight to the Marketplace Review page.
The picture below lists all reviews and ratings the app got in the US region.
Windows Phone Store ranking responded as expected to the reviews and ratings
Download rates and reviews compared to apps in the same category define the ranking within the Windows Phone Store – as far as my experience is telling me. Each country has it’s own app ranking. Your app in the US might be in the first spot, whereas in Germany it’s only at 107. There are basically 2 ways of looking for apps.
#1 is going by category. traXs is listed in the ‘Personal Finance’ category. In Italy the app is under the ‘Quick-Sub-Category’ as I call it (no official wording!) ‘New + Rising’ at a remarkable second place.
#2 is by using a search term. When searching for ‘expense’ in Italy the app is in second place as well. Keep in mind though, that this list is overall in Italy across all categories.
When searching more specifically for ‘expense tracking’ its the number one overall. That is pretty solid as I suppose a huge portion of potential customer are either entering ‘expense’ or ‘expense tracking’.
Remember, only weeks ago the app was not showing up on the first pages (!) at all, hence it was not discoverable and therefore buyable at all.
How to find the real problems customer are facing
The Windows Phone Store offers a great feature that lets you see all exception that have been raised for a certain period with the full stacktrace of the exception. It also includes the number of times that specific exceptions occurred. It is a nice feature to see what goes wrong when customer are using the app.
Besides the reporting from the store, we found Telerik’s Diagnostics Control that comes with their Rad Controls for Windows Phone, offers a way customer can send those exception information straight from the app to a certain email address of the App publisher. It includes more information about the actual device, OEM and OS Version the customer is using and a screenshot, which is very useful in most cases.
That way we get more information about the problems customer were experiencing, more detailed information and an actual email from the customer, which we use to inform each user once the bug has been fixed and an update is available from the store.
By the way, we just released a new version of traXs into the store and extended the sale to February. It solves a majority of problems people were reporting.
When Google pulled the plug for it’s maps for all Windows Phone users two weeks ago, a loud fuss went trough the loyal Windows Phone user and developer base. A couple of days later Google found the plug again and since then we’re able to use the web version of Google Maps from our Windows Phones again.
The discussion around the whole map provider thing reminded me about a an implementation I did a while back for Windows Phone 7. I developed an app that displayed various map provider instead of the provided Bing Maps. It changed the base layer and allowed to display basically all base layer that support a standard URL scheme. Google Maps, Bing Maps and OpenStreetMaps are just a few examples. In this post I would like to show you how to use the Maps control in Windows Phone 8 and change the underlying base layer from Bing Maps to a different one.
Unfortunately this explanation has to start with a disclaimer. In Windows Phone 7 the shipped map control was using Bing Maps as a Base Layer and supported the change of the base layer. In Windows Phone 8 the story is a bit different as the Maps Control that ships with WP8 is a complete rewrite of the control from WP7 and does not support the change of the base layer at this point – although Microsoft said in a forum it’ll support it in a future version. That said, you can still use the “old” map control that has Bing Maps as a base layer in your Windows Phone 8 application. Keep in mind though, that the control is deprecated.
Create a new project
First of all create a new Windows Phone 8 project and add the old Maps control as a reference to your project. You can find the assembly in the WP SDK folder here C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Libraries.
Add maps control to view
The view, where you want to add the map, needs the following references in the header. Please pay attention to the correct paths as you need to reference the “old” map control and not the new one with the Nokia base layer.
The next step is to add the actual map control to the view, by adding the following xaml into your view.
By default the map control supports all the known features of a map control like navigating the map, zooming and pinching, and displays the Bing Map as a base layer.
Implement custom base layer as TileSource
In order to change the underlying base layer and add a custom one, we need to create a custom TileSource that maps the request from the control to the Google Maps URL Scheme. The Map control cannot load all images for all zoom level for a given position. Therefore the layer is divided into map tiles. The control calculates how many map tiles it needs to display the current map section and requests each map tile individually from the base map provider. In our case GetUri gets called for each map tile with different values for x and y. The zoom level stays constant for a given section of the map as the zoom level is the same.
Special binding for base layer
The last piece is to swap the base map provider from Bing Maps to Google Maps. To accomplish this, I’ve created a special binding class that binds to a TileSource implementation on the ViewModel. This way it is very easy to change the base map provider again, as we only need to implement a new TileSource and change the type of the bound property on the ViewModel to the new implementation.
The Binding Helper is listed below.
To bind to the map, please change the xaml in the view to the following.
Make sure you create a ViewModel, bind that to your View and have a property called GoogleMap in your ViewModel that is of type Google – the type of the custom TileSource implementation.
In our implementation we choose Google Street as map type. Google offers Satellite, Hybrid and others as well. You can change those by swapping the map type in the constructor of the Google Map TileSource implementation.
Adding another base layer
Google Maps is not the only publisher of Web Mapping Service (WMS). Openstreetmap offers a service as well. To integrate openstreetmap as a base layer, use the implementation below and change the used TileSource in the ViewModel.
In my last post I describe what we experienced during 2012 having an app – traXs – in the Windows Phone Store. We can summarize it with the following points:
There seems to be no correlation between app price and app downloads.
The download rates are too low for us to support further development.
We need to change the business model behind the app.
The basic question is why are the download rates so low? The reason for that might be nobody is in a need for that app. Or the people that do have a need don’t find the app in the store, are not willing to pay the price, or don’t find the app attractive enough to pay for it and may go with a competitor product.
As Hal Berenson mentions in his addition to my last post on his blog, he tried to find traXs on various channels. On the Windows Phone Store Page the app is listed as number 47 when you search for the search term “expense tracking”. Most of the other apps in front of traXs have more ratings. If you search for “travel expense travel” it is number 5 as of today. Unfortunately there are not a lot of search criteria you can specify other than the search term. You can’t slice the results by the different categories like Personal Finance, Business or Travel. If I look in the store on my phone though, I find traXs being number 6 when searching for “expense tracking”. I wonder where the difference between phone and web store results lies.
Searching on the web is another story, although I don’t believe people are actually looking for apps on the internet. Instead they scroll through the stores on their phones. But nevertheless, people suggested me, having an internet presence in this market as being very important. I created one, when you look at my last post – app.net, facebook and general webpage. When searching on Bing for an expense tracking app for the Windows Phone with the search term “Windows phone app expense tracking”, the app is not existing as I couldn’t find anything related to the app on the first 10 pages. The same applies for a search on google.com.
To summarize it up, it is pretty hard to even find the app. Even if the app shows up on searches it is too far down the line. People don’t bother scrolling down after the first 2 pages.
One way to fix that is too increase review numbers and download rates as I am pretty sure Microsoft’s search algorithm takes those two variables into account. Another way of improving discoverability is to choose better search terms. The store allows you to specify 5 different search terms and a category. I chose Personal Finance as category and expense, budget, travel, expense tracking, money as search keywords. Do you think I should change them? There are basically 2 strategies to follow: either you select the most obvious keywords and hope your app is distinguishable from the huge competition or you chose more uncommon keywords to reduce the competition as less competitive apps will show up on those searches, however the app won’t show up as many times overall. We decided for now to go with the most common keywords and get into the competition battle with all the other apps.
Once someone clicks on the app page on the phone or on the web, they need to be persuaded to buy the app. Although the description and screenshots are important, I think reviews and ratings even count more. If an app does not have any or only a few reviews in comparison with the competition, the user is not going to buy or try the app at all. I’ll come to the try-part later. It’s a chicken and egg problem. If you don’t have reviews, people aren’t going to buy the app; if people don’t buy the app, they aren’t going to review and rate your app.
Does the trial-concept work? Do the people understand the concept? We as developers may understand what it means, but I don’t think general phone users appreciate the concept of trials. It’s not only to blame the user, the store does not emphasize the concept as well. The general list of apps lack an indication for apps, which support trials. For the user an app either is for free or paid. There should be a little icon or overlay telling the user that this particular app supports a trial mode.
A different road to take: Ad supported version
Apart from a paid model, the ad-supported road is becoming a heavy taken one for most mobile developer across all mobile platforms. It’s a question whether advertiser or consumer pay more. The Windows Phone Platform offers with the Microsoft Windows Phone Ad SDK an easy way to integrate into the Microsoft Advertising portal.
One road we considered was to publish the app as free with ads placed at the bottom of all screens. Since Windows Phone 8 supports In-App-Purchases it would be possible to remove the ads for a fee. That way we maximize user reach by having a free app with a lower barrier of entry for a user as users are more likely to download the app and try it for free before paying for it. Although that road sounds very appealing, we don’t want to give up on the paid model just yet. Lately a lot of developers seemed to give up on the paid model completely.
Implication for traXs
The main message when we talk about increasing download rates for a paid app is by increasing it’s discoverability in the store. Ratings, reviews and download rates seem to have a huge impact on the ranking. In order to increase the reviews we put traXs on sale for a limited time only just now. This way, we hope to increase download rates and get more reviews and ratings.
At the moment we’ve got 1 rating and roughly 30 downloads. That’s 3% at the moment. To increase this ratio we ask the user to review the app in the store after a certain number of uses. If a user already used the app for more than one or two times, he is more likely to give the app a better rating. From an implementation point of view, we leveraged the Telerik Windows Phone Control set as it already contains this functionality out of the box.
So go to the store, give the app a try and let use know what you think. If you like a feature, let others know by writing a review. For all the features you don’t like, leave a comment.
In the beginning of 2012 we were all exciting about the improvements Microsoft made to the Windows Phone story, the development and the marketplace. The devices were getting pretty good with the Nokia Lumia 900 being a pretty good flag ship device. Developing for Windows Phone seemed pretty straightforward and the marketplace seemed to get some traction finally.
So it was time to make a foot into the market. We started scratching our heads about app ideas. After a couple of weeks we came out with the idea for a travel and business expense app that lets you keep track of your expenses and gives you a simple and fast process already built in. It also supports sharing expenses via email and uploading them to SkyDrive. An interesting new way of thinking about your expenses is when you give them a location. So we added that as well. A feature to break away from all the other expense tracking apps is our nice chart.
In September of 2012 we released version 1.0 of traXs. Our initial Business plan was to position traXs as a high premium application along the lines of apps like 1Password. The app used to be priced at $2,99. Unfortunately we did not see enough downloads to support further development so we reduced the price over the course of 2 months in steps down to $0,99. As you can see in the chart below, there is absolute no correlation between downloads and price.
The charts includes all application types including paid, trial and beta downloads. It gets really frustrating when you look at the chart below that only includes paid downloads.
It seems no one is willing to pay any money for an expense tracking app or the trial features are sufficient for most people.
How are the financial details about building an app for the windows phone store
From a financial point of view the development tools are free with Visual Studio for Windows Phone being free. Microsoft restricts submissions to the Windows Phone Store to only approved Windows Phone Store Developers. To become one of those you need to pay a license fee of $99 per year. As we wanted to get the app out to door fast and rely on controls that have been built with high quality to reduce the risk of having a buggy or sluggish app, we decided to buy the Telerik RadControls for WIndows Phone. The control suite is another $99 per year. Apart from our time we invested a total of roughly $200 in the app. The revenue after 3 months is 0 though.
Updates to push the market
Over the course of the last 2 months we had 2 significant releases.
Version 1.1 included an improved About page and several bug fixes.
In Version 1.2 we added the ability to search for expenses, added an autocomplete box for the notes and fixed several bugs as well.
In retrospective the new features did not push any app downloads.
Dude, you need marketing
Most of the responses we get from people talking about those problems are to invest in marketing, having paid adds on relevant portals or in add markets.
First we created a Facebook fanpage that is suppose to be a single home for all the fans of the app. Apart from some friends of us not a lot of actual customer are ready to like our page. Does it look that bad? We have regular updates and try to be as reachable as possible.
Besides Facebook we took the opportunity to get a nice introduction video shot that shows most of the features in an entertaining way. Its up on youtube.
Another channel was Telerik – a provider for Controls for the Windows Phone stack, which we use in our app. Telerik featured our app on their page as well.
As a result we can clearly say that the Windows Phone Story so far did not work for us. One reason might be that our app idea just isn’t working, the app itself does not fulfil the needs for a larger audience or people never found the app itself.
In the next post we are going to dig a bit deeper into the consequences we choose going forward.