Susan IbachTechnical Evangelist
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.
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.
Compass Rose Studios, composed of four students from Carleton university built a flight game for Windows Phone and share what they learned
Check out more tips from fellow students here
Could you briefly describe your application/game?
Airborne is a fast paced 3D adventure game that takes modern fascination of the steampunk style to new levels. The user flies an airship along the treasure map in order to reach the treasure located at the end. Wage aerial battle with air pirates, loot their ships for treasure to purchase speed and gun upgrades to get that extra edge in battle. Firing is triggered by tap controls, and steering is controlled by the phone’s Accelerometer.
Did you use XNA, Silverlight or both?
To develop Airborne we used both XNA and Silverlight. We used XNA to program the main gameplay, which we wrapped in Silverlight pages for menus/GUI functionality.
What was your banging your head against a wall moment?
Finding the right library to support our animation was slightly frustrating, since there does not appear to be one at this point that supports blend shapes. The one we ended up using (SkinnedPhoneModel) required skin and bone data (the mesh must be attached to a skeleton with only one root node), and assumed a vaguely humanoid shape, so we had to adjust our animations heavily – so something to keep in mind for unusual shapes and animations. Another issue we ran into was Tombstoning, a feature that allows the game to remember its state when the player launches another application then comes back to the game. With more time this can be ironed out, but it is not as quick and intuitive as could be desired. Another issue was that the game seemed to lag when we put in sound effects.
Did you ever solve that issue?
For the animation issue, we had to use a library that didn’t quite suit our needs. Since our airships had non-humanoid animations that do not generally necessitate a skeleton and skinning, we had get creative with skeletons and skinning methods to redo our animations in order to comply. Simply something to keep in mind when designing a game or beginning animation for Windows Phones. The Tombstoning issue was ironed out after more in-depth exploration of the documentation. With respect to the sound effects, we simply took them out.
If you had to build this same app again from scratch, what would you do differently?
We would skip trying to animate things with blend shapes, and we would try to make our models lower polygon so as to avoid lagging in-game. I also really want to explore the background music thread I recently discovered. That may also solve the lagging problem. On top of what we already have, we’d like to develop training modes, and further levels/functionality.
Any nice surprises?
It only took minor adjustments to cross over from standard XNA to phone XNA and we really enjoyed working with Silverlight and XNA together. Silverlight was very intuitive with Visual Studio, and it was so much nicer than having to program menus manually with XNA! It was painless to put the game on the phone and to test it. It was also easy to get started with the help of Microsoft documentation.
Did you leverage the mobile platform?
Yes, we used the phone’s Accelerometer for steering the airship. Tilting the phone right or left will steer the airship right or left; tilting the phone forward will cause the ship to accelerate; and tilting the phone back will slow it down.
Did you leverage the touch screen?
In Airborne we use the touch screen to fire the ship’s bullets using the tap command. This makes it easy to steer and fire at the same time, since the player can tilt the phone while tapping the screen with their thumbs.
Did you have a favourite feature?
Our favourite feature is definitely to have XNA and Silverlight working together. Silverlight makes it easy to develop attractive graphic user interfaces, and XNA is an intuitive game development language. We definitely hope this feature sticks around, and develops further.
What is one thing you think you did really well in this application?
Every group member did good work. In particular, the concept and design were well appreciated by our testers. Our game is not hard on the eyes! Our artists did a great job. Programmatically, we are particularly proud of the enemy AI, which took some time to develop.
Are you publishing your application/game?
We do hope to release our game in the marketplace; however we’re not quite ready to share it with the world yet. We would like to iron out a few more bugs first, and develop a training mode.
Where can I learn more about your app/game?
You can learn more on our website and on our Facebook page. We also have a video
Compass Rose studios is a group of four BIT (Bachelor of Information Technology) students currently going into our last semester at Carleton University. This project was developed for our Design Studio 4 class. Our team leader, Meagan Leflar, is responsible for project management, XNA programing, concept art, and some 2D art such as the game map, textures, and promotional material. Laura Kenney, our other programmer, is responsible for the Silverlight programming, and some XNA programming, as well as the 2D art for menu screens and promotional material. Lacey Maw and Jaimie Thom are our art team, and they are responsible for modeling, rigging, texturing and animating game assets.
Tyler Pearce, a student from Carleton university shares what he learned developing a Windows Phone game with his team.
The game is called ChopChop, you play the role of a chef. Players must use phone/touch gestures such as 'Flip, Stir, or Spread' to cook as much food as possible before the time runs out! You can see a video demo as well
We used a combination of XNA and Silverlight for the game. This allowed us to create all of our core gameplay and content inside of XNA, while at the same time overlaying our score and timer elements that were created in Silverlight. This sped up development quite a bit.
What was your banging your head against a wall moment?
Because this was the first mobile app I have developed, there were many new things to learn. One of these was the current state of the application. When the user closes the app and it enters the 'tombstoned' state, the user can lose their current place in the game. This caused many headaches. If the player did this, the game appeared 'broken'.
After learning about this issue, we found out it is possible to store specific settings of your game to be reloaded later. Because of the scale of our game and the amount of specific settings we had, we ended up just navigating the user back to the main menu rather than restoring. It is possible however to resume the game if we want to go that route.
We would do more research into the features that Windows Phone 7 has and take advantage of them in our game. Towards the end of development we discovered many things that we wished we knew about such as customizing Live Tiles for your app which is super cool. We would also test on the actual device rather than the emulator much sooner. We found a major bug that only happened on the device that we had to fix quickly.
We were looking for an easy way to detect when the phone was 'shaking'. After some searching we found this fantastic library on the Microsoft website that made it extremely easy and customizable. (Called 'Shake Gesture Library') I would highly recommend it.
We did our best to keep the User Interface as simple and clean as possible. We used the accelerometer as one of our main features in the game.
Since our game is based around gestures, we used a huge variety of different touches. Some gestures we used in the food in the game were: Squeeze (Pinch), Stir (Move fingers around in circle), and Tap (Tap finger).
I really enjoyed how easy it was to create different pages/screens in the game. We were able to design a great looking score screen in Silverlight, and once the user completed a level, navigate them there with their score and overview. This was a really nice work flow.
We needed an easy way to extend the game by easily adding levels, gestures, food items, etc. With this in mind, I spent a very long time developing the framework for the game. With this in place, we were able to design new levels and easily choose different touch gestures for foods or animations. I was very proud of this.
We plan to plan to publish the game as soon as we polish and perfect it. The game is currently called ChopChop, but may change due to other competing apps with a very similar name. We will be sure to let everyone know if we decide to change it.
Where can I learn more about your app/game? You can view our website
Who developed this application?
The game was created by 4 Carleton University students in the Interactive Multimedia and Design program.
I was responsible for the full development of the game as well as the User Interface and Menu Design. I take great pride in what I do and always hope to make an influence in my work.
I currently operate an Ottawa Web Design business in Ottawa called TeeMedia where I specialize in WordPress development. After this great experience, I plan to continue exploring app development on the Windows Phone.
I was responsible for the music and sound in the game, as well as aiding in visual assets. I also created the marketing for our game (Poster designs, demo video, 3D logo, etc...) Currently I do contract work in audio production, video editing, and graphic design (www.andrewrobillard.com) and also hope to continue to work on new apps for Windows Phone.
After a Microsoft representative pointed out the benefits of designing for the Windows Mobile community, our team brainstormed some ideas and started developing. Chop-Chop was a fun idea and even though I had my doubts in the beginning, it was really fun to play! It really opened my mind up to the possibility of working in the mobile app industry.
I was inspired by the opportunity to create a mobile app game this semester because I'm very passionate about the creative process and was excited to test my skill set. My contributions for the mobile app game included the game concept, level concepts, 2D and 3D graphics and animation.Getting to work on a project that's finished product has the potential to be used by an outside company motivates me beyond just this project and has excited me to pursue a career in the industry.
Part 4 in Susan’s series on building a Windows phone app from absolute scratch, in this post I figure out the differences between project types including pivot and panorama.
Did you miss part of the series? Check here!
Okay, I’ve installed the tools, I’ve done a Hello World application.l I want to start building my app now! So Go to Visual Studio 2010 | File | New Project and I see this…
There are 9 different project types just for Silverlight! (Quick aside: the XNA Game Studio 4.0 Phone projects are generally for games, and I am not going to try a game for my first app, but if you have played with XNA and are interested go for it and let me know how it goes, I’ve seen lots of cool windows phone games built by students!)
So which one should I use? Well I suppose I need to figure out the differences so here goes, I’ll dig through all the documentation and hopefully save you some time and effort doing the same.
This creates a one page application. I checked and yes, you can add additional pages. You can’t get any simpler than this as a project type. So if your application is just going to be one or more screens and you will have the user navigate between them, this will work. Users will click on buttons or links to move between pages.
This creates a one page application, that has a listbox on the page and it implements the Model-View-ViewModel design pattern! Well that clears that up! Okay what the heck does that mean for me…apparently its a way to separate your data from your user interface. So basically you write a class that says what data you want to show in the application (that’s the Model part), then you design a control that will show the data (that’s the View part), then you write code that says which bits of data display in which parts of your control (that’s the ViewModel part). Users will click on buttons or links to move between pages.
So I would choose this type of project if I was designing an app that was going to get data from some sort of source and was going to be displaying this data to the user. I think the Where’s Timmy app that finds you the nearest Tim Hortons is an example of a Windows Phone Databound application.
If you are planning to build multiple phone applications, and you write a clever piece of code that you want to be able to re-use in more than one phone app, put it into a Windows Phone Class library.
If you aren’t sure, you can always do this later. I have two apps I want to build this year, both of them will have a timer that counts down, so there is a probably a way I can make the logic that counts down the timer re-usable. But for my first app, I’m not going to worry too much about re-usability, I just want to get it working, I’ll probably go back and rework it a bit to make the code re-usable when I build my second app. But if you are one of those programmers who likes to make everything re-usable right from the get go, you could add a Windows Phone Class Library to your application right away to hold the code you want to use in other apps.
Gives you a project with a panorama control. Well that doesn’t help if I don’t know what a Panorama control is! Luckily I have a co-worker who wrote a blog post on the difference between panorama and pivot and here’s what I learned from that post.
Forgetting the phone for a second, a panorama picture is one of those long horizontal pictures like this
On phones sometimes you scroll up and down, sometimes you scroll from left to right. Apparently they did research and figured out that it is more natural for our hands to scroll side to side instead of up and down (who knew!) Panorama applications are designed for sideways scrolling. When you do a panorama application you can make multiple pages appear on a single background. Users scroll side to side to see the different pages but the pages feel more integrated as you scroll across the content because you have a continuous background. It’s a really cool look and feel. You move from one page to the next as you scroll. It’s great for unstructured content, where you just want someone to explore by scrolling across to see what’s in the application. The red rectangle below gives you a sense of what the user sees on the screen. They can see just a fraction of the header and content for the second page so they can see that something is there and it encourages them to scroll and explore.
The IMDb app is an example of a Panorama app.
According to MSDN a pivot application is a phone that uses a Pivot Control (and if you look up redundant in the dictionary it says see redundant). So back to Paul’s blog on Pivot vs Panorama.
Pivot applications scroll left to right just like panorama applications, but Pivot applications are usually more structured and data driven. If you think your user will expect specific menu items to choose from in the application, go with pivot. For example, when I open a twitter application, as a user I want to be able to choose between viewing my twitter feed, my Direct messages, and tweets that mention my twitter handle. Each of those will display a different list of data on my screen.
Another difference between a pivot and panorama control is that you can see the title of the next page. The user can scroll to move pages or tap the menu item to move to the that page. For example, if I built an app for the winter Olympics, when they are looking at Today’s events they can see from the title bar that scrolling will take them to the medals, or they can tap the word medals to move to that page.
You can’t see any content from the medals until you move to that page.
The Globe and Mail is a pivot application, so is the email application built into the phone.
These rules are not absolute! There is no rule that says you can’t show structured data in a panorama app. Check out the Facebook app, they went with Panorama, Twitter went with Pivot. I recommend checking out different panorama and pivot apps and seeing which you think best suits your app.
This creates a project that allows you to use Silverlight and XNA in the same application. This is something that lots of people wanted and was added in 7.5/Mango. You can also go the XNA Game Studio 4.0 project types and pick the same template. You get the same template either way. This template will give you an application with two pages: one Silverlight, and one Silverlight that shows XNA content. You also get a button to go from the Silverlight to the XNA.
Gamers like to use this project type because they use XNA for their games, but Silverlight is great for things like listing high scores, or letting users choose between levels.
Don’t dismiss it for non gaming applications! if you want to add cool 3D graphics to your application you’ll need XNA for that. Check out the application built by British Airways, it’s a great example of how using XNA can add some Wow to a Silverlight application.
Want to play music in the background? Do you want the option of having the music keep playing if someone leaves the application?
Adding this project to your application will give your application access to the classes you need to play audio files in the background.
This is the same as the Windows Phone Audio Playback agent except you use it for streaming audio files.
Adding this project to your application will give your application access to the classes you need to play streamed audio files in the background.
Do you want to have a scheduled task running in the background? Do you want to periodically check if there are new blog entries? DO you want to refresh data on the phone when the user has a network connection instead of over the data plan?
Adding a windows phone scheduled task agent gives you access to the classes that allow you to schedule tasks to run in the background at a particular time or under particular conditions (such as when the user has a network connection).
Wow, did that blog ever take me a long time to write! But I feel a lot better about my understanding of the project types now and hopefully I saved you some time with the summary. There are really 4 base project types: Phone Application, Phone Databound Application, Panorama, and Pivot. My first app is going to be a timer so I’m starting with a Phone application next blog I can start coding my app!
Join me on my quest to publish an app, and remember you could get cool stuff if you publish an app in Canada by May 20th, 2012.