These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
Paul LabergeDeveloper Evangelist
Frédéric HarperDeveloper Evangelist
By now, you probably are aware that when you’re building a mobile app or mobile website, trying to fit an existing PC-based app into a phone app isn’t the right answer. You have to be mindful of what you choose to put on a mobile app’s screen and where you lay it out. But that’s not the end of it. Understanding size of the various controls and which to show on the screen is also part of it. This post lays out the details of how to think about the size of your controls and some of the reasons why you should make certain controls bigger than others.
Designing the look and feel of your mobile app is clearly as much science as it is art. We have already discussed how rationalizing your UI for your app is a good thing and also how you lay out the controls and UI assets on each screen of your app. Now we will discuss the size of each control on your screen and what that really means to your app and how your user interacts with it.
If you will remember from the previous post in this series, I showed you how the effectiveness of the earliest version of the FourSquare app on Windows Phone diminished the usability of the app because of where controls were placed on the screen. As a refresher, I have added them to this post as well (FYI – Foursquare has rev’ed their app several times since then, including a new UI that is very clean and effective). As you can see, by placing the Check-In button on the app near the top, the view of the screen and likely the most important UI asset of the page (namely the map) are obstructed by your hand when you check in. While this may seem like a minor detail and one that users might not even notice, subconsciously this makes the app harder to use which then adds friction to the user experience. And as previously discussed, friction leads to lost users. Lost users means less use of your app which in turn means less revenue or “eyeballs” on your product (or both). In other words, don’t do that.
But that is not the end of the scenario. Once you have have placed the Check-In button in a more appropriate place (my suggestion is at the bottom of the screen but above the app bar (which will be discussed at length in the next post), then you should start thinking about how much space those controls should take. Take the following change from the screens above:
Note how all I have done here is move the “CHECK IN HERE” button from the top to the bottom of the screen, thereby eliminating the finger-obstructing-the-screen issue. There is still a problem here and it lies in the size of the controls on the screen. To the point:
The screenshot below gives an example of how a better screen layout might be for the app itself. Specifically:
Getting deeper into the last point I made above (i.e.: making buttons larger), there is actually some science behind it and it is known as Fitt’s Law:
While I love math as much as the next person (anyone who is in the middle of or completed a computer science degree like I did will know that you don’t get through it without have an affinity towards mathematics), the only way this equation would destroy more of my brain cells is if it included some differential calculus. So let’s get to the point of what Fitt’s Law is really about:
Okay. This is easier to understand. And amazingly simple and intuitive when you think about it! Always remember this when identifying which controls and screen assets you want to put on your mobile app’s screen and adhere to the spirit of Fitt’s Law when designing the layout. The key here is to reduce the friction in usability for your app, so make it as easy as possible for your app to be used, then you will have happier users and the likelihood of them returning to your app often is higher as a result!
The last nugget of info I will leave with you in this post is understanding the size of the human finger and the various guidelines that mobile platforms provide for minimum sizes of controls to use on a phone. Make sure you follow those guidelines as they will lead to a better user experience for your users and your adherence to these guidelines may make the argument for having your app featured in the Marketplace for your platform stronger.
Bottom line: the sizes vary from platform to platform (which is to be expected as each platform supports various resolutions and pixel densities) but they all state that in order for a control to be usable, it’s best to make sure that the finger is able to interact with the control with relative ease (Fitt’s Law at work, but in the guise of Interaction Guidelines).
This post is the third in a five-part series on creating awesome mobile UIs and creating your app with mobility-first in mind. The first post was on resisting the urge to recreate a PC or web app on the mobile form factor. The second post was on creating effective layouts for mobile platforms. The fourth post will be on when to use an app bar vs. populating controls on your app’s screens. The fifth and final post will be on implementing gestures and animations to make them useful to the app.
Securing your software product is one of the key, non-negotiable items you need to do before you release it and make it available to customers. Regardless of who you are, security should be top-of-mind when you build your Windows Phone apps as well. In this post, we’ll go over tips and tricks on how you can secure your Windows Phone app as well as touch on the various types of security you need to keep in mind when building your app.
Let’s call a spade a spade and say unequivocally that the world of technology is a vastly different and more dangerous place than it ever was even 10 years ago (or perhaps even one year ago…). The days where functionality of software being the primary focus are now gone, being replaced by a combination of functionality, experience, ubiquity, manageability and certainly not the least of which is security.
The world continues to change with new and stronger threats to be challenged every day. This includes our software creations. Clearly a black market economy has emerged around technology, specifically in getting data from software that may be valuable to unsavoury people looking to gain insights to the information that the software (or data stores used by the software) can provide.
There is an amazing book by James Gleick call The Information: A History, A Theory A Flood that talks about what information is, how it has evolved and explains in great detail what the value of information truly is. In it, Gleick makes a case for why information is important and how it has become a means for people to gain a competitive advantage.
When you look at software in its fundamental form (regardless of the channel – mobile, pc-based, web, service or otherwise), the only purpose it serves is to provide you, the user, with data that you can transform into information that you or your business can act upon based on the facts or probabilities it provides. The true value of your software is the information it holds.
Because the information your software product holds on your users’ behalf is valuable, you need to protect it. The viability and future of your software depends on your ability to build trust with the user and that includes making sure nothing that non-authorized users shouldn’t see gets leaked to them.
When I am talking to others about data security, I’m reminded of a great scene from the movie Heat (one of my all-time favourites, actually). The scene is near the beginning of the movie where Robert DeNiro’s character and Jon Voigt’s character meet with an unnamed man that knows when a certain bank is going to get an influx of bearer bonds in their vaults (which, of course, they decide to steal). At the end of the scene, DeNiro asks the man “How do you know this stuff?” to which the man answers (and I am paraphrasing) “It’s in the airwaves, all around us. You just have to know how to find it. I know how to find it.”.
That scene is actually really telling. You get a sense for how the human mind can find correlations across disparate, almost seemingly non-connected bits of data (in the case of the movie, the ability to get building blueprints from city, having information that a large shipment of bonds will be in the vault at a certain date and time, electrical schematics for disabling that specific bank’s alarms, etc.). Basically, your software is in a eternal battle against the vastness of intelligence and creativity of the human mind. Sounds daunting, right? Well, luckily for us as software developers, there are a number of tried and tested best practices that we can use to protect our software and they also work for Windows Phone. Some of these are listed below:
Since mobile devices figure out ways to get lost, if your app is expected to handle sensitive data (by sensitive, I mean private, confidential, etc.), make sure your data footprint on that device is minimal. A great example of this is the way banks in implement mobile banking apps in general on smartphones (and web browsers for that matter). Account numbers are never kept on the device – instead, mobile banking apps tend to use transient tokens (i.e.: non-permanent tokens that go stale after a certain amount of time) on the device that is paired specifically to that device and the user on the server side. In other words, full account data is not kept on the device and any data kept on the device goes stale quickly.
After figuring out what data would need to reside locally (however transiently) for your app to work, you must architect and plan for that data to be encrypted and isolated from other apps and system functions. Please remember, however, that if you are worried about security and privacy within your app and you have the option to store that data server-side, you should always do so.
In Windows Phone, make use of isolated storage for your local data. You can (and in the case of sensitive data, should) encrypt the data in isolated storage. Oh, and don’t “roll your own” encryption algorithms – you should use those provided by the .NET platform for Windows Phone if at all possible as they are tested and proven solid. That is, unless you love cryptomath, love creating salted hashes and get giddy at the though of getting home from work and scheming up new encryption methods to thwart hackers (if that rocks your boat, I strongly suggest you grab a copy of the applied cryptography bible written by Bruce Schneier – it’s a great book but not for the faint of heart).
(By the way, extra credit for those that can identify the typewriter-looking-thingy associated with this section!)
Challenge/Response is an old security pattern, but it is one that is very effective. Especially true in Line-of-Business app scenarios, but equally relevant in any case where you want users to prove their identity to the app, Challenge/Response is basically a request made by the app to authenticate themselves before they are let in the gate. Authentication is the process by which a user provides a user name and password (or something similar like biometric feedback or other methods) to basically act as a proxy to the app demonstrating the user is who he/she say she/he is. That’s all it is – permission to enter the property.
Authorization, on the other hand, is where the second line of defence resides and it is also the way apps with well-architected security really shine, in my opinion. Once you have authenticated, the app knows who you are. At that point, the app (and any server-side logic the app consumes) uses your credentials to determine what data you will have access to. For example, if your app was a fantasy football pool, a football league commissioner would likely have the ability to set new rules and send special, league-wide notifications to the members of the league, while as a regular league member using the same app would have access to only his/her fantasy football team. Authorization is the magic that makes this happen.
There are very few scenarios where you have a mobile app that has a requirement for security and encryption that doesn’t have a server-side or internet connectivity component. As such, make sure your mobile app does have a central management capability outside of the app itself (likely a web app for the server or something similar). If something goes wrong (especially if it affects more than one individual user), you are going to need a way to fix the issue quickly and through ways that won’t require you as a manager of the central data to have physical access to the app on the user’s device.
There are many more ways to secure your phone apps, to be sure, but these are some of the ones to start a discussion. Throughout the following weeks, stay tuned for further posts around data security in Windows Phone apps.
If you were born in the 70’s like I was, you may remember a show hosted by Leonard Nimoy called In Search Of… that explored unexplained phenomena and some of the theories behind it. Being young and impressionable, I soaked in the theories that this show presented about things supernatural and odd and I thought it was fascinating. As I got older, I realized that it was highly unlikely that many (if not all) of the theories the show presented had real merit, but it was good television (including the wicked 70’s fashion Leonard sported). In comical kind of way, you might feel that finding open source code targeting Windows might make for a great episode for a modern day In Search Of… You may feel that they are unnatural together and finding FOSS creations for Windows is an elusive challenge. Well, we have an answer for you that is a lot more solid than the often vapid theories the original show. There is a site that Microsoft (yes, Microsoft) created that is solely dedicated to allowing you as a developer to consume, create and host FOSS that benefits the entire developer community. That site is Codeplex.
If you’re familiar with Codeplex, you are probably already familiar with the value of the site. Some of the best open source software for Windows can be found here, including NuGet (if you don’t have and use it yet, you really need to check it out), JSON.net and even Windows Phone tools (which I’ll list later on in this post). Some are actually created and provided by Microsoft itself and some are provided by the open source community. All in all, it’s a great repository that you as a developer, whether you are targeting Windows Phone, Windows Azure, Windows 7 or even other platforms that work with Windows.
As I referenced above, there is a lot of goodness that Codeplex provides for you if you are targeting the Windows Phone platform. If you are building apps for Windows Phone, there are some projects on Codeplex that are nice to have access to as they make your life easier as a developer, but there are actually some tools on Codeplex that I consider absolutely essential to have in your belt before you even start building your app. Below are some of my favourites:
Now, of course there are a lot more projects available on Codeplex to support your Windows Phone application development and you may have your own favourites. If you have one you use a lot that isn’t listed, feel free to share on this post!
By now, most people have realized (in theory) that recreating a PC-based app (or web app) is not exactly the right idea for mobile apps. In practice, however, it is clear that this is not as easy as it sounds. When you’re building an app that has no history on the PC or web, building the app for mobile is a little easier as you can resist the temptation to add too much of the functionality from that original app to your mobile app. But even then, it’s not always easy to pare down the functionality of your app to a mobile screen. The original scope of your app when you wrote it down on a napkin in a bar while talking to friends was a great start, but like most other software projects, you find the urge to add more in with the expectation that more functionality means more useful. Cluttering your app with more controls is not the answer. This post will provide some guidance on how to thoughtfully build functionality for your app’s user interface so that it meets the right balance of complexity and usability.
Let’s face it. Aging paradigm or not, successful PC apps and web apps have the ability to make you very productive. Get in, do the work, get out fast (and maybe hang out a while to check out other parts of the app afterward). That’s the aspiration PC/Web app developers have for the users of their apps. A good example of this is Microsoft’s OneNote product (if you’ve never heard of it, it’s a relatively new addition to Microsoft Office and one of the best apps I’ve used for productivity – it’s singlehandedly replaced Word and Notepad for my free-form thought transfer and note-taking tasks). It’s awesome and has materially increased my productivity while using my laptop. It’s also a fairly “busy” tool with lots of bells and whistles in the control ribbon to help me get things done. I like to humourously call this traditional app design the PC and Web app “Mullet”.
On the top (or front), it’s all business, meaning all of the controls go at the top. The “party” as it were, is on the bottom (or back), which is another way of saying the valuable information (your content) goes there. It’s similar with browser-based apps, with the web controls going on the top and the content below it.
This design is actually a very effective one as it allows you to focus in on the content on the screen and use your mouse to modify the content through the ribbon at the top. But how does this translate to mobile apps? You may have noticed that the most user-friendly mobile apps don’t use this standard PC-based design for presenting information to the user. There’s a good reason for that.
Let’s use a very early iteration of the FourSquare app for Windows Phone as an example. This is what one of the screens looked like, and the issue that was found with it:
Do you see the challenge in using this screen? If you guessed that the Check-In button caused the screen to be obstructed when you used the app, you would be right!
By placing the check-in button for this app near the top of the screen, the user cannot see other valuable information that it provides, such as the location map and other functionality such as getting directions or calling the establishment the user was checking into.
You might provide the counter-argument that most users would likely use their thumbs to use the controls on the screen and you’d be right, but the general principle still holds; if you place critical components of your app near the top of the screen, you will obstruct the view of the rest of the screen from the user which is a usability no-no. In other words, controls that represent critical functionality of the screen should be placed near the bottom of the screen, not the top.
The FourSquare team noticed this usability challenge very quickly and iterated their Windows Phone app quickly as a result, which ended up in a much more usable screen for the user. The screenshots below show this change for the FourSquare app, as well as how OneNote for Windows Phone was designed with this principle in mind as well:
Notice the change here? This is the exact opposite of how traditional PC and web apps are designed. The content is front and center near closer to the top, and the controls are at the bottom. Ladies and gentlemen, I present to you the classic mobile app design that I like to call the “Reverse Application Mullet”.
It’s important to note how both examples to the allow the content of the app to take center stage. Any real functionality in this case is handled by the app bar at the bottom. Well save that lesson for the upcoming fourth instalment in this blog post series, so stay tuned for that.
It’s also important to note that if you compare the PC and mobile versions of OneNote, they are clearly very different in look and feel. They both allow the user to do the same thing but the implementation of each does look very different. Consistency in the look and feel of your mobile app and it’s PC-based app counterpart (if there is one) is not something you truly need to aspire to. Look at what the mobile version of your app is meant to accomplish and keep a furious focus on that functionality (I talked about that in my first post in this blog post series). When porting a PC app to a mobile app, scope creep is your mortal enemy.
The last thing I want to impart on you is the importance of grid-like placement of your controls in your mobile apps. Clean, consistent lines make for a more desirable user experience in mobile apps. When you have a large screen size (like PCs and web apps generally do), you can get away with less consistency in lining up controls as the size of the screen can hide imperfections. When you have a smartphone-sized screen, the story is completely different. Use a grid to place the controls on your screen. This will allow you to align controls and add consistency to the personality of your app.
You may hear designers for mobile apps talk about a concept of “magic numbers” for mobile app platforms. These numbers act as guidelines for you to design your mobile app screens with a consistency that aligns with the platform in general. For example, the Magic Number for Windows Phone (i.e.: Metro) is 12. The number 12 is indicative of the best offset (i.e.: spacing) in between controls. That is to say, when grouping controls together on the screen, don’t group them any closer than 12 pixels apart. With the offset of 12, Microsoft has built a handy version of this design grid that you can use to design your apps with the magic number of 12 in mind. Basically, the grid is a series of 25 pixel squares (12 squares wide and 20 squares long), each square offset by 12 pixels with a 24 pixel border around the edges. There are two great posts on the grid that I encourage you to read, the first by Jeff Wilcox found here (which provides a download to the grid and an example Windows Phone code project) and the second by Arturo Toledo found here (which provides a download to the raw grid files in various formats for your own use).
Below are some great examples how the Windows Phone team adheres to the grid principle in areas like the People hub and others:
You’ll notice how the various controls and screen assets adhere to the grid guidelines. This allows for a truly consistent experience across the OS and through your own app. And trust me on this, your users will notice if things are out of alignment. They may not necessarily be able to state outright what the issue is, but they will notice something is a little off in your app. It takes a little more time to build out your app’s screens, but in the end it is worth it.
This post is the second in a five-part series on creating awesome mobile UIs and creating your app with mobility-first in mind. The first post was on resisting the urge to recreate a PC or web app on the mobile form factor. The third post will be on the size of UI assets on the screen and why it is important. The fourth post will be on when to use an app bar vs. populating controls on your app’s screens. The fifth and final post will be on implementing gestures and animations to make them useful to the app.
In March, we are visiting four cities across Canada to give a full day workshop to help you get started building Windows Phone apps. In this workshop, you can expect to learn how to build apps for Windows Phone and have expert support for you to build your very own Windows Phone app or game. It’s a full day of learning, doing and fun – get brained up on Windows Phone!
If you live in or close to Montreal, Ottawa, Toronto or Vancouver and you want to learn how to build Windows Phone apps, this is an event you’ll want to attend. For $25, you will receive a full day of training and support in building your Windows Phone apps. Microsoft, in partnership with Wavefront, is offering this workshop to help you kickstart your app creation on Windows Phone, with the intent that at the end of the day, you will have the knowledge you need to not only start an app, but get far enough along that you’ll be close to publishing the app (depending on its complexity).
The registration links are here:
The agenda and details are as follows:
Wavefront and Microsoft are pleased to present a hands-on WaveGuide code camp for developers that will help you build your app and get you prepared to submit it to the Windows Phone Marketplace. With an application ecosystem that is continuing to not only grow, but accelerate in growth, now is the time to port your existing apps to Windows Phone and build new apps for the platform as well. In January, the Windows Phone Marketplace hit the 50,000 app/game milestone in just over a year, the fastest mobile platform to reach that mark.
The workshop will start off with a presentation that goes over the basic principles of building an app and how you submit it to the Marketplace. The intent of this presentation is to provide an overview of what you as a mobile developer can expect throughout the experience of building a Windows Phone 7.5 application. After the presentation, you will be able to begin building your own Windows Phone apps with support from Windows Phone experts and proctors who will answer questions that you may have. We will also have mini-lessons in regular intervals throughout the day to help you learn some of the deeper concepts of Windows Phone development. Attendees can choose to listen to these lessons or continue building the apps they started.
In order to participate in the workshop, you will need your own PC running either Windows 7 or Windows Vista. You must download the free developer tools ahead of time so you can hit the ground running rather than spend time during the workshop installing the tools.
Register by March 2 and your name will be entered in the early bird prize draw to win 1 of 2 Windows phones! At the event, you will be able to get hands-on with Windows Phone demo devices and enter for a chance to win your own!
Who should attend?
Reasons to develop apps for Windows Phone:
Hopefully we’ll see you there!
Ok, I admit it. The headline was a bit of link bait given how obvious it is. That being said, it’s surprising how often the mistake is made by app developers to add more features and screen activity than is necessary. This is especially true of developers porting a PC app to the mobile form factor. It’s actually really easy to fall into the trap of making an app busier than it needs to be. Good mobile app design is more than an appealing UI. It’s even more important to understand the purpose of the app and how it will be used. Take your cues from that and your app will be more usable to the masses. This post is the first in a five-part series on creating awesome mobile UIs and creating your app with mobility-first in mind. The second post is on placement of controls in your UI to be most effective for frequent use. The third post will be on the size of UI assets on the screen and why it is important. The fourth post will be on when to use an app bar vs. populating controls on your app’s screens. The fifth and final post will be on implementing gestures and animations to make them useful to the app.
A little while back, I wrote a 5-part Metro Primer blog post series that has received some pretty great reviews (thanks to those who shared your feedback on this series!). The intent of this series was to introduce you to Microsoft’s Metro Design Language if you hadn’t yet seen it as an app developer and if you had seen Metro before, to help you craft great Metro experiences. Metro is powerful and expressive and you can really create amazing and artful experiences for your apps with it. Like any other user interface paradigm, however, it’s just as easy (actually, maybe even easier) to create truly horrible experiences that ultimately hurt your app’s chances of being adopted.
This series of 5 blog posts (the others will be posted throughout the next few days on the Canadian Mobile Developers blog) is meant to be a companion to the Metro primer in that its purpose it to provide some good practices to use for your apps’ screens so that they are effective, intuitive and make your users come back to the app. Even if you never read the Metro Primer series, you might want to read this series as I will dive into tips that will make you think critically about how to build the UI for your app. And a little hint here – a lot of what I’ll talk about is actually platform agnostic. So if you are an Android developer, iOS developer or any other mobile platform developer, this content could be very useful to you.
Again, duh. Clearly they are not the same. Even the smallest of laptops are distinctly different from mobile devices. Yet many app developers make the fatal mistake of assuming a mobile app is just:
In the back of our heads, we all innately understand the concept that mobile devices and PCs are fundamentally different. But when we make the mistakes like the ones listed above (and trust me, app marketplaces across all platforms are littered with examples), it becomes clearer that the issue is not as cut and dry as it first seems.
Let’s face it. Even app developers that are currently in high school have earned a pedigree in understanding their way around a computer. In many cases, that history with PCs is long and full of experience building technology solutions that target PCs. When we make the change to becoming mobile app developers, we have a bias (whether or not we are aware of it) towards building apps that adhere to traditional PC software design principles, at least in part. Children in grade school are seeing a very different technological reality. Their first experiences in technology are just as likely to be on a mobile device (phone or tablet) than on a PC-form factored device.
If you take a look at the PC, it is a true workhorse tool capable of doing almost infinite things. It also has a lot of power behind it. It also has the ability to provide a huge amount of screen real estate. Mobile devices are by nature almost the opposite. They are capable of doing amazing things, but the use case is generally much more limited than that of a PC. Likewise, the power of the device, while equivalent in modern smartphones to PCs even just 5 years ago, is limited and the intent is to have it untethered from power sources for much larger amounts of time. Finally, screen real estate is generally fixed and often small.
As developers of traditional PC or web solutions, our mindset must change from creating apps that are scaled down versions of PC apps. That just doesn’t work. And believe me, it’s tough to remove yourself from a PC mindset when designing a mobile app. Instead, try to watch grade school children use mobile technology and try to understand the patterns they employ to get tasks done on those devices. The activities that grade school children do on mobile devices are much more pure to the spirit of the mobile form factor as they have no real past history on the PC form factor and provide hints as to how to best implement functionality in your mobile app.
The last point I will bring up in this post is to always keep in mind that we need to design for motion. By motion, I don’t mean crazy animation on the screen (that’s a topic for the fifth post in this series). I mean we have to design our app with the understanding that our users are always in motion. Your app will be used by someone that is just as likely to be walking to an elevator or shifting in the cold waiting for a bus as someone who is sitting at his/her desk.
In other words, this is what we think mobile experiences are like:
When, in fact, mobile experiences are more like this:
Busy user interfaces on mobile apps simply don’t work in truly mobile conditions. Users are not going to pay 100% attention to your app if they are on the move, so designing the user interface to take this in mind will make your app exponentially better to your users.
The following post is the second in a series about how to manage apps you’ve built after you’ve published them. The first post was an introduction to the series. This post talks about how to deal with application errors reported to the Marketplace after you have published your app. The series is written by Atley Hunter, one of the top Windows Phone app developers in the world and Canadian! This series was originally posted on Atley’s blog and is re-syndicated here with his permission.
As much as we all try, some of our apps crash. The more complex your app, the more libraries it includes, the more toolkits you utilize, the higher the risk of a crash when the user runs your apps.
We have all been guilty of it, I found out recently that I had an app that crashed all the time according to the users, but in my testing, I never did see a crash. This actually speaks of a different problem, testing your own software. If you can, get other people to test your software, preferably a mix of designers, software developers and most importantly, n00bs, neophytes and technophobes . The latter group will give you the best bang for your buck because they will do things to/with your software that you would never dream of and, guess what? They are actually your audience!!! You are building this software for them if you are trying to make money with it!
Now, back to the crashes… Horrible things, but they need to be dealt with. Bugs, we gotta squash ‘em. Here’s how to get a pretty accurate account of what is happening to your poor users.
You should regularly check with your App Hub account to see what is going on. (I am trying to write an app for us all to do, comment if you want this!).
To do this, go to your Dashboard for Windows Phone and look under the App Highlights. Here you will find a report that shows you your Most downloaded and Recent crashes.
Under the list of Recent crashes, you will see a list of any of your apps that have had crashes reported by the users. Click on the number of crashes listed beside.
This will take you to a screen called crash count (beta) which will show you when the crashes are occurring and allows you to download a file that contains the stack traces of the errors! A note: I usually select a start date way before I released the app to make sure that the report includes all the crashes!
Once the file has downloaded, you can then examine it for a wealth of information on the details of the crashes that the users have experienced. Everything from the Version of Windows Phone the user was using and the Problem Function:
To the Exception Type and how often that type of crash has occurred:
To the meat and potatoes of the Stack Trace (Format with Wrap for best readability ):
So, there you have it, you can harvest enough information to make sure that, with some adjustments, you can improve your users’ experiences with your apps and also extend your knowledge of the Windows Phone development framework!!!
The following post is the first in a series about how to manage apps you’ve built after you’ve published them. The series is written by Atley Hunter, one of the top Windows Phone app developers in the world and Canadian! This series was originally posted on Atley’s blog and is re-syndicated here with his permission.
I get asked a lot of questions that basically start out with – “I made my app, now what do I do with it???”
That is pretty much the thing that is in most, if not all, developers’ minds. You have built an app and now what? How do you make money? How do you support it? How do you improve it? How do you get more users?
Most of us are developers, not Project Managers, not Software Development Managers, not Solutions Architects, not Marketers, so once the code is done in our day to day work lives, it goes away, to be replaced by a new feature spec to be coded and released on it’s merry way. We do not see features again unless they are being changed/modified/enhanced or unless there are bugs.
This leaves some of us at a distinct disadvantage when it comes to the new paradigm of the One-Man-Software-Shop that the new ‘App’ markets have created. Some of us have done very well, some of us have done very not-so-well.
That’s where this series comes in. I am, or have held each one of those roles listed above in one capacity or another, plus I have a lot of contacts that currently hold those types of positions. I am going to do the research, testing and share what I find right here with you!
Check here often (or subscribe) and look for the WP App Lifecycle in the title and you will get all the info I find as soon as I can post it here!
I am very open to suggestions, ideas and questions, so please! Ask/comment/suggest away and lets all make awesome experiences for both our users and us!
Once you have built your app or game and have published it into the Windows Phone Marketplace, you’re likely going to want to monitor the uptake of your app via download and (potentially) revenue statistics. You are also going to want to find ways to market your app to people who may not know about it. There are several ways of doing this, some more costly than others. One of the most effective ways of marketing your app is actually completely free – have the Windows Phone Marketplace showcase your app! It sounds easy but there are a few things you need to do to increase the chances of this happening and that is what this post focuses on.
One of the more effective ways of marketing your app is being chosen for promotion in the Windows Phone Marketplace. We’ve seen how being promoted in the Marketplace can materially affect the download numbers of you app in a positive way. The Windows Phone Marketplace offers a great number of different ways your apps can be promoted as well, which we will talk about, but first here is a graphic that shows the different ways you can be promoted and how each type of promotion increases your downloads (based on averages from apps that have been promoted on the Windows Phone Marketplace in similar ways in the past):
In essence, there are 3 types of promotion available on the Marketplace and the graphic above shows those ways. Each has value and being featured in any of those buckets can mean good things to the adoption of your app or game. Each type of promotion is unique and their values are described below:
As you can see, being featured is very much worth your while. While your app is featured (usually for a period that lasts anywhere from 3 to 5 days), you will likely see a noticeable uptick in your app downloads which you can then amplify through any other marketing methods you choose to use throughout your app’s lifecycle.
So you’re sold on the whole featured app thing and want in. How exactly do you get your app featured? While there is no specific steps that will guarantee your ability to be featured, the featured apps process is implicitly a fair one (the best, most popular apps will bubble up to the top). If you feel you have a great app or game, you should read the following sub-sections to get a better understanding of how the Marketplace team assesses quality apps.
A functional app is more than one that passes the Marketplace certification. Think of a functional app as a contract between yourself and the user. When a user downloads your app or game, they are likely doing so either from the description of your app on the Marketplace, it’s screenshots or by recommendation from friends or other users (including ratings). In any case, they expect your app to have an experience that is consistent with any of those inputs. If it’s not, then the app is likely to be less popular and as a result, be less likely to be promoted.
An app that shows utility is one that thoughtfully includes features that take advantage of the Windows Phone platform. Features like Live Tiles, Search Extras, multi-tasking and the like. It also refers to apps that differentiate themselves with amazing user interfaces that are both visually appealing as well as intuitive and productive. The Marketplace team also look at the stickiness of the app, which is another way of saying “is this an app that users will use often?”.
The final area of differentiation that the Marketplace team will look at in apps and games is how the app will delight users. This is where most featured apps really, really shine. If the app shows a “wow factor” (a decidedly unscientific term for sure, but you generally know it when you see it), if it is really unique and has something that no other app or game has, then that is a way that your creation will delight users.
A must for the delight factor is proper and effective use of Metro, the Windows Phone Design language. This is more than just square tiles and lots of text. To implement Metro properly, you need to take into account a number of principles of the Metro design language (see here and here). If your app follows these principles properly, your app will look amazing on Windows Phone and have a truly awesome experience on the platform.
As you can see, you need to think hard about the quality of your app if you hope for it to be featured. That said, the payoff of getting featured might very be worth the effort you put in.
I have just one last tip for you before this blog post series on Marketplace success strategies is finished: When looking at apps to build, sometimes being featured is a numbers/statistics game. If there are categories within the Marketplace that are currently underserved compared to other categories (for example, as of the publication date of this post, the Politics section is light in apps compared to other categories like Entertainment and Sports), then your chances of getting featured are that much greater. Just food for thought…
This post was the fifth and final post in a series of five posts on strategies for being successful on the Windows Phone Marketplace. The first post (publishing in the right geographies) is here. The second post (trial mode and the art of the upsell) is here. The third post (finding the pricing sweet spot) is here. The fourth post (the differentiation game) is here.
A good number of us from the team are in Redmond this week on our annual pilgrimage to the mothership (Microsoft Headquarters) for training, so content from me will be a little lighter than usual.
As a result, I wanted to share with you a set of links and resources that are new to help you learn more on Windows Phone development and also a reminder of some older links that you might want to bookmark as well.
Five-Part Series on Metro Design
Five-Part Series on Succeeding on the Windows Phone Marketplace
A five-part series on strategies you can use to increase the adoption and downloads of your app/game on the Windows Phone Marketplace.
When a mobile app marketplace hits a population of five figures, it becomes a little tough at times to have your app stand out of the crowd. Even if your app or game is the most awesome thing ever invented since the spork, it’s still tough to get that initial traction when there is a sea of other apps that also get users’ attention. One of the ways to gain that traction is to create an app or game experience that is fundamentally different (in a positive way) from your competitors’ apps and even making your app stand out across apps that are not even related to yours. Experience trumps almost everything, so if you make the experience of your app amazing, then you will get traction sooner or later.
Differentiation is one of those buzzwords that seems to find its way into most tech-related conversations these days. It’s right up there with the phrase leveraging synergies. That said, there is a time and place for every word and phrase and I’m going to use Differentiation in this post.
Mobile app stores are funny things, really. When they are new and therefore not very populated, users complain that they can’t find the apps they’re looking for. Then, when a mobile platform takes off and becomes popular, users complain that they can’t find the apps they’re looking for. Interesting similarities, aren’t they.
If the marketplace is new, it’s much easier to get traction when your app is awesome because the focus becomes squarely on your app or game. This post isn’t about that scenario. This post is about getting your apps and games to stand out in a crowded marketplace (the Windows Phone Marketplace is rapidly getting to that state with over 50,000 apps published and growing and a fast clip on top of that).
The rest of this discussion will focus on strategies to make your apps and games shine and therefore get your users’ attention by implementing great features that will rock your app experience.
The first thing you really need to do to succeed in differentiating your app from the rest is understand your mobile app platform. The more your know about the capabilities of your target platform, the easier it is to determine scenarios under which your app will really shine on the platform. Be creative with the capabilities; maybe there’s something you could do with a feature like push notifications in your app that no one has ever done before.
It also means to understand the personality of your target platform. In the case of Windows Phone, this is largely about the Metro Design Language (more on that here). If you were talking about iOS, the personality is more glassy and bubble-oriented. For Android, it looks like Google has adopted something similar to Metro (focus on typography, flat style, etc.). Going against the native style of the phone platform makes your app jarring. That said, a jarring interface is likely going to differentiate your app from competitors but you have to be careful; it the app doesn’t feel like it belongs, then users will likely make sure it doesn’t belong in their app list, either.
I talked a little bit about experience already in this post (and others) and it may sound a bit like a broken record, but I cannot stress the point enough that a great user experience sells more apps. Users want to be delighted. Users want to have intuitive interfaces. Users want the cool features they expect in the mobile apps they already use in your app and they expect something different as well. It’s up to you to define “something different” but suffice it to say, it’s that extra added touch that makes your app that much more in demand.
Ultimately, the experience of your app defines a journey for your user. There are three stages to this journey as well and you need to think about all of them:
Now that we’ve talked about strategies on differentiation in a fairly general sense, it’s time for me to give you examples of features on the Windows Phone platform that you can use on your apps to create amazing (and differentiated) experiences that make your app more marketable!
Hopefully this article gave you some new ideas on how to make your app more marketable. If you have found more ways to make your app more successful in the Marketplace, feel free to share!
This post was the fourth in a series of five posts on strategies for being successful on the Windows Phone Marketplace. The first post (publishing in the right geographies) is here. The second post (trial mode and the art of the upsell) is here. The third post (finding the pricing sweet spot) is here. The fifth post (how to get promoted in the Windows Phone Marketplace) is upcoming on this blog.
Ah, the ultimate question for developers trying to maximize their profits on the Marketplace: “What should I charge for my app?” The question is simple. The answer is always far from simple. As a developer who spent intense and likely long hours making an idea come to life in the form of a Windows Phone app, honing it and tweaking it and then tweaking it once more, this decision is an agonizing one. Fear, uncertainty and doubt creep into your head… What if I overprice it? Even worse, what if I underprice it? How many apps will I have to sell/distribute to break even? Every single app situation is unique; there isn’t any single silver bullet that can solve your pricing questions. This post is meant to provide you with a set of tools to help you come to an answer to that incredibly important question.
$5.99 for that? Are they crazy? How many times have you found an app you wanted to purchase but balked at the price? Probably quite a few times. And here’s an even more interesting question: After balking at that price the developer is charging for that app you want, how often have you bought it anyway (even if you had to walk away first and then come back later to purchase it)? It’s a good question and says a lot about the psyche of the typical consumer with app shopping on the mind.
The most successful entrepreneurs selling apps and games on application Marketplaces (it really doesn’t matter which mobile platform we’re talking about here; Windows Phone, iOS, Android, Blackberry – it’s all the same for this context) have something in common. They know their market, their target customer and the purchasing behaviour of their customer. In other words, they intrinsically know the true value of their app to prospective purchasers.
So how do these successful app publishers know what price to charge their app? Well, frankly they do their homework. Think of it this way: if you were in the market to purchase a fast food franchise, I’m guessing you wouldn’t just hand over a suitcase full of cash to the franchisor and say “Here, now gimme my franchise!”. Of course you would research it first! Things like how much does the franchisor charge as a startup fee? What are the recurring franchisor fees? Are there minimum revenue targets required to keep the franchise? Is there an ideal (or at least good) location for my franchise? Is my location going to attract the clientele I am targeting? etc., etc., etc.
It’s essentially the same thing with pricing an app. Doing your homework (and not cheating or copying, mind you) goes a long way to driving the success of your app. For example:
The equation above is about as obvious as it gets. But your revenue goals may vary greatly from other publishers’ revenue goals. Are you looking to break even? Make a profit? Make a monster profit? Every decision comes at a price so be aware of the cost of your goals.
There are basically three revenue models in the Windows Phone Marketplace (at least, the way I see it).
Free is free. As in beer. Meaning you build the app, you publish the app and make it available to anyone and everyone with a Windows Phone for free with no real strings attached. In this model, price = 0, meaning your revenue is also 0. There are lots of reasons why you would want to build free apps, but I’ll leave it to you to think of some of them.
Freemium is free, with a catch. The catch could be implemented in a number of ways. The most obvious way is advertisement-supported. That means that you are giving away your app for free to anyone on the Windows Phone Marketplace who wants it, but you are generating your revenue from ads that exist on the app. There are tons of apps in the Marketplace that have adopted this model. The catch to you as a publisher, however, is that the revenue stream you get from this model will vary. The revenue you get from an app in this model depends not only on the number of downloads, but also how often the users will open the app. If users download the app and open it once, your revenue will be small. If your app is popular and often used, however, the app may actually far exceed the revenue you would get from a paid app. For more info on how freemium can work, there’s a really great blog post by the author of the Krashlander game that you might want to check out about how his app did.
Paid apps are exactly what you would expect. Users download your app and (eventually) pay for it and continue using it. If you price your app or game right, this model is a great one as you can almost forecast the revenue you get from your app in the Marketplace based on download trends and run rates. If you use the paid app model, however, please be aware of a few things:
As you can see, pricing your app correctly requires work on your end. Do your homework and it will likely pay off in spades for you. That said, you can still have a number of tricks up your sleeve to entice users to buy your app. I discuss some of them now:
Good luck! If you have other pricing strategies that you have found worked, feel free to comment!
This post was the third in a series of five posts on strategies for being successful on the Windows Phone Marketplace. The first post (publishing in the right geographies) is here. The second post (trial mode and the art of the upsell) is here. The fourth post (differentiation using Windows Phone-specific features like Live Tiles and Push Notifications) and fifth post (how to get promoted in the Windows Phone Marketplace) are upcoming on this blog.
Part 2 of this 5-part blog post series on success strategies in the Windows Phone Marketplace deals with a fairly unique component to the Windows Phone platform called Trial Mode. If you make use of trial mode in your paid apps and games (and you really, really should if you plan on putting a price on your app/game), then you are making it much more likely that users will download your app and in response to that, make the possibility of them paying for your app much higher as well.
If your aim is to publish a Windows Phone app or game and charge money for it in the Windows Phone Marketplace, then you really should get to know a nice feature of the platform called Trial Mode. Trial Mode allows you to publish your app that you charge users to make use of, but gives them a free trial mode of the app so that they can download it and make use of it to determine whether or not they want to purchase it. And the beautiful thing about Trial Mode is that it means you don’t have to create a second, stripped-down version of your paid app that you have to manage separately from your paid app – both your trial app and paid app are one and the same, with the trial determining how your app will behave.
While it may seem counter-intuitive to provide a free version of your paid app, consider these statistics that the Windows Phone Marketplace team has published describing the opportunity using trial mode in your apps represents:
Basically, what this means is that if you implement trial mode in your paid app/game, you will get an average of 70 times the downloads you would have gotten without trial mode and 10% of those trial mode downloaders will actually buy your app/game. That works out to 7 times the number of paid apps you will have earned than if you hadn’t used trial mode at all.
What do you want it to be? Seriously, that is the answer – we don’t limit the definition of “trial” to something we say it is. Basically, we offer an API to query the Marketplace to determine if the user of your app has paid for it or not and you decide the behaviour of your app if the user has not paid for it. In other words, the trial for your app is whatever you want it to be, including but not limited to scenarios like:
There are two scenarios that are covered really well in the MSDN knowledgebase. The first shows details on how to implement Trial Mode in a Silverlight app. The second shows how to implement Trial Mode in an XNA-based game.
If all you want to see is code, I have implemented trial mode in the following Silverlight sample here (a Visual Studio project in a zip file).
As you saw from the code examples above, trial mode is extremely versatile. Ultimately, it’s your choice as to how you implement a trial in your app or game. That said, there are a few tips that can make your trial more effective, both for your end goals of having the user buy your app in the end as well as maximize the trial experience for your app’s users so they see the value of the work you have published. Some of the things we have found are:
Remember, if your app is a paid app, you want to add a trial. Given that trials are common in the Windows Phone Marketplace, if you have a paid app with no trial, I can tell you that you are leaving a lot of money on the table as not many users will take the chance on your app. Just some food for thought.
This post was the second in a series of five posts on strategies for being successful on the Windows Phone Marketplace. The first post (publishing in the right geographies) is here. The third post (pricing strategies) is here. The fourth post (differentiation using Windows Phone-specific features like Live Tiles and Push Notifications) and fifth post (how to get promoted in the Windows Phone Marketplace) are upcoming on this blog.
Last week I presented a marathon, three hour webcast called “A Lap Around Windows Phone 7.5”. This webcast provided developer content and demos on how to build apps that take advantage of the new and improved features of Windows Phone 7.5, as well as going over some strategies for making your app successful in the Windows Phone Marketplace. This webcast is now available on-demand here.
Abstract: A Lap Around Windows Phone 7.5
Windows Phone 7 presents a fresh user interface and a smartphone platform with a unique value proposition for consumers, businesses and application developers. Windows Phone represents a new way to interact with friends, family and work in a mobile context and it delivers this experience in a way that is both productive and enjoyable. In this online event, Paul Laberge from Microsoft will provide you with an overview of the Windows Phone 7.5 platform from a application developer’s perspective as well as present the market opportunity that Windows Phone provides you as a developer. By the end of this session, you will be able to begin developing applications for Windows Phone and understand some of the most effective ways to market your solution in the Marketplace.
Duration: Three Hours
Available on-demand here. Please note that it requires you to register (for free) on the site if you haven’t already; if you need to register, be aware that it takes a few minutes for your registration to activate so you may need to wait a little bit before getting to the on-demand webcast.
Assets for the webcast (presentation deck and code demos) are available here.
If you’ve built modern mobile apps, you probably already know that coming up with the idea for the app/game and coding it is really only half the battle. Success is largely determined in the marketing strategy you adopt for your app. There are quite a few strategies that you can take and you can likely mix and match them, but there is no one “silver bullet” that will make your app an instant success. This post is the first in a series of five that will give you an idea of some of the ways you can help your app become a success in the Windows Phone Marketplace.
There’s a statistic that was published by analytics vendor Localytics that states that only 26% of all mobile apps downloaded are ever opened more than once. That’s actually a little higher than the numbers I’ve heard around mobile app circles, but still that number is quite astounding. What it means is that for a myriad of reasons, most users are interested enough to open your app but quickly lose interest and either delete right away or never open it again. Those odds are not good, so if you intend for your app to be popular, you need to adopt a strategy that will give you an edge and compel your user base to make use of your app more than once.
There are multiple things you need to do before your app is ready for consumption. One is to have a great idea (this is pretty much non-negotiable in my opinion). Second, you need to build it the right way (i.e.: great functionality, application flow, pleasant interface and intuitive app design). Third, you need to figure out a way for your app to make your users awesome in the moment. All this before your very first user even thinks of downloading your app.
At the same time as building your app, you should be thinking about how you’ll market it once it’s ready. Over the next 5 days, I’ll be posting an entry per day discussing some of the strategies you can employ to help make your app or game more successful on the Windows Phone Marketplace.
Making your apps available on as many markets that make sense to support, not ALL markets possible
The context of this first post is about understanding which geographies you can make your app available in. Your first answer to “which countries should your app be available in?” might be “All of them, of course!”, but keep in mind a few things. The correct answer to this question is that you should assess which countries your app will have value to users and how you will be able to support those users with your app.
For example, there is a fantastic app called “Where’s Timmy?” that RedBit Development created and published that is a consistently popular one in Canada. While there is nothing that limited Redbit from making the app available in every single market, the purpose of the app is to locate the closest Tim Horton’s coffee shop from your location. Tim Horton’s is very popular in Canada and growing in popularity in the US, but has no presence in Europe. As a result, Redbit did not publish the app in European countries but did publish it in Canada and the US.
Another consideration to take into account is localization. Making your app available in many markets may require you to support many different languages for your apps. You must make a judgment call as to which languages you wish to support. While this adds to the complexity of your app from a maintainability perspective, it enhances the local user’s experience while using the app. By localizing the content of your app to the appropriate language and culture considerations, you will likely have better adoption and better ratings for your app in the Marketplace.
Markets Supported by Windows Phone
So with that said, what markets are currently supported by Windows Phone? The graphic below shows which markets are supported (countries highlighted in yellow are markets that have been supported since launch in November, 2010 while markets highlighted in green were added just recently).
Marketplace distribution and targeting the right locales is one of the strategies for being successful in the Windows Phone Marketplace. Stay tuned for further Marketplace strategies over the next few posts on the Canadian Mobile Developer Connection, where I’ll talk about the trial API, pricing strategies, differentiation using Windows Phone-specific features like Live Tiles and Push Notifications and finally, how you can get promoted in the Windows Phone Marketplace.
This post is the first in a series of five posts on strategies for being successful on the Windows Phone Marketplace. The second post (trial mode and the art of the upsell) is here. The third post (pricing strategies) is here. The fourth post (differentiation using Windows Phone-specific features like Live Tiles and Push Notifications) and fifth post (how to get promoted in the Windows Phone Marketplace) are upcoming on this blog.
Tomorrow (Thursday, January 19, 2012) at 1PM ET/10AM PT, I will be conducting a three hour webcast on how to develop for Windows Phone 7.5 and an overview of the Windows Phone Marketplace. During this webcast, I will discuss and show how to implement Windows Phone 7.5 features in your apps like using the accelerometer, camera, fast app resume, local database, push notifications like live tile notifications among other features.
If you are interested in learning about the new and improved features of Windows Phone in version 7.5 of the OS, I would like to invite you to join in on a webcast I will be conducting on developing apps for the platform. I expect it will be informative and fun and hopefully you can join us! If you cannot join live, have no fear as the webcast will be recorded (I will update this post at some point after the webcast is done, probably in the week of January 23 with the link and resources).
Windows Phone 7 presents a fresh user interface and a smartphone platform with a unique value proposition for consumers, businesses and application developers. Windows Phone represents a new way to interact with friends, family and work in a mobile context and it delivers this experience in a way that is both productive and enjoyable. In this online event, Paul Laberge from Microsoft will provide you with an overview of the Windows Phone 7.5 platform from a application developer’s perspective as well as present the market opportunity that Windows Phone provides you as a developer. By the end of this session, you will be able to begin developing applications for Windows Phone and understand some of the most effective ways to market your solution in the Marketplace.
Date: Thursday, January 19, 2012
Time: 1PM ET / 10AM PT
Duration: 3 Hours
Registration Link: http://mctreadiness.com/MicrosoftCareerConferenceRegistration.aspx?pid=287
Date: Thursday, January 19, 2012
Time: 1PM ET / 10AM PT
Duration: 3 Hours
Registration Link: http://mctreadiness.com/MicrosoftCareerConferenceRegistration.aspx?pid=287
I look forward to seeing you there!
UPDATED: This webcast is now available on-demand here. Please note that it requires you to register (for free) on the site if you haven’t already; if you need to register, be aware that it takes a few minutes for your registration to activate so you may need to wait a little bit before getting to the on-demand webcast.
It’s been a little over a year and a half since the Windows Phone Marketplace opened for business for developers to create and publish apps. Without a doubt, there have been a few hiccups, but the great thing about the Marketplace team is that they have responded to multiple points of feedback and have acted on it. In fact, I just found out that joining the Marketplace as an individual publisher has become a whole lot easier!
When the Marketplace opened, there were a large number of traditional Microsoft platform developers that signed up for accounts so they could publish apps and games for Windows Phone. Since then, the health of the app ecosystem has consistently grown stronger with each passing day – the Marketplace actually now has over 50,000 apps and is growing at an increasingly faster clip. This is a feat in of itself that none of our competitors can say a year into their phone platform being commercially available.
Since then, the Marketplace product team have tweaked the experience for publishers to make it easier and more valuable to invest in the platform, with growing the number of markets that apps that can be sold in, abolishing the need to fill out a paper-based W8BEN US IRS form to get the revenue from your apps (there are still some things you need to do according to US tax law, but this process has become much better).
And just today, I found out that individuals signing up for a Marketplace account are no longer required to go through the GeoTrust identity verification step to finish your Marketplace registration (companies still do, however). This is good news as it means that you don’t have to wait to submit apps to the Marketplace for certification anymore. Once you’ve signed up, your account status will appear as “Account Pending” until you actually submit your first app for certification. Once you’ve done that, then your account goes live.
This isn’t breaking news, but it is something that I found interesting!
Thanks to Adam Bell (@b3ll) for the tip!
If you waited on reading my 5-part Metro and Mobile app design series until the final post, there’s great news in that you can now read each of them online. Also, if you want an overview of the developer perspective of Windows Phone, from a development standpoint as well as a Marketplace and marketing strategy standpoint, I will be conducting an in-depth webcast on this on Thursday, January 19th, 2012.
Last week I published a five-part series on Metro and mobile app design in general. It has received a great deal of interest and I wanted to make sure that everyone that was interested in reading the full series knew where to find it. As a result, you can find the 5-part series here:
Finally, as a heads-up, I will be conducting a webcast on developing for Windows Phone 7.5 on Thursday, January 19th at starting at 1PM ET (10AM PT). In this webcast, I will be talking about how to develop apps for Windows Phone 7.5, discussing the Marketplace and strategies for making your app more marketable on the Marketplace and I’ll probably smatter in some of the concepts I talked about in my blog series above as well for good measure. If you’re interested in joining me, you can register for free – I’ll “see” you there!
Have you ever sat down and really thought about what made games like Guitar Hero and Rock Band so successful? Certainly the challenge of competition had something to do with it. But at its very heart, all those games are is a challenge to hit the right coloured key on a device (guitar, drumkit or otherwise) at the right moment. That’s it. So why did those games achieve such popularity? Well, it doesn’t take much to realize that these games cater to our inner fantasy of being a rock star. Seriously, who hasn’t thought of how awesome it would be to be performing in front of 50,000 screaming fans that love your every move? These games have achieved making users awesome in the moment. As a mobile app/game developer, if you can achieve that same emotional connection to your user with your app, I’m guessing your app will be quite successful too!
Mobile apps and games are interesting things. Around 5 years ago (not that long ago!), mobile apps and games were considered niche and not many people paid attention to it. Then Apple came along and changed the game with the iPhone. A stream of consciousness that every mobile platform company had finally awoke. Apple got there first, but now there are many other great mobile platforms (like Windows Phone) with great and increasing momentum and how these platforms support their application and game ecosystems has become just as important as the OS experience itself.
Windows Phone is a now a modern smartphone platform with features that are on par as well as ahead of our competitors. We also have amazing velocity with our app ecosystem, having hit over 50,000 applications in our marketplace in just over 1 year of availability. Clearly, developers see the value.
But one of the things that Microsoft is keenly aware of is making sure that good quality applications are prevalent in the Marketplace rather than 20,000 “Hello World” apps or apps of equally dubious value. This is an area where Windows Phone is doing very well. A good number of the app developers on the Marketplace have embraced and found out that their success is tied to making their users awesome in the moment.
It is pretty obvious if you take the bullet points above and integrate them into your mobile app that you will likely have more success with its adoption than if you didn’t. These ideas are not Metro-specific or even Windows Phone-specific; they are true of any mobile platform. But what do these points really mean?
Don’t make the user think about the interface: Interfaces can be minimalistic or busy depending on the goal of the app. Always remember, however, that regardless of how busy the interface is, the goal is to ensure the user doesn’t have to think about how to use the app! Make the app intuitive. Make it fun. Make it easy. Remember the quote I used in the first post in this five-post series? A user does not want to use your app. A user wants to have used your app. The quicker a user can get done what they need with your app, the happier they will be.
Deal with complex tasks, but insulate the user from the complexity: Your mobile app may do rocket science in the background but the intent is to insulate the user from that complexity.
Make accomplishing a goal easier: The intent of a mobile application is to get stuff done quickly. Always keep in mind the form factor you are dealing with; simple is usually better and reduction of complexity is key.
Help users be awesome in the moment: I’ve talked about this quite a bit already so I’ll finish with this – creating an emotional connection with a user for your app is critical to its adoption. The phone is a deeply personal piece of technology. We all tend to choose which phone we use and its often our own choice as to which apps we use the most to get things done. When a user downloads your app, they are hoping that your app will make them awesome. Always keep that in mind.
This post is the fifth and final post in a series of posts on Metro found on this blog. The first post (“Unlocking the motivation of your mobile app user”) can be found here. The second (“My app has principles – understanding the Metro design principles”) can be found here. The third (“Isn’t “tile” just another word for “icon”? Infography vs iconography explained.”) can be found here. The fourth post (“Going with the flow… Using Metro to control the experience”) can be found here.
Figuring out the flow of your mobile app is tough but it’s key to the experience. Without good app flow your app will be tough to use and users will get annoyed with it. Annoyed users tend not to use the app that annoys them. In fact, there’s a statistic that only 1 in 100 apps downloaded by a user actually gets opened a second time – those aren’t good odds, so anything you can do to entice the user to come back will increase its chance of success. A way to help drive a positive app experience on Windows Phone is to follow the guidance provided by the Metro design language. This post talks about what Metro can do to help you create a great navigation experience for your app.
Even before you do layouts for each screen of your app, chances are you are charting out the navigation of your app. Which screen goes where, how to determine under what conditions the user may go to the next step, etc. It certainly sounds trivial as it’s written, but in truth it’s one of the hardest tasks to do right in app design.
The flow of your app very much defines its character, more so than any screen.
Metro navigation guidance comes from 5 separate areas, each of which are related but focus on separate components of application flow.
Hub and Spoke Model: The intent behind the hub and spoke model is that you have a home screen for your app that basically all other screens are navigated to in a linear fashion. That is to say, you get to each screen in your app by following a line. There are no short-circuits in your navigation structure. If you take a look at the image to the right, the main screen is the one that is green. As you can see, the correct navigation structure for the app follows the black lines to the other screens (also black). A “short circuit”, the line in red with the “x” through it, creates a loop that can confuse navigation (and even potentially break some of the Marketplace certification guidelines on back button functionality).
It’s also important to note that the structure found in the image above can be recursive in nature. What I mean by this is that one of the black screens may even be replaced with a copy of this diagram (or another hub/spoke structure), with the green screen being one of the black screens. That being said, I caution you on making navigation structure between screens as simple as possible; complexity breeds confusion and confusion creates frustration, leading the user to abandon your app’s use.
Trust the Hardware: You may have noticed that every single modern Windows Phone device (i.e.: any Windows Phone 7 or higher versioned device) has only 3 hardware buttons on the front. Yes, these devices may have various other hardware buttons on the sides of the device, but only 3 appear on its face. These 3 hardware buttons (shown on the right), are the Back button, the Home button and the Search button. Each are easy to understand – “Back” sends you to the previous screen or out of the app if you are on the app’s first screen. “Home” sends you to the home screen of the phone, regardless of what screen you’re on at that point in time. “Search” invokes the bing search app, regardless of where in your current app you’re in.
The reason this is important is because the first two buttons in particular provide a consistent understanding of navigation to the user regardless of which app he/she is using. You must adhere to their functionality in order for your app to pass certification. In other words, do not create your own soft key back buttons or soft key home buttons. Use the hardware for the purpose that it has been built for.
Avoid Traps, Loops and Phantom Pages: As I stated before, each of these guidance areas are separate but related. This area of guidance actually is a sum of the two points above. Traps are described as getting to a screen without a natural way to get out. You can fix this by implementing the back button functionality in your app properly. Loops refer to avoiding short circuits (the red line and x in the Hub and Spoke Model diagram) that may create loops in your navigation. Phantom pages refers to making sure that there is actually a natural way to get to every screen in your app. If there isn’t a natural way to get to that page, it is extraneous and should be removed. It also refers to pages with little-to-no purpose. In reviewing the content of each of your screens, ask yourself if the content is better served as part of another screen, thereby eliminating that phantom page altogether (and reducing complexity in the process.
Be Predictable: Try to make your application flow predictable enough that your user can anticipate what the next screen will be. Conversely, make your app easy to understand with the back button. If you have to press the back button of your app more than 4 or 5 times to get to the main screen of your app, your app is likely too complex or the flow of the app could be better architected. Also, always implement the hardware back button functionality properly in your app; as discussed above in “Trust the Hardware”, the back button is how you should get to the previous screen if no action is taken on the current screen.
Being predictable also refers to maintaining a consistent experience for your app even when its use is interrupted by events such as a phone call, low battery, the user pressing the Home screen or other event that causes the app to exit. Your app should exit gracefully by saving state as appropriate (including tombstoning techniques). This will increase the chances of your app being able to return the user back to the screen and state the app was left at before its interruption.
Integrated Experiences: Some of the more interesting features of Windows Phone are its hubs. Hubs are areas of the phone OS that collect common information so that the user does not have to go to multiple locations or apps on the phone to get the information or content he/she is looking for. The great thing about these hubs is that you as an application developer can integrate features of your app to make use of hubs. The reason why this is important is twofold:
By managing the flow of your application through these points of Metro guidance, your app will feel more natural and native to Windows Phone. This in turn will create a more enjoyable and productive experience for your users while in your app!
UPDATE: Arturo Toledo has just published an in-depth view of Hub and Spoke design (and linked to this post as well!) in his 31 Weeks of Windows Phone Metro Design series (a MUST READ for any Windows Phone dev or designer). I strongly encourage you to take a look at it!
This post is the fourth in a series of posts on Metro found on this blog. The first post (“Unlocking the motivation of your mobile app user”) can be found here. The second (“My app has principles – understanding the Metro design principles”) can be found here. The third (“Isn’t “tile” just another word for “icon”? Infography vs iconography explained.”) can be found here. The fifth and final post (“Making users awesome in the moment”) can be found here.
Icons are everywhere. Literally everywhere. They have become as mainstream as apple pie and any time we’re in front of a computer or other digital device, chances are you’re launching an app through an icon. But what if there was a better way?
We are inundated with icons wherever we go. On the PC desktop, on tablets, on websites, on phones and pretty much everywhere else. Icons are very useful as they are an abstraction of a concept that our brains can associate with that makes it easy to understand and launch an app.
But as an abstraction of a concept, all an icon does is act as a gateway to the user to launch an app. It doesn’t provide any real information. When we introduced Windows Phone, we also introduced the concept of the “tile”. A tile is much more than an icon. In the very base case, a tile is like an icon, but to you as an Windows Phone application publisher, the tile can become much, much more. The intent of a tile is to provide information to the user, not just an abstraction of a concept. This is what we call being infographic vs. iconographic.
The intent of Live Tiles is to present information that the user can act upon. The tile becomes more than a a picture; it becomes something that allows the user to find information about that particular app without even getting in it. For example, looking at the Windows Phone start screen (right-most phone screen), without getting into an app I know that that I have:
All of that information at a single glance, without needing to open a single app. As an app developer targeting Windows Phone, you can take advantage of Live Tiles in your app to drive further value for your users and differentiate your app over others in the Marketplace.
If you want to find out how to use Live Tiles in your apps, you can find more information on programming with Live Tiles here.
To see live tiles in action, take a look at the video below by Daniel Egan, a colleague of mine in the US:
This post is the third in a series of posts on Metro found on this blog. The first post (“Unlocking the motivation of your mobile app user”) can be found here. The second (“My app has principles – understanding the Metro design principles”) can be found here. The fourth post (“Going with the flow… Using Metro to control the experience”) can be found here. The fifth and final post (“Making users awesome in the moment”) can be found here.
This infographic can be found on the Windows Team blog, but it’s a great summary of how the Marketplace formed in 2011 and what was popular (and what wasn’t):
Metro is gaining popularity as a way to create compelling app designs for Windows Phone. It’s theme is distinct and very oriented towards providing the user with information. At the same time, given its emphasis on information, it is more than just presenting data on the screen. A well-built Metro app follows a set of principles that make the app truly flow and through that makes the app useful.
The marketing for Windows Phone often proclaims it as the glance and go platform. The intent of this catch phrase is to convey the fact that you can get information from your phone in only a very short amount of time looking at it. And from that quick glance and the information you retain from it, you can decide the course of action you want to take from it, be it opening your email client to check your email, find out who called you, answer a Twitter message, or even grab that umbrella because your weather app told you that it’s raining outside. The platform really tries to live up to that glance and go mantra.
But how does an app use Metro to achieve the glance and go goal? Like life, there is really no one answer to that question; your creativity as the author of the app plays a distinct role in this process and guides it to its finish. That said, free reign to do whatever you want can lead to issues with the experience the app provides its users.
With great power comes great responsibility.
That’s where the Metro Design Principles come in.
The principles as laid out in the graphic above are meant to provide you with a set of guidelines for building your app using Metro the right way. What it is not is a blueprint. The guidelines above are not meant to define your app or its personality; the intent is to allow you room to express the creativity of your app.
So, with that said, here is a brief description of the principles as laid out above:
Clean, Light, Open, Fast: This refers to the flow of the app. How is the experience of the app from the user perspective? Is it responsive and dynamic? Is it inviting and usable?
Celebrate Typography: Rarely is text mistaken for art (at least in the visual sense; in a literary sense it is absolutely – one of my personal favourites of literary text as art is Ken Follett’s Pillars of the Earth, but I digress…). In Metro, however, text is very much artful. Because Metro is very text-driven (again, due to its focus on information), how you use fonts and how you place text on the screen is very important. That said, your app should not be only text; this is a common misconception with Metro. Use text wisely. Use it as much as you need it and no more. Make sure that the text flows with other screen assets like images, video, buttons, etc. It should look and feel natural.
Alive and In Motion: This principle follows closely with Clean, Light, Open, Fast. Your app should not feel or be static. Use animation (but not too much to cause negative distraction). Use of colour is important (you know those apps in the Marketplace that are black backgrounds with white text and not much else? Yeah, those apps may look “metro-ey”, but they are not really Metro). Make sure your app invites interaction with the user. Your app should compel the user to explore and use your app.
Content not Chrome: When we say “chrome” we speak of the facilities of the app meant to provide peripheral functionality. Chrome in this context are things like app toolbars, system information like battery life remaining, URL bars, etc. Your app should focus on giving the prime real estate of your app to its content. Content is king. Not buttons.
Authentically Digital: In the times of the Renaissance, there was an explosion of discovery that made a permanent impression on the human condition and how we view ourselves. Art, science, philosophy, social awareness – all of it was viewed through new lenses with the guidance of genius of the likes of Galilei, Michaelangelo, da Vinci, Machiavelli, Copernicus and others. The world was their canvas and the expression in their creations were limited only by their own creativity. We, on the other hand, are not afforded the boundlessness that these great thinkers had in the physical sense. The unlimited potential of the apps we create are truly found in their digital nature. This is because apps are limited by the form factors that they are housed in. The art and awesome power of the app are found in the bits that are interpreted by the hardware.
The content of this post is just a very brief description of the Metro Design Principles. If you want a truly immersive description of them, I encourage you to check out Arturo Toledo’s post titled 31 Weeks of Metro Design | #1 Metro Design Principles and the Metro Design Language.
This post is the second in a series of posts on Metro found on this blog. The first post (“Unlocking the motivation of your mobile app user”) can be found here. The third post, "Isn’t “tile” just another word for “icon”? Infography vs iconography explained." can be found here. The fourth post (“Going with the flow… Using Metro to control the experience”) can be found here. The fifth and final post (“Making users awesome in the moment”) can be found here.
When you look at successful mobile apps and games, there are a few common traits that you will notice in them. They all achieve a certain set of goals that may be subtle or completely obvious (or both!). If you harness the power of motivation for your app user, you have created an experience for your app that will make that user use your app more often than others, make them champions for your app to their friends and family, and generate word of mouth that will increase the popularity of your app in ways that traditional marketing simply can’t do.
At the heart of things, mobile applications are simple. They solve problems that may be simple or complex, but the way apps solve problems is by making it simple for the user to get done what they need to do quickly. Really, that’s the crux of it and it’s a bit of a corollary to traditional (i.e.: desktop/web) apps:
A user does not want to use your app. A user wants to have used your app.
The quicker a user can use your app and achieve the results he/she was looking for, the happier he/she will be and the more likely he/she will use your app again. Just think about the mobile scenarios below:
Success (in my opinion) is dictated largely on the user’s ability to do any of the above as quickly as possible.
So now that we have established that task completion speed is key to the successful adoption of an app or game, let’s dive more deeply into the basic motivations of any mobile app. If you joined me on the latest D3 episode with my partner in crime, Jonathan Rozenblit, you will have heard me talk about this. These motivations are as follows:
The three motivations, as described by Josh Clark in his amazing book Tapworthy, are that every user of a mobile app is one or more of the following:
If your app has an answer to one or more of these motivations and you’ve implemented it the right way, then guess what? You may have a marketplace winner on your hands! If your app doesn’t satisfy any of these motivations or doesn’t execute well on them, then you probably should rethink how your app should work.
By the way, if you find it odd that I’m talking about a book targeting iOS as a way to create successful apps on Windows Phone, the truth of the matter is that learnings from this book are very relevant to building apps on any mobile app platform.
This post is the first in a series of posts on Metro found on this blog. The second (“My app has principles – understanding the Metro design principles”) can be found here. The third post, "Isn’t “tile” just another word for “icon”? Infography vs iconography explained." can be found here. The third post, "Isn’t “tile” just another word for “icon”? Infography vs iconography explained." can be found here. The fourth post (“Going with the flow… Using Metro to control the experience”) can be found here. The fifth and final post (“Making users awesome in the moment”) can be found here.
Happy New Year! With 2012 upon us and a fresh outlook on what a new year can bring, you might have a few ideas up your sleeve for apps/games that you’ve always wanted to build. Windows Phone should definitely be one of the platforms you target for your upcoming masterpieces; given the momentum the app ecosystem for the platform is seeing now is the time to seize the moment and publish. In this post I’ll give you a glimpse of what we will be providing on this blog to help you get to your goal.
2011 was an exciting year for Microsoft with a number of new and updated platforms announced and introduced. One of these platforms getting a lot of coverage not only from Microsoft but also in the press is Windows Phone 7.5. With the major update that was launched in the second half of the year (version 7.5, also commonly referred to by it’s former code name “Mango”), the platform reached a level of maturity and capability that puts it on par and even ahead of its staunchest competitors like iOS and Android. This update provided developers with a way to build truly innovative experiences that users will not only love, but come back to again and again.
If you’ve been interested in targeting Windows Phone for your apps and games this year, now is the time to take the plunge. The tools are free, we have lots of guidance and get started material for you to learn and get going quickly, great incentives for Canadian developers like The Developer Movement and a platform that literally is fun to build on.
Even with all that, you may be feeling a little overwhelmed and not know where to start. To help you with that, the rest of this post will give you an idea of what we will be doing to help you in 2012 get to where you want to be. The information below will provide you with overviews of some of the things we will be providing you online.
You can expect to find a wide variety of “snack-sized” (i.e.: short and to-the-point) video tutorials on how to take advantage of the Windows Phone platform. The intent of these videos is to provide you with information that you can take immediate action on in your apps. We won’t be building full apps in these videos; rather you can expect us to focus on features of the platform you can take advantage of in your apps.
It’s all well and good to read posts or watch videos from Microsoft employees to give you guidance on how to build your Windows Phone apps and games. Getting the information straight from the company is the only way to get official product information. That said, there are developers just like you that have real world experience developing for the platform. The good, the bad and the tricky. We will be providing guest posts from community members that are building apps/games on Windows Phone (whether they are new to the platform or veterans with lots of apps under their belts). These posts will be authored by people that have built or are building apps for Windows Phone, have built apps for other mobile platforms (like iOS, Android and the web) and have hard-earned guidance that they can share with you so you don’t fall into traps that can make you spin your wheels.
In addition to guest posts and video tutorials, we’ll be conducting interviews (video, podcast or text-based) with some of the leading Windows Phone developers in Canada (and believe me, some of these people are the best Windows Phone developers on the planet – Canada is well-represented in the Windows Phone developer community). In these interviews we’ll be talking about their experiences targeting Windows Phone, their experiences porting apps from other platforms to Windows Phone and their ideas of the mobile app industry in general.
We’ll be providing you with details about specific Windows Phone apps and games that were built by Canadian developers to give you an idea of how they achieved the success they did. In addition to that, we’ll be providing information on some of the choices they made from a technical, business and marketing perspective, and more importantly, why they made those choices (and whether they were the right choices – nobody is perfect and it’s usually the wrong choices that make for the best learnings).
So, does this sound interesting and valuable to you? We have a few tricks up our sleeves that we’re working on as well, but hopefully this piqued your interest! If you have other ideas we’re also listening, so if you suggest something that’s doable, we’ll take you up on it.