Developer EventsWindows Azure Developer Stories
General ResourcesWindows PhoneWindows Azure
D³: LIVE & INTERACTiVE Monthly, 1st Wednesday
These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
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.