AdDuplex has introduced real-time bidding - what this means for you

Last week, AdDuplex have announced the introduction of a bidding based sub-system. If you're an AdDuplex user then you may have some questions about this and what it means for you.

Here, in hopefully simple terms, is what it means to you and what has changed.

Cross-Promotion
If you're cross promoting your app with the AdDuplex control then nothing has changed. This is true whether you've got a Windows or Windows Phone app and if you're using the control directly or through AdRotator or AdMediator.
If you show ads for other apps and in exchange ads for your app are shown in the other apps then nothing changes.

Direct Campaigns
If you've bought direct advertising in an app nothing changes. Any campaigns you're bought will continue in the same way. You can also continue to buy advertising in the same way.

Network Campaigns
This is where things have changed.
Previously, all ad impressions that you purchased cost the same amount.
This made things were nice and simple and you knew what you'd get for your money.

In reality though, some ad inventory is more desirable than others. This could be ads in some types of apps and people in some locations.
When something is more desirable it is reasonable that some people will be prepared to pay more for it. Similarly it's reasonable to want to pay less for something that other people aren't as interested in.

The way that advertising platforms account for the varying relative value of different impressions is via real-time bidding or RTB. (RTB article on Wikipedia)
This is what AdDUplex has changed to using for paid network advertising.

What this means for you is that:

• Some ad impressions will cost more.
• Some ad impressions will cost less
• You can expect to get more impressions for your money
• If you want specific targeting for your ads you may end up getting fewer impressions for your money but they should be more valuable to you and therefore something which will convert better. (If you're targeting correctly.)

Practically, what does this mean for you?
If you are currently running paid network campaigns you can switch them to be RTB based.
If you do this before July 7th 2015 you'll get your current balance doubled!
If you don't do this manually, all accounts will be automatically updated on January 1st 2016.

As per the instructions on the blog post, to make the switch, log in to your account and go to "Buy ads –> Billing –> Add credits" then follow the instructions to convert your credit.
The day after you do this you'll be able to adjust your campaign(s). Just go to the bottom of each campaign and adjust as appropriate.

I'd suggest keeping the old daily budget and starting with a low bid (e.g. $0.99) and then adjusting based on performance once you see what you get with those settings.

Are bugs on one device more serious than bugs on another?

Overheard (somewhere I'd expect people to know better):

"Bugs in mobile apps aren't as serious as bugs in desktop apps."

Really?
What are the implications of believing this?
What happens when this is the prevailing attitude in the developer culture? In a company or in a wider community? Especially when "building once to run everywhere"?


The background to the above quote was that they believed that lots of mobile apps are buggy but desktop apps are generally of a higher quality.

I think the opposite is true (at least of good apps). The connection to mobile devices and the competition between apps mean that bugs are more obvious and developers work harder to avoid and address bugs as part of a greater focus on UI & UX.
On the desktop there hasn't, traditionally, been a great focus on UI & UX and quality hasn't been as great as users are more tolerant of bugs and a substandard experience as their expectations are lower.

Of course, in a brave new world of universal apps that run on multiple devices a bug can easily exist on both mobile and desktop. The good news in such situations is that you can fix it in both locations at once. But sometimes that might not be the case and you could have a bug that only manifests on one platform. This means you have to test everywhere.

Using a keyboard shortcut for the back button on your Windows [10] desktop app? Set IsTabStop on the page to True

*Disclaimer - This is based on my experience with the current preview tools/SDK. Things may change in the future.*

So, you've got a Windows 8[.1] desktop app and want to port it to Windows 10 (or just want to build a Windows 10 app that will run on the desktop), read on.

If your app has more than one page you'll almost certainly have some way of navigating backwards through the page stack. The default way of doing this will be with some form of button on screen that the user can tap with their finger or click with their mouse.

But what about the keyboard?
Yes, it's possible to `Tab` to the back button and invoke it that way, but if you have a page with a lot of controls on it it may require a frustratingly large number of key presses to "tab" to the back button.
A common (defacto/unofficial) alternative is to use the keyboard `Escape` and/or `BackSpace` buttons as a shortcut.
If doing this you'll probably do so by adding a `KeyUp` (or `KeyDown`) event handler to the page.

Here's where it get's fun.

To have the page listen to keyboard events it needs to have focus (or contain controls that have focus and let event bubble up to it).
In Windows 8.1 a page code get focus and listen to events even if `IsTabStop` was false (the default).
In Windows 10 a page must have `IsTabStop` set to True to be able to get focus and be able to listen to key press events.


Discovering this cost me far more time than I would have liked. I document it here in the hope that it saves someone else some time in the future.

What if I enable developer mode, install an app and then disable developer mode?

This question came up on our webinar this afternoon.

What happens if you put a device in developer mode, install an app as a developer and then turn off developer mode? Can you still use the app?

I didn't know, so I tried it:

• I put a device (phone) in developer mode.
• I then deployed an app from Visual Studio to a phone.
• The app ran fine when launched from the apps list or the pinned main tile.
• I then disabled developer mode.
• When trying to run the app again it would not start. Nothing happened when tapping the app (in the list) or the tile. No message, nothing.

Based on the current preview build (10135) you cannot use an app installed through the developer tools once developer mode has been disabled.


*Update* - apparently the lack of message when the app doesn't start is a bug that will be addressed ;)

Badass: Making Users Awesome - Book review

This was originally posted at http://windowsapps.london/2015/06/10/badass-making-users-awesome-book-review/

---

I feel I should start by apologising to you. I was given a review copy of this book a few months ago but the fact it's taken me this long to tell you about it is something I should apologies for. You need to know about this book. And yes, I should apologies to the person who gave me the review copy too. ;)

This is a book about products and services but equally applies to apps. Given multiple similar apps, why are some more successful than others and what can we learn from the ones that are successful so that we can be successful too?

The structure and layout of the book is different to most but something you’ll recognize if you’ve read any of the Head First series.

The book aims to provide a “formula for improving our chance of making a sustainable, bestselling product or service” or app!

I think there’s something in it for everyone involved in app development and who want to create apps that uses will love and get value from. Obviously if you’re just building apps for yourself and/or to scratch a technical itch then carry on. Well, actually, upon reflection, there’s still something in this book for you too.

Here’s the thing. When it comes to a product/service/app in any category or niche, what distinguishes the successful from the not so successful is not luck. It’s about making the person using it a badass!

What does that mean?

It’s about creating better users, not better products.

The knock on from this is that people will talk about themselves more (people like doing that) and the reason for that will be your app. The most trusted form of advertising is recommendations from friends and family members. When others discover that the reason for then becoming badass is down to your app you’ll see the number of downloads of your app go up.

You may have heard the advice that you should “build services, not apps”. While that advice is generally good, it’s better to not “build a better service, [but] make a better user of the service”.

If you can create your app so that it creates a great Post-UX UX (the experience after using the app) then you’re on your way to a winner.

The book has a lot of information to help you create apps (and services) that will help create badass users. That is users who “reliably perform in a superior way”.

The advice covers everything you’ll need to know to help your users. Whether it’s practice, examples, struggle, progress, rewards, jargon, choices, memorization, willpower or affordances. There is a lot you’ll need to know and this book will help you through it.

There are also two other things you’ll learn about that are especially close to my heart.

“Cake features” and how you app can actually make people fat. Yes really. And how you can cause an emotional response in your users through appropriate prompts and a compelling context.

I urge you. Go get and read this book to learn more.

You owe it to the people who will use the apps you help create.

Get it from Amazon or O'Reilly.

When you go truly multi platform with UWP everything will be paid for with In App Purchases

In App Purchases (IAP) are how everything will be monetized in Windows 10.

Well, at least in part.
If you have any other thoughts I'd love to hear them.

In the Windows 10 every app will have a single store entry with a single price. Clearly this won't be appropriate when the app or game varies greatly on different platforms (device families).

Consider a game that exists on mobile, desktop and Xbox. Today you'd expect the gameplay to be very different across the platforms and also the price of the game to be different on each and you'll probably have to pay for each platform separately.

Obviously this won't work when there's a single price.
The solution then is for the app to be free and then you pay to unlock the app on each device you want to use it on.
There's an important UX consideration here around apps that appear to be free but then you have to pay for them once you've downloaded them.
A possible solution for this is to provide a free trial on each platform and then a paywall for the full game.

Obviously, some goodwill in the pricing will be nice and appreciated too.
For instance, if I buy the Xbox version first I might get the other platforms included too. Or, if I buy the mobile version first then I'd like a discount when I later buy the Xbox version.

Or maybe you use different monetization strategies for different platforms. Maybe the game is listed as free in the store but monetized with adverts in the mobile version and paid for (via IAP after a trial/sample) on the Xbox. With the desktop version being the same as one or other of those as is deemed appropriate.

Apps might be even more varied than games in their differences on different platforms. The near canonical example of this is the phone or tablet that is used for data collection and the desktop version that is used for reporting.
For some scenarios the above won't work or be appropriate and so having separate store entries for different platforms will be a better solution.

There are lots of unknowns here. The thing to note is that it's very unlikely that there will be a simple solution that works for all (or even most?) apps and games.

If you're building for Windows or Windows Phone and aren't yet familiar with IAP then now might be a good time to get prepared. You'll find documentation on MSDN.

5 tips for reducing the memory footprint in a background task

I was just asked for 5 tips on reducing memory footprint in background tasks.
Here's what I came up with:

1. Include as few external dependencies as possible.
2. Include as little of your own code as possible.
3. Don't load anything in memory you don't need - and free anything you do load before carrying on.
4. Do as little as possible - stick tightly to only what you absolutely must do.
5. Don't be afraid to split functionality between multiple tasks if need be.


Yes, they're all quite generic but this is actually a fairly standard scenario on mobile. Ultimately, to save time and resources (memory, network, power, etc.) you should do as little as possible and only use the things you must.

Reserve you Windows 10 upgrade today! It's free. It's easy. No worries.

If you see this icon in the notification area (system tray) on your machine then you should click on it.

Here's what you can expect when you do.

Reserve your free upgrade. It's not like they're going to run out but it means you'll get the free update as soon it's available.