On "Responsive Design"

What your design should be responding to is the context of the user. Not just the device they're using.

It's about more than just screen size and capabilities.

It's about enabling the person using the software to get the value they want out of using the software regardless of which device they are using.

Of course, understanding the context of the user (so you can best give them what they want) requires consideration of more than just the size of the screen.

And although it should go without saying you can't put all the logic to do this on just the client side or just the server side. (Assuming you have both - some apps may only be client.) Some of the logic to do this will need to be on the server and some on the client. The client will tell the server general information to the server which will impact what the server returns. The client will then refine this to the specifics of the device. Allowing for consideration of its current configuration and its current environment.

Think before you truncate

There is a convention on Windows Phone to not wrap text but let it overflow the right edge of the screen.

This shouldn't always be done though.

There are cases where the text at the end of a sentence is REALLY important and it's more important to compromise the convention or the layout so that the information that matters can be seen.

Take a look at these directions (from the maps app).

In the second step, is the street I should take on the right or the left?

It's important I know. 

This shouldn't have been clipped.

The arrow doesn't make it obviously clear either. 

Fortunately, in this case, the apps supports rotation and by switching to landscape I can see that I need to take the road on the left.

It's a work around for this instance but not all apps are as good.
Even in this case though it would have been better if the app didn't give me that initial moment of confusion and frustration.

Is there anything you could do to your apps to make sure that the most important information is always visible?
Or would supporting both portrait and landscape orientations in your app allow the people using it to see things more clearly?

If you previously built Windows Phone games with XNA...

I'm still regularly asked what options people have for taking forward the games they originally built for Windows Phone 7 with XNA.
If you're not aware this question is driven by the fact that Microsoft removed XNA tooling and support from Windows Phone 8.

There are 2 main options: MonoGame or Unity.

MonoGame is an open source project that aims to provide the same options and APIs for building apps across platforms as were available for building with XNA on Windows.

Unity is a game developing ecosystem for building apps that work across a wide variety of platforms.

So which should you use?

If you already have a code base (based on XNA) that you want to reuse then MonoGame is the obvious choice.
If you have no existing code base or are happy to rewrite it then Unity is probably the way to go. Microsoft seem to be putting more emphasis on this as a solution for game development as it is popular with many big game studios and has a strong cross platform story. After all why would you build for just Windows when you can reach more potential users for your game by targeting multiple platforms?

Is this how things are likely to remain? Well, I don't see Microsoft changing their opinion about Unity in the short term. They've just bought a company who makes a plugin for Visual Studio to help with building with Unity.

SQLitePCL vs Akavache

Earlier this week I shared the news that there is now an "official(ish)" version of SQLite that can be used in what Microsoft calls "Universal Apps".

SQLitePCL Now Supports Universal Windows Apps! http://t.co/X31x3Zjw1t
— Windows Phone UG (@wpug) June 30, 2014

I was asked how this compares with using Akavache and if I have any recommendations?

If you're not familiar Akavache it's "an asynchronous, persistent key-value store for native applications". In that it can use SQLite as its data store and that both can be used in Windows and Windows Phone apps then the comparison question becomes even more relevant.

That's to risk potential confusion though. The underlying data source isn't really relevant. What matters is what their purpose is and what they're capable of.

The first big difference between the two options is in the type of data they can store. SQLite allows the storing of relational data. (It is a relational database after all.) Akavache can just store key-value pairs.

Of course you could just store key-value data in SQLite yourself. So why use Akavache?
The answer lies in what it adds beyond just being a key-value store. It is designed for working with (and storing) remote data that may be cached. Whether that's HTTP response, images or JSON data. Akavache adds more than just a key value store it provides smart logic for retrieving and caching remote resources.

So, my recommendation is that if you only need to store remotely sourced key-value pairs then use Akavache. If you need to store relational data then use SQLite.

Understanding the "second screen"

Recently I've heard a few people talking about mobile devices (primarily phones and tablets) becoming the "first screen" and televisions becoming the "second screen".

I think this based on a misunderstanding of what is meant by a "second screen" experience.
It's not about the amount of time that a person spends with a specific screen it's about the screen that provides the primary output and which screen supplies secondary data.
The screen supplying supplementary, extended or additional information about what is being watched on the primary screen.
For example, if you're watching a program on TV and also reading tweets about it on tablet, the TV is the first screen and the tablet is the second screen.
If you watch programs mostly on a tablet and only occasionally on a TV, the TV doesn't become a second screen.

Don't believe me? Ask wikipedia