I had a great time last night at the Windows Phone Meetup in Silicon Valley. Many thanks to all that attended and thanks to the Nokia folks for hosting the event. There were a ton of great questions and comments. I hope you all go out and start localizing your apps for the 63 consumer markets now waiting for them.
I spent the last 2 weeks traveling through various countries through Europe talking to developers of all kinds. The whirlwind tour through 7 countries in 14 days gave me an opportunity to hear many ideas and concerns and to learn about what developers are out there building.
If you attended one of the events where I was speaking, thank you so much for your participation. I enjoyed every single one of those. There was a ton of great comments and questions. Clearly, there is some passion out there for development on Windows Phone.
Over the last week of the tour I focused mostly on Windows Phone 7.5 Refresh at events in Denmark, Finland, Austria and Italy. At those events I gave an update of Windows Phone 7.5 Refresh. I also provided some developer guidance for devs who are building apps and provided some info on how to optimize apps to adapt to the new requirements of lower end devices. To encourage developers to take advantage of the many new countries and languages we now support, I also provided an overview of how to localize apps . Finally I gave you some tips on publishing and more importantly some guidance on how to make a bigger impact with the apps you’re publishing.
I promised to post my slides for those events so I’ve now made those available for you to download. I’d love to hear feedback about the events, any topics I presented or any other issues you may have hit.
Feel free to let me know your thoughts via the comments below or via private message using the blog contact form.
Bad stuff happens! There is no way around that. It’s a fact; your apps, out there in the wild on consumers devices, will crash. This in itself is ok but only if you can get the information about those crashes and use that information to fix the bugs that cause them. The Windows Phone platform actually captures stack traces and provides those to you, the publisher of the app. You can get a view of the number of crashes that are happening as well as download an Excel file with all the appropriate information and stack traces. This is a good thing and you should take advantage of that information as it may give you some good clues as to what to fix to make your app a higher quality product.
There are a few things that App Hub does not give you though. The first thing is that it may not give you enough information about the bugs that you are hitting. One example of that is that the version number of the app is not provided so if you have published a few different versions of your app it is possible that a user is hitting a bug that you may have already fixed in a later version.
The other issue is that stats on App Hub are delayed. As a result you don’t see the issues that your end-users are hitting for a few days. If something is happening out there that is causing a lot of crashes then you may not see it until after users start posting lots of low ratings and negative reviews.
Another thing to keep in mind is that App Hub does not provide any sort of notification of issues. It’s up to you to visit App Hub regularly and pull down those stack traces to see what’s going on.
Finally (and I realize this is more a perception thing than an issue) end-users have no idea that the platform is gathering up those stack traces and making them available to you. And, of course, they have no idea if you are looking at those traces and working on bug fixes. As a result, when they see a bug most will assume the worst and give bad ratings and reviews. As I’ve mentioned on a previous post you really want to make sure that, whenever you can, you provide the ability for the end-user to provide you feedback as that helps build a relationship which ultimately will result in higher ratings and ranking.
Fortunately there is a way to get around all of these issues. Andy Pennell, a colleague on the Windows Phone dev team has posted some sample code which he dubbed Little Watson that I think every developer should include in all their apps. Just like “Big” Watson does on Windows, that code does exactly what you would expect in that it captures all that stack trace info (including additional info you may need) and allows the end user to email it you so you can get to work fixing whatever bug caused the error.
Little Watson is pretty easy to use. There are a few steps that you need to do:
The first is to include the LittleWatson.cs in your project
Then you need to let Little Watson know every time an exception happens. When you do that Little Watson captures the trace info to isolated storage. This is done by calling LittleWatson.ReportException. You’ll need to do that in both RootFrame_NavigationFailed and Application_UnhandledException. Both of those are in App.xaml.cs
Finally to allow the end user to send you the stack trace you’ll need to add a call to LittleWatson.CheckForPreviousException() in the constructor for your main page (i.e. whatever page it is that your app launches into, usually that is MainPage.xaml.cs). When you make that call Little Watson checks for an exception report file in isolated storage and if one exists prompts the end user to send it to you via email.
Since Andy blogged about Little Watson, other devs have grabbed that great idea and taken it further. One example of that is the Northern Lights open source project. Northern Lights has many different capabilities that are useful to Windows Phone developers. One of those is an implementation of Little Watson based on the work I mentioned above from Andy Pennell. One thing that Northern Lights does beyond Andy’s code is that they provide you the capability to automatically send the trace info to a web service behind the scenes so that the end user does not have to see it. You should probably be careful in doing something like that. As I mentioned above, it might actually be a good thing for end-users to know that you care about bugs. You may also want to be careful about sending stuff to a web service behind the users back. Some users will get freaked out about that if they notice. This would be especially bad if you were including any sort of Personally Identifiable Information (PII) along with those traces. In general, you’ll probably want to let users know somehow that you are doing that and definitely stay away from capturing any PII.
Below I’ve included the source code for the project I used in the video. It’s a ridiculously dumb app but I often get asked for source so I’m including it here for completeness.
Let me know what you think about this episode of Top Ranked.
If you have questions about any of the videos, about problems or issues you’re hitting or if you have topics that you think would be of interest to other devs on the Windows Phone platform then drop me a note. I’d be particularly interested in hearing about some of the best practices you’ve adopted that you think have raised your quality or your ratings/ranking in the Marketplace. I’ll be sure to give full credit and link love whenever I can.
The Top Ranked series is hosted on Channel 9. You can view all the past videos there. You can also subscribe to the entire series via Zune or iTunes. All of that is available here: https://channel9.msdn.com/Series/Top-Ranked
Misaligned elements is probably one of the most common issues I see with apps in the marketplace. In this episode of Top Ranked, I delve into why this is an issue and how easy it is to check for that and fix it. Alignment is a part of the overall Metro design language. I’ve even seen some designers in our UK COE group actually put post-it notes on their screens or on a device to verify that elements align properly. This acts as a sort of forcing mechanism for them to check alignment. The reason they do that is that you may not explicitly notice that stuff is out of alignment but when it is, you intuitively feel like something is off. In general your app will feel a little sloppy when the element alignment is out of kilter.
The Metro design language does take alignment into account and as a result there are some things that you can keep in mind when designing and building pages. The magic number 12 seems to resonate throughout the experience. Most elements in the native apps align up in a grid of one form or another.
The ingenious Jeff Wilcox built a development utility that makes getting the alignment right super simple. This utility is called MetroGridHelper is also simple to find since you can grab it with NuGet. Once included in your project you turn it on in App.xaml.cs in the same place where you turn on and off the frame rate counters and redraw regions etc. You simply add MetroGridHelper.IsVisible = true; in the if block where the profiling info is included. By doing it there you are assured that you will only ever see that grid when the debugger is actually attached (i.e. only in development). When you run your project with the MetroGridHelper turned on, you’ll see a series of red squares layered over every screen in the app. Those squares are strategically placed to make it really easy for you to see when elements are out of alignment.
Another thing to keep in mind while we’re talking about element alignment is the amount of space you leave to allow users to tap on an element (like an item in a list for instance). Again here the magic number 12 is the number that you need. Make sure that you have at least 12 pixels between tappable items so that the user can easily tap the item they want as opposed to mistakenly tapping nearby items.
You can read up on Jeff Wilcox’s MetroGridHelper on the original blog post but really all you need to do to use it is to grab it using NuGet.
Let me know what you think about this episode of Top Ranked.
If you have questions about any of the videos, about problems or issues you’re hitting or if you have topics that you think would be of interest to other devs on the Windows Phone platform then drop me a note. I’d be particularly interested in hearing about some of the best practices you’ve adopted that you think have raised your quality or your ratings/ranking in the Marketplace. I’ll be sure to give full credit and link love whenever I can.
The Top Ranked series is hosted on Channel 9. You can view all the past videos there. You can also subscribe to the entire series via Zune or iTunes. All that is available here: https://channel9.msdn.com/Series/Top-Ranked
In this episode we talk about pricing and more generically about market testing. I know, I know, marketing is probably not every coders favorite subject. I bring it up as I’ve noticed many apps in the marketplace that are underpriced. Apps that are cool, differentiated or do something of great value to the consumer can clearly support higher price points. No user is ever going to ask you to charge them more for your app so the task of picking the right price point falls on you. The easiest way to do that is to do market testing aka A/B testing (or split testing, bucket testing etc.). In this episode I refer specifically to price testing for paid apps but this technique could easily be used to test for other things that might increase revenue in paid apps or downloads in free apps. All sorts of things like categories, descriptions, keywords, or artwork can be affect the performance of your app and so could be optimized.
As I mentioned above, from what I’ve seen in the marketplace many developers will underprice their apps. They seem to be optimizing for number of downloads. That is indeed what you want for free or ad-supported apps but for paid apps you probably want to optimize for revenue and that formula is a simple one everyone knows: revenue = paid downloads x price. If you optimize for downloads then likely you are in a race to the bottom; i.e. how fast you can get to the $0.99 price point.
Since you have 2 variables to optimize and only one which you have any control over, the easiest way to optimize for revenue is to test different price points and watch the number of paid downloads at each point. Obviously if you want to maximize revenue then you want to get the highest price possible for your app. To do that start at a high price. Over time you may need to drop the price (e.g. for competitive reasons or for sales or promotional events).
So the obvious question is: how do I do market testing on the Windows Phone marketplace? Since you cannot vary pricing by market in the marketplace the way I recommend is to submit the same app with the same metadata twice. You would do that to two different markets that have very similar buying behavior. Examples of markets that have similar buying behavior are US/Canada, France/Belgium, Germany/Austria, or Australia/New Zealand. By doing this you can do your A/B testing; i.e. by maintaining all things equal except for pricing then you can figure out what price the market will bear for your app.
Let me know what you think about this episode of Top Ranked.
If you have questions about any of the videos, about problems or issues you’re hitting or if you have topics that you think would be of interest to other devs on the Windows Phone platform then drop me a note. I’d be particularly interested in hearing about some of the best practices you’ve adopted that you think have raised your quality or your ratings/ranking in the Marketplace. I’ll be sure to give full credit and link love whenever I can.
The Top Ranked series is hosted on Channel 9. You can view all the past videos there. You can also subscribe to the entire series via Zune or iTunes. All that is available here: https://channel9.msdn.com/Series/Top-Ranked
As part of our efforts to help developers get started with building their applications and games on the Windows Phone 7 platform we’re planning a couple of events in Redmond (May 18-19) and Silicon Valley (May 25-26). If you’re interested, be sure to register using the links below.
Abstract
Get a jump-start on building apps for Windows Phone 7 with this 2 day hands-on training event. You’ll learn how to build Silverlight or XNA applications that take advantage of the many Windows Phone 7 platform features.
We’ll introduce all the basic topics required to get started building Silverlight applications or XNA games. We’ll cover the Windows Phone 7 platform, the frameworks and both designer and developer tooling. We’ll also cover the process for publishing your application or game to the Marketplace. Topics covered will be reinforced with hands-on-labs where attendees practice on their own laptops.
This event will take a basic approach so, while it may be helpful to know Visual Studio etc, that will not be a prerequisite. Developers new to the platform are welcome (encouraged, even!) to attend.
Attendee Prerequisites:
Attendees are expected to bring their own laptops to follow along and to participate in the Hand-On Labs.
Supported Operating Systems: Windows 7 or Windows Vista
Windows® Vista® (x86 and x64) ENU with Service Pack 2 – all editions except Starter Edition
Windows 7 (x86 and x64) ENU – all editions except Starter Edition
Installation requires 3 GB of free disk space on the system drive.
Minimum 2 GB RAM
DirectX 10 capable graphics card with a WDDM 1.1 driver
Technical Prerequisites: To save time, be sure to have the following installed on your laptop before arriving for the event:
This event is free of charge. However, attendees are responsible for booking and paying for their own travel and accommodation. Both breakfast and lunch will be provided for session days.
I’m getting to this party late but I just had to post a link to this. I’m in awe of Chris Craft who took the challenge to write 30 Windows Mobile apps in 30 days. And Yes, that’s including weekends. So from June 1 through June 30 he posted those 30 apps complete with source code. I love that.
Oh, and he’s not taking a break. No. He’s now on 31 days of Visual Studio Tips and Tricks.
I had a great time last night at the Windows Phone Meetup in Silicon Valley. Many thanks to all that attended and thanks to the Nokia folks for hosting the event. There were a ton of great questions and comments. I hope you all go out and start localizing your apps for the 63 consumer markets now waiting for them.
I spent the last 2 weeks traveling through various countries through Europe talking to developers of all kinds. The whirlwind tour through 7 countries in 14 days gave me an opportunity to hear many ideas and concerns and to learn about what developers are out there building. 
