Tag Archives: windows phone

Death of the Start Screen Exagerated

It seems like the online media is foaming at the mouth about Windows 8.1 Update 1 supposedly making the move to boot by default to the desktop. The first article I came across was by Steven J. Vaughan-Nichols over at Computerworld followed by an article at Mary Jo Foley over at ZDNet (who gives the topic a much more balanced treatment).

Where Mary Jo Foley stops at reporting the news, Steven’s opinion piece is vitriolic which is typical of his previous articles. I mentioned to one of my co-workers the other day that I was disappointed in the state of tech journalism these days. Alas, there is only so much news to go around which means that content ends up being rehashed – so the only way to stand out is to write an opinion piece, the more bitter the better.

With that out-of-the-way, I have to acknowledge that where there is smoke, there is fire. So what about the rumour that Windows 8.1 Update 1 will boot straight to the desktop. If the rumour is true it is worth stepping back and thinking practically how this might work.

When Microsoft introduced Windows 8.x, the Start Screen didn’t replace the desktop. Rather the Start Screen replaced the Start Menu. The Desktop was always there in the background, it was just as if immediately after login that the Start button had been pressed and a full screen start menu was being displayed.

I suspect that Microsoft might ideally want to just boot to the desktop by default for devices that don’t have a touch first experience (desktop PCs and laptops) leaving touch first devices to boot to the Windows 8-style Start Screen. This would give users balance the best possible experience on their particular devices form-factor.

Some of the press has pointed out that if you boot to the desktop, then how will users know to launch metro-style apps? Well, remember that the Start Screen did not replace the Desktop, it replaced the Start Menu. So when a user presses the start button on the desktop (or on their keyboard) the Start Screen would still be displayed. If this continues to be the case then metro apps would still be discoverable in a desktop environment.

As Mary Jo Foley pointed out, leaked screenshots of the Windows 8.1 Update 1 UX reveal that users will be able pin metro-apps to the start menu. This means that users could quickly switch between legacy desktop apps and modern apps. I suspect that Microsoft has more plans for blending the metro and desktop environments.

I speculate that in a future release (not necessarily Windows 8.1 Update 1) we’ll see metro apps being able to run in floating windows on the desktop along with API support to make apps intelligently respond to this environmental change. Windows Runtime (or WinRT) is the underlying platform for modern metro applications, but that doesn’t mean that you can’t produce a UI in it that is more optimal for a mouse/keyboard user.

The second change we MIGHT see is a Start Menu / Start Screen hybrid. So far the best concept of how this might work I have seen is this start menu/screen transition video which was posted recently (and received great reviews).

What this video hints at is that the theme for phone, tablet and PC operating systems moving forward is convergence. Microsoft has pretty much confirmed this to be the case for Windows and Windows Phone, but I suspect this will also happen with OSX/iOS. Google is an interesting case because they have two quite different approaches to apps in Android and Chrome OS.

For Windows the key ingredient to convergence is Windows Runtime. Not only does Windows Runtime expose the UI building capabilities, but it also surfaces other OS features, file system, networking, sensors etc. WinRT modernizes key aspects of the existing Windows API (in Win32) in a way that is suitable for desktop, tablet and phone.

In summary, I don’t think that booting to the desktop on desktop-style devices spells the end for either metro, or the Windows 8-style start screen. Rather I think it’s just a continued fine-tuning of the user experience to support as broader range as users as possible. Indeed this kind of UX spread is a necessary feature of a single operating system running on a multitude of devices.

The NFC wave is coming…kinda.

I stepped out yesterday morning to go to an appointment and when I got back I dumped my wallet on my desk then neatly stacked my phone on top of it. I’ve got a Nokia Lumia 920 running Windows Phone 8. After a second my phone chimed. I was familiar with the noise because I have a wireless charging stand by my bedside table.

Turns out that the NFC proximity sensor on the Nokia Lumia 920 had picked up an NFC chip from the many cards within my wallet. This afternoon I sat down to figure out which card it was and how I could use the proximity API within Windows RT to read the card.

As I flicked through the cards in my wallet and held them out to my phone I found that if the 23 cards in my wallet, six of them had NFC chips within them. Of those there were 3 bank cards, 2 transport cards and 1 loyalty card.

My next goal was to figure out how the proximity API within Windows Phone works to see whether I could get access to any of the details on the cards. I’ve slapped together a quick example of how to use the proximity API. The code uses the ProximityDevice and hooks up to the DeviceArrived and DeviceDeparted events and also calls SubscribeForMessage.

Unfortunately none of the cards that I had in my wallet contained an NFC device which was in a format that Windows Phone 8 could understand. NFC messages that Windows RT supports are listed on the PublishBinaryMessage documentation page. From what I can tell Windows Phone 8 only supports a subset of these, and other than Windows specific message types, the messages need to be formatted using NDEF. If you happen to have an NDEF formatted card you can use the NDEF library hosted at CodePlex to work with the data directly.

I hope that in the future Microsoft will open up more of the NFC device capabilities on their mobile platform. I suspect that many loyalty card programs that use NFC won’t necessarily encode their messages with NDEF which will limit the ability to do anything interesting with Windows Phone unless they take the step to redistribute cards (unlikely).

Either way, I think that we are going to see more and more NFC moving forward. It is already quickly taking hold with credit card/over-the-counter transactions, but so much more is possible with mobile integration. Maybe I’ll look at using NFC in between mobile devices next. The NFC wave is coming…kinda.

More Windows Phone 8 sillyness.

I’ve been watching the Windows Phone 8 conversation with great interest. I say conversation, but it has been kind of one sided. That said, Todd Brix who posted the most recent post (12 Sept) on the WP development blog has chimed in on the comments following the post. Here is a copy of what he commented:

I wanted to respond to those of you who are frustrated about the fact that we haven’t publicly released the Windows Phone 8 SDK. This year we’ve taken the approach of unveiling the new features of the OS as close to device availability as possible.  Unfortunately we can’t release the SDK without revealing all of the new features and capabilities.  I recognize this is a departure from how we’ve operated in years past and some of you are questioning our thinking.  That’s ok – let me give you a little more to consider.

Windows Phone 8 was designed to run the apps written with the Windows Phone 7 SDK which is available today.  Right now and for most devs the high-volume app development opportunity remains on the Windows Phone 7 SDK because these apps will run on phones available later this year, regardless of what OS version is on the phone.  If you want to help make sure your Windows Phone 7 app runs well on Windows Phone 8, when it is released, you’ll want to take a look at the Sept 12th post from Andrew Whitechapel . And while I know you want to test your app in our new emulator, the reality is that you will also want to do final testing with Windows Phone 8 devices which are not yet in market.

There are also devs who want to jump on new Windows Phone 8 technologies before anyone has bought a device, which is fantastic.  This is why we’re doing the early Preview Program. For those who don’t get the Windows Phone 8 SDK via the program, we will get the final SDK out in time for you to capitalize on the wave of new devices.

Thanks for your interest in Windows Phone!

Todd makes several good points in his comment:

  1. The biggest opportunity right now for Windows Phone developers is the 7.x generation of devices.
  2. They can’t release the Windows Phone 8 SDK without developers figuring out what the platform has on offer.

Unfortunately, the comment still completely misses the point. Firstly, even if I am going to target Windows Phone 7.x generation devices, I still want to work within the latest version of Microsoft’s IDE. Developers don’t just write Windows Phone applications, they build the backends which support those applications and when your vendor doesn’t continually bring their SDKs up to a level where you can use a single IDE they are effectively introducing a productivity burden. I want an updated SDK which allows me to use Visual Studio 2012, I’m actually less concerned about the Windows Phone 8 specifics right now.

The other point, which has been raised by others is that by sharing the SDK with some developers, they are effectively sharing the SDK with all developers. We are already hearing rumours about WP8 devices being found in the wild. It is possible that these are just unfounded rumours, but it definitely appears like they have RTM’d the operating system. Sorry guys – you can’t contain this stuff it will leak out. Developers will be pissed if they are the last to know – it is a great way to completely screw an product eco-system and fill it with ill-will.

So where are we after my previous post? Nowhere. I had hoped that Microsoft would quickly switch strategies and open up access to the SDK as soon as it was ready (so no super secret preview program). That is looking less and less likely now. Not only that, but it appears that Microsoft is suggesting that we should be happy and target the mobile platform with the most opportunity (see highlighted second in Todd’s comment). Fair enough – here are some statistics for you to consider (according to the Mobile Mix report):

  • 46% Android
  • 34% iPhone
  • 15% BlackBerry
  • 4% Windows
  • 1% Symbian

Time to leap to action! Go and download the Android SDK and the iOS SDK.

In-app purchases: Clarity is required for the Windows Phone platform.

About a week ago I was gob-smacked when the reality of the new in-app content purchasing policy from Apple impacted me personally. Occasionally I like to use my iPad as a way of reading books rather than my Kindle reader, especially if I am surfing and reading at the same time. On the day I realised what was going on I launched the Kindle application and went to search for a book – but the shop button had disappeared. I thought that I had gone crazy.

Eventually I did some searching and found about the policy change and that Amazon had complied not by giving Apple a 30% cut of content purchases, but by pulling the feature from their native Kindle application and then launching the Kindle Cloud Reader.

Apple’s move here may have just shot themselves in the foot. I can’t see many of my clients racing how and build native iOS applications when Apple has shown such a disregard for the viability of the application ecosystem. The problem is this policy will also negatively impact any platform which has a centralised application discovery service (AppStore for Apple, Marketplace for Microsoft, Android is somewhat decentralised).

I believe that Microsoft in particular needs to come out into the open with what they are planning around marketplace. At the moment there is no specific in-app purchasing API, so developers can roll their own and Microsoft doesn’t take a cut (good).

One would assume that Microsoft will tackle this at some point in the future. Regardless I believe that Microsoft needs to be clear about what their policy will be. Specifically, if Microsoft does introduce in-app purchases, will they stop applications using other mechanisms for purchasing content (and other goods/services) in preference to their API, and will they exclude applications from the marketplace until they do so they can make a commission.

To be clear – this isn’t Microsoft’s fault. Apple’s business practices have introduced uncertainty into the mobile developer community. So what does nirvana look like to me if Microsoft does come clear on what their policy is?

  1. Have a policy – and stick to it.
  2. It would be good if you did have an API, and a native experience.
  3. Be honest, you are going to charge a commission, but don’t make it 30%, be competitive with say, PayPal.
  4. Allow developers to choose whether they use your native API and experience, or roll their own to avoid the commission (although they’ll probably pay someone else anyway – so compete!)
  5. If you want to get really slick, but a backend platform that the likes of PayPal, “payclick” and other payment providers can plug  – so the consumer gets a choice (sure, may yours the default).

Come on Microsoft. Windows Phone is an awesome platform, this is your chance to show some leadership around the business side of the platform.