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 “CHECK IN HERE” button is the primary activity of this screen.  As such, don’t you think it should have a more prominent surface area on the screen?
• The map is the primary visual component of this screen and yet it only takes roughly 1/6th of the screen’s size.  Probably not a bad idea to give it more space to shine as well.
• The “Get Directions” and “Call” buttons, while not as important to this screen as the “CHECK IN HERE” button, are small and tough to tap, relative to the rest of the screen.  As secondary control features to this screen with a fair amount of use by the average user, you might want to give those controls more prominence on the screen as well.

The screenshot below gives an example of how a better screen layout might be for the app itself.  Specifically:

• Note how the “CHECK IN HERE” button is much larger than it was before.  As the primary control on the screen, this is critically important to removing friction from the experience for the user.
• The map is larger, at roughly 1/4 the size of the screen compared to the 1/6th screen size.  This makes it easier to show where the check in location is and a primary visual cue to the user on what to do on this screen.  (and yes, I cheated on the map control as I just stretched it in this case, but the intent is that you you don’t do that and instead show more of the map)
• The “Get Directions” and “Call” buttons now span the width of the screen, making them more visible and easier to hit.  An even better idea would be to have these two buttons larger in height and existing side-by-side rather than stacked as it makes it easier to tap the button with your finger.

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:

Where:

• T is the average time taken to complete the movement
• a is the start/stop time of the device
• b is the inherent speed of the device
• D is the distance from the starting point to the target’s center
• W is the width of the target, measured along the access of motion

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:

Fitt’s Law:  The bigger and closer a target is on the screen, the easier it is to hit.

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.

• Windows Phone (discussed in the Windows Phone UI Design and Interaction Guidelines): 34 pixels / 9mm minimum
• iPhone (as discussed in the iPhone Human Interface Guidelines):  44 pixels / 7mm minimum
• Ubuntu Linux (discussed in Ubuntu Designing for Finger UI’s):  16mm to 20 mm minimum

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.

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:

1. Understand your apps data needs and ruthlessly cut out data that doesn’t need to be on the device.

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.

2. Any sensitive data that must sit on the device for the app to run properly should be isolated and encrypted.

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!)

3. Challenge your users to prove themselves:  authenticate and authorize

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.

4. Central Management Capabilities are key

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:

• Silverlight Toolkit (this one is a must-have):  The Silverlight Toolkit and Silverlight for Windows Phone Toolkit provide the developer community with new components, functionality, and an efficient way to help shape product development. Toolkit releases include open source code, samples & docs, plus design-time support for the Windows Phone platform as well as the Silverlight browser plugin.
• Windows Azure Toolkit for Windows Phone (if you’re targeting Windows Azure with Windows Phone, this is a must-have):  The Windows Azure Toolkit for Windows Phone includes libraries, project templates, samples, and documentation that help you to quickly take advantage of Windows Azure with your Windows Phone applications.
• Windows Phone 7 Design Templates (must-have):  A project for sharing XAML based resources for creating consistent Windows Phone 7 user experiences. The templates are based on the UI Design and Interaction Guide for Windows Phone 7. With these templates you can easily create common Windows Phone UI layouts by simply copying and pasting the desired page. We’ve taken care of the margins, styling, and custom controls that may not be available in the platform.
• Windows Phone 7 Isolated Storage Explorer (must-have): WP7 Isolated Storage Explorer is a tool designed to help developers and testers interact with the isolated storage file for Silverlight Windows Phone 7 applications.  The explorer can work both as a desktop application for testers or integrated in Visual Studio for developers.
• Windows Phone Powertools (must-have):  The Windows Phone Power Tools are a natural extension to the developer tools that come with the Windows Phone SDK. Instead of allowing you to only install developer xaps the Power Tools let you test update scenarios by allowing you to update an existing developer app. Instead of having to step through the IsolatedStorage file browser on the command line, the Power Tools provide a GUI to allow you to interact with your applications.
• Windows Phone 7 Ad Rotator (nice to have):  An ad rotator control for Windows Phone 7 with Silverlight and XNA support.  Supports showing ads from different providers with configurable probabilities based on culture. The control fetches the settings from a remote XML file making real time swapping / replacing of ad providers possible.
• Simple MVVM Toolkit for Silverlight, WPF and Windows Phone (nice to have): Simple MVVM Toolkit makes it easier to develop Silverlight, WPF and WP7 applications using the Model-View-ViewModel design pattern. The purpose of the toolkit is to provide a simple framework and set of tools for getting up to speed quickly with applications based on the MVVM design pattern. The emphasis is on simplicity, but it contains everything you need to implement MVVM for real-world line of business applications.
• Sterling NoSQL OODB for .NET 4.0, Silverlight and Windows Phone (nice to have):  Sterling is a lightweight NoSQL object-oriented database for .Net 4.0, Silverlight 4 and 5, and Windows Phone 7 that works with your existing class structures. Sterling supports full LINQ to Object queries over keys and indexes for fast retrieval of information from large data sets.
• Silverlight and Windows Phone Augmented Reality Toolkit (nice to have):  SLARToolkit is a flexible Augmented Reality library for Silverlight and Windows Phone with the aim to make real time Augmented Reality applications with Silverlight as easy and fast as possible.

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!

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:

• Montreal (March 26, 2012)
• Ottawa (March 27, 2012)
• Toronto (March 28, 2012)
• Vancouver (date to be announced; link will be made available once the date is available)

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?

• Developers with an iOS or Android app ready to port to Windows Phone
• Experienced developers wanting to learn more about the opportunity and looking to build Windows Phone applications

Reasons to develop apps for Windows Phone:

• Showcase your apps that may be buried or lost in other saturated Marketplaces
• Increase your reach to a new audience of early adopters looking for great apps
• Windows Phone developers are well supported and rewarded, check out http://www.developermovement.com/ for details

Agenda:

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.

The Smartphone is not a PC

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:

• A scaled-down desktop
• A smaller screen
• A PC with less computing power.

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.

Designing for motion

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.

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.

What to Do:

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!!!

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!

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:

• Panorama Placement:  Panorama placement is the premiere placement for promotion on the Windows Phone Marketplace.  In essence, the when a user opens the Marketplace app on his/her phone, that user will be greeted by a panaroma image of your app (this is the panorama image that you included with your app upon its submission for certification).  The value of this placement is immense as we have seen a 2000% increase in downloads for an app (on average) that is featured in panorma mode.
• Featured Icon Placement:  Being promoted as a featured icon is the second best way to be featured on the Marketplace.  Your app/game will be seen on the very left portion of the screen of the panorama of the Marketplace (i.e.:  if you flip the screen left by one full phone screen).  Your tile is prominently shown as is the app name, basically enticing users to tap on it and explore what your app entry on the Marketplace says.  Apps that get Featured Icon Placement on average see an 800% increase in app/game downloads during their time being featured.
• Featured List:  The third mode of getting featured in the Marketplace is the Featured List.  In this list, your app will be featured alongside a number of other apps.  Featured List apps appear in the list of apps in the categories of the Marketplace.  While your app is not as prominently visible compared to the other two methods, it does return an average of a 150% increase in app/game downloads.

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 how do I get promoted?

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.

Functionality

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.

Utility

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?”.

Delight

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.

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.

Happy coding!