So I was wrong: W8 & WP8 to have a shared core.

Back in December I gave some fairly well reasonsed arguments about why I thought that the next version of Windows Phone 8 would not be based on the same underlying framework as the also forthcoming Windows 8.

Based on a leak reported yesterday (see here and here), it looks like I was wrong and I have 3 reactions.

I'm excited.
In many ways this is more than I could have hoped for. There are loads of cool features previously announced for Windows 8 that I would love to see and be able to use on the phone. And yes, also some I wouldn't.

I'm not counting my chickens yet.
There are still no public confirmation, details or timelines for any of this. I also wouldn't be surprised if we didn't see a greater similarity with Silverlight 5 than with WinRT in the short term.

I'm a bit nervous.
What will it mean for things going forward? (If advances in both platforms are to be kept in sync in the future.)
In the mobile space the market demands yearly updates. (Just consider the reaction when there was no iPhone 5 announced last year.--The 4S was considered by most as a disappointing stop gap to whatever comes next.)
On the desktop this (yearly frequency of updates) hasn't been seen in the past and is something that businesses don't want, as frequent (even yearly) updates become very expensive and awkward for them to manage. (Supporting the enterprise has always been one of Microsoft's strengths so I don't see them looking to upset the enterprise. Especially as one of the reasons for this initial synchronization and a lot of the upcoming changes are to support enterprise scenarios.)
Forcing updates to multiple systems to be permanently tied together just causes more work and slows releases. Microsoft know this and we've seen lots of products which were historically always released together change to be released separately and more frequently over recent years. I trust they're smart enough to do the right thing here (whatever that may be).

Don't use the OnSelectionChanged event to trigger navigation #wp7dev

It's a comon practice. Hey, it' even in some of the default templates.

But don't attach an event handler to the `OnSelectionChanged` (or equivalent `OnSelectedItemChanged`) events and then use this as the trigger for  starting navigation.

This is typically used when there are options displayed in a list[box] and the user can select an item to navigate to the appropriate page. It's also really common for such a list to be large enough that the user must scroll to see all the items. Therein lies the problem. It's common for the first part of the swipe gesture (intended to scroll the list) to be interpreted as a selection. This then causes the app to navigate to the item that was touched while swiping, not the one the user actually wanted.

Instead, add a handler for the `Tap` event of the individual item. This way you don't risk confusing the gestures.

This way you'll have an app that behaves as the user expects. This is definitely a step towards having happier users which will hopefully help lead to you havinng more of them.

I'm heading to Scotland to talk about #WP7Dev and "thinking mobile and beyond""

On the 21st, 22nd and 23rd of February, I'm heading north of the border to talk at user groups in Edinburgh, Dundee and Aberdeen.

• Tuesday 21 February
  • What and why every developer needs to know about mobile development – BCS Edinburgh and Scottish Developers
• Wednesday 22nd February
  • What and why every developer needs to know about mobile development – Dundee Web Standards
• Thursday 23rd February
  • Getting started with Windows Phone – Aberdeen Developers .Net User Group

If you're anywhere near and can make it, it'd be great to see you there. Or if you know someone nearby then please spread the word.

Yes, this is further than I've ever travelled to present before but I thought the opportunity to feel like a rock star, jet setting, developer/presenter was too much to miss out on. (At least this once.)

The absolutely most important thing developers need to know about #Windows8

Forget Metro.

Forget tablets.

Forget WinRT.

Forget building apps in HTML/JS.

The absolutely most important thing developers (and anyone involved in the creation, design, sale, marketing, etc. of software) need to know is based on the fact that it is designed to be used on multiple devices.

Which leads to my point. People (your users/customers) are starting to use a wider variety of devices. And not only that, they are using them in different/new ways and this requires that the applications which run on them work/behave in different/new ways too.




Windows 8 tells "desktop" developers they MUST start thinking about developing for multiple devices and uses.



Whether it's a 10" tablet, a 15" laptop or a desktop PC with a 32" screen, these different form factors encourage use in different ways. But that's just an example of where we'll initially see Win8. There's also the even smaller tablet and phone devices. There's table based interfaces. There's wall sized interfaces. There's also many more we probably can't even begin to imagine yet. Even in Sci-Fi films. But one day, probably sooner than you think, we'll be building apps to run on such devices.

If you've heard me talk at any point in the last 4 years or so, you will have inevitably/hopefully heard me say that all developers should start learning about developing for mobile NOW as it will help prepare you for all the plethora of devices they'll inevitably end up building for in the future.

If you're a developer who currently only targets the laptop/desktop environment usage scenario whether for APPS OR WEBSITES and you care about how your skills will meet the future demands of the marketplace. I can't recommend strongly enough that you should go and learn about HOW developing for mobile is different.
I'm not saying you should go and learn how to build apps for Windows Phone, iPhone or Android, etc. What you need to know is how apps designed for those platforms are different from ones that run on the "desktop".

If you have experience developing apps for the desktop environment you'll bring with you (whether you intend it or not) a number of assumptions and expectations about what your app should look like, how it should work and how people will use it. The good thing about mobile development is that it challenges all these common assumptions and so forces you to think differently.
Once you know how to challenge your thinking about these areas regarding mobile development you'll be prepared and ready to approach developing for other devices, form factors, etc. in a way which will help you create apps which work well on that platform.
In turn this will lead to apps which are easier (possible?) for your users/customers to use. Which can only be good for you/your company. Afterall, if people can't use your software they wont do so for long. This makes it much harder to get repeat business or referals.
Alternatively if your business is based on income from selling support contracts then you probably want (or need?) your software to be bad. So you should probably check out all the things you shouldn't be doing as it would only make your app better.


Side note.
You may try and argue that previously PC apps were used on PCs and laptops. But, seriously, can you show me the apps you have been building which allow for these (slightly) different environments. Thought not.

Windows Phone 8 and WinRT

I've heard a lot of people claim that they think that the next major version of Windows Phone (which they assume will be called Windows Phone 8) will use WinRT as part of the phone's OS. I don't.

At this point I should state that even though I have spent a few months earlier this year working at Microsoft (in their Windows Phone Centre of Excellence). I do not have any insider knowledge of Windows Phone beyond what has already been publically released.

Here's why I don't think that the next version of Windows Phone (whether it's called 8 or "apollo" or anything else the internets may speculate at): Time!

WinRT is part of Windows 8 (if you weren't aware).
What's the timeline for the release of Win8?
We don't know, but I'm going to make a, hopefully, intelligent guess.
The only thing we know about it were announced back in September (at BUILD) when it was in the pre-alpha stage. Based on that and what we know from the time it's taken for previous Windows operating systems to be released, I think we'll be lucky to see it publically available before the end of 2012. There are some rumours that we may see a beta in early 2012 which sounds reasonable and ties in with what we might expect.

What about Windows Phone v.Next? (Which from now on I'll call WP8 to save typing.)
Again there is no public information on timelines for releases but we can make some informed decisions based on a knowledge of the "mobile space", the release schedule of other mobile operating systems and the timeframes over which WP 7.0 & 7.1/7.5 were released. I don't think it's unreasonable to expect to have details of WP8 announced in February, have an SDK released around April/May and have general availability/public rollout around September.

That means that, realistically, the details of WP8 need to be fairly locked down by February (if not several months before). At this time Win8 could still be in a very variable position. I don't see Microsoft letting WP8 dictate feature lockdown for Win8 (and it shouldn't). Similarly, Microsoft can't afford to delay WP8, possibly for many months, until Win8 is stable.

They're two separate (albeit related) operating systems which have their own requirements, uses, users and competitors and therefore require their own release schedules.

Any other arguments?

In a number of ways Windows Phone is still playing catch up to other, more mature or fully featured mobile operating systems. It's going to be better for Microsoft to spend time addressing (at least) some of these disparities and adding or refining features and functionality which will allow WP8 to compete in the mobile arena than doing things that improve parity with a desktop operating system.

Yes, sharing development resources across multiple platforms is a great thing but it's more important that the individual platforms are strong enough to compete individually. There will never be a situation where the exact same codebase will (or should!?) run on both platforms though, so perfect synchronicity is an unnecessary (and impossible?) goal.


Additionally we need to consider what WinRT actually includes.
WinRT is an alternative/update to Win32 which provides a set of APIs which can be used/consumed in the same way as the APIs of .net. Having to do things with Win32 on the desktop can be less than ideal or so difficult as to lead many/most to not even try. On the phone this doesn't matter. The only things you & I (us mere mortals - not Microsoft, operators or OEMs) can do on the phone are in managed code through a .net API (the compact framework - v 3.7). We don't have to address issues about things which are hard or impossible to do with Win32 APIs. It's not that the functionality isn't available. The whole issue is irrelevant.
Yes there are some things in WinRT that it would be nice to see in Windows Phone but I hope they can be migrated to WP without needing to make a major change to the underlying OS.

Making a dramatic change to Windows Phone such that it had anything more than a trivial impact on the upgrade path of 7.X apps would be a big issue and upset a lot of WP7 developers. At a time when Microsoft are still trying to persuade companies/developers of the merits of building apps for WP adding unnecessary hurdles to upgrade paths would not, in my opinion, be a smart move.