"House Ads" vs AdDuplex

Microsoft has recently released what it calls "house ads" these are a way to promote one of your apps from within another.

This might sound very similar to what's possible with AdDuplex* so let's look at the similarities and differences between the two.

House Ads are a way of having PubCenter show ads for your other apps if it doesn't have any paid ads to show.

AdDuplex is a cross promotion network that allows you to show ads for other apps and in exchange they show ads for yours.

So, you see, there's similarity in that they both allow you to show ads for your apps.

Let's look into the similarities and differences in a bit more detail though.

Similarities

• Both are free for developers to use and integrate
• Both support integration with Ad Mediator and AdRotator
• Both work well as a fall-back for when no paid ads to display
• Either could be used on their own to just show non-paid ads
• Both must have a network connection to be able to serve ads.

Differences

• House Ads only works with PubCenter - some people don't like this
• House Ads is a Microsoft product - some people take comfort in this (knowing it's from a big company). AdDuplex is independent and grew out of the community.
• House Ads Provides a mediation capability without having to use a mediation/rotation tool.
• House Ads are capped (at 5) per user per day so users won’t experience "ad fatigue" from seeing the same ad repeatedly - AdDuplex doesn't need this as it has a wide variety (1000's) of apps to show ads for
• House Ads can only be used by accounts that have multiple published apps. AdDuplex can be used even if you only have one app in store/
• House Ads are only available in limited markets (http://advertising.microsoft.com/en/blogpost/129472/microsoft-advertising-blog/announcing-new-capabilities-for-developers-to-promote-their-windows-and-windows-phone-apps) - AdDuplex can be used anywhere.
• House Ads may be prioritized over paid ads from other ad providers - AdDuplex gives you greater control over this (via Ad Mediator or AdRotator)

So, which should you use?

Simple. Use whatever is best for you, your circumstances and your apps.

My personal opinion:

If House Ads are available to you, then, if you’re already using PubCenter as part of your monetization solution with an existing successful apps and you’re about to launch something new that will appeal to the users of your existing app then House Ads are a good tool to use while your new app is still gaining traction.

For all other scenarios and as a final fall-back in addition to using House Ads in the above scenario, you should always include AdDuplex as part of a multiple ad provider strategy.

* Disclaimer: I'm an advocate forAdDuplex which means that I'm paid (a small amount) to talk about them - but all opinions are my own. Don't be fooled though. I believed and talked about them in a positive way before I became an advocate. That's one of the reasons I became one. If you question my objectivity I'd love to hear why.

Pricing apps in the Windows App stores

Earlier today I tweeted this:

Are you selling you mobile app in Russia? Have you upped the price to reflect the falling value of the Ruble? #wpdev #windev
— Matt Lacey (@mrlacey) December 17, 2014

It prompted some discussion on how the store adjusts prices between different currencies and how often these are adjusted to reflect changes in exchange rates.

Some discussion of this has already started on twitter (feel free to carry it on there or in the comments) but I wanted to share a bit more than I can fit in 140 chars.

Let's look at how the Windows Store translates prices at the moment.

The lowest price tier is 0.79 USD or 0.99 GBP which the store translates as 34.00 RUB

However, right now, Google says that 1 USD is worth 64.59 RUB

That means that the 34 RUB you get for a sale in Russia is really worth 0.53 USD

This may mean that you're getting much less for sales of your app in Russia than you are expecting.

If you've set your price based on the cost per user this may seriously matter to you. Getting new user (in Russia) could end up losing you money!

On the plus side, this means that your app just got cheaper for people in Russia. Maybe you're considering this an early Christmas present for them ;)


The solution: increase the price in Russia.*

The take away (for everybody even if you;'re not selling a lot in Russia) : If you're business is based on selling in multiple countries then you need to keep an eye out for large, rapid changes in exchange rates.



* If you want to adjust the price in an individual country see http://msdn.microsoft.com/en-us/library/windows/apps/hh694062.aspx

Why using just one ad provider is being foolish

So, you've built an app and now want to make money from it. That seems a reasonable desire.
For whatever reason (hopefully strategic, but often for simplicity) you decide to put ads in the app as a way for making money.

All that's good but here's a common mistake developers often make. They only use a single ad provider.

Here's why that's a mistake.
No ad provider will have ads for you to show all the time. No traditional advertiser will always have an advert for you to show every time you request one. This is known as the fill rate. It's typically shown as a percentage and is the number of ads delivered divided by the number of adverts requested.

There are variations by country, user and type of app, but for most mobile advert providers, to get a fill rate of 40% from a global app is very good. It's often common to see rates as low as 10%.
That means that for every 10 times you want to show an advert (and be paid for doing so) you can only show (and be paid for showing) between 1 and 4 adverts.

There's a simple solution to this though. When one ad provider doesn't have an ad to show, "fall back" to use another ad provider and ask them for an ad. And so on and so on.

Fortunately there are tools that can help you do this. The two main ones in the Windows world are AdRotator and Ad Mediator.
Both will let you specify a list of ad providers to use and the order in which they should be contacted.

Here's how Ad Mediator visualize the process:

This is all well and good, but what about when none of the ad providers you're using have an ad to show?
There are no traditional ad providers who always have an ad for you to show (100% fill rate) and even when you integrate all the advertising providers there are there will still be times when none of them have an ad for you to display.

This is where AdDuplex comes in. AdDuplex* are different from traditional app ad providers in two key ways that are relevant to this conversation.
Firstly, they do have a 100% fill rate. They will always have an ad for you to show. (Subject to network connectivity - but then if the app can't connect to the web then all bets are off.)
Secondly, they don't pay you for showing ads. When we're discussing making money from showing ads this might seem like a big issue though. But consider the scenario: None of the ad providers you use have an ad to show, so, rather than letting the space in your app where you would show adverts go to waste you can use it for something else. You can use it to promote your app. This is where AdDuplex is different. It is not a traditional advertising platform, rather it's a cross promotion network. You display ads for other people's apps in your app and they show your ads in theirs. It works on a simple exchange basis. For every 10 ads you show, 8 are shown for your app(s) and the other 2 slots are sold to fund the service.

This is the key then. If you've got space in your app that you have dedicated to displaying ads with the aim of making money then if there are no paid for ads to display, use that space to promote the app itself. This will help you grow the number users of your app and, in turn, the number of paid for ads you can potentially display in the future.


If you're not yet using AdDuplex but wish to start, then register using promo code:
ML10-1OFKNH and you'll get an exchange rate of 90% (compared to the usual 80% for the first 6 months)

If you are putting ads in your app you should be using a mediation or rotation service that includes use of AdDuplex.



* Disclaimer: I'm an advocate for AdDuplex which means that I'm paid to talk about them. Don't be fooled though. I believed and talked about them this way before I became an advocate. That's one of the reasons I became one.

At the end of a bad conference session...

I've been thinking about feedback to speakers at the end of a session.
I'm currently at NDC London and at the end of each session they use a traffic light system to provide feedback. If you liked a session you put a green card in. If you didn't like it or thought it was bad you put in a red card and if you are somewhere in the middle you put in a yellow card.

Here's the thing though. With multiple sessions on at the same time, what are you saying by staying to the end and then putting in a red card?
Yes, it's good to provide feedback to the speaker and organiser if you didn't think the session was very good.
But why would you stay to the end of a session you are not enjoying or don't think is very good? Vote with your feet. If you're not enjoying something or benefitting from listening then go to another session.
If you stay to the end and leave a bad review aren't you saying something about yourself in addition to what you're saying about the session? What does it mean to say "I didn't find this useful or enjoyable, but chose to stay and listen to it all"?

Additionally, providing feedback via a voting system is good. But providing more detail is better! Whether your feedback is positive or negative please share it with the speaker and organiser. Events are organised and speakers speak for the benefit of the people who attend and listen not for the ego of the speaker. By providing constructive feedback you can help the speakers do a better job in future and allow organizers to ensure that session abstracts match what is wanted and delivered and that it benefits the audience and matches their expectations.

100 developer events that wouldn't have been the same without me!

Tomorrow I'll be speaking about Mobile app security at NDC London. Not only will this be the biggest developer event I've been involved with it'll also be the 100th.

Yes, I've spoken at or organised 100 developer events.

There are also many dozens that I've been to as an attendee, I just haven't kept track of all of them.

Here's how it breaks down:

• Organised and hosted DevEvening 27 times
• Organised and hosted WPUG/WinAppsLDN 48 times 
• Spoke at or hosted events organised by other people 25 times, in: Aberdeen, Birmingham, Bournemouth, Bradford, Bristol (twice), Dundee (Twice), Edinburgh, Glasgow, Gloucester, London (five times), Newcastle, Norwich, Reading (twice), Southampton, Taunton, Telford and Woking (twice).

With an approximate average audience of 50 people that's an awful lot of developers I've helped to build better software. Most of which has been related to creating apps for Windows and Windows Phone.
I want to build great apps and that's made possible by learning from and with others who are also building apps. That the only way opportunities for developers to meet and learn from each other is if I put the events on is by-the-by. It's not just all about me though. I know the ecosystem benefits when more people build better apps and that's what we all want--as it benefits everyone, not just me.

I'm not very good at self-promotion. That's partly the reason for this post. It was more that I just wanted to mark this milestone .
I'm quite happy not shouting about all I do. I put the time, effort and energy into promoting the events to people who may be interested in coming. If you ever find me talking more about how great I am for putting on events (or running a user group) rather than taking the time to actually put on events, please call me on it.

At a time when it seems community events stopping and organisers stepping down is becoming a regular occurrence I can only say that I haven't got any plans of stopping soon. Getting to 200 events is more than I'm thinking about at the moment. For now I'm just focusing on all the exciting things planned and being planned for 2015.

;)

What does it mean to "Advertise before you monetize"?

If you weren't aware, one of the slogans for AdDuplex is to "advertise before you monetize". But what does this mean?

If you've built an app with a view to making money from it, there are two basic options for you.

(There are other options but I'm just looking at the simplest ones here as these are what most developers use.)

Firstly you can charge people directly for using the app. They either pay once, up front, for it (possibly after a trial period) or on a recurring basis. Either as some form of subscription or through the repeated purchase of in app/game consumables or access to more functionality (or levels).

Alternatively, you can indirectly monetize the app based on selling access to the people who use it. This may sound like a strange description or one you've not heard before but that's what you're doing when you put adverts in your app that you are paid for on a CPM basis. From a user/consumer perspective you should be aware that if you're not paying for something you're probably the product.
It can be summed up this way: If people aren't paying to use the app you force them to look at something (an advert) that someone else has paid (or will pay) to show to them.

It's if you're considering using the second approach that the idea of advertising before you monetize is relevant.


If you're income is based on advertising then it's the number of people using the app, and therefore looking at the ads that matters to you.

A common thought process is that having spent time building an app it would be nice to see some return as soon as possible.
There's a problem with this approach though:
You're trying to monetize a small number of users but for advertising to provide a good return you need a large number of users.

This is where the intent behind the AdDuplex slogan comes in.

Rather than using the advertising space in your app to show adverts that you are paid for, use it to help you promote your app and get more users.

This is a great way of integrating the AdDuplex control within your app. You put the control in your app and rather than be paid for showing ads, you exchange the ads you display with adverts for your app being displayed in other apps.

In time, once you have a large number of users for your app you can start to introduce paid adverts as well. Using AdRotator or AdMediator you can have a smart solution for combining paid ads when the provider has one to show, and AdDuplex ads for when the ad provider doesn't have an app to display. This combines the opportunity to make money from adverts and promote the app and get new users so you can make more money in the future.

If you're not already using AdDuplex and would like to start. Email me (adduplex [at] mrlacey.co.uk) and I'll send you a promo code, to use when registering) so you can have even more of your ads shown.

How to add a Twitter feed to your App Studio app

I've recently released an app for the UK based charity Toilet Twinning. I wholeheartedly encourage you to support the work they do and twin your toilet now. This post is based on lessons from building that app.

The app started life in App Studio but I wanted to add the ability to show tweets from a specific account in the app. I was surprised that this functionality wasn't built in. I was further surprised that there wasn't good documentation anywhere to help add it.
This post is an attempt to address this and show how to add a twitter feed to an app studio app,

If you've looked into trying to do this before you may have discovered that there is a video recorded as Build that shows a way of doing this. You'll find it at http://channel9.msdn.com/Events/Build/2014/2-565 The downside of this is that it is more complicated than I needed and only a small amount of the code is available (at
http://blogs.msdn.com/b/rido/archive/2014/04/25/app-studio-build-session.aspx).


The following uses no third party libraries and is done entirely in Visual Studio. It allows adding a list of tweets by a named user to be displayed in the app without requiring a user to log in. If you wanted it to display a search term, such as a hashtag, then minor modifications would be needed but they aren't documented here.

The twitter API requires that all requests are from an authenticated source. While you may typically have a user authenticate, in this case the app is the what is authenticated, using Application-only authentication. This provides access to limited API methods but is sufficient for our needs. If you wish to know more see https://dev.twitter.com/oauth/application-only

To integrate with Twitter you first need to create an app entry on the Twitter website.

• Go to https://apps.twitter.com/
• then click "Create New App"
• You can add any website value if you don't a suitable URL right now. Just remember to come back and replace it with the Store link later.
• You don't need to enter a callback URL.
• After accepting the terms and creating the app entry, go to the "Keys and Access Tokens" tab.

This is where you'll get the values for the "Consumer Key" and "Consumer Secret". You'll need to add these to TwitterDataSource.cs later.
Leave the permissions as "Read-only".

Please note that the values in this image are no longer valid for anything. Don't waste your time trying to check for security holes. They are for an app entry that no longer exists and won't work. ;)


We now need to modify and add some files to the solution. You'll find all the changes at https://gist.github.com/mrlacey/1cd1f7a0049c69eb774f but we'll also step through all the individual changes.


To add the details to both the Windows and Windows Phone project we need to add or modify 10 files:

1. Firstly we need a ViewModel to handle the retrieval of data and passing it to the view. Create AppStudio.Shared\Views\TwitterViewModel.cs (from here).

2. The ViewModel has to get the data from somewhere so next we need get the data, so we a data source.  Create AppStudio.Data\DataSources\TwitterDataSource.cs (from here)
It is in this file where we need to set the three constants that are used. The first is the username of the account you want to show the tweets from. The next two are the application API values highlighted above.

3. The data source needs something that will provide it with the data from the twitter API. Create AppStudio.Data\DataProviders\TwitterDataProvider.cs (from here)

4. The provider will return a collection of strongly typed objects. So we need to define the schema of that object. Create AppStudio.Data\DataSchemas\TwitterSchema.cs (from here)

5. Now we've got the data back from Twitter and into our ViewModel we need to tell our MainViewModel about it. Update AppStudio.Shared\ViewModels\MainViewModel.cs with the instructions here.

6. We now need to think about how the data will be displayed. We'll be using resources to define the templates we use in the views. We need to add a reference to the shared app resource (AppStudio.Shared\App.xaml) as defined here.

Let's update the Windows Phone project first.

7. We need to add a new hub section to the main page (AppStudio.WindowsPhone\Views\MainPage.xaml) that will look like this.

8. Then we need to add the resources we defined in the shared project and use in the new hub section. Create AppStudio.WindowsPhone\Views\DataTemplates\TwitterViews.xaml (from here)

Now let's update the Windows project.

9. Again, we need to add a new hub section to the main page (AppStudio.Windows\Views\MainPage.xaml) that will look like this.

10. Finally we need to add the data templates used by the view. Create AppStudio.Windows\Views\DataTemplates\TwitterViews.xaml (from here)


And with that we're done.

An important point to note is that when submitting your app to the store and using the above code, there is an extra consideration you need when submitting the Windows version.

In the cryptography section there are specific declarations you must make as credentials are encrypted and passed over SSL to authenticate with the Twitter API.

Assuming you're not doing anything else involving encryption then you just need to select "Yes" for both questions. Check the box if you can confirm the distributability of your app as asked. If you have other encryption in your app or questions about the legal consequences of using encryption in your app then seek appropriate legal advice.

An important note if you want to update this code and change what or how it's displayed.
As part of the terms and conditions of using twitter and integrating it within your app there are specific requirements about how you display a tweet. You'll find these at https://dev.twitter.com/overview/terms/display-requirements. Consider these carefully before you decide to modify how individual tweets are displayed.


Additionally, if you're interested in improving App Studio apps in other ways you should check out this related blog post.

Making an App Studio app better

I've recently released an app for the UK based charity Toilet Twinning. I wholeheartedly encourage you to support the work they do and twin your toilet now. This post is based on lessons from building that app.

The Toilet Twinning apps were built using App Studio. In the past I've been very critical of apps built this way as most of the ones I've seen have been of what I'll politely call a "less than perfect" quality. Evaluated against some of the older store requirements (that were originally intended to improve app quality but have since been removed to simplify the submission process) many of these apps would not get into the store.

Here's a list of things I did to improve the apps. Hopefully, if you're building an app with App Studio, you'll be able to apply some of these changes to your apps and improve them too.

• I originally included an Instagram section in the app to show related images. Unfortunately the search functionality stopped working shortly so I removed the related pages and hub sections.
• The Windows Phone app did not include scaled versions of the images in the assets folder. So I added them to get a better visual experience on phones with larger screens.

• In the Windows app it didn't include a placeholder for the 310x310 logo image. But it did include them for all other logo images. So I added it and was therefore able to support all tile sizes.
• I had to remove the, pointless, default tile updating behaviour which just replaces the tile image with the one from Shared/Assets/DataImages/FlipSquareTile.jpg. All this did was replace one image with another. Always the same one and with no extra information. Updating a live tile with new information as it becomes available can be a great thing to do. But this didn't do that. I've made a note below that adding a background agent to have some useful, new, information added to the live tile would be a great future enhancement to the app.
• Added a placeholder for images in the list while they are loading or to be displayed if there is an item without an image.
• Replaced the trivial default caching behaviour. What good is a caching data provider that when it tries to refresh and there's no network connection it deletes the data it does have and so shows nothing? Or a cache that only keeps data for 2 hours even if it is updated much less frequently. I replaced the caching behaviour with something smarter. It now keeps older data for much longer by default. It will always show data if it has some, even if it's not able to load any new data. 
• I've also simplified the logic around attempting to load data. Always loading data every time that the user navigates back to the main page seems like overkill. Open app > Load data > tap on item > tap back > reload all data > tap on item > tap back > reload all data (again) > tap on item > tap back > reload all data (yet again). It seems a bit unnecessary. Loading only when it's likely to have changed seems much more sensible. I opted to do this only when the user returns to the app. OnNavigatedTo in MainPage now contains this:
  await MainViewModel.LoadDataAsync(e.NavigationMode != NavigationMode.Back);
• Thinking about offline support. I added an indicator when there is no network connection available. After all, if there's a good reason why the app can't load any new data it makes sense to let the user know.
• On each of the hub sections I moved the progress bar used to indicate network activity/loading so that they appear above the items, not behind them.

• The default formatting for the blog template that I chose was poorly designed such that the right edge of text was clipped. See in the green rectangle below.

In that I want the text being displayed to actually be readable by the person using this app. I fixed this issue with widths and margins. I also adjusted the spacing and margins so that an extra line of text is visible. It now looks like this:

• When looking at an individual item from the blog / RSS feed there were other improvements to be made. The original output from the tool looked like this:

But with a few changes was made to look like this:

There are 5 changes here: made the system tray transparent; removed the unnecessary and not fully visible app logo and title; reduced page margins; reduced paragraph spacing; and increased the size of the image. There's more that can still be done with RSS content formatting but this is a definite improvement

• There was also a subtle issue I fixed that is experienced when swiping between stories/items. If there are multiple items that are long enough to be scrolled and one is scrolled down. Then if you swipe to the side 4 times you will find that you get to an item that is not at the top but already partially scrolled. Almost certainly not what you want but easy to fix. Every time the selected item in the FlipView is changed, walk the visual tree to find the ScrollViewer and have it scroll back to the top (VerticalOffset = 0).
• On the Facebook hub section there was again more work to be done to tidy up the margins, spacing and text formatting and clipping of text on the right and bottom edges. This is not ideal:

It also doesn't make sense to trim the title at the expense of body detail content. This looks much better:

• For the Facebook details page, similar changes were made as for the blog details page.
• On the YouTube hub section there was again a need for a bit of finessing of the basic layout but there were two bigger issues. Firstly, even though a large image is used in the item template the image displayed is actually very small and scaled up leading to a blurry image being shown.

Fortunately the details that the YouTube API returns include a variety of images at different sizes. With this knowledge I changed the code so that it uses the largest thumbnail image available, not just the first in the list. This lead to no blurring in the image (click to view full size)

• The second big issue I had was that the search for my desired search term "Toilet Twinning" was returning some completely unrelated item. After a little exploration I realised that this was because the search term wasn't being used in quotes. This meant that the server was also returning videos that match on the individual words also. As I don't want to show general videos about twinning (or toilets), it's necessary to make sure the term is encoded in quotes. Unfortunately the web site doesn't allow this.

As it seems that encoding values entered in a URL is too much for I manually edited YoutubeDataSource so it now includes
private const string _url = @"https://gdata.youtube.com/feeds/api/videos?q=%22toilet%20twinning%22&orderby=published&start-index=1&max-results=20&safeSearch=strict&format=5&v=2";

• Again the YouTube details page needed some refining. The strangest being the removal of the hard coded string "Detail" at the top of the page. I can only assume that this was there as the result of an error in App Studio.

• I added another hub section to show the tweets from the @toilettwinning account. For details of this see the link at the bottom of this post.
• The final hub section originally contained HTML content. I replaced this with the direct XAML equivalent as the HTML version prevented horizontal swipes from navigating the hub control. This could be frustrating for users as they swipe through the hub but find the the gesture they're doing suddenly stops working.
• Many of the above changes shown in the Phone app were also made in the Windows one.
• Additionally, in the Windows app I removed space reserved for back button on the main page - as the back button will never be shown there
• On the Facebook detail page in the Phone version, it originally used a purple colour for hyperlinks. This was sometimes very hard to read on the background so I changed it to be white like in the Phone version.

That's not the end though. There are still other things that can be done to improve the app further.
Here are some ideas:

• Default data for when first run and a better first run experience
• Add a FAQs page directly within the app to explain more about the charity without needing to redirect to the website
• Add a background agent to update the tile so new content can be seen without having to open the app
• Add image caching so that images can be viewed with the other offline content.
• Improve the HTML parsing to improve the display of content
• Improve the display of images to better scale and stretch images with consistency but still coping with the variety of images sizes to display.
• And probably many more things. Got any suggestions?

Hopefully I'll be able to add at least some of these to the app soon.


If you're building an app with App Studio and wish to add a Twitter feed to it, I have another blog post that explains how to do this.

Combining app development and trying to make the world a better place

For a long time, I've been thinking about how app developers, myself in particular, can do more to help make the world a better place. Building apps is all well and good but I often feel that simply having more apps in the various app stores isn't really helping anyone.
Couldn't we do more to help make the world a better place?

It's a potentially noble but quite a grand goal. So I decided to try and simplify things a bit and trying to do something with my limited free time and the other projects I have on at the moment.
Realising there are many organisations already doing lots of fantastic work to help make the world a better place, my thoughts turned to supporting them rather than trying to start something all by myself.

In terms of supporting a charity through app development I see three available options:

1. Build an app that directly supports the work
2. Build an app that makes money that can be donated
3. Build an app that raises awareness

Option 1 could be appropriate if directly tied to the work of an organisation. For example, this may be appropriate if having people look at images to identify patterns or objects or by using the processing power of the device to perform work that helps the charity directly. Such effort requires working closely
Option 2 is best suited to games. Not being a game developer I passed on this option.
This left me with option 3.
But which charity to support?

A few years ago I was working for a company and our office was in a large building housing many other companies. Our office was in one corner of the floor and the toilets were at the far side of the building. To get from my desk to the toilet meant going through seven doors, two of which were security controlled and required an electronic key to get through. A first world problem I know, but this really bugged me.
At least it did until I heard about Toilet Twinning.

When 2.5 Billion people don't have access to a toilet I felt bad about complaining about the minor inconvenience I experienced when I had to go.
Rather than just striving to not feel bad about my first world problem I wanted to do something practical to help and remind me of the fortunate position I'm in. So I twinned my toilet. I got this nice certificate and they got funds to "enable people living in poor communities to have clean water, a decent toilet, and to learn about hygiene – a vital combination that prevents the spread of disease, reduces the number of deaths among children, and brings hope for the future."

Here's the certificate, resting on the toilet I twinned.

It's something I should have been aware of more as I'd used the statistic that more people have mobile phones than access to a toilet in talks I've given in the past.

So, when it came to me thinking about which charity I'd like to help raise awareness for Toilet Twinning were my first thought.

Wanting to be respectful of IP and copyright and not wanting to use someone else's brand without permission or potentially duplicate anything they already have planned I contacted them (via their website) to see if they were happy for me to build something.
To be honest I wasn't expecting a response. If one came I could probably fit in the work around other projects and if I got no response then I'd have eased my conscience for a bit.

However, a few weeks later, when I got back from the Native Summit conference, all fired up by the talk by Mike Lee about developers doing more to improve the world and not just building more and more apps, I had an email from Toilet Twinning saying they were happy for me to build them an app. Taking this as a well timed sign as something I should get off my butt and do. I have.

I've found a bit of time over the last few weeks to fit this in and the apps are now available in the Windows and Windows Phone stores. See links below.

This story doesn't stop there though. If you know me or have read this blog for a while though, you may know I don't just want to make great apps myself, I want to help others build better apps also.

With this in mind, I wanted to combine building the Toilet Twinning apps with doing something that could help other developers improve their apps too.

Having been critical of apps built with App Studio in the past I took this opportunity to use it to build the base of the apps and then document all the issue I found (that many developers simply ignore) and how I addressed them so that others can improve their App Studio built apps too. I have a blog post explaining all this here.

In using App Studio to build an app that aggregates data from external sources, most of which are social networks, I was surprised to see that integration with Twitter was not supported. As I wanted this and I suspect many others would use it if it was available, I have also created a blog post that explains how to add twitter integration to an App Studio app and this is available here.



Get the apps now

and

Amazon are willing to pay £5 for details of my Facebook friends

<JustWondering>
I got this email last week:

Glossing over the fact they ignore our 16+ year relationship and can only address me as "Amazon.co.uk Customer".
I don't think I can recall another business being so transparent about how much access to my Facebook data is worth.

Exactly what data?
We'll, here's what they want to know:

So, that's my details, plus my friends details, their birthday's and their likes.

Wow. At the very least, Amazon think they can make more than £5 extra in profit by being able to remind me that my friend has an upcoming birthday and suggesting things I can buy for them as a gift.
Plus many more things as well no doubt.

Yes, there's a potential benefit of potentially improving relationships by helping make sure I don't forget a birthday and making it easier for me to give (send?) them an appropriate gift based on their likes.
However:

• Do I really need yet another service sending me emails about peoples upcoming birthdays?
• Am I really likely to need the present suggestions for my close friends?
• Based on Amazon's ability to mine large amounts of data, what will be the long term consequence of me giving them this Facebook access?
• Is £5 really enough to get lots of people to sign up to this? If not, then I wonder how much would be?
• Do people look at an offer like this and think about the data security implications? Or do they just think "free money"?

</JustWondering>

Windows, Windows Phone, App Studio, Privacy Policies, Certification and legal responsibilities

At some point, probably in the not too distant future, the privacy of app data is going to become a seriously important issue. Some country or another is going to suddenly clamp down hard or a developer who should have known better is going to do something silly and end up getting taken to court and made an example of.

Why am I saying this?
Because I've been thinking about privacy policies and how they are referred to in apps created with App Studio.


In case you are developing apps and didn't realise it, you almost certainly need a privacy policy for your app.

If your app connects over the internet you definitely (supposedly?*) need one for it to be certified in the store.

App policies for Windows Phone 2.8.1

If your app has the technical ability to transmit data to you or a third party, you must maintain a privacy policy. This can be hosted within or directly linked from the app. The privacy policy must be accessible from your app at any time. App capability declarations that make your app network-capable include: internetClient, internetClientServer, privateNetworkClientServer, and ID_CAP_NETWORKING. Your privacy policy must inform users of the personal information accessed or transmitted by your app and how that information is used, stored, secured and disclosed, and describe the controls that users have over the use and sharing of their information, how they may access their information, and it must comply with applicable laws and regulations.

App certification requirements for the Windows Store

4.1.1 Your app must have a privacy statement if it is network-capable
If your app has the technical ability to transmit data to you or a third party, you must maintain a privacy policy. 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.
App capability declarations that make your app network-capable include: internetClient, internetClientServer and privateNetworkClientServer.
Your privacy policy must inform users of the personal information accessed or transmitted by your app and how that information is used, stored, secured and disclosed, and describe the controls that users have over the use and sharing of their information, how they may access their information, and it must comply with applicable laws and regulations.

* I say "supposedly" because this isn't checked or enforced.

In that the store's have a space for the developer to enter the required privacy policy link then would it not be reasonable that when an app is submitted the URL becomes mandatory for apps which have a networking capability? (The store can easily detect his capability when an app is submitted.)

Is this a widespread issue?
Yes. Take a publisher. For the sake of an example let's look at "Microsoft Corporation". Take a look at their apps in the Windows Phone Store. For some you'll see they're breaking their own requirements and not including the required privacy policy link.

With App Studio apps (where I started this explorations) it's even worse.
For many such apps that make it into the store you'll find no privacy policy whatsoever. In the app bar there's also a "privacy" option but tapping it does nothing as they haven't added a link.

For a few apps you'll be directed to http://appstudio.windows.com/en-us/home/appprivacyterms
I'm not a lawyer (obviously) but this seems inadequate and overly vague. It doesn't even (IMHO) meet the store certification requirements for a privacy policy. At best it just defers any responsibility from any privacy related issues from Microsoft and onto the developer. It doesn't help the developer know what they should be declaring or even help them create an app without broken links in it's menu.


The app studio agreement also highlights the developers responsibility regarding the need for a privacy policy in two places:


II.1.a.3:

The Application must comply with the applicable laws of each jurisdiction into which you choose to make the Application available, including (i) export control laws; (ii) data protection, privacy, and other laws and regulations relating to collection and use of user information by your Application; (iii) telecommunications laws; and (iv) content ratings regulations. 

II.2.c:

Terms of Use and Privacy Policy. If you distribute an Application that enables access to and use of Internet-based or mobile services or otherwise collects and/or transmits user information to you or a third party, you are responsible for informing Development Partners and Application Recipients of your terms of use and privacy policy. At a minimum, you must maintain a privacy policy that (i) complies with applicable laws and regulations, (ii) informs users of the information collected by your Application and how that information is used, stored, secured, and disclosed, and (iii) describes the controls that users have over the use and sharing of their information and how they may access their information.

If you're publishing an app (including or maybe especially if it's created via App Studio) you need to consider what should be in your privacy policy.



Also though, don't you think Microsoft could and should be doing more to help developers? Most of whom are individuals who don't have the resources or knowledge to do a sufficient job in this area on their own.
It would also be nice to see the store enforcing its own policies - or at least helping flag to developers where they need to provide something, Especially when this can be done in an automated way.



I'm not a lawyer - this isn't legal advice. (It's advice to seek legal advice.)
You may (probably) need actual, bona fide legal advice for your app (business).
Seek it from someone suitably qualified. Not just some random blog! ;)

Comparing WP7 stats: AdDuplex and Microsoft

Last month, both Microsoft and AdDuplex released statistics which include figures for Windows Phone 7.X usage.
As a number of developers and companies are starting to think more about how long they continue to support WP7.x devices (I've spoken with a few recently) I thought it was worth looking at this subject in a bit of detail and to consider why the figures from Microsoft and AdDuplex are so different.

Let's start by looking at those figures.

Microsoft claim that "Windows Phone devices running OS 7.x represent less than 5% of all downloads."

AdDuplex (on slide 6) say Windows Phone 7 has a 15.2% share of the OS market.

"15.2" and "less than 5" are quite different. One is more than 3 times the other.
So why could this be?

The answer of course is that I'm not comparing like with like.

Microsoft are reporting that 5% of downloads come from WP7 devices.
AdDuplex are reporting that 15% of app usage is done on WP7 devices.


Downloads and usage are very different.

• An app is (typically) only downloaded once per user but (hopefully) will be used many times.
• Due to the nature of the apps that AdDuplex collects data from (ones that show adverts) this may skew the results in favour of devices used over longer periods of time. (Which is a factor that makes showing ads a more viable monetization strategy.)
• There is an anecdotally supported and widely held opinion that people download more apps when their devices are new. Given that anyone with a WP7 device has likely had it for more than a year I'm surprised it's still this high. (Maybe the second hand market and hand-me-down scenarios are meaning many people are still getting devices that are new to them.)

So, should you still support WP7 devices?
Let's look at some scenarios:

If you're building a new app that needs WP8 specific features then you obviously can't.

If  you're building a new app that doesn't need WP8 specific features then it comes down to considering whether the opportunity to have your app available to 1 in 20 more people is worth the effort (of development, maintenance, support, etc.).

If you have a WP7 app that you're considering dropping support for then it will come down to the potential costs and impact of any potential future problems or issues anyone using the app may have.

If you have a WP7 app that you're considering removing from the store then it will come down to whether you actively want to stop 1 in 20 people potentially downloading the app. Note that this will also prevent people from uninstalling and then reinstalling the app. I know some people use this a documented solution to some issues and so may be an issue.

If you have a WP7 app that you're considering disabling then it will come down to the potential costs and impact of stopping some people from using the app. Hopefully you've got analytics in your app to tell you this. If you haven't then AdDuplex's figure of 15% is very close to numbers I've seen for apps that have been around for about 3 years.

Of course this isn't a complete list (technical issues and commercial pressures can also have an impact) but hopefully this covers the majority of scenarios.

SVG to XAML conversion

Notes for my reference as I only do this every now and again and have to look it up every time.

[Updated]
Ignore the below.
Inkscape can export to XAML!
- thanks @AwesomeDevsigner


--------  Ignore the below, it's far more complicated than it need be --------

1. Open .svg in Inkscape
2. Save as .pdf
3. Change file extension to .ai
4. Import in Blend
   OR
   Import into Expression Design (Adobe Illustrator-PDF compatible)
5. [If in Expression Blend] Export as XAML

Why I've become an AdDuplex Advocate

Starting this week, I'm now a Developer Advocate for AdDuplex.

What does this mean?
It means you may now find me talking more about AdDuplex and I am available to help if you have any questions or technical issues.

Who or what is AdDuplex?

"AdDuplex is a cross-promotion network specifically targeted at Windows 8 and Windows Phone apps and games. It empowers developers to promote apps for free by helping each other."

You simply register and add a control to your app. The control in your app shows ads for other apps and in return the other apps show ads for your app. A few paid ads are also displayed to fund the service.

Why am I doing this?
Firstly because I believe that AdDuplex is a great service and has the potential to benefit lots of developers.
Also, because AdDuplex solves two important problems.

1. Many developers struggle with knowing where and how to promote their apps. AdDuplex provides a very simple way to help developers do this.
2. Most advertisers can't guarantee 100% fill rate. AdDuplex can. If you've got an app that you're monetising with adverts then there will be times that your ad provider doesn't have an advertfor you to display. So what happens then? Without a fallback you'll end up with unused ad space. If you use AdDuplex as a backup (AdRotator could help here) for when your other provider doesn't have anything to show then rather than completely wasting an advertising opportunity you are using it to help promote your app.

What can I do for you?
If you aren't already registered and using AdDuplex then please get in touch (@mrlacey or via 'matt [at] catchyagency [dot] com') and I'll send you a promo code to use when you register. This will give your apps extra exposure for the next six months!

If you have already registered please get in touch and tell me about the apps you've published that include the control. I'll have promotional opportunities for you in the coming weeks and the sooner you get in touch the more promotion I'll be able to give your apps.

What about other things I do?
None of that will change or stop because of this.
I'm still doing contract development work.
I'll still be organising Windows Apps London.

Book Review: Designing Mobile Payment Experiences - Skip Allums

Cross-posted from http://windowsapps.london/2014/10/13/book-review-designing-mobile-payment-experiences-skip-allums/

Back in the late nineties I worked on a system that produced store gift cards/vouchers. Fast forward to 2008-9 and I was working on mobile payments, NFC payments, stored value cards on mobiles and even custom software for chip and pin terminals. More recently I've worked with a number of banks and money transfer services to build them mobile apps. (There are more than a couple of screenshots in the book that look VERY familiar!)
All in all it's fair to say I have an interest and background in working with mobile payment solutions.
When I first heard about this book I became very interested. Mobile payment and money transfer is an area which I expect to grow considerably in the next few years and the recent announcements by Apple, with the iPhone 6, will only help fuel interest in this area and speed up growth.

The book is relatively short at just 7 chapters and a little over 200 pages but it's packed with useful information.

The first chapter starts the book by providing some background on the history of money and how and why it is used. It provides the perfect grounding for the rest of the book.

The second chapter introduces the three payment types covered in the book: NFC; Cloud : and Closed loop. The description of each of these is intermingled with a few UX notes dotted about. I think it would have been nicer to have made the UX points stand out more. As I am familiar with the payment options and their pros and cons I would have liked to see the UX tips stand out more form the text so I didn't risk skipping over them as I skimmed a paragraph about a subject I am already familiar with.

The third chapter is the first to provide some easy take-aways for the reader. It analyses the strengths and weaknesses of the design, payments, feedback and security aspects of popular mobile payment solutions available today in the US. Namely Google Wallet, ISIS, PayPal, LevelUp, Starbucks and GoWallet.

The fourth chapter is about building trust into mobile payments. It was while reading this chapter that I realized I had been reading this book with my "developers hat" on, rather than one of a designer. I think of myself as a developer who wants to understand design. I also hope that more developers take an interest in design and how it impacts what they are developing. Anyway, this chapter diverged from what I was expecting and had a strong focus on the psychology of the consumer (or person using the app). I found it really useful to have this focus and the idea of designing for the most common security concerns people have with mobile payments was explored in depth in the rest of the chapter.

The fifth chapter is about actually designing successful payment interactions. The chapter is full of useful advice if creating an interaction using NFC, Bar or QR codes, or geolocation. It even made me smile as I remembered back to building an app that displayed barcodes on an iPhone and testing it in actual supermarkets. I'm sure with the information from this chapter I could revisit many past applications and create improvements. My only criticism would be that it would be nice to touch upon iBeacons or similar when also focusing on geolocation as that would, I suspect, address some of the issues of a geolocation approach. (e.g. getting the wrong neighboring store.)

Chapter six feels somewhat of a mish-mash of topics. This is probably due to the nature of the chapter being about additional services that can be provided with a payment experience to bring a richer and more valuable user engagement. Depending on the original app or services purpose is will affect what additional services are appropriate. This chapter provides guidance on: managing finances; rewarding loyalty; offers and coupons; and travel.

The final chapter looks to the future. As Apple has such an influence in the mobile space (especially in the US - the market this book focuses on) it is right that there is talk about what Apple may do. (This includes consideration for iBeacons-as noted earlier.) Then there's speculation on what may come from MCX (the Merchant Customer Exchange) and Facebook. The chapter concludes with a look at wearable devices and bio-metrics and how they may be part of payment experiences in the future. As it's still early days for these technologies the book provides no specific guidance in using them though.


All in all a useful book. If you are, or are likely to be working with mobile payment with regard to mobile devices and apps then I recommend you buy and read this book.


There is also a website by the author that contains additional content (via a blog) and a collection of mobile wallet & payment UI design patterns: http://mobilepaymentux.com/



Disclaimer: The copy of this book was supplied for review as part of the O'Reilly User Group/Community program.

Is your mobile app as secure as you think? #NDCLondon

This December, NDC is returning to London and I'm speaking along with some fantastic other speakers.

I'll be talking about mobile security:

News stories of security vulnerabilities in mobile apps are becoming more common and their impact risks affecting more and more business and consumers. It doesn't have to be this way.
There are solutions to all the common security issues in mobile but sometimes we need to be made aware of what the issues are and how they can be prevented.
That's what I'll show in this talk.
I'll draw on more than twelve years personal experience building apps for a wide variety of industries and the accumulated knowledge of the OWASP Mobile Security Project.
We'll look at some examples of the common security mistakes apps on iOS, Android and Windows have made and then show practical examples of how to address the issues.
You'll leave this session wanting to review the security of your mobile apps but armed with the knowledge to make improvements and fix some security holes.

The conference runs for 3 days with 2 days of workshops beforehand.

If you order your ticket before Oct 15th you can also benefit from early bird pricing.

I attended the conference last year and it was great. I'm expecting that this year things will be even better!

See you there.

//publish/ again at the Jumpstart Live Hackathon

You may remember that in May, Microsoft held a series of global hack events under the title //publish/.
I was asked to help with the event and it was a very rewarding and enjoyable, if exhausting experience.

Many people came and published apps to the Windows and Windows Phone stores.
The feedback was very good and it was so popular we're doing it again.

If you can get to London on Saturday September 20th, why not come along. You'll go home with a swag bag and possibly phones and other goodies to if you submit to the store on the day.
Register at http://aka.ms/winappspublishhack.

Half a million views - wow!

According to the stats in blogger, earlier today, views of this blog passed the half a million mark.
It sounds like quite a big number so it must be a big deal. I don't know people who talk about how many people actually view their blog so don't really have anything to compare it with. I expect that there are many with fewer views and many with more though.

So, many years ago I started a blog as an excuse to write stuff. A few years I started posting mostly about Windows Phone development related topics and renamed the blog.
It was really after this point that anyone really started reading what I've written. I still just write what I want to write but I've also tried to document things I've discovered that weren't documented anywhere and may be of use to others.
It's good to know that some people have found what I write useful and interesting. It still shocks me that people at Microsoft even read this stuff (sometimes) and I've even known some of them find solutions to their issues here. You're welcome.

I've no plans on stopping writing here. I'm just going to continue writing about what I want when the mood takes me (so it'll continue to be intermittent). Do feel free to tell me if I write something of use to you. :)

OCR in Windows Phone and Windows Store apps

Over the years, lots of developers have asked about having OCR (Optical Character Recognition) capabilities in their apps.
Well, last week a preview of the ability to do this was released by Microsoft.
I've not seen much publicity of this but know many people will be interested so I'm trying to help spread the word.

If you're interested, it's the same code that powered the Bing client on Windows Phone, Bing Translator app, OneNote and OneDrive.

You can find the documentation (and sample) on MSDN http://msdn.microsoft.com/en-us/library/windows/apps/xaml/windowspreview.media.ocr.aspx and the NuGet package at http://www.nuget.org/packages/Microsoft.Windows.Ocr/

On "Responsive Design"

What your design should be responding to is the context of the user. Not just the device they're using.

It's about more than just screen size and capabilities.

It's about enabling the person using the software to get the value they want out of using the software regardless of which device they are using.

Of course, understanding the context of the user (so you can best give them what they want) requires consideration of more than just the size of the screen.

And although it should go without saying you can't put all the logic to do this on just the client side or just the server side. (Assuming you have both - some apps may only be client.) Some of the logic to do this will need to be on the server and some on the client. The client will tell the server general information to the server which will impact what the server returns. The client will then refine this to the specifics of the device. Allowing for consideration of its current configuration and its current environment.

Think before you truncate

There is a convention on Windows Phone to not wrap text but let it overflow the right edge of the screen.

This shouldn't always be done though.

There are cases where the text at the end of a sentence is REALLY important and it's more important to compromise the convention or the layout so that the information that matters can be seen.

Take a look at these directions (from the maps app).

In the second step, is the street I should take on the right or the left?

It's important I know. 

This shouldn't have been clipped.

The arrow doesn't make it obviously clear either. 

Fortunately, in this case, the apps supports rotation and by switching to landscape I can see that I need to take the road on the left.

It's a work around for this instance but not all apps are as good.
Even in this case though it would have been better if the app didn't give me that initial moment of confusion and frustration.

Is there anything you could do to your apps to make sure that the most important information is always visible?
Or would supporting both portrait and landscape orientations in your app allow the people using it to see things more clearly?

If you previously built Windows Phone games with XNA...

I'm still regularly asked what options people have for taking forward the games they originally built for Windows Phone 7 with XNA.
If you're not aware this question is driven by the fact that Microsoft removed XNA tooling and support from Windows Phone 8.

There are 2 main options: MonoGame or Unity.

MonoGame is an open source project that aims to provide the same options and APIs for building apps across platforms as were available for building with XNA on Windows.

Unity is a game developing ecosystem for building apps that work across a wide variety of platforms.

So which should you use?

If you already have a code base (based on XNA) that you want to reuse then MonoGame is the obvious choice.
If you have no existing code base or are happy to rewrite it then Unity is probably the way to go. Microsoft seem to be putting more emphasis on this as a solution for game development as it is popular with many big game studios and has a strong cross platform story. After all why would you build for just Windows when you can reach more potential users for your game by targeting multiple platforms?

Is this how things are likely to remain? Well, I don't see Microsoft changing their opinion about Unity in the short term. They've just bought a company who makes a plugin for Visual Studio to help with building with Unity.

SQLitePCL vs Akavache

Earlier this week I shared the news that there is now an "official(ish)" version of SQLite that can be used in what Microsoft calls "Universal Apps".

SQLitePCL Now Supports Universal Windows Apps! http://t.co/X31x3Zjw1t
— Windows Phone UG (@wpug) June 30, 2014

I was asked how this compares with using Akavache and if I have any recommendations?

If you're not familiar Akavache it's "an asynchronous, persistent key-value store for native applications". In that it can use SQLite as its data store and that both can be used in Windows and Windows Phone apps then the comparison question becomes even more relevant.

That's to risk potential confusion though. The underlying data source isn't really relevant. What matters is what their purpose is and what they're capable of.

The first big difference between the two options is in the type of data they can store. SQLite allows the storing of relational data. (It is a relational database after all.) Akavache can just store key-value pairs.

Of course you could just store key-value data in SQLite yourself. So why use Akavache?
The answer lies in what it adds beyond just being a key-value store. It is designed for working with (and storing) remote data that may be cached. Whether that's HTTP response, images or JSON data. Akavache adds more than just a key value store it provides smart logic for retrieving and caching remote resources.

So, my recommendation is that if you only need to store remotely sourced key-value pairs then use Akavache. If you need to store relational data then use SQLite.