Geeks With Blogs

News Bob Taco Industries is an ISV focused on game and app development for Microsoft platforms headed up by Michael B. McLaughlin. Mike is a Microsoft Visual C++ MVP (previously an XNA/DirectX MVP from 2011-2013), a developer, a writer, a consultant, and a retired lawyer. If you're a developer who is just getting started, consider checking out the BTI website's section for developers for links to code samples and other helpful sites.
Bob Taco Industries Blogging Division

For Windows Phone 7 developers, one of the more important pages on the MSDN website is the Design Resources for Windows Phone page. In particular, the UI Design and Interaction Guide for Windows Phone 7 (PDF) found there is something that every developer should read (and sooner rather than later unless you look forward to major redevelopment work at the end of your product’s development cycle). If you read it a while ago, check it out again as it’s now at Version 2.0 (updated and expanded quite a bit around the same time as the Beta of the Developer Tools was released).

In particular, page 24 of that PDF (page 47 using the internal labeling), which covers “Tiles and tile notification” specifies that, “Tile images should be 173 pixels by 173 pixels at 256 dpi and in JPEG or PNG formats.” What interests me about that line (beyond knowing that I need a tile image) is the 256 dpi specification. We know that the hardware specs require an 800 x 480 screen. So with a target dpi of 256 (with some minor variance from manufacturer to manufacturer, in practice) and a resolution of 800 x 480, we can run the numbers and determine the approximate size of a “standard” WP7 display.

  • 800 / 256 = 3.125 in. = 7,9375 cm
  • 480 / 256 = 1.875 in. = 4,7625 cm

There are two ways this is important. First, at 256 dpi, your applications will look nice a crisp. Second, you can use this to size the emulator appropriately when testing to get an idea of the approximate size of things you expect the user to press. Fire up the emulator (the easiest way is to launch an application or game you’re working on), then once it’s ready, exit your application. Yep, exit (by pressing the “hardware” back button – the point is to keep the emulator open). You should be on a screen with just the Internet Explorer tile and an arrow in a circle that would be pointing right if you were in portrait mode (probably best to switch to portrait mode temporarily if you happen to be in landscape mode for whatever reason). Press the arrow in a circle and you should see a menu of things. At a minimum it will include “Internet Explorer” and “Settings”. It might include one or more of your applications. (If you’re developing an XNA game and don’t see your game, go read this great post from Michael Klucher explaining why that is and what you can do to make your game appear). Press “Settings”. Under the “System” panel, you will see “theme”. Press that. Then press “Background” and switch from “dark” to “light”. All of this wasn’t strictly necessary, of course, but it gives you a chance to see the system’s theming (particularly important for you Silverlight developers out there) and it makes it more important to determine the exact boundaries of the screen in the emulator.

When you hover your mouse over the emulator, a toolbar appears on the right. It’s the one that lets you rotate between landscape and portrait, amongst other things. On that toolbar is a little wrench icon. Click it and you’ll see a “Settings” window pop up. At present, the only setting available in the window is “Zoom level”. But that’s exactly what we need.

Start by switching down to 33%. Press “OK” and watch the emulator magically shrink. Now take a ruler (the kind that measures things – you can print one out from the internet if you find you don’t have one) and measure the area that comprises the emulator’s screen. You’re aiming for the long end to be about 3.125 inches (3 and 1/8 inches) which equates to 7,9375 cm (yes I used a comma as a decimal separator – for many who would be measuring in cms, a comma is their decimal separator, no matter how odd I think it looks :) ). Depending on the size of your monitor and the dpi of your monitor, you will want to either go up or go down (unless it’s perfect as is, in which case you’re done). Click the wrench icon again, and this time use the “Custom” textbox to enter a suitable guess. Click “OK”, measure, and repeat until it’s basically right. I ended up with 36% being about right based on my monitor size, resolution, and dpi. Once you’ve got the correct value, write it down somewhere so you don’t need to keep doing this (remember that it will change on different monitors, on the same monitor at a different resolution, on the same monitor at a different dpi, etc.). At this point, you can switch back to the “dark” theme if you’d like.

Now go back and start up your application/game again. Before you balk at the graphics being fuzzy or the text being hard to read, remember that the fuzzy, hard-to-read text is a result of you running the image scaled way down (most computers tend to run at 96 dpi, which means 9216 dots in a square inch, whereas the phone will run at ~256 dpi, which means 65536 dots in a square inch, more than 7 times as many pixels in the same area!). So this doesn’t tell you a thing about how your app or game will look on a phone. What it does do is allow you to poke your finger at your monitor and have a good idea as to whether or not the sizes you have assigned to elements you expect the user to touch and interact with are sufficiently large to be usable. The UI Design and Interaction Guide (linked to above) provides a lot of great information on minimum sizes (especially for you Silverlight designers out there), but being able to actually poke your finger and see how the area you’ve provided for someone to poke at compares to the size of an actual finger tip is very nice, especially for XNA developers who aren’t working in minimum pt sizes but instead in raw pixels or even in the more fluid world of 3D (where everything is measured in units and sizes are all merely relative to one another).

Of course none of this compares to the experience of having an actual Windows Phone 7 device to work with, but until more devices make their way out there, this is a pretty good reality check for those of us plugging away at developing games and apps with the emulator. You needn’t always run the emulator at that size, and it probably doesn’t make much sense to do so since the scaling will distort graphics and text as a by-product. But every now and then it’ll be a good idea to switch back down to that size and poke your finger at the screen some so that you can make any sizing adjustments on an on-going basis rather than having to suddenly do some major redesign work towards what you thought was the end of your development cycle. Good luck!

Posted on Friday, August 6, 2010 2:28 AM xna , silverlight , wp7 | Back to top

Comments on this post: Size Apps and Games Properly Using the WP7 Emulator

Comments are closed.
Comments have been closed on this topic.
Copyright © Michael B. McLaughlin | Powered by: