ux.artu.tv » Articles

Archive for the ‘Articles’ Category

24 Weeks of Windows Phone Metro Design | #24 Pushing Metro Further with Design Inspiration

Friday, October 5th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Pushing Metro Further with Design Inspiration

In this final post I won’t close the door. Instead, I want to leave the door open to the possibilities ahead with regards to Metro design. To push Metro design further. I love Metro design - as an architect I was helpless in appreciating the core principles and my admiration to the folks in the Windows Phone design team who consciously materialized/realized this design style. Metro has changed many things inside and outside of Microsoft and it will continue to do so.

Today in the industry I’m following two big design trends: Skeumorphism and Modernism. And I’m not referring to ‘Modern UI’ re: Microsoft rumored new term for ‘Metro-style’ but to digital user interface design inspired in the Modernist movement, a design movement that many other companies, agencies and designers have pursued much before Microsoft started Metro. Metro design is one the many UI languages that are inspired in Modernist principles. It wasn’t the first one and it won’t be the last one.

By now I hope we all agree on the difference between ‘Metro design’ and ‘Metro-style’ right? If not let me tell you the way I understand these two very different things:

Metro design is a design language inspired on Modernism movement principles and extends these to include principles that guide us in the digital era.

‘Metro-style’ is an application platform.  I’m so glad to hear the Windows team decided for the right path to drop ‘Metro-style’. There were multiple reasons they decided to do so. I won’t discuss that here but I’m glad they dropped this term. Microsoft has confirmed publicly and in private that the right way to refer to ‘Metro-style’ apps is Windows Store apps.

Ok, settled. ‘Metro-style apps’ is now Windows Store apps.

So the application platform issue is settled. How about Metro design? You know - the principles?

Do we really care how we refer to those? Argh, I’d like to say no but I kind of do. At the same time I don’t want to continue calling them Metro because as a friend of Microsoft I don’t wanna step on their toes. So how do we call them?

As far as I know the Windows design principles continue to be:

Show pride in craftsmanship
Be fast and fluid
Be authentically digital
Do more with less
Win as one

And the Windows Phone design principles to me still are:

Light, Clean, Open, Fast
Content, Not Chrome
Celebrate Typography
Alive in Motion
Authentically Digital

I’m looking forward to learning from BUILD 2012 more about these two sets of principles and how will Microsoft will refer to the different terminology. I plan to adhere to their guidance on this regard and will update this post as soon as we get some clarity here.

Independently of this I will leave you with a collection of links to sources of inspiration I’m currently following an exploring:

Pentagram

Swissted

Minimalist Apps not in the way the look but in the way they function

Microsoft Office Vision

Microsoft Office Labs Website

Microsoft.com - Hotness!

25 Beautiful Responsive Web Design Samples

Milwaukee Police - Badass!

Introduction to Genetic Algorithms

Programming Architecture

Tom Wiscombe of EMERGENT Architecture

24 Weeks of Windows Phone Metro Design | #19 Tips for Designing Tiles

Wednesday, August 15th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Tips for Designing Tiles

If you are looking for Windows Tile design guidance check out this great blog post from Ratio Interactive.

Tiles and especially Live Tiles are one of the biggest contributions of Windows Phone to the ecosystem as a whole. From the static app icons in iPhone or Android (with minimal notification capability) comes a concept of a tile that is rich and immersive and informative. It is a way to take your app beyond your app. Users can gain value from what your app can provide before even launching your application. If you have a weather app, don’t make the user have to launch your app to find out what’s the current weather conditions. Instead present those conditions live, right there on the application tile. Live tiles allow you to present even more information as the tile rotates.

There is plenty of information about Tiles already. And keep in mind this will evolve once Windows Phone 8 is released as we will now have at least 3 different tile sizes. We’ll post an update in this blog when specs about those new tiles are available.

startscreen.png

One of the coolest tricks I’ve seen with Tiles in Windows Phone is their ability to display PNG images with transparency. You can do all sort of fun tricks with this like the couple examples below…

The first example is an image of a glass created in Illustrator. It was exported as a PNG with the interior of the glass being transparent. When overlaid on the tile, the transparent area reveals the background color of the tile which of course happens to be the accent color of the user in her phone. This makes the branding of the app be nicely and smartly “customized” to a preference of the user (the accent color…) the fill color for the glass will change depending on the accent color.

Windows Phone Tiles Transparency

Here is another example. These ones show different tiles layouts providing useful information. Pay attention to the martini glass example in particular. That was a photo of a martini glass, imported into Photoshop, where we isolated on of the RGB channels and selected its contents. We then pasted that selection to a grayscale document. What you end up with is a semitransparent image that allows once more, the user chosen accent color to “go through”. It looks pretty cool and makes your brand more personal to the user.

Notification Tiles in Windows Phone

This is how you produce these type of images in Photoshop.

1 Open an image and desaturate it (turning it 100% to grayscale)

Photoshop Channel Selection

2 Switch to the Channels panel and turn off all color channels except for blue (or red, or green but just leave one of them visible).

Photoshop Channel Selection

3 Hit the Load Channel as Selection button. This will select the contents of this channel. Because some pixels only contain a portion (%) of Blue, then those pixels will only be “partially selected”… isn’t that cool? Photoshop can actually partially select a pixel J this is what will give us the transparency.

Photoshop Channel Selection

4 Press Ctrl-Shift-I to invert your selection

5 Press Ctrl-C to copy the selection and then Ctrl-N to create a new file. Leave the default size there (which if done correctly will be the size of the image copied to the clipboard)

6 Press Ctrl-V to paste the clipboard to the new image

7 Play with the Image Levels to adjust darkness and lightness. Sometimes I even duplicate the layer and then merge it to make it darker.

Photoshop Channel Selection

8 Remove or hide the Background layer and you will see the resulting glass with transparency. You are now ready to export this as PNG and continue working on it for use in your tile.

Photoshop Channel Selection

24 Weeks of Windows Phone Metro Design | #17 Motion Catalog in Windows Phone

Monday, August 13th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Alive in Motion is one of the Metro Design Principles. Motion is what gives Windows Phone depth. Windows Phone relies a lot on the concept of depth. It provides horizontal depth with controls like Pivot and Panorama which make you feel as if you were dealing with content that spans beyond the screen limits. Windows Phone also conveys depth on the Z axis with the help of motion. If it wasn’t for motion we would think Windows Phone is completely flat but it is with the swipes, rotations, slides and tilts that objects in Windows Phone reveal themselves as planes in 3D space… had you realized that? Metro is not flat. It is made out of 2D planes floating on a 3D space.

A catalog of animations are available with the Silverlight Toolkit for Windows Phone for designers and developers to apply to Windows Phone UIs. Here is a brief description of 5 of the animations available in the Toolkit. If you would like to see these in action please download this small Powerpoint slide deck which includes 5 short videos demonstrating each of these motions.

Turnstile

The Turnstile animation helps convey to the user that you are moving her into a different context. You are here, now I’m taking you there - to a completely different place. It is a more aggressive animation that tells the user that they are being “teleported” to another place. For example when you are moving from one app to another.

Continuum

Continuum is the opposite of Turnstile. It is meant to convey continuity between different sections of the same application. It is meant to tell the user that new or different information will be presented to her but that she will remain within context. An example is an email or messaging app - you are in a list view with all the messages and you tap one of them, the continuum animation plays and the contents of the message are displayed…

Swivel

Swivel is great for dialog boxes or transient UI. Imagine a dialog box that presents an OK button to the user… the user taps it and it gets dismissed. Or an Accept and Cancel button… the user selects one and the dialog is dismissed.

Slide

Slide is great for conveying dead end scenarios. For example you select a category of settings to define, you are taken to a selection mode, you make a selection and you come back.

Tilt

Tilt is an animation that plays when you tap an object. Lists for instance have list items, you tap one of them, it tilts to convey interaction and then an action occurs - perhaps this action links to one of the other four motions mentioned above…

24 Weeks of Windows Phone Metro Design | #12 Use of Images and Photography

Monday, August 13th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Use of Images and Photography

Even though we’ve talked a lot about Typography, Metro is all about content and content of different types including imagery of different kinds like photography and information graphics. Let’s review a few examples to highlight the different ways to use images and photography in Windows Phone.

In this first example we can see a few interesting occurrences. You can see some information graphics floating on top the Panorama background. Notice these information graphics do not have a background themselves or a border… they are floating freely on top of the Panorama background. This makes them more integrated with the overall composition. Always try leaving infographics floating freely over the Panorama backgrounds.

The other thing we see here are photos. These photos and many we’ve all seen in Metro are usually presented as squares. No borders or drop shadows… One thing to consider here is photos do not have to be used or presented as squares all the time. Just adhere to the Windows Phone design grid and if you can tailor your photos to be squares great but if it makes sense then use another proportion - for example if you are presenting ‘movies’ - usually movie posters are portrait so you could use vertical rectangles. If you were presenting thumbnails of movies, then those tend to be horizontal and these days most possible 16:9 so you’d get horizontal rectangles.

image01.png

In this other image notice the use of clusters of square shaped photos in groups of four. These is to present four of the golf players we are playing with. Second, notice the little infographic which shows an aerial view of hole 1 in this golf course. Notice how this infographic as mentioned previously is not enclosed in a rectangle or square, doesn’t have a border or other effects… it’s just there floating on top of the background.

image02.png

In this final example we can see the XBOX experience. There’s an avatar there. Notice how the avatar is not enclosed in a rectangle and no borders are used. It is just there floating on top of the background. As we’ve mentioned before infographics look and work great when just left floating on top of the background.

image03.png

24 Weeks of Windows Phone Metro Design | #20 Helvetica

Monday, August 13th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

I wanted to share a video with you that I really love. It’s a small segment part of the movie Helvetica. This video snippet is great because it perfectly describes and explains the philosophy behind Metro Design. Use only what is needed. In this video you can see the passion of a designer (Michael Bierut) who truly believes in being rational with visual communication. When sometimes we ask ourselves why Metro looks the way it looks, this video has the answer. It is simple. Period.

You can find more information the movie in the Helvetica movie website.

During the amazing week with Massimo Vignelli, my friend August de los Reyes pointed me to the right Helvetica to buy. It is called Neue Haas Grotesk. You can find it here. I bought it. It was pricey but man, it is gorgeous and will help me and my brother migrate towards dropping Segoe and using only Helvetica in all of our Windows Phone and Windows projects (as well as iOS and Android). The reason this Helvetica font seems to better than others is that this resurrects a lot of the original alternates and other devices from Max Miedinger.

Here are some of the design made during the week with Massimo, all using Neue Haas Grotesk.

Massimo Vignelli Workshop, Helvetica

Massimo Vignelli Workshop, Helvetica

Massimo Vignelli Workshop, Helvetica

24 Weeks of Windows Phone Metro Design | #11 Windows Phone Design Grid

Sunday, August 12th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

We’ve talked about the Windows Phone Design Grid before so I will keep this post short. The key is to leverage the Grid for composing your Windows Phone UIs. The Grid has a 24 pixel margin to left and right. Always respect that margin. Then you have 25 pixel columns and 12 pixel gutters. It’s always best to deploy UI objects from within a 25 x 25 cell. Take a look at the Layout and Composition in Windows Phone posts in this same series to get a better idea of how to use the grid.

Windows Phone Grid for Expression Design.

Windows Phone Grid Plain in PNG (Transparency - great for Expression Blend) - Thanks Michael for recommending this…

Windows Phone Grid Basic Cells in PNG (Transparency - great for Expression Blend)

Photoshop and Illustrator format Grids (thank you Jaycob!)

GIMP .xcf Windows Phone Grid (thank you  Robert!)

gridsmall.png

24 Weeks of Windows Phone Metro Design | #22 Orientation

Saturday, August 11th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Quick few tips about orientation in Windows Phone. Windows Phone supports three orientations.

Portrait (vertical)

Landscape Left

Landscape Right

I didn’t know we had those two different landscape orientations until a while after starting to study Metro. You can see the effects of these three orientations in the Calculator app that comes with Windows Phone. Try it out yourself – if your rotate  you get different calculators (normal, accounting and scientific modes). The take away from this is that you can leverage the different orientation modes for *different* functions in your app.

calculatorportrait2.png

calculatorlandscapeleft.png

calculatorlanscapteright.png

The old school approach to designing apps was to make them work on both portrait and landscape mode by reflowing or reformatting UI objects. But nah, no need to do that really. If you design your app you can focus your efforts on targeting a single orientation. Or, when it makes sense, you can support multiple orientations to provide different functionalities (or modes) in your apps like in the case of the Calculator. Now, honestly I would have never guessed on my own that rotating the Calculator the left or right would render different results… so I’d say some visual hints might be useful to let people know this is possible. Perhaps when running the app for the first time you get a visual indication that tells people it is possible to rotate the phone to accomplish different modes.

Here is another example that taught me a lot from the potential of using different orientations to convey different functionality or modes in your app. The app is a golf application demo created by the Windows Phone team. The cool thing about this app is it shows again how it is not needed to support the same functions in both portrait and landscape. Instead the team decided to use portrait mode for the overall set of functionalities of the app – it includes a number of Panoramas, Pivots and Pages.

portrait1.png

Then, when the user rotates the phone (left or right), the app doesn’t reflow objects to make them look nice on landscape mode… instead, they do something smart, they completely and totally reshape the app to accommodate a score card. What a smart idea! Score cards are horizontal so a landscape mode works great – makes sense – strengthens the function and it is not gratuitous.

landscape.png

So takeaways: We have three orientations: portrait, landscape left and landscape right. Strongly recommend not to waste efforts in making an app functionality render on both portrait and landscape… (as in reflowing or re-laying out UI objects). Instead analyze your app and study the different user scenarios and your information architecture. Then leverage the best of portraying, landscape (right and/or left) to craft different application modes between orientations.

Here is a great article from Smashing Magazine on designing for different orientations in mobile devices…  

24 Weeks of Windows Phone Metro Design | #21 Touch Targets

Saturday, August 11th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

What is touch target? (scroll down to the Touch Target section).

In a touch device you use your finger or fingers to interact with UI controls on the screen. Our fingers are chubby in general J so if we present UI objects that are too tiny, it will be hard for users to target these. So the following guidelines give you some ideas for how to avoid user frustration and ensure UI objects on the screen are accessible and touchable by users.

The minimum recommended touch target is 9 millimeters. Giving you millimeters might only take you so far since we all use pixels when it comes to designing a screen UI. I usually use 9 pixels as the reference.

windows-phone-touch-target-01.png

When you really need to have tiny elements you can go down to 7mm (around 7px).

windows-phone-touch-target-02.png

Now, one thing is the touchable area and another is the visual size of the item. The minimum size for a touchable item is 4.5mm (some 5 pixels). So you could have a tiny elements of 5 pixels but with a touchable area of 9 pixels around it.

windows-phone-touch-target-04.png

Try to avoid having two touch areas overlap.

windows-phone-touch-target-05.png

Better to put them side by side… or if possible leave a bit of buffer in between.

windows-phone-touch-target-07.png

Touch targets are so important when designing mobile apps that the Windows Phone Design studio came up with something called greenlines. Let’s start by explaining what redlines are. You know how in architecture there are blueprints? Basically detailed drawings with dimensions, heights, widths, and other information that then allows the contractor to build the house precisely as it was designed. Well, in interaction design things have gotten to a level of complexity that we use something called redlines which are just like the blueprints in architecture. Redlines specify the dimensions and positioning (and other details) of every UI object on the screen. These redlines are provided to developers so they can craft markup code (HTML, XAML) that represents the design with fidelity. So, all this said, greenlines are just like redlines but they focus on helping you specify *touch areas*. This is because touch areas are separate than the actual UI objects.

Here are a couple examples. This first example shows the phone call screen. Notice how the touch areas in green exceed the size of the actual UI objects. Also notice how none of these UI objects are tiny… they are actually decently sized yet the touch areas exceed their UI dimension… this is to help users find more touchable areas and get a higher success rate when tapping elements.

windows-phone-touch-target-08.png

Here is a second example. It shows the touch target for the arrow button that takes you from the start screen to the application list in Windows Phone. Notice how the touch area is larger than the actual UI control

windows-phone-touch-target-09.png

24 Weeks of Windows Phone Metro Design | #13 Touch Gestures

Saturday, August 11th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

When going through the Windows Phone UX guidelines Gestures article (scroll down to the Touch Gestures section) you can see and explore the different out-of-the-box gestures that allow users to interact with UI controls in Windows Phone. However, I must say these gestures are listed more as a reference or and FYI than as something we can leverage. As far as I understand you can’t change the gestures you use to operate things… a Panorama will be panned. A push button will be tapped. A list item could be tapped or tap and held to reveal a context menu. But all these gestures are already baked into the Windows Phone control library so that’s why I say it seems to be more of an FYI list for us that something we can directly use.

One interesting concept to mention is the multi-touch gesture. Turns out Windows Phone supports up to 10 touch points as an operating system but there aren’t really any devices that support 10 touch points and the minimum support for all Windows Phone devices is 4 points. So there is the ability to design your own gestures by leveraging this four touch point concept. You will definitely need to work with a developer to make this work as it requires of coding.

Here is a quick summary of the gestures but I encourage you to visit the Windows Phone UX Guidelines to learn more about all these…

A tap is a single, brief touch on the screen within a bounded area and back up off the screen again.

tap.png

A double tap is two quick taps within a bounded area.

doubletap.png

A pan is a single finger placed down and moved across the screen in any direction. The pan gesture ends when the finger is lifted from the screen.

pan.png

A flick is a single finger down moved rapidly in any direction and ends with the finger lifted up off the screen. A flick can follow a pan gesture.

flick.png

Tap and hold is a single finger down within a bounded area for a defined period of time.

tapandhold.png

A pinch and stretch is two fingers down within separate bounded areas followed by the fingers moving closer together (pinch) or further apart (stretch).

pinchandstretch.png

Four points. Windows Phone supports four simultaneous user touch input points to enable unique application interactions.

fourpoints.png

24 Weeks of Windows Phone Metro Design | #18 Creating backgrounds for Panoramas

Saturday, August 11th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

We’ve covered this topic in a previous post but I thought I’d add some tips here to design backgrounds for Panoramas.

Use background images that help enhance the parallax effect

One of the most delightful features of a Panorama control is its parallax effect. This effect provides depth to the Panorama and makes it more immersive. It consists of displacing the background image of the panorama at a different (slower) rate than the floating objects on top of it. So the user interface elements move faster horizontally (scroll) compared to the background. This is an animation principle. Walt Disney Studios, Warner Bros. they all used this effect from the beginning. Do you remember Bugs Bunny walking down a nice forest path with a beautiful background with mountains? And the background moved slower than the foreground? That’s the parallax effect and it helps sell depth in a scene. It’s a visual trick.

Here are some cool websites that use this effect… study them and see why they look so… freakin’… gorgeous! - :) try leveraging similar tools for Windows Phone Panoramas.

http://silverbackapp.com/ - Rumor has it, this was the site that made this effect popular on the web (although the animation principle has been around for decades…) - Resize the browser and look at the leaves on the top.

http://www.nikebetterworld.com/about Why does Nike always rock on the web? Because they care J

So, using images that help sell this effect will make your Panorama work better. Note it is not mandatory that you use a background image, only if it makes sense to your brand and experience. Like Facebook, they don’t use a background image. Now, the good thing is you might only need a very subtle background to increase the effect, and it doesn’t necessarily have to be a super complex, full sized background image. Here are some examples:

Four ways of using background images in Panoramas

You can use Panorama background images in different ways. Here are four different techniques I’ve found being used:

1 - Full size image or photo background

This is a very popular option because photos look great as Panorama backgrounds. The only thing to be aware of is that light photos might make it hard for light foreground UI objects to be visible and same potential problem for dark objects (in the case of darker photos). So as long as you can curate photos properly it is possible to obtain good results here. You can pre-edit photos in something like Photoshop and make then a bit darker (say 20%) or a bit lighter. Or plan B (as in better :)) is to have a semi transparent rectangle on top of the Panorama background. Make it 10-20% opaque in black or white and have it rest on top of the photograph image.

2 - Blurry, lightened or darkened background. Tinted backgrounds in any color.

This approach addresses the complexities of using full screen photography as Panorama backgrounds. By lightening or darkening a photo based background you make it easier for UI objects to be visible while floating on top of the background. It also makes the background less dominant in the overall design composition. You can implement this approach by pre-editing the background(s) with Photoshop.

3 -  Footer background

You don’t need to use full screen imagery for backgrounds all the time. In many cases a more gently footer only background could work and add depth to the Panorama. It is also less invasive to the overall Panorama and the UI controls floating on top.

4 - No Background 

This one is my favorite! No background - nice and clean.

Background images in Panoramas

24 Weeks of Windows Phone Metro Design | #23 Perceived Performance

Thursday, August 9th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Notice the title of this blog post re: “Perceived” Performance. When creating a Windows Phone app there is design and there is engineering involved. Even though we could think that when it comes to performance, it’s all about engineering, the truth is there’s a number of visual, motion and interaction tricks we can implement to make it feel as if the application was more responsive or faster than it really is… there are common sense things that we’ve learned back in the day when creating websites. For example, something is loading? show a loader just so people know something is happening on the backend. Now this is where things get interesting as there could be different types of loaders, for example loaders that simply tell people to wait indefinitely (hopefully not forever!) and loaders that show how something is going from 0% to 100%… it could be a download or a task that is making progress. Just like these best practices we’ve used and mastered on the web, mobile devices are no different and we want to use these type of tricks to make the user experience a better one. Notice that we say “perceived” performance as whether we provide a loader or not, the system will take exactly the same time to load something or download something or to full fill a task. But when we provide visual cues to users, the perceived time or wait they go through “feels” or is “perceived” as being less than without any of these visual hints.

The best source of tips and tricks for Perceived Performance is this video produced by the Windows Phone team.  I highly recommend you watch it :)

I also asked my brother Alejandro if he wouldn’t mind writing a post to aggregate some of the best engineering (and experience) performance tricks he knows of. He is a developer so if you are a developer you will find the following very valuable. Please leave us a note for comments/questions. Here is Alejandro’s post:

Windows Phone Application Performance

One of the key elements for a great user experience design is the application performance. From the point of view of the end user a great app is just a responsive, quick and interactive app. In order to give our users a responsive app we need to take into consideration that our Windows Phone device has limited resources compared to a desktop or even a tablet PC, -Battery life, CPU/GPU, connectivity, bandwidth, storage capacity, multi-tasking model - to mention a few.

Here is a list of aspects to take into consideration while designing the UX for you app.

Loading performance

Today’s mobile systems have their constraints regarding app loading and in Windows Phone the system terminates an app that takes more than 10 secs to load. But even 10 seconds to load is so much time for a common user. We need to make it faster as we can.

Consider psychological time

One element is the splash screen whose design should have a compelling design and some information about the app. Keep it minimal but not boring. Splash screen is the may entrance to your app so you should offer something useful and compelling to the user. With this you may get a psychological effect on the loading time of your app.

Larger the application assembly, the longer it takes to load

Keep your assets, images, media, files, etc as content of your app and not within your assembly. So remember to set the Build Action property to Content for each. Set elements as Resource will increase the size of your assembly, but don’t take this as law because in some circumstances you may need something set as resource for architectural reasons.

Minimize the size of application assemblies

Break the Application into Smaller Assemblies so you don’t have to load a huge one.

Look at this code to check how we can load a page that is in some other assembly.

private void button1_Click(object sender, RoutedEventArgs e)

{

// Use the name of the separate assembly when generating the Uri for the page

NavigationService.Navigate(new Uri(”/PageInExternalAssembly;component/ExternalPage.xaml”,

UriKind.Relative));

}

Runtime performance when a user interacts with an application

Run heavy code in background thread or composition thread, not UI thread.

If you put heavy processing code in the main UI thread then it will block the thread so you may put it in other thread or an event such as LayoutUpdated.

Watch for API’s that may block the UI thread.

Location services, push notifications, network information, and radio may block the UI thread due to their processing nature.

Don’t rely on Windows Phone emulator

It will never be the same as a targeted device.

Check memory usage

Even though currently we can’t control memory in Windows Phone we can check how we are doing with ApplicationMemoryUsageLimit and ApplicationCurrentMemoryUsage

Hiding elements: Visibility Property vs Opacity/BitmapCaching

As stated in the documentation

“When you set the Visibility property of an element to Collapsed, Windows Phone does not hold any visual data for the element in visual memory and does not do any processing related to the element. However, when you bring the element back on the screen, by setting Visibility to Visible, the contents of the visual tree have to be drawn again. The element is redrawn completely.”

If you use the visibility property technique make sure the draw process is not too complex.

When you use opacity alone, performance of the app could get really messy. But if you mix the opacity with Bitmap caching you can improve performance in some scenarios. Bitmap caching allows visual elements to be stored as bitmaps after the first render so the main purpose of this technique is to avoid the heavy processing of complex xaml code instead of a bitmap. In this case the technique is similar between choosing xaml or images for certain graphical elements. If you have a complex xaml graphic that is static use a bitmap.

Remember you should evaluate the performance of each technique on a case-by-case basis

Image transparency and format

If the images you are going to use don’t need transparency use jpg and if you must use png format.

Performance knowledge of controls

Check the performance considerations of controls when designing your app. Knowledge of which are the main performance differences between controls can help you decide whether use one or the other. At the end there will be decisions to make.

 

Use perfomance tools

Windows Phone Performance Analysis

Lets you measure, evaluate, and target performance-related issues in your code

Frame Rate Counters in Windows Phone Emulator

Use the frame rate counters to monitor the performance of your application.

Silverlight EnableRedrawRegions Property

Enables a diagnostic feature that is used during development for performance-tuning your application by showing the areas of the plug-in that are being redrawn each frame.

Useful links

Performance Considerations in Applications for Windows Phone

Technical Certification Requirements

Execution Model Overview for Windows Phone

Performance Techniques for Windows Phone

24 Weeks of Windows Phone Metro Design | #16 Typography

Thursday, August 9th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Typography is one of the Metro Design Principles. The principle is formally “Celebrate Typography” but I always remove the word Celebrate thinking it’s a nice adorner but nothing more :) Typography can stand on its own. We’ve mentioned before that in Metro everything seems to be about typography. Microsoft talks a lot about it and so does everyone in the community. I would not however, say that Typography is the most important aspect of Metro. Metro is a comprehensive language where Typography is important but it’s not the most important or the only way to express things. I wanted to mention this to kick off this article just so that when you think of Metro you do not only think of typography. Think of photography, infographics, animation, input controls and more. All this said, the reason Typography is important in Metro is because typography offers a particularly extensive and expressive range of tools to convey structured information. This is the key: structured information.

Typography uses different tools like weight, size, color, font family, line height, alignment and others to help you convey structured information. Here is another key takeaway here: traditionally when designing websites or mobile apps, developers tend to make all text the same size and the same type. In Metro you do not do this. Not all data is the same. There is high priority data and medium and low priority data. There are hierarchy levels and these need to be expressed using one or many of the above mentioned typographic tools. So if I have the following pieces of data… I need to ask myself which of these are more important, and those I emphasize with typographic size, weight and color and/or other mechanisms.

structuredinfomation_typography1.png

Another aspect to consider when doing typography in Windows Phone is line height. Check out the following examples. Proper line height management is one of the most common problems we’ve seen in lists.

lineheight_typography.png

Finally, the out of the box font family provided my Microsoft is Segoe. Segoe is simply that, the out-of-box option for you to use but it is not a requirement for you to use it. The Metro design principle is not “Always use Segoe”. It is Celebrate Typography. And there are many ways of doing so. Use any font type that you like. You can use both sans serif and serif fonts (serif means adorners). I personally love sans serif fonts like Swiss, Helvetica or Futura but serif fonts like Baskerville or Bodoni are great too when used properly. This is one of those areas where I’m paying to attention to the Metro Design Principles. If I were to follow the Metro Design Language then I’d feel more constrained to using Segoe but remember the Principles are always first. This also applies to Windows 8. You will hear Microsoft asking you to use specific fonts but it is not a restriction to use others if you like and to my knowledge they will not reject apps that use say, Helvetica, instead of Segoe. Of course Microsoft prefers not to pitch Helvetica because they own Segoe and that helps them maintain consistency but also because Apple uses Helvetica and Helvetica is included as an out of the box font in iOS and OSX devices. But again, coming back to the Metro Design Principles, inspired in Swiss design and International Typographic Style, we can use whatever makes sense to us.

Check out these couple samples that show using both serif and sans serif types to convey information yet they both follow the same principles that inspired Metro.

swiss-graphic-design-142.jpg

vignelli-poster-2609-final-530px.jpg

24 Weeks of Windows Phone Metro Design | #10 Layout & Composition in Windows Phone Part III

Sunday, July 29th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Loooong video - I promise to keep them to less than 10 minutes in the future. I hope this is useful as I share some of the thinking behind layout in Windows Phone. Some comments:

Use the grid to layout elements in Windows Phone

Respect the 24 pixel margin to the left and right

For text, deploy or set the baseline of the first line to match the grid but then do not worry about the rest of the text lines to match the grid… just let it flow naturally.

Swiss design always (almost) flushes text to the left (flushing meaning aligning). I prefer the layout I do in this video where I keep items aligned to the left. Always look to flush text left.

In layout, you want to create the feeling of “unity” so in our case we have an image, a title and a description. We use the same padding between these objects (12 pixels) to create the feeling of cohesion. Then we use 24 pixels of vertical separation between different items.

Next video we’ll get more into lists design,

24 Weeks of Windows Phone Metro Design - #9 Layout & Composition in Windows Phone - Part II

Thursday, July 19th, 2012

In this video we cover the basics of designing tiles. Tiles are used in Windows Phone and can (when it makes sense) be used inside of apps too. A general guideline is, if all you are going to have inside of a tile is text then do not create a tile but a list. We’ll talk more about lists in upcoming videos.

Video Notes

In this one I share my personal approach and thoughts on why and how to align text in tiles. While this video is super focused on that particularity, I hope some of these tips give you ideas for layouts of your own. In Metro design there are no rules, just ideas and exploration - as long as we defend the 5 design principles, we can do anything we like :) The magical number I refer to in this video is 12 pixels. I use it a lot. In addition to the Windows Phone design grid, the number 12 really helps in laying out objects. Remember the grid simply helps us with our general layout but from there and on, we can rely on other mechanisms, like the number 12 and multiples of it to position elements.

24 Weeks of Windows Phone Metro Design | #8 Layout & Composition Part I

Tuesday, July 10th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

Hello! This time I decided to record a video for you. Finishing the design series is taking me more than I’d like so I’ll produce videos to finish sooner and at the same time be able to cover all topics in depth. Here is the first part of Layout & Composition in Windows Phone.

Here is the Panorama.design file I mention in the video…

Video Notes

The key take away of this video is to leverage the Windows Phone design grid. Last year while I was at Microsoft, we started pushing strongly towards using this grid. During a casual conversation with Jeff Wilcox he picked up on the notion of the grid and created a Metro Grid Helper. Note: This helper displays a Grid that is 25 x 25 pixels… the actual grid should be from left to right: 24 pixels, 12 pixels, 25 pixels, 12 pixels, 25 pixels etc etc and finish in 24 pixels. Could any one in the community update Jeff’s helper to match these dimensions? :) Remember to respect the 24 pixels margin to the left and right in your Windows Phone design composition. The next magical number is 12 pixels which is the padding used extensively across Windows Phone. I usually set my nudge distance to 12 pixels in Expression Design (you can do something similar in Photoshop and Illustrator). With a nudge of 12 pixels I can then move, position and copy objects in multiples of 12 which is a great way of laying out items. In this video we show the Windows Phone design grid and we lay out some basic shapes. In the next few videos we’ll get deeper into how to lay out text and also on how to deal with irregular shapes or custom sized tiles.

24 Weeks of Windows Phone Metro Design | #7 Designing Panoramas

Sunday, June 10th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

In this post we will talk about all we need to know to design Panorama controls for Windows Phone apps.

Let’s start by demystifying the Panorama control. As we mentioned in a previous post, the Panorama control is a beautiful user interface metaphor and thus we tend to over use it. I recommend we leave Panorama(s) control(s) to the end in your design process. That’s because it is by the end of the information architecture definition process that you will know best what information to highlight in a Panorama and how to do it. This approach comes from understanding that a Panorama control is like a magazine cover, in the case of being the main hub in your app, or as a spread within a magazine, if a secondary or tertiary hub.

Windows Phone Panoramas as Magazine Covers

http://www.sailingworld.com/

I recommend reading the Choosing Between Panoramas, Pivots or Pages post for more information about when to use Panoramas.

Panoramas are great for showing only those few pieces of information you want to highlight in your app. The one or two top featured recipes of the day. The latest 10 results of your top 5 sports teams. The top 6 pieces of news or stock trades you are interested in. Basically, only a few pieces of information.

 

The metaphor of a magazine cover applies to the way a Panorama looks and feels but also on the way the Panorama is designed - that is, the methodology. Studying how actual magazine covers are designed will take your Panorama design skills to the next level. Go to your nearest magazine stand and pick up a few of your favorite magazines. Pick some sports, fashion, architecture, music and news magazines. Study the composition, layout, typography, color. But also try to think the way a magazine editor would think when she chose that particular portrait photo of a popular singer or that particular wide angle shot of a the latest tallest skyscraper in Dubai. Why did they choose to align things to the left or use that particular set of colors? Or how many featured articles are being highlighted? You will have to go through a very similar decision process to design a Panorama control and the content in it.

Here is a great series on designing magazine covers by Tony Quinn: The secrets of magazine cover design. The Time Magazine cover archive is too good not to share J Very Metro.

Time Magazine Covers


Design Guidance

Ok, so first some design tips and tricks. Things to keep in mind when designing a Panorama:

Leave Panoramas until the end

Design Panoramas after defining the information architecture for your app, preferably even after designing all other pivots and pages in your app. You might know from early in the IA process that you will “eventually” need a Panorama… but don’t design it just yet even if it’s tempting. Just draw a big rectangle with the word Panorama inside it but don’t design it… move on and work on Pivots and Pages. In many cases, many, you will find you don’t even need a Panorama control and despite common belief you do not need nor require, nor should include a Panorama control on every Windows Phone app. Look at the Twitter app, only Pivots and Pages. Why don’t I need a Panorama in the Twitter app? Well because they provide natively pure streams of tweets. There’s no concept of “my top tweets” or featured tweets etc… While there are sponsored tweets, Twitter is being kind enough not to put those in our face with a Panorama (thank you Twitter!). Does that mean you couldn’t create your own Twitter client where you feature some tweets? You certainly have the freedom to do that - I just think that by understanding the IA for Twitter which is basically lists of tweets, you basically end up with a great scenario for Pivot controls.

Think of Panoramas as magazine covers

But now look at the Facebook app. Facebook as an experience does have tons of things we’d like to see in a nicely featured area, things like top stories, newest friend photos, my status, notifications and more. So in Facebook the challenge becomes selecting only the few set of pieces of information we want to present in the Panorama.

Facebook Panorama

Note: This is the previous version of the Facebook app but the new one emphasizes this magazine cover thinking even more…

Design Panoramas as full spreads, not in chunks

Even though Panoramas are made out of panels or sections, we should design them as single long spreads of content. Think of one of those two, three or even four page spreads in magazines. The ones that unfold, sometimes being the cover itself, and others being pages within the magazine for an advertisement or poster. By designing the Panorama as a single spread and not in chunks you will be able to sell the immersive experience that Panoramas offer in a much more compelling manner to users. You still have to remember that Panoramas will be “framed” within the screen for every swipe the user does to the right or left thus yes, you do have “steps” or “panels” - but the design process of a Panorama should first consider it as a whole spread. I like to have a fake Windows Phone hardware skin and move it over my Panorama to picture how the different sections of it will look like once they are inside the phone. That is because even though we design Panoramas in spreads, you still have to try out and test how Panorama panels (sections) will look once framed in by the screen.

music and video hub in Windows Phone

Use 3 to 5 panels maximum in a Panorama

Keep Panoramas within 3 to 5 panels which equals to up to 4 swipe gestures. More swipes or panels can start making the user get lost. Panoramas flow right or left depending on the swipe and if you get to the last panel and swipe again, the control presents panel 1 again. It is a cyclical control. Users will depend on their memory to navigate through the Panorama control - and panels in a panorama are like steps. That’s why we need to keep them short.

Panorama panels

The anchor point in a Panorama control

Usually the anchor point in users’ memory, while in a Panorama control, is either or both, panel one and panel two. Panel one tends to be devoted to host a navigation menu. Panel two tends to have the outmost featured or highlighted set of content. When users start swiping throughout a Panorama, the panel that welcomed them will be the one the will remember the most and thus will help as a memory anchor point. This means it is good to highlight this welcoming panel somehow to make it even easier for the user to remember. You could make the background of the panorama particularly visible on that panel, branding elements could be shown on that panel primarily, and other visual cues. This will help users clearly map the Panorama in their minds and identify the beginning/end of a cycle (since as mentioned above, Panoramas are cyclical).

Anchor in Windows Phone Panorama

When launching an app, you can welcome users on panel number two

Welcoming users to your beautiful panorama with a menu might not be the best experience. If your application flow and information architecture say users pretty much *have* to take a decision and select an option in the menu to move on in your app, then yes, welcome them with a main menu. But, if selecting a menu option is not critical for the user to move on within your app, then don’t welcome the user with a “main menu” - instead take them to panel two for some featured item(s)… welcoming a user with a main menu is like putting the table of contents on the magazine cover.

Using Tiles as Buttons… No. Unless…

Ah! I wanted to touch on this topic - Just like Panoramas, the other thing people love to use are Tiles :) And I’ve seen many apps using tiles for composing main menus in Panoramas. Tiles are used as buttons. I’d just say that tiles make sense if your menu options need more than just text to describe themselves. If you have an option called Set Meeting Point - is it clear enough? or do you still need an icon? I guess it’s clear enough. The icon could just add visual noise. The tile itself could add noise. ‘Set Meeting Point’ seems clear enough to me. Asides from an icon, the other thing we could need in a menu option is some sort of number, counter, notification or alert… That is the one other scenario where tile looking menu options could really be needed as the tile could help you bring visual unity between ‘Set Meeting Point’ and say, an alert or counter of replies to your meeting point.

Tiles have been misunderstood and overly used in my opinion. The Windows Phone team came up with the idea of tiles which is primarily used in the start screen of the phone. The concept of live tiles is awesome and a true contribution and innovation in the smart phone industry. The power of taking your app beyond your app and have it help users from the start screen is very compelling. Live tiles act as ambassadors of the apps, on the start screen, for the user. They allow the user to gain information about something relevant to them without a single tap - it’s just there. If you can identify a similar need within your app, and a live tile type of concept works in your scenario, then use tiles in your Panoramas. Otherwise, I would just stay away from them.

No Tiles in Panorama

Use background images that help enhance the parallax effect

One of the most delightful features of a Panorama control is its parallax effect. This effect provides depth to the Panorama and makes it more immersive. It consists of displacing the background image of the panorama at a different (slower) rate than the floating objects on top of it. So the user interface elements move faster horizontally (scroll) compared to the background. This is an animation principle. Walt Disney Studios, Warner Bros. they all used this effect from the beginning. Do you remember Bugs Bunny walking down a nice forest path with a beautiful background with mountains? And the background moved slower than the foreground? That’s the parallax effect and it helps sell depth in a scene. It’s a visual trick.

Here are some cool websites that use this effect… study them and see why they look so… freakin’… gorgeous! - J try leveraging similar tools for Windows Phone Panoramas.

http://silverbackapp.com/ - Rumor has it, this was the site that made this effect popular on the web (although the animation principle has been around for decades…) - Resize the browser and look at the leaves on the top.

http://www.nikebetterworld.com/about Why does Nike always rock on the web? Because they care J

So, using images that help sell this effect will make your Panorama work better. Note it is not mandatory that you use a background image, only if it makes sense to your brand and experience. Like Facebook, they don’t use a background image. Now, the good thing is you might only need a very subtle background to increase the effect, and it doesn’t necessarily have to be a super complex, full sized background image. Here are some examples:

Four ways of using background images in Panoramas

You can use Panorama background images in different ways. Here are four different techniques I’ve found being used:

Background images in Panoramas

Use app bars and mini app bars at your discretion

The guideline here is simple: It is ok to use different app bar modes between Panorama panels or no app bar at all. You can have a mini app bar with X, Y, Z, options on panel one. Then on panel two you only have option Z. Then panel three you have a full app bar with option W, X, Y and Z plus 3 icon buttons for delete, search and edit. So in a nutshell, you can make the app bar adapt to specific panel needs. App bars consume real state - valuable pixels - so be picky when designing them. Best not to need an app bar at all, if needed then start thinking of it as a mini app bar and only if deserves it, promote it upwards to become a full app bar.

You can change the out-of-the-box template… really!

One of the most common questions I’ve heard is how do we integrate our brand to a Panorama. Here are some examples of apps showing how they’ve taken over a Panorama control and made it their own. By default, Expression Blend and Visual Studio give you a Panorama template that doesn’t include specific place holders for branding elements so we tend to think there’s no place for branding. We also see the Panorama title in big font size using Segoe Semilight. A lot of us might think we can simply get away by writing the name of our app in there. The reality is that the Panorama title in the template is there as a place holder. While it might be enough for some apps and certainly for Windows Phone out-of-the-box services to use only a big Panorama title, for the majority of 3rd party apps (like yours) the Panorama template title is just not enough… it doesn’t help differentiate your app from another. The template exposes this title more as a place holder - something you can substitute for not only text but a graphic like the logo of the brand. You can make it smaller, you can make it a logo floating there on top of the Panorama background or even an image that spans several or all of the Panorama panels.

Fandango Panorama

MSN Money Windows Phone

Next Post

In the next post we will talk about how to compose Panorama panels using the Windows Phone design grid and other tips and tricks…


24 Weeks of Windows Phone Metro Design | #6 Information Architecture for a Windows Phone App

Friday, May 18th, 2012

 24 Weeks of Windows Phone Design Index

Twitter   

This blog post might not make justice to the depth and expertise that the discipline of Information Architecture deserves (although the definition of Information Architecture is still in flux) so I’m providing links at the end of this post to other websites that can take you much deeper into Information Architecture.

Demystifying IA

As deep as Information Architecture is however, it really is just a portion of a larger scope of activity called User Experience. Information Architecture is a means to an end. Information is not the user. The user is the user - a human. I’ve seen many websites or apps that sometimes seem to be primarily designed to please information itself - as if information or content was THE user. Take the typical approach of defining the ‘navigation menu’ for a content driven website. It is typical to see the navigation menu reflect the content structure available in the site, for example:

We’ve designed menus like these for years, but this is a completely anti-user view of the world. The website or app in this case is designed based on content types instead of designing it based on user needs. A user (in this case a ‘developer ‘) arrives to the website with a technical question about ‘how to set up data binding in a data grid control for a line of business application’. When the user gets to this site they know they have a need but the site is talking to them as if they knew where to search for their answer - should they go to Case Studies and hope to find how another development company solved a similar problem? Should they go to Tutorials and see if there’s an article that addresses this question? Should they go to Code Reference hoping some information is provided there? How about the Forums?

A different approach is to make the navigation menu based on a different metaphor that addresses users’ needs. If you start simplifying the sample menu I mentioned above you will perhaps find that the best result is just to substitute all those options for one single search box where users can write their need/question.

                  

While I might sound too extreme here, well, that’s actually what Google did - instead of having nested menus with tons of topics or categories like AOL or Compuserve did back in the day - Google said, let’s just give the user one simple input textbox so users type what they are looking for and voila! one of the cleanest UIs that turned into one of the most profitable and efficient user interface metaphors in the last decade. Still today the Google search page is considered a digital icon - just like the Fallingwater house from the Architect Frank Lloyd Wright in architecture or the Starry Night from Van Gogh in painting.

If you ask me, the Google.com site is a great example of how the Metro Principles would manifest on the web. There’s a lot of conversation going on right now about applying the Metro Principles to phone and tablets but a lot of people are also asking, how would Metro manifest in a website - look at Google.com. Fierce reduction of elements. Content, not Chrome (no pun intended :) ). Google.com has slowly been getting more elements (look at the top) but it still is quite clean.

The Google example is pretty radical (though real) and shows how Information Architecture doesn’t mean only information structure. The term Information Architecture tends to make it feel like users are not part of it (since the word ‘user’ is not included in ‘information architecture’) but users are actually the center of it. Some of today’s best and most recognized Information Architects like the folks at iA get this and while they love to give shape to information, all their projects have user as the center - Try the IA Writer app for iPad.

On October 15th, 2008 Glenn Murphy, a Software Engineer in Google wrote a blog post titled Content, Not Chrome. It’s interesting to see how the browser ended up being named ‘Chrome’ though :)

In conclusion, IA is not only about “structuring content” but about crafting the axis, the foundation, the structure of your entire digital experience. Saying IA is critical for a digital experience is an understatement. Literally think of IA like the soul or spirit - the essence of the experience. And just like every spirit (that I know of… :)) it needs of a body to manifest through. This body is the app.  So there you go: IA is the spirit. The app is the body. They are so interconnected, so tightly integrated that you can’t think of them separately. They form THE experience.

IA is all about bringing order to chaos, to align the misaligned, to sequence the random, to parse the mix, to understand the complex.

What is Information Architecture?

The Information Architecture Institute defines Information Architecture as “the art and science of organizing and labeling websites, intranets, online communities and software to support usability“. The Guardian recently made this post about the definition of Information Architecture. Also, here is a really good video produced by Buuteeq on What is Information Architecture? to show their non-techie customers the value of Information Architecture. It’s a good video to understand IA in simple words.

The way I describe the activity of Information Architecture is bringing order to chaos, to align the misaligned, to sequence the random, to parse the mix, to understand the complex.

The goal of the Information Architecture (IA) stage is to define three things:

-  Information

-  User Tasks

-  Relations between Information & Tasks

That’s what the user has in a digital experience: 1) information and 2) the potential of doing something with this information - whether it’s consuming information to help take decisions and/or for generating new information.

Most of us will start creating a Windows Phone app for either A) a client B) an idea of our own (startup idea). In both cases when the project begins we will be exposed to shapeless and scary ‘blobs’ of information like names, dates, prices, images, temperature ranges, zip codes, phone numbers, avatar images, scores, in-app purchases, stocks, locations… in the Information Architecture stage you take that shapeless blob and deliver structured information. Doing it in single try is impossible. It needs many passes. If I think I’ve nailed it on the first pass I’m wrong - Only Zeus himself could do it in a single pass :) But in all seriousness, force the IA to go through many passes whether you do it or you have others take a stab at it and provide feedback.

Tools to Define Information Architecture

We have three very useful tools that help us define our IA:

1.       IA Document

2.       Application Flow chart(s)

3.       Low Fidelity Prototypes

Something very important to consider here is that at this point we are not designing the user interface or the app itself. We are still working at the ‘essence’ or ‘spirit’ level :) - so no need for us to over invest time in visual design, user interface or animation details. Right now we simply want to straighten out our blob of information, bring order to chaos.

IA Document

The IA document I usually create is quite simple although you could add as much detail as possible. The truth is in many cases this document grows to become the actual specs of the app. But in our case we will keep this document nice and short. Here is an example that shows how we have brought our now more orderly blob of information into a document that shows the main and primary hubs as well as the spokes. This is a sample IA Document for a simple ’stock price’ app.

Download the sample IA Document in Word format. 

 

App Flow Charts

Remember the good old flow charts for software engineering (or any other process)? That’s what App Flow charts are, it’s just that the visual nomenclature we use is focused on user flow, experience and interaction design. I take the IA Document, with its early stab at the main, primary, and secondary hubs and also the spokes and transform it into a App Flow chart. Initially I add little visual information to each screen. Just enough to see the different modules connecting to other modules.

Then little by little I start adding more details to those screens for example I start adding some UI controls - only the critical ones that allow me to start telling user stories. Later I start turning some of these screens into abstract Pivots, Panoramas or Pages.

And so, little by little App Flow charts become more detailed going from simple task flows to screens that show an idea of content views and even navigation. I wouldn’t call high end fidelity App Flow charts wireframes but many people would. Low fidelity wireframes certainly.

Low Fidelity Prototypes

Once the IA Document and the App Flow chart are more solid, it is always a good idea to start working on paper prototypes - our third tool in defining the IA for our app. These can be helpful due to their low cost ($ and time-wise). A paper prototype is a paper version of your app - how fun is that! :) You can put together one of these bad boys by simply sketching out the different screens of your app, or for a more refined paper prototype you can use wireframes of your app. Just like with an IA Document or an App Flow chart, Paper Prototypes also evolve little by little and go from low fidelity to higher fidelity. Notice I say “higher” and not “high” fidelity because I personally don’t think it’s worth producing a super refined, polished, high fidelity paper prototype. The idea of a paper prototype is *precisely* to keep it rough, quick and dirty. The good thing about a paper prototype is that it is something that you can actually place in front of an actual test user.  The IA Document and the App Flow chart are too abstract for mortals to go through :) You and I sure… but for our dear user testers, a paper prototype is something they can actually use.

Please refer to the Paper Prototype section of the #3 Ideation and Concept post of this series for more information on how to create Paper Prototypes.

Now, it might seem, when I tell you that after the IA Document, comes the App Flow chart and afterwards comes the Paper Prototype, that I’m implying there are days or weeks or months in between these different stages/steps, but no :) In fact we are probably talking about minutes or hours between IA Document to App Flow to Paper Prototype. That’s the whole point of this process - to make it quick and dirty.

At the end you will have a solid IA document with structured information, a solid set of App Flow chart(s) and even some low fidelity Prototypes.

Architecting Information (for a Windows Phone App)

As I mentioned before, I won’t make justice to the practice of Information Architecture in this post but the method I use to define the IA for a Windows Phone app is the following:

1. We capture the needs of the project. We work with our client and write down the different needs, requests, data types, questions, wishes, and even ponies and unicorns in post it notes.

Important

Write user tasks or needs in post it notes of the same color. Write information/data or content on post it notes on another color.

2. We host a creative analysis session with at least one person from engineering and one person from our creative team and we go through the post it notes, we explore, we best guess, we inquire, we question and we debate to define and understand what the client really needs (which might be different from what they think they need).

3. We add our own flavor. Based on this analysis we add our own post it notes with needs, questions and also ponies and unicorns.

4. Create logical groups of related items. Group things in a way that makes sense. Pair things up, group them, relate them and highlight cross over connections.

5. Define hierarchies and give order by capturing the general structure of the blob we are dealing with in an IA document.

6. Create an App Flow chart. Once the IA Document is at least a bit readable - transform it into an App Flow Chart. Notice our natural approach here will be to create a tree like structure but this is precisely where you can break the mold - you could approach your app structure in different ways, radial, layered, multidimensional, hub & spoke or others… however, talking about Windows Phone apps in particular, where the app structure is based on the Hub & Spoke model, it is best to from the beginning of this exercise define a Hub & Spoke structure to your information. A Hub & Spoke model would define a 1) Main Hub 2) Sub-Hubs or Spokes of top level 3) Spokes of secondary levels. Eventually these different hubs or spokes will end up manifesting as Panoramas, Pivots or Pages in Windows Phone but in this stage we are not yet looking into this. Notice I mentioned “eventually” J No need to get too concerned about Panoramas, Pivots or Pages during the first few passes.

Microsoft will not reject your app if you decide not to adopt or follow the Hub & Spoke navigation model - so feel free to explore other models if they make sense to your app. That said, the Hub & Spoke navigation model is arguably the best one and the one that will become the most familiar with users so it is better to use it.

7. We identify relations (or dependencies) between different branches in the structure and we capture them in the IA document or the App Flow Chart.

8. Put the IA Document and/or App Flow chart to the test by telling user stories against them. Look for showstoppers - gaps or excess tasks and/or content/information and/or relations between tasks and content that are blocking you from being able to tell a user story. Based on these run-throughs, refine your Document and/or Chart and test it again with the same and/or more user stories. Do this a few times until your structure reacts firmly to all the user stories you are trying to address with your app.

9. Create a Paper Prototype. After a few passes, it is good to transport the IA Document and/or App Flow Chart to a Paper Prototype. And from there you have 3 things to iterate on, IA Document, App Flow Chart and Paper Prototype. Test the Paper Prototype with user stories and refine it until it can stand the test of all the user stories you want to address in your app. The Paper Prototype is useful because it takes your IA to the next level and it starts feeling more real (even if just in paper). You might be able to capture other pieces of data with a Paper Prototype vs just using an App Flow Chart. Also note that a Paper Prototype is something you can actually put in the hands of a test user whereas the IA Document and the App Flow Chart might be too abstract for a non-techie user or simply someone outside of your team…

The process of defining the Information Architecture for your app is not a one shot or one pass type of activity. It requires of many passes and many tests to your IA Document, App Flow Chart and Paper Prototype. Also, a reminder that at this point we are not fully designing our UI so you do not need (and I would probably not recommend) to invest a lot of time making the screens look beautiful - that comes later. Right now we are just trying to bring order to chaos.

Conclusion

At the end you will have a solid IA Document and App Flow chart(s). Not sure I’d say Paper Prototypes are something that you end up with - I personally see those more for iteration and to refine your specs. Things you will throw away at the end. Everything that you learned with the Paper Prototype(s) will be reflected in the IA Document and the App Flow chart(s) anyway plus the Paper Prototypes can easily get really messy J

So with IA Document and App Flow chart(s) you are ready to go to the next step which is to really start nailing down your Pivots, Panoramas and Pages with more detail.

More Resources on Information Architecture

The Guardian - What is Information Architecture?

Information Architecture Wikipedia

Usability First - Information Architecture

Web Monkey - Information Architecture Tutorial

What is Information Architecture?

Complete Beginners Guide to Information Architecture

Information Architecture - A List Apart

Information Architecture 101- Techniques and Best Practices

Design Your Windows Phone Apps to Sell

Understanding Information Architecture Differently

Next Post | #7 Layout and Composition in Windows Phone. In the next post we will review a couple different techniques to compose and layout Windows Phone UIs. The first one is using the Windows Phone design grid and the second one is using lists.

24 Weeks of Windows Phone Metro Design | #14 Using the Windows Phone App Bar

Tuesday, February 14th, 2012

24 Weeks of Windows Phone Design Index

Twitter   

To give continuity to the previous post on iconography, let’s talk about App Bar this week. I apologize for the “organic” approach to tackling down the blog post schedule :) In this post we will discuss the Windows Phone App Bar. The reality is there’s already plenty of good information about the App Bar out there so I’ll see this post more as an aggregation of what I’ve found out there plus some other tips I’ve learned along the way.

The App Bar in Windows Phone is one of the controls with more personality in Windows Phone. It is usually seen as a navigation bar but what I’ve found consistently is it’s more like an “action bar”. The reason I say this is because if you look at the out-of-box experience in Windows Phone you will find most of the Icon Button or Menu Items are more like actions or ‘verbs’ than pointers to other portions of the app. This might sound like semantics but I think it’s actually something stronger than just that.

The most important navigation mechanism in Windows Phone is content itself. Our instinct when creating an app tends to be solving navigation by adding as many buttons or UI controls as we think we need. In iPhone you will find developers enable users to go to other sections or even content views using the tab bar. In Windows Phone these views would be part of a Pivot control (Featured and Most Recent). Categories will most possibly have been located in a previous Page, Pivot or Panorama. If the user wanted to go to Categories in Windows Phone they would hit the back button. The Search button would be in the App Bar and the “More” would remain there as our Ellipsis Expander.

iPhone Tab Bar

Windows Phone App Bar

So, in Windows Phone the App Bar is usually not used for navigation per se but for “actions”. I don’t think this is written in stone though - for example you will find Settings available in many apps in Windows Phone (in the App Bar). Settings is clearly navigating the user to another section of the app - it doesn’t sound like a verb. In Windows Phone if you wanted to have two Icon Buttons in the App Bar called Theaters and Movies, then instead of navigating the user outside of their current context, these buttons would act more like “view switches” so the user stays in context, but the view changes to show movies or theaters. This is what happens in the Calendar - you have a Month Icon Button - you hit it and the view changes to Month view but the user is still within the same context aka Calendar.

Windows Phone Calendar

So they key takeaway is to always try to enable navigation through your application using content first - not UI controls. Use the App Bar mainly for hosting actions, not navigation (again, there’s always navigation occurring as you will be taken to another screen but within the same context).

Also a common approach coming from iPhone/Android worlds is to locate navigation buttons within content on the main page. In Windows Phone we usually avoid mixing UI elements like buttons with content. So if you have an email items list we would never place a button next each item for say “Deleting”. Instead we would recur to the use of tap and hold to bring out the Context Menu for the item, then hit Delete. In the case of the App Bar we could also have a Delete button in there, hit it and that switches the List View to multi-selection along with changing the App Bar to display new icon buttons relevant in this multi-selection mode, the user multi-selects items and hits the trash can button in the app bar.

The App Bar can either be collapsed or expanded (up or down). In both cases there are different states the App Bar can adopt.

Windows Phone Using App Bar Modes

App Bar

The Application Bar is one of our core navigation mechanisms in Windows Phone. It is a flexible control that lives on the bottom of the screen or on the sides if on landscape mode. The App Bar is 72 pixels high. The Application Bar always stays on the same edge of the display as the hardware buttons (Back, Start, and Search). Up to 4 icon buttons can be displayed in the App Bar but you could display down to 0 (zero) buttons if needed. If you don’t have icon buttons to display it’s better to switch to the Mini App Bar.

Windows Phone Page Structure
The App Bar is made out of the following elements:

Windows Phone App Bar Parts

Mini App Bar

In Mango, the Windows Phone team released a new mode for the app bar called Mini App Bar. The Mini App Bar is 29 pixels high. The goal was for this mode to release more pixels for developers/designers to use in their application when in many cases icon buttons were not needed and it was possible to condense required functions within the app bar menu space. This Mini App Bar would also enable us to use an App Bar in a Panorama, something that on the first release of Windows Phone wasn’t officially allowed. An option is to make Mini App Bar semitransparent (just the way you can do with a standard App Bar) if you want to let the content be visible. You can apply a 65% transparency to the Mini App Bar.

Windows Phone Mini App Bar

The App Bar is Flexible

Not every Panorama  (or Pivot or Pages for that matter) will require an App Bar. It will depend on your Information Architecture and content.  You can go from standard to minimized App Bar modes when going from Panorama panel to Panorama panel which means the user will see the bar rise or fall depending on the App Bar mode needed in that particular panel.

Windows Phone People Hub

Icon Buttons as well as sub menu options in the App Bar may change across different panels to accommodate the right functions needed for each panel.

Windows Phone Calendar App

Multistate Buttons in App Bars

A common question we hear is if we can host two or even three state icon buttons in the App Bar and the answer is yes. Two states could be enabled/disable and three states could be state 1/state 2/disabled. In all these cases it is important to portray the icon button state using the right icons. In general we want to preserve the same icon throughout the different states although in some cases when it makes sense you can slightly alter the icon to represent the new state or even change it completely. For example in the case of the Favorite icon (I don’t believe we actually use this example in Phone but totally valid).

Favorite Icons 3 States

Another example is for instance the SMS (Text Messages app) in Windows Phone - you will notice that if you press the + to send a new message the “send” Icon Button in the App Bar is disabled (because you have not yet typed anything). As soon as you type one character, the Icon Button goes from disabled to enabled state and you can now hit it. These are the subtle details that can really make you app nice and polished.

Windows Phone Enabled/Disable Icon Button App Bar States

App Bar Menu Items

Menu Items live in the App Bar and they are only visible when the App Bar is open or extended. Menu Items present tier 2 or second priority functions in your app.

It is important to consider that Icon Buttons and Menu Items should be seen as two different groups of functions. You have 4 open seats for Icon Buttons in the App Bar and in theory an unlimited number of Menu Items… although it is good to keep this from zero (0) to 10 items.

At the same time, note that you do not have to necessarily fill up the 4 seats you have available for Icon Buttons. You could decide to have only one Icon Button. You also could decide you do not need any Menu Items… zero. That’s just fine too.

One question/myth I’ve heard a few times is that you forcefully fill up the 4 seats available for Icon Buttons pushing the 5th function and beyond as Menu Items but as mentioned previously, Icons Buttons and Menu Items should be seen as two different function groups (not necessarily with continuity). So  if you realize you need two Icon buttons, and three Menu Items… that’s just fine.

Any Number of States in Windows Phone App Bar

Custom Usage of App Bar

Throughout the out-of-box experience in Windows Phone you will find some instances where the App Bar seems to be designed and working in a non-conventional way. The reality is you can define custom setups for App Bars as long as they help you address your particular user experience. An example of this is the Photo Camera which when expanded will show the Menu Items for camera settings on top and display the icon buttons for picking the camera flash mode on the bottom.

Windows Phone Camera App Bar

App Bar Colors

The out-of-box color in app bars is dark gray. This color remains while in a Light or Dark themes. This color is neutral and reliable for a number of scenarios. You don’t have to use that color all the time though. There are a couple other ways to setting the color for your App Bar. You can set these colors on the background color of the App Bar or in the foreground color of the App Bar (the Icon Buttons and Menu Items).

1 - Using the user accent color in the phone

2 - Using a custom color based on your brand

While all these are possible, freedom means responsibility J Remember we are talking about Metro here so we want to keep design clean. Usually you will find black and white color (defaults) for icon buttons work the best. For the app bar background itself the default gray will always be a safe bet but if you need to color the app bar for branding reasons, just make sure this color doesn’t make the white/black icon button invisible or hard to see (like making the app bar yellow will make the icon buttons hard to see).

Any Number of States in Windows Phone App Bar    Bad use of colors in Windows Phone App Bar

More Resources

In this section you will find some useful links to learn more about App Bar. There’s really good info about this control out there. Please drop me a comment if you have specific questions or scenarios and I’ll be happy to ask the team to give me ideas for me to share with you.

Page Structure - App Bar

App Bar on Orientation

App Bar Overview for Windows Phone

App Bar Design Guidelines

App Bar Icon Buttons

Jeff Blankenburg on App Bar



Next Post | #15 Designing Windows Phone Icons. In the next post we’ll cover Windows Phones icons in depth.

24 Weeks of Windows Phone Metro Design | #15 Designing Windows Phone Icons

Tuesday, February 7th, 2012

24 Weeks of Windows Phone Design Index

Twitter

Good week everyone! Last week I traveled to Germany to speak at M-Days. It was a quick visit but super fun event with tons of people who participate in different segments of the Mobile industry. I learned a lot about the staggering growth expected for everything related to mobile, phones, tablets, devices. Because of the trip I didn’t have enough time to write the next article called 6 - Translating Information Architecture into a Windows Phone App Flow. So instead of failing at my commitment to post every week I decided to produce the 15 - Designing Windows Phone Icons post. How naive! this post turned out to be one of the longest ones! (and I’ve wrote some long posts already!) - so here it goes.

Designing Windows Phone Icons is one of those things that would seem straightforward but instead it can be something actually quite challenging for different reasons. Compared to other aspects of Windows Phone, designing icons is definitely more of an art than a set of rules or guidelines. We’ll certainly cover the guidelines but ultimately there will be some creative/artistic aspects to creating great icons. This applies not only to Windows Phone for any other platform. Designing icons for iPhone, Android or Windows is always a whole specialty on its own. Creating icons is such a specialty that there are companies and designers who are devoted 100% to designing icons like the popular Icon Factory.

Windows has a long tradition with icons since its inception and the Windows team has provided guidance for previous version of Windows. Windows 7 icon design basically shows the highest point in skeuomorphism (using physical world metaphors with realism to illustrate abstract concepts) for Microsoft. From there, we are now going to a very clean and minimal style with Metro.

Windows Icons

Let me provide you with a useful resource right off the bat before we start going deeper into the topic of the day. A designer in the Studio provided me with a cheat sheet that includes different tips for designing Metro icons. This is the designer that has drafted most of the icons in the Phone or has helped other designers in the Studio do it as well. Here are a few of his tips:

- All icons are monochrome

- Use knock outs instead of drop shadows

- Transparency instead of shade

- Chisel arrow heads

- Use square corners instead of rounded

- Use square end caps instead of rounded

And here is a visual chart with his tips:

Designing Metro Icons

You know how I always take things deep right? Cool So it won’t surprise you I will now want to talk to you a little about design history and where Metro icon style comes from. I think this will give you some context and will eventually enable you as a developer to look for the right designers to partner with. It should also help designers to pin point the visual style used in Metro for icons.

We’ve mentioned before that Metro is influenced by the International Typographic Style or Swiss Style which in turn learned also from the Bauhaus school of Architecture and Design. This whole movement was broad and global. With the continued globalization of the world in the early 20th century, many people realized that more common visual languages were needed to communicate with people of all sorts of different cultures and backgrounds.

Otto Neurath, a philosopher, sociologist and political economist defined the thinking behind something called the Isotype. His goal was to share political, economic and social data to people even when these were not experts on these disciplines or couldn’t even read. He is what I’d call, the father of Infographics - or at least the first one who really kicked of the idea of conveying complex scientific and economic/social data using only images. Neurath’s theories were put in practice when he partnered with Gerd Arntz, a designer. Arntz helped visualize Neurath’s ideas and craft an Isotype Collection that is now regarded as the early origins of all international communication, urban signage and transportation graphic iconography.

In Arntz Isotypes you can see how the concept of abstraction was present. Communicating a concept with as few elements as possible. No use of regional or extremely local aspects, textures or symbols but instead looking into represent concepts by observing a global understanding.

The Pictographic Corporation, founded by Rudolf Modley - designer, was the American wing of the thoughts and visual communication language that Neurath and Arntz started in Europe. Modley’s work, which represents American economics/communication aspects, demonstrates the same abstract, global visual expression from Neurath/Arntz.

One interesting visual aspect that Isotypes used was contrast. A masterful use of this tool allowed designers to produce and convey complex graphics in a single color. This would not only strengthen the idea of minimalism and clean design but it would also make printing cheaper. There was a strong social understanding from this visual design school of thought.

I found this concept of contrast has been applied in a couple different manifestations: Infographics and Illustrations.

ContrastInfographic

From those years, 30s-40s, this visual language spread out throughout the world. The Second World War and its conclusion increased the need for a global language. Society had never had so many people traveling throughout the world. People from Asia came to America, and from America to Europe. People from Europe went to Africa, and from Africa to Asia. Globalization. With people from different cultures and languages, governments had the need to create universal visual languages to enable visitors to major cities like Paris, New York, London, Tokyo, Mexico, Munich. Throughout these years many designers addressed and produced symbols (icons) to address this need. Producing large amounts of graphics to convey instructions, warnings, guidance and information in communications, transportation, society/politics/economics and even sports primarily driven by the Olympics.

In 1974 the United States Department of Transportation (DOT) realized that just within the U.S, there were many different isotype collections being used. Multiple versions coming from different sources. Most of them would address the same concepts, for example, 21 different icons were found for Coffee Shop being used across different cities in the U.S.

The DOT commissioned AIGA (formerly the American Institute for Graphic Arts) to produce a single (”one rules all”) symbol (icon) catalog that address the visual needs across U.S. cities. This would basically unify the visual language in the country. It’s kind of ironic that a design style that’s supposed to convey universal concepts had SO MANY different versions of doing so! Smile This topic could take us into a deep deep conversation about Metro (how there are many ways of doing things , not just one) but I’ll skip that discussion for now Smile A number of designers including Massimo Vignelli, one of the most influential designers in the U.S. who brought the International Typographic Style to this continent.

This team of designers performed an extensive research and catalogued a huge number of symbols (icon libraries) used by different cities in the U.S. and other countries like Japan, France and the UK. Then they designed the “one rules all” symbol collection which is now used across the U.S. and many other countries. This symbol collection is available free of use in the AIGA website. Many of these icons would work great as Metro icons… some of them might not be readable at 26 x 26 pixels in an app bar but for in-app icons yeah, they could work.

AIGA Symbols

This effort gave birth to what Ellen Lupton, prolific type and graphic designer described as “The Helvetica Man“. It is interesting to find similarities with Helvetica Man and with what we all know as Stick Figure which is kind of the simplest way to represent a person. Egyptians were already using this symbol back in the day. This just reinforces the lesson of today’s post: Abstraction. That’s all. See you next week.

Helvetica Man

Ok, not enough let’s go deeper Smile

But really, when designing Metro icons we are not thinking too different from those Egyptians or from our friends Otto, Gerd or Rudolf and even from Master Vignelli. Abstraction… how can I represent this concept with the minimum set of visual elements possible and in a way that as many people from anywhere around the world can understand?

That’s the same question we have to ask ourselves every time we design an icon for a Metro app (same applies to Windows and Windows Phone of course).

The goal behind these design style is to illustrate a concept in the most abstract and universal way possible. Think of a taxi cab. Taxi cabs are different all over the world - in some places they are yellow and black, others are red and white, others are black. Some have a tiled texture, others have local ornaments depending on the culture. So creating a icons in 3D, with textures and details could make the icon “too local”. By abstracting those details and leaving only the essence of what a taxi cab is, we are able to communicate more globally. This is inline with the Metro principle, Content, Not Chrome. By reducing details and visual weight from the iconography in the phone we release our user’s eyes to focus more on the content - not the icons. Icons, along with typography, motion, and other UI controls form a sort of thing veil letting the content stand out. Like we’ve said before, this icon style is simply a different style from what we see in iPhone or even Windows XP or Windows 7. This style follows different design principles.

Here are some Metro icons to be used in the App Bar or within your App as UI elements. You will immediately recognize the same design style behind these compared to the work of the designers described above.

Metro Icons

Let’s now jump from History Channel to DIY (Do it Yourself) Channel!

Designing icons for Windows Phone

Talking about Windows Phone icons, let’s start by defining the different contexts and scope in which “icons” can exist in Windows Phone:

Branding

- Start Screen Tiles

- Application Tiles

- Splash Screen

- In-App Branding

- Marketplace

User Interface

- App Bar

- Status Bar

- In-App Icons

As you can see from this list, there’s a lot to talk about but I can see a couple big different areas or contexts in which we need to design icons:

1.       Branding of your app (we will cover this in a future post!)

2.       User Interface Icons (below…)

Designing icons for your app is part of defining the identity of your app itself, your brand, your value proposition and even business model. Branding is a whole big area of conversation. It’s also about color, style, value proposition, identity and others aspects. We’ll talk about Branding in a future post.

So in this post I will focus on User Interface icons, meaning we’ll explore the following 3 types of icons:

1.       Status Bar

2.       App bar

3.       In-App (UI) Icons

Status Bar Icons

Let’s start with status bar icons. The key takeaway here is there is no take away J You can’t do anything with status bar icons. They are pre-defined. Unchangeable. Fixed. So perhaps that’s the take away. There is no way to design a custom icon and put it in the status bar. The only thing we can do with the status bar as a whole is hide it while in our app (or show it). The status bar is 32 pixels high so a good tip is not to place any critical UI elements of your app up there so that if the user taps the upper portion of the screen to reveal the status bar, your UI gets obscured. 32 pixels is not a lot so you will usually not have this problem with UI controls but sometimes you want to take precaution depending on how you are incorporating branding or header-like elements up there. You might want to leave a buffer of 32 pixels or even push the branding/header down 32 pixels when the status bar is revealed.

Helvetica Man

This is a good article that describes every icon in the status bar.

App Bar Icons

Let’s start by killing a myth here. From a purist point of view, those icons we see in the Windows Phone app bar are actually buttons. I’m being a purist here. We tend to think that icons in Metro and Windows Phone need that circle around them. The reality is that the circle is a button control and not part of the icon itself. The icon is just the graphic. So formally speaking these are called App Bar Icon Button. Icon Buttons exist mainly in the app bar but you can also use them within the app space. Learning more about the app bar in general can help you understand better the context in which buttons exist. Jeff Blankenburg’s 31 Days of Windows Phone also has a good article on App Bar.

Icon Buttons in the app bar also use a small text label underneath them. This label is hidden until the user taps the ellipsis to expand the app bar. Theory says the icons should be self-explanatory but a label, which in this case acts like a website tooltip can be useful too.

The Best Metro Icon Design Tutorial - Templarian

The best Metro icon design tutorial out there is from Austin Andrews. This is a must follow designer - Austin shows us how to create an icon following the right dimensions (approximately 26 x 26 pixels for the icon which will be hosted in a 48 x 48 pixels circular button) and the right color (white). Note that we call it approximately 26 x 26 pixels because depending on the proportion of your icon, more vertical like a clip or more horizontal like say, a ruler, you might actually go a bit (2 or 3 pixels) bigger than the 26 either horizontally or vertically. You do not need to create a black version of the icons for the Dark Theme because the system will automatically invert the colors. Austin uses Expression Design for this tutorial. I love Expression Design and it is my number one tool. It’s like a mini Adobe Illustrator but the color picker is so much better because it’s big and always visible.

I really want to highlight Austin’s contributions to the Metro community here. Not only he provided an amazing tutorial but he has created a library of 300+ icons for you to use in your projects! You can even send him a tweet and he’ll create an icon and include in the next release of the library (just make sure the icon doesn’t already exist J).

Our popular friend Kirupa, Flash community God and Expression Blend Program Manager also has a good tutorial on creating Windows Phone icons with Adobe Fireworks. I personally don’t love the ‘k’ in the example (needs more weight) but nevertheless a useful tutorial.

The MSDN Library provides guidance on icon design as well. Here is some key design guidance:

Icon images should be 48 x 48 pixels in size. The foreground graphic for the button should fit in a 26 x 26 area in the center of the image so that it does not overlap the circle.

The circle displayed on each button is drawn by the Application Bar and should not be included in the source image.

Icon images should use a white foreground on a transparent background using an alpha channel. Windows Phone automatically colors the icon according to the theme selection (light or dark), and colored icons can cause this effect to display unpredictably.

Do not create a button that navigates backward in the page stack. All Windows Phones have a dedicated hardware Back button that should be used for backward navigation.

Keep Icon Button labels as short as possible. If the language of the device is English, labels appear on only one line, and are truncated if necessary.

Choose icons that have clear meanings when the phone is rotated. When the phone is in landscape orientation, the Application Bar appears on the side of the screen vertically. The icon buttons are rotated so that they appear upright to the user. It is possible for icon meanings to be confused when this occurs, particularly if two of the icons are mirror images of each other such as << and >>.

One thing to keep in mind here is that these guidelines kind of mix tips for icons and for icon buttons - they are not the same thing :) but useful anyways.

In-App User Interface Icons

The third way of using icons inside of a Windows Phone app is within the UI itself. I’d say we can classify the use of icons in:

1 - Notifications or Idle Icons

2 - Interactive Objects (usually inside of buttons or list items).

The same design principles reviewed in the previous section apply here except you are not restricted by a 26 x 26 pixel size because since you are stepping outside of the app bar well, size doesn’t matter. Note however that the 26 x 26 guideline is still “recommended” as you will see in the following examples. You can however depending on your design make icons bigger if you wanna push Metro beyond what comes out of the box :)

Notification or Idle Icons

These are icons that communicate a visual message without being actionable. They are not buttons or other interactive control - they are simply graphics. These icons will usually be floating without any container around them. They can piggy back on some other interactive element to provide this object with context. For example an email will display a clip icon indicating this item has an attachment but the icon itself is not tappable (clickable?) - the email item is.

Interactive Objects

Icons can also exist as part of interactive objects. Here the icons can sit to the sides, top or below an interactive element like a button or a listbox item. Check out Facebook for example which uses the icons people have grown to know well in their website next to their main Panorama menu. Icons could also exist inside of icon buttons. Icon buttons are those little 48 x 48 circular buttons we use in the app bar. Well, we can also use those outside of the app bar and within the app itself. In Metro you will always tend to wrap an icon that is meant to be interactive within a container of some sort to make it “feel clickable”. This is more of a guideline than a rule. I can see how you could create some nice apps using big tappable icons without a container.

One of the things to consider when using icons in your app either as notifications or as part of interactive objects is to make sure you are adapting to the user theme (light or dark) if you app is designed to respect this user choice. If you have decided to make your app not follow the user theme choice, that’s fine, you won’t have to make your icons adapt. If the theme is light then you want to make your icons black. If the theme is dark then the icons should be white. Here are a couple articles that will explain more how to do this (mostly for Developers).

Reacting to Themes to set the right icons…

How to: Change Icon Buttons and Menu Items Dynamically for Windows Phone

Tip: Do not use Tiles inside of apps! Smile This is a classic. Everyone loves Tiles. I know I do. But we always see folks using Tiles as “tab controls” or simply as “icons”… so you’d have the icon inside a square (like a Tile)… No, let’s not that. Tiles are Tiles, and they are meant to exist “outside of the app context”. That’s precisely their value. So, remember, no tiles inside of apps, even if it’s tempting. Icons are usually used floating nicely without any borders or containers unless they exist within buttons.

Update: Someone named ‘contextfree’ left me a comment on this post with 3 really good things to consider if you do want to use tiles in your app:

- Do the tiles represent “content” that someone might care about? They shouldn’t be used for navigation or tools.

- Is the page with the tiles a kind of sub-Start-screen for the kinds of content your app deals with?

- Can you actually pin the tiles to the Start screen as secondary tiles? (If it doesn’t make sense to implement a pin-to-start feature for your tiles, it probably doesn’t make sense to present them as “tiles” to begin with.)
Here are a bunch of examples with annotations to highlight the type of icons we are using within these apps. Remember there are basically two types of In App Icons: Notifications and Interactive Objects.

Windows Icons

Click Image for many more examples of icons in Windows Phone apps…

Tools to create icons for Windows Phone

App bar icons are required in PNG format (with transparency) so they are bitmaps, not vectors. Vector based icons simply don’t work in the app bar control. I received a question in Twitter about whether it was a good or bad idea to represent the user accent color in the icon buttons in the app bar. From a Metro point of view there’ s nothing wrong with changing the color of the icons to something other than white or black (look at Twitter for example). You provide icons in white with transparency (PNG) and then you can specify the foreground color of the App Bar - this foreground color will be applied to your icons magically! You could bind this foreground color to the Phone accent color or even pick a custom color based on your branding (i.e. Twitter app) - thanks @Asmodai42  for the clarification here!

Because of this the tools you will need for creating Windows Phone icons need to produce bitmap graphics which basically any graphic design tool will do. Now, here’s something important: even though the icons are to be saved as PNGs (bitmaps), I strongly recommend you use a vector graphic design tool to create them like Illustrator or Expression Design. Photoshop and Fireworks also support vector paths. The goal is to create your icons in vectors so you can easily scale them without losing quality. Once you are ready export them as PNGs. Creating your icons with vectors is like preserving the source code of an app - you can always go back and make any changes you want.

If you are a developer and don’t have these tools you might want to use Paint .NET (designers will cringe with this Smile) - it’s all good as long as you can adhere to the specs, guidelines and style we’ve described here.

Resources

Icons are one of those things that are produced by the thousands. We’ve found many free Metro icon libraries and some for sale. Here is a list of some of these libraries and I’m placing a little note on what I think about these. If you know of others please leave me a comment. If you disagree with my review let me know too J

Some of my comments will actually help you I think in getting a better idea of what’s good and what’s bad.

Windows Phone SDK - The SDK includes a number of icons produced by the Windows Phone Design Studio. I believe we have nearly 40 of them. These are great to use in many scenarios and in some cases can be modified. The icons also get automatically exposed in Expression Blend under Common Properties | IconUri Property (check out Kirupa’s tutorial). The physical path for the icons in your PC is: C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Icons

Templarian - Amazing collection - amazing contribution to the community.  @templarian

http://idsgn.org/posts/helveticons/ Let’s start with quality. These are simply to notch and also $279 USD :) No comments. They are just awesome.

http://www.iconspedia.com/search/windows%20phone%207/ Many good icons but watch out for some that have too much density and when scaled down for app bar usage will not be readable. Do not use icons with so much going on: Example 1 Example 2 Example 3. Another thing with these icons is that they are provided in blue and black. Ideally they be provided only in white. You don’t really need blue. Second thing I notice is these are all provided with a circle. The circle should not exist. Remember the icon is just an icon - a lot of people think Metro icons always need a circle but no, that is never the case. The App bar icon button are circle buttons with an icon inside. Finally the other issue I see is these icons are provided as PNGs which means you will have to edit them to remove the circle and change them to white. It’s not like it’s a lot of work but vector icons would be better (remember, create icons in vectors and save them as PNGs). All this said, showing the icons within a circle does help providing context on how the icons will look.

http://www.iconsforwindows8.com/free-windows-metro-icons/index.htm These are free icons that are good. I noticed a consistent issue when centering the icon in the circle (through remember the circle shouldn’t be there).  If this misalignment is caused by some extra transparent pixels in the icons then that could be a problem when you add these to your app bar. It is better not to use the arrow icons in this collection. The arrows used in this set are not chiseled so formally speaking they are not Metro. You can always check icons against the AIGA collection which is the style we follow in Metro.

http://yankoa.deviantart.com/art/MetroDroid-200340391 I understand these are not really for Windows Phone - don’t get confused using these for Metro. Gradients and shadows, not Metro :)

http://yankoa.deviantart.com/art/MetroStation-183210118 These are some really good icons. Use these J There is one icon for a CD that when previewed showed like it was using two colors - black and gray but no, it was just black and semitransparent black. That’s perfect! You never wanna use two colors, only one - but you can use transparency. Good job!

http://metro.windowswiki.info/ Good icons. They look so similar to the ones we provide in the SDK that I wonder if they came from there J

http://graphicriver.net/item/metro-icons/1399780 Really good icons - for sale at $8. Provided in multiple formats so you can edit them if needed. While they present the icons in a circle they do so to show them in context of being used in an app bar.

http://msdn.microsoft.com/ja-jp/windowsphone/hh544699 These icons are provided by Microsoft but unfortunately they are not Metro icons. Even the icons shown there with a single “gray” color seem to come simply from changing colors in one of the full colored icons and not optimized to work well on small icon buttons in the app bar. Do not use these icons for app bar buttons or for in-app Metro UIs. These graphics are great for games but not Metro apps.

Icons and Localization

Turns out that text is not the only thing we need to localize. In many cases icons or graphics can have different meanings in different locales. Some interpretations of icons can end up being pretty rude! J So here are some tips for you to consider when choosing icons for apps that will be used in multiple countries and cultures.

Question for you: During the Windows Phone Design Day tour I heard at least a couple different comments from people saying that X or Y icon meant something different in China, India or Norway… do you guys have examples of these type of icons that you know have a different meaning (perhaps a bad one) in other countries? Drop me a comment here please J

Icons using fingers such as an OK sign or V-sign may mean different things to different cultures. Our Western symbols do not always mean the same abroad. An oft cited example is the representation of the house referring to a home page, or a letterbox to mail. The use of animals in logos can cause embarrassment and further problems. For example, pigs are considered unclean in the Middle East and cows as holy in India.

Avoid single-letter concepts, as confusion will be introduced through translation

Avoid graphic elements with text

Avoid graphics depicting human body elements and body language

Avoid graphics depicting humor, puns, and slang

Avoid graphics depicting physical environments

Avoid graphics depicting ethnic, racial, political, and religious environments

Avoid graphics depicting gender-specific elements

Avoid graphics depicting images of animals

Avoid graphics depicting sexual and violent elements

Avoid graphics depicting regional conventions, such as reading direction, date/time, and monetary elements

Avoid text and numbers in icons and images because they require localization.

Source

This is a good paper with more details on localizing images, considering cultural aspects and visual metaphors.

24 Weeks of Windows Phone Metro Design | #5 Choosing between Panoramas, Pivots and/or Pages.

Sunday, January 29th, 2012

24 Weeks of Windows Phone Design Index

Twitter

In this post we’ll try to answer a very common question that developers and designers ask us all the time and that in fact we in the Studio try to define always when exploring new features in Windows Phone: Should we use a Panorama? Or a Pivot? Or a Page?

First I will start by saying that it is not Panorama OR Pivot OR Page. It is more like Panorama(s) and/or Pivot(s) and/or Page(s).

When I first started working on Windows Phone I had a wrong perception.  I’ve found this wrong perception also in many other developers and designers throughout these months. The perception many times is that you have to choose one out of these three screen types for your application. False. Windows Phone apps are made out of a collection of screens of different types that are interconnected. So Windows Phone apps are made out of a number of Panoramas, Pivots and Pages. It’s not OR, it’s AND/OR.  In Expression Blend and Visual Studio you can create a new Windows Phone project with a Panorama or a Pivot but it’s just the starting point - from there you can add a number of Panoramas, Pivots or Pages.

New Project

Could you have apps that needed only one single Panorama? Sure (i.e People Hub although it has so many connections to other parts of the phone like contacts list, settings etc - that’s it doesn’t feel like a “one panorama” app).

How about a single Pivot? Yes (i.e. Twitter app - kind of, although even that one has orbiting pages around the main Pivot).

How about apps made out of a single Page? Yes. But it is not common.

The large majority of apps are made out of a healthy mix of many screens of different types, Panoramas, Pivots and Pages.

Multiple Screens

Defining what types of screens to use depends on the Information Architecture (IA) of your app. We will get deeper into IA in the next couple posts so for now let’s try to define a series of guidelines (or rules when possible) to know when to choose one screen type versus the others.

During the tour last Fall I came up with the following statement that I think exemplifies the current ‘state of the union’ in the Windows Phone Marketplace:

“Panoramas are overused, Pivots are misused, Pages are underused.”

As we mentioned before, the choice of using Panoramas, Pivots or Pages is directly influenced by the IA in your app. Here is a quick guide to pick Panorama, Pivot or Page depending on your information needs:

Panoramas are for content consumption.

Pivots are mostly for content consumption and in some cases for content input.

Pages are for one dimensional (one view) content consumption scenarios (whether lists or video, audio, images/photos…), great for content input and great for content generation.

Screen versus Content


Panoramas

“Panoramas are like Magazine Covers. They expose only a few top pieces of content.”

Panoramas are gorgeous! Why wouldn’t we use them? Every Windows Phone app needs at least one or more Panoramas! - Wrong. Panoramas are gorgeous yes, they leverage the Light, Clean, Open, Fast Metro Design Principle. They are designed to make the user feel like they are dealing with content that spans beyond the physical borders of the phone itself! - content peaking communicates continuity in a beautiful way tempting the user to swipe to the left or right and discover more content. The parallax animation effect where the background of the Panorama moves a bit slower than the content floating on top of it (basic animation principle to convey depth used since early animation studios) makes panorama an immersive adventure.

Panoramas rock, and because they are awesome we tend to overuse them.

Here are some guidelines for when to use and when not to use Panoramas:

Panorama(s) are the “Magazine Cover(s)” of your app. They display only the top or featured content for users. They expose a sneak peak. Not all the content - just those top headers and articles. It’s just a sample of the goodness of your app - not your whole app! Panoramas display a summary of the functions and content available in your app. Literally think of them as magazine covers. To design Panoramas, think of them as full spreads of content, not as single Pages but as a whole large spread. It’s fun to design. Want to get inspired to design Panoramas? Explore some popular and well design magazine covers:

Dwell  Entertainment Weekly

Rolling Stone  Dwell


Panoramas are Magazine Covers

Windows Phone apps do not always require of a Panorama. There are apps that use no Panoramas and that’s just fine.

Panoramas can’t hold large amounts of data. For performance and experience reasons do not use Panoramas if you have the need to present a large amount of content for users. How much is too much? In general stay within 3 to 5 Panorama panels. Use ListBoxes that use a maximum of 15-20 items. Panoramas are not virtualized (memory managed) so think of them almost as big flat images than dynamic content controls (like Pivots). Again, they are more of Magazine Covers - beautiful and immersive.

Panoramas are not best friends with ‘draggable’ controls or objects. Sliders or other controls that have a draggable function can interfere with the swipe gesture in a Panorama. If you require of input controls that are draggable it is better to pop out a Page, have the user make input there and then return them to the Panorama.

Leave Panoramas for the end of your design process. What?! Yes! J I realized that Panoramas are better designed and more easily laid out when you leave them to the end. This is contrary to what I did initially and what I’ve seen most people do. It’s even contrary to what Visual Studio promotes but trust me, leave Panoramas to the end. Panoramas expose only the top/featured/most recent pieces of content of your app - but you cannot define what top/feature/recent content to display in your Panorama until you have not nailed down the full extent of your IA and the rest of your app including Pivots and Pages. Creating a Panorama once the IA and flow of your app have been defined (including Pivots and Pages) is the way to go and makes your Panoramas more streamlined, better designed and more efficient. You can certainly decide or define you will need one or more Panoramas early enough in the process - go ahead and include them in your application flow - but do not go ahead and design them just yet.

Pivots

“Pivots are data friendly. You have large lists of information to present to the user? Use Pivots, not Panoramas.”

Pivots tend to be misused. These are powerful, horse power controls that have the ability to present and handle large amounts of data. They are virtualized so their performance is much better and optimized for handling large amounts of data compared to Panoramas. Pivots are best friends with ListBoxes (or ListView) controls. Many times we see us trying to use Panoramas (because of their cool, immersive value proposition) when we should be using Pivots.

Pivots help you present lists with information from the same data source but sorted out in different ways. Pivots have Pivot Items. Each of these Pivots Items can present information from the same database but sorted out in different ways. For example in these two cases we have two different Pivots. The first one shows golf courses presented in three different Pivot Items, one shows Recent golf courses, next shows nearby golf courses, the third one shows all gold courses available. So, all are golf courses but we present them in 3 different ways. Also notice that we present information from the same database in completely different ways. Notice how nearby courses use a map and highlight data related to location, where recent shows a list in chronological order and displays the date when we last played in that golf course.

Pivot 01

Pivot 01

Pivots are not best friends with ‘draggable’ controls or objects. Sliders or other controls that have a draggable function can interfere with the swipe gesture in a Pivot. If you require of input controls that are draggable it is better to pop out a Page, have the user make input there and then return them to the Pivot.

List view design is fundamental for a great Pivot experience.

Pivots can also be used for displaying completely unrelated information between its different Pivot items. For example Settings. Think of this metaphor as application tabs.

Pages

“Pages are best for content input and content generation. ”

Pages sound kind of boring - no parallax effect like in Panoramas, not immersive, not feeling like they span beyond the screen borders - just a plain good old static screen. This perception is what drives many of us not to use Pages enough and instead force functionality into Pivots and Panoramas even when these are not needed.

iPhone and Android apps are naturally driven by single static pages. It is the task of the developers/designers to create immersive experiences within these page boundaries. In Windows Phone, with Pivot and Panorama as strong and exciting UI metaphors, it is easy to forget that Pages, like in iPhone and Android, are still super important and can help us solve many scenarios.

Pivots and Panoramas are great for content consumption. Pages are best for content input and content generation.

Pages are the best for receiving input from users. Think of a calculator (multiple buttons), forms that users will fill out with information and other heavy input scenarios. Perhaps configuration or settings and other scenarios with a number of input controls like sliders, text boxes, checkboxes, radio buttons.

Run Keeper

Pages are great for content generation. Think of note taking apps, drawing or sketching, chat or communication apps and games as well.

Run Keeper

If you only need to present a set of data without multiple views use a Page. If you need multiple views, a Pivot might work much better, or a Page linking to other Pages.

Run Keeper

Pages are great for showing details of a previously selected item in a list or another object in a Panorama or Pivot.

Run Keeper

Pages are like pawns in chess, there are many of them, they are usually not the star the show but, they are essential for an app to function.

Next Post | #6 Translating Information Architecture into a Windows Phone Application FlowNow that we have learned more about application flow and choosing the right screens, Panoramas, Pivots and Pages for our apps, we are ready to get deeper into Information Architecture. In the next post we’ll learn more about IA and how we can translate it to Windows Phone Design paradigms.