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

Friday, March 20, 2015

I've started building my first windows 10 app

No, I don't have the SDK but that doesn't matter.

I'm building an app that will exclusively target the phone but requires capabilities that aren't available today (in 8.1) but do currently exist on the desktop for Windows apps. 
I'm assuming that what Microsoft are telling me about being able to build one app that can run on all devices and the convergence of APIs will mean that the capability will be available on the phone when the Windows 10 SDK is available.

Planning is the most important step in development anyway so doing most of the work before the API is available (but assuming it will be like the existing desktop version) means I'm not blocked by a lack of SDK.

I want to be ready for when the tools and store become available so I can make the app available as soon as possible.

What if the API is very different or doesn't allow the functionality I want when it is released? 
I'm allowing for some level of difference in the APIs so am not expecting it to be completely painless when the tools are available. 
If it's a very large difference and requires massive effort I can reevaluate then. 
If the app won't be possible when the SDK is available I'm not losing a massive amount of effort as it's a simple app. 
I think the risk is worth the initial effort and I'm learning things now in terms of having to think about what the app should be like and how I will design it for a great Windows 10 experience.

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

Tuesday, March 17, 2015

It's taken me 5 years to come to this realization about Windows Phone apps

For many years I've had the idea that you should wait before you publish your app to the store until it's the best it can be. Add all the features, polish it thoroughly, test extensively, that sort of thing.
It's part personal opinion and also, I believe, part a culture thing - I know this isn't a common attitude in other parts of the world.

However, I no longer believe this. As soon as it's "good enough" - submit it.

What's "good enough"? - As soon as it can provide use or value to the person using it.

The benefits of getting feedback from having real people use your app will far out-weigh any benefit from you tinkering with the code or adding one more feature before you do.

I'm not saying don't test your app, or don't fix bugs, or that features don't matter. I'm saying that feedback from real users matters more.

Being first to market doesn't have an impact in most app categories. And are you really defining a new category in your app?

But here's the most important thing:

Getting an app in store is the start of the real process, not just the end of the initial development one.

Putting off launching your app on the public isn't helpful. Ship it. Get started.

When you haven't released it can be easy to put things off, to wait before adding a feature, to defer fixing that bug until another day.
When you have actual users asking for the feature or being affected by the bug there's a greater incentive to make the change. This will often lead to you having a better app in the store, with more users, sooner than if you'd waited until you did everything before releasing it.

Disclaimer: this above is focusing on smaller, developer driven apps. If you have a large brand name or are planning a high profile launch then there is a greater reason to get more features and functionality in the app for launch. I understand that and hopefully you do too ;)

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

Monday, March 16, 2015

Slide view / splitview / side draw and a hamburger are not necessarily the same thing

There has been a lot of discussion about some of the native apps in the Windows 10 technical preview releases using a hidden menu, accessed via a "Hamburger icon". Some people have taken great offence to this and object to it's use in Windows Apps.
Let's get a few things clear though:

  • The hamburger icon is a variation on the icon for a list that represents a menu (a menu is just a list of options anyway)
  • It's typically used on a small screen device, where space is limited, to allow for the person using the software to cause the menu to be displayed. The menu is not typically shown all the time because of the amount of screen real estate it requires.
  • In addition to being useful on small screen devices, it's also useful when the size of the window can be changed and vary greatly.
  • The idea is to hide the menu off screen until it's needed.
  • The downside is that the person using the software doesn't know what's in the menu until they open it. If they don't use it regularly and/or it contains a long list of options then they have to remember what's there. Or, more likely, they have to open it to see what options they have.
  • How the menu is displayed is not related to using the "hamburger" icon to represent it.
  • You do not have to use a side draw or slideview to show a menu.
  • Using a side draw or slideview does not require the use of a hamburger icon. You could use something else. Even text.
  • It's a convention though. Many people already recognise the hamburger icon (even if they don't call it that) and have an expectation about what it will do.

You don't have to use a hamburger icon in your [Windows 10] app.

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

Monday, March 09, 2015

Native API usage from Windows 10 web apps

When Microsoft demoed the packaging of web sites at MWC last week, I noticed an interesting thing. The demo was hosted on a public website:

As all the logic for the extra new functionality exists on the web server (in the javascript served with the page), I wondered if this was public also. They may have been detecting appropriate user agents and only serving the functionality to devices which can use it.
It turns out they weren't and examples of the new API usage exists (minified) at

Through the help of I was able to tidy this up a bit and find some examples of things that can be done. And yes, they look a lot like WinJS. **Disclaimer** this is all pre-release and so may change. I only know what was said publicly at MWC and what I found looking at the JavaScript on the above public website. If you find anything else interesting in the

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

Microsoft removed 2 reasons for building an app for a website...

... by making it possible to bundle a website as an app.

At MWC last week Microsoft announced that in Windows 10 it will be possible to package websites for distribution via the store. Additionally, when the website is viewed after having been installed from the store it will have access to device APIs (via javascript).

This actually removes two of the reasons that used to exist for creating an app equivalent for a website.

1. Discoverability (via the store)
2. Access to device specific functionality.

In some circumstances there are more but these are the main ones.

1. If you can package a website as an app just to help people discover it in the store then there's no need for a separate app. This is a good thing. If you have a website that works perfectly well on Windows devices you shouldn't have to create an app just so you appear in the store.

2. Access to device specific functionality is normally only available through native APIs. This was a strong reason for needing to build an app previously. Of particular general use was the ability to use push notifications to inform people of new content. As this is (will be) now available to websites installed through the store it is no longer a reason to need an app. Additionally access to contacts and calendars will also be available, further removing necessities to build an app.

Here's the other important point. The packaging for the website is simple. It's a manifest defining the URL and the permissions/capabilities required plus some store specific assets. (images, description, screenshots, etc.)
You won't have to include all the files that make up the website/webapp and ship them to the store. They will stay on your server. This will make updating and modifying the site (app) much simpler than if it had to go through the store.

There are some potential gotchas though too:

  • You won't have access to this extra functionality if the site is not being accessed after having been "installed" from the store. You may have to detect this and advise the user appropriately if they want some functionality that is only available when "installed".
  • By blurring the lines between web site and installed app you may have to make this extra clear to your user what this is and how it works.
  • The browser in Windows (8.1 & presumably 10) has a user agent that many websites can mistake for Android or iOS devices. Be aware of this and consider your device detection carefully. It might look very bad if a website is installed as an "app" only for it to display messages to the user telling them to 'install the Android app' when they try and use it on their Windows 10 device. I see this quite a lot from sites on a Windows Phone 8.1 device and it just reflects badly on the site.
  • You'll still need to make sure that your website works on all devices and only exposes this, new, Windows 10 specific functionality on appropriate devices. Yes it's more work but probably less than maintaining a separate app.

**Disclaimer** all the above is based on comments made by Microsoft at MWC. There was no recording and the information was made publicly only to those people in the room. I was there so you'll just have to trust me. Also, the information released wasn't final so all this may change and the feature/functionality may even get cut.

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