Subscribe to the RSS feed then follow me on twitter at @mrlacey

Monday, August 17, 2015

Why the Windows 10 Universal Windows Platform Bridges are a GREAT thing!

At the build conference earlier this year, one of the more controversial announcements were the "Bridges" that were introduced.




These "bridges" are new ways of building apps and involve using tools and languages that are different from the "native" methods of C#, C++, VB.Net or F# for the code and XAML or Direct-X for the UI.

They allow the use of Objective-C to build UWP apps, or repackaging Android APK bundles, Native Win32 apps or websites as Windows 10 apps.

Recently the iOS bridge has been open sourced and made publicly available. There's also been a leak of Project Astoria (the Android bridge).

Some people (mostly developers) think these bridges (for Android and iOS in particular) are a bad thing. I don't.

I suspect that negative reactions to the bridges are mostly reactionary and come from a place of fear, elitism and uncertainty.

If you've spent the last few years building Windows and Windows Phone apps you'll have built up some skills and experience that you were probably hoping would help you build similar apps in the future.
That's no bad thing but some people presume that the introduction of these bridges means the end of native development for Windows (& Phone) using C# & XAML. That's probably a bit of a reach.
If you've been doing native development professionally, especially as a contractor, then you may be more concerned. There will probably be less work creating ports of other apps to Windows (Phone/Mobile).
Yes, losing your job is a bad thing and I know of one person who has lost their job due to a change in need for developers who can do straight ports of Android apps to Windows Phone. If you end up unable to find work I don't think you can solely blame the bridges though.

I believe that many of the skills and experience that are used to create great apps for Windows and Windows Phone can also be used to create other things too.
If you've been developing such apps you'll know more than just how to use a specific SDK or programming language.

If someone explicitly told you that you could keep building apps for Windows/Windows Phone with the same skills and knowledge for a long period of time I'd take them to one side and have a quiet word.

The world of software development is ever changing and in the world of mobile development particularly so. This is a world where we can almost guarantee at least one new major OS update every year. A place where tools, technologies, languages and frameworks are regularly updated or replaced. This is not a place you can afford to stand by for a long period of time and expect nothing to change. The mobile app landscape was very different 5 years ago.

If you'd decided that you will only ever continue to develop apps for Windows and will only consider using C# and XAML to do so (I've spoken with a few developers who have this attitude) then you're making things hard on yourself.

If you want to stop with what we've got now, why stop now? Are things not going to get better or easier in the future?  If now, why now? Why didn't you stop at some point in the past?

If either on your own or on the advice of others you are confident in the technologies and levels of knowledge you will need to continue building apps for the next few years would you please share them with the rest of us. Oh, and if you're really that good at predicting the future can you let me know next month's lottery numbers. (Actually, you might need them too, if you're going to refuse to learn anything new and insist that you'll keep using the same tools to build for the same platforms evermore.)

So, if we can't rely on a future of porting Android and iOS apps to Windows/Windows Phone, what can we do?

How about something new? Rather than just reinventing the wheel.

Getting to do exciting new things is better than just rehashing what already exists. Even if it is easy money.

We don't build a better future by just building variations of things that already exist. There's more to life than just building apps.


That was a lot of words and some sentiments that I know many will take umbrage with so let's recap the details.

Why they may be a bad thing?
- Less investment in native Windows apps may affect people looking for work doing such.
- Running Android or iOS apps on Windows (Phone) may create a sub-standard app experience that could put users off the platform.
- Existing Windows developers abandoning the platform in backlash at the news. (I've heard a few people claim they're going to do this.)
- Windows may be seen as just a third place ecosystem where running a version of an app built for another OS is good enough. The knock-on effect of this could mean fewer companies considering developing for Windows at all and the platform taking a decline.
- Lack of access to Windows specific features may lead to apps that don't work as well or show the platform in the best light.

Why they may be a good thing?
- More "official" apps coming to Windows sooner as the process is easier for companies to do so.
- More "official" apps should lead to a stronger platform that attracts more users and could lead to opportunities for other apps.
- They allow companies to not need to build the same thing an extra time. This means they can focus on building better products that work across multiple platforms.

Why don't the matter?
- The Android bridge only works on the "Mobile" version of Windows 10.
- There are still things (features, APIS, etc.) you can only build/access with native Windows technologies.
- The bridges don't let you target everything you can with Microsoft's own technologies.
- The existing skills you already have (I hope) enable you to do more than just build native Windows apps.
- Visual Studio and other development tools from Microsoft are super powerful and can enable you to be more productive building native Windows apps than adjusting existing Objective-C or Java code to run on Windows.


And one final question that I know has come to mind for a lot of independent (hobbyist) Windows Phone developers.

What if you've built a WP version of an app that wasn't on the platform and now may be?
Many developers have seen spaces left by the "app gap" and created their own apps to fill these gaps. This typically means building a version of an app that exists on iOS and/or Android for Windows Phone. I've had a few people ask what these bridges mean for them. Their concern is that the official version of the app may now come to Windows Phone (probably via the Android bridge) and so be competition for their app.
This is a curious situation. Surely if building a 3rd party app because the creators of the app on other platforms haven't built a WP version because they see a lack of opportunity for return on investment, the creator of the 3rd party app is relying on the platform not getting big/popular enough that a first party/official app is released. At the same time they almost certainly want as many users of their app as possible.
If an official app is released and you've built your own version of that app it may not be the end of the world for you. Here's why:
- The launch of the official version could bring a wave of promotion that you could benefit from.
- You already have a user base. Will they automatically leave? If so, then wouldn't you have been vulnerable to another 3rd party app.
- Hopefully your version will be better suited to the Windows Platform and so feel more natural to people familiar with the OS.
- With a native app you can do more platform specific things that an Android app running on Windows can't.
- You can specialize in the features of your app to better serve a niche or certain type of user or certain scenarios. After all, there are many services which provide an official app but for which there are also many successful and popular third party apps that are also for the same service.




If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.

Thursday, August 13, 2015

My thoughts on the Surface Hub now I've used them


Yesterday I got a hands-on with both sizes of the Surface Hub. If you're not familiar with the name it's Microsoft's new wall mounted computer intended for collaborative work and meetings.

In the picture above you'll see the small one (yes really) which is a 55" 1080P screen. There's also an 84" 4K version.

They're available for pre-order now but aren't expected to ship until January 2016.
The small one is $7k and the larger is $20k. So, not cheap.

These devices really excite me. I'd love to do some work with collaborative software on such devices. In fact, given the choice, I'd take one of these over a HoloLens! Don't mistake them for just an all-in-one PC with a massive touchscreen. These are a completely new type of computing device.

I was very tempted to order one when orders opened last month. I held out though for two reasons.
Firstly I don't have anywhere to put one.
Secondly I had concerns about the screen on the 55" one.

1080P on a 55" screen means the pixels must be quite big. I have a 1080P screen on two 5.5 inch phones I carry in my pocket all day. I've learnt that a 1080P screen that is only 5.5" in diameter means that I can't see the pixels. I was concerned that I'd see the pixels on a 55" screen.

Having used one, the curves on a circle and diagonal lines were decidedly blocky when I was standing in front of the 55" screen. Personally I'd expect that I'd spend a lot of time very close to the screen and so this would constantly bother me. :(
This isn't typical of most user though. I understand the intention/expectation is that most people using the surface hub will view it from a distance.
From a distance both sizes looked great.

If the 55" device had a 4K screen then it would be very compelling.

My first reason for holding out deserves further comment too. These are not light devices. You're not going to hang them on a plasterboard wall. You'll want to seriously consider the structure of the wall you want to put it on. At these prices you don't want one falling off and breaking. Or worse, falling on someone.

Using the 84" version brought up usability ideas I hadn't thought of before.

  • How do you mount it so that short people can reach the top and tall people easily reach the bottom?
  • What about people who can't reach the top? Apps that require a swipe down from the top may have issues if the user can't stand.
  • Having a button on one side may mean a few steps for a person standing on the other side of the screen if they want to touch it. Might buttons on both sides be better?


What I saw was not the final version of the OS and so didn't handle multiple concurrent users. It was all very exciting though.



If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.

Tuesday, August 11, 2015

Looking at the AdDuplex data differently: Treating variants the same

If there are two variants of a phone: for example one that takes one sim card and the other two; or one version that supports LGT and one that doesn't. Are they really different devices?

Each month, AdDuplex releases stats based on the devices that it serves ads to. You'll find July's stats here.

In looking through the data, it made me wonder if the device variants were really that different. What if we considered the Lumia 520, 521 and 525 as the same. And of course the 630 & 635. And the 530 & 535. etc. etc.
So I rehashed the data to combine the Lumia figures ignoring the last number and replacing it with an 'X'

Here's the impact on the top ten most popular devices.
Make of it what you will.


So, it's still all 5's and 6's.
The 64X is higher than I would have expected.
The 1320 is a nice surprise too.

Yes, you may quibble over whether the 640 & 640XL should be considered the same or claim that 928/Icon is more like the 930 than the 920 but here we are. If you can come up with a really convincing argument for me to adjust accordingly I might be persuaded ;)



If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.

Friday, August 07, 2015

Creating an Xbox One style loading indicator



If you've started an XBox One you'll have seen the loading screen where the three white circles pulsate below the logo while the console starts up.

Watching this the other day I thought I'd have a go at recreating such an animation. (I've been looking at a lot of loading indicators recently and thinking about different ways of displaying a waiting state.)

After fiddling around in Blend for a bit (I decided to just do it all in Blend for a change) I came up with this: https://github.com/mrlacey/XboxStyleLoadingIndicator

It's a (Windows 8 style) Universal project but the UserControl in the Shared project will also work with Windows 10 (and probably WPF & Silverlight too).

It's quite simple.
It has `Foreground` and `Background` Brush properties, that are set to White and Green by default.
It has an `IsEnabled` property that you can bind to if you're so inclined.
It has `Start()`and `Stop()` methods, and if you can't work out what they do then you're probably in the wrong place.

Here's the interesting bit:
I don't like it when animations stop abruptly part way through or when loading indicators flash up on the screen for only a split second. Some people use a timer for preventing very brief display (e.g. the indicator must be shown for at least N seconds before being hidden) but that doesn't prevent it disappearing part way through the animation. To address this I made the control so that it will always complete the animation it is doing before stopping. This means that calling `Stop()` or setting `IsEnabled` to false won't immediately make the animation go away. If that's what you want then change `Visibility` or hide or remove it in some other way. ;)


There are a couple of known issues:
- You have to specify a background colour that matches the background of whatever it is displayed on top of. This means it might look odd if not on a solid colour background.
- It doesn't scale well. But you could easily modify the code in the UserControl if you wanted something bigger.

Both of these issues could be addressed by switching to using a Path, rather than the Ellipses I'm using at the moment. It might be something I get round to eventually, But if you'd really like to see it sooner then let me know.


Thoughts? Interest? Feedback?



If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.

Wednesday, August 05, 2015

How important is the color of an app icon?

So, someone is viewing your app in the store. How much effort do you put into optimizing what they see?
What about the colour of the app icon?

I have an app I use for demos, experiments and the like. It's called PhoneBook.

It has a bright pink icon.


The reason it had such a coloured icon was to try and make it stand out. There are aren't a lot of apps with pink icons:


So, earlier this year, I decided to do an experiment to see what impact changing the icon colour would have on downloads. I didn't change anything else in the app or store description or do any other promotion. I just tried different colour icons to see what impact it would have on organic downloads.

I tried six other colours to see what impact they would have and ran with each colour for seven days.

I had my suspicions about which would be positive and which would have a negative impact on downloads.

Quick.
Before you scroll down any further, which colours do you think would increase, and which would decrease downloads.




Have you made a guess?



Here's what happened:



Compared with the last week in pink, just changing the color of the icon of the app in the store saw downloads increase by 23% or decrease by 19%.


What colour do you use for your app icon?
Have you explored what the difference might be if you changed the colour of it?
It might be worth the change. But you won't know if you don't try.




If you've built Windows Phone or Windows Store apps you can cross-promote them with AdDuplex to get more users.