ux.artu.tv » Blog Archive » 24 Weeks of Windows Phone Metro Design | #5 Choosing between Panoramas, Pivots and/or Pages.

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

24 Weeks of Windows Phone Design Index


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

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

  1. Todd Says:

    I wish there was even more emphasis on not using draggable interface objects on panoramas and pivots. In fact your example even gets it wrong. Toggle buttons (the on/off slidey switch things) are draggable items, though of course you can tap to toggle them, too. But if you try to slide them and you have them on a pivot or panorama page, you’re going to accidentally navigate more often than not. Toggle buttons are great for settings pages, but this means that settings pages really *shouldn’t* be on pivots. Present your settings categories on a list in a pivot, if you must, and have each entry go to a page where you can use whatever controls you wish without having to worry about accidental horizontal navigation.

  2. Andrew Says:

    Good article! I hate when developers put settings pages inside a pivot… Or some even put settings in a panorama… Worst experience ever!

    I’ve noticed that when multitasking away from an app and then navigating back, the LongListSelector’s scrolling is often very laggy at first when inside a panorama page. Is that simply because it is a panorama, or that’s just how WP7 works?

  3. Jen Triñanes Says:

    Thank You! I’ve been designing my windows phone application and this gave me an idea of when to use Pano, Pivot and Pages.

  4. ArturoT Says:

    Todd - thanks for catching that mistake. I used the wrong image when uploading the Wordpress. As I mentioned in the articles it’s better not to put any draggable controls in a Panorama or Pivot.

    Andrew - I have a feeling that’s because of being inside of a Panorama yes - but let me ask around what folks know in terms of performance.

  5. » Developers: Guidance For Choosing Between Panoramas, Pivots And/Or Pages Zunited Says:

    […] his post on his blog to get a clear view of panoramas, pivots, […]

  6. Panoramas, Pivots or Pages ? - Windows Phone Forums at wpcentral.com Says:

    […] Pivots or Pages ? Maybe this article will help you decide. ux.artu.tv

  7. Martijn van Steenbergen Says:

    Very nice article! Thank you.

    Small typo in the TuneIn image: typogrraphy -> typography.

  8. Jakub Florczyk Says:

    Great post again. Please add twitter / facebook share buttons.

  9. Alberto Says:

    Hello Arturo since Lisbon Portugal design days :)

    Nice article you got here, and it’s so much true I totally agree!

    I am involved in several windows phone apps, most are not for me, but for enterprises, and the thing is that I find hard to use a panorama to start an app, just because I think of a Panorama like a menu that should be light in content, but rich ( not oversaturated ) in graphics, with great typo and engaging images (don’t necessarily be with very hi-res) displayed in a not so ordinary but organized way (in a sense to cause admiration but not confusion)! A panorama should great and so the content off that the panorama page hides, should be greater.

    Sometimes I wonder why developers take a panorama approach so quickly and use with such a emptiness of conception. But I guess is like it was pointed out. The panorama page is amazing and causes expectations.

    I look forward to see more articles like this, as it’s never enough to learn new ways to help designing and building great apps. It’s as addictive and fun to learn your design language as it is to apply it.

  10. WindowsDevNews.com Says:

    […] 31 Weeks of Windows Phone Metro Design | #5 Choosing between Panoramas, Pivots and/or Pages. […]

  11. Glenn Broadway Says:

    So if you don’t want to use Pivots (because of the problems you mention with sliding controls) what is the best way to design an app with ’sections’?

    For example, something like the Music app on iOS (formerly iPod) - The toolbar navigates between Podcasts, Artists, Songs, iTunes U etc. These are not necessarily different ways of presenting the same data (you site this as a reason for using pivots).

    I mean, if you’re just using pages how would you suggest the user navigates between them?

    I’m really interested to know what your thoughts are on how Windows Phone would present application structures that already exist on other platforms.

  12. Stilgar Says:

    Is it OK to use Panorama as a main menu for an app. It kind of fits the “cover” metaphore but not the “featured content” metaphore.

  13. ArturoT Says:

    @Alberto, thank you for the comments! Yes, Panorama is so cool we immediately assume we need one in our project but as I always say: UI is guilty until proven innocent.

    @Glenn: Good question - We have a pattern called Shuffle Cards or Pages which is basically a Pivot whose Pages present completely different content (not from the same database) as you mention in the Music app in iOS. So yes, you could use a Pivot - now if you need those Pivots to use draggable controls then you might need to use a Page as the main hub (menU to Podcasts, Artists, Songs) and that Page connects to other individual Pages so that you can have draggable controls. Another option I think is if the draggable controls are mainly the music player controls like a time slider… then you could put this *outside* of the Pivot control so that this control stays in place while the user flicks to go from Pivot page to Pivot page but the play controls stay in place. They can be dragged without making the Pivot flick because they are outside the Pivot.

    We’ll have a post in the future about iOS and Android metaphors and how we translate to Windows Phone.

    @Stilgar - Panoramas can have a “main menu” on Panel 1. Then Panel 2, 3, 4 can have only featured content. If you only need a main menu (as in a list) then you could simply use a Page - not a Panorama…

  14. Stilgar Says:

    Thanks for your answer.

    What about tiles? Do tiles fit inside panoramas or the visual infomation (panorama picture and pictures on the tiles) is too much?

  15. Glenn Broadway Says:

    @ArturoT Well, I’ve read te page at msdn.microsoft.com about Uniform Page Shuffle and it doesn’t seem to differ from a Pivot in any way. Your suggestion of using individual Pages instead of a Pivot (due the problems with draggable items) takes me back to J2ME development at the start of century.

    The reason I’m so interested in this particular area is because I specifically work on tools which enable cross platform deployment of mobile applications. Windows Phone’s idiosyncrasies are right up there with BlackBerry’s lack of touchscreen.

    Right now, the only choice is to crowbar in an iPhone/Android style toolbar which looks a bit like Windows Phone’s Application Bar, but which is less limited.

    I keenly await your Android/iOS metaphors post.

  16. ArturoT Says:

    @Stilgar Hello! - Yes, you could have tiles in panoramas. I personally don’t like that but it is possible. In a way I see those less than tiles and more like “grids” - but someone left a good comment in the Designing Icons post - check the comments for a good 3 step checklist on when “tiles” make sense in a Panorama (mostly in the main Panorama in your app) http://ux.artu.tv/?p=235

    @Glenn Thank you! - could you tell me a bit more about your scenario? Say Pivot could work well for draggable controls like sliders… is that what you would like to see? I’d love to understand user scenarios that would need of Pivot. Drop me an email to arturot (microsoft). Also, one way I’ve seen this done before is having a toggle Icon Button in the App Bar (ideally there) so that the user locks the Pivot page, then interacts with controls, then unlocks to keep moving… sounds like too much work for users but it works. I can’t remember what app I saw this in. Another option is to make the Pivot shorter so you leave some controls “outside” of the Pivot itself. The user can interact with draggable controls here without swiping the Pivot… potentially in this scenario you could programatically change the controls every time the user moves between Pivot pages so each page has the controls it needs. (When I say page here I mean Pivot page, not Page :))

  17. ux.artu.tv » Blog Archive » 24 Weeks of Windows Phone Metro Design | #8 Designing Panoramas Says:

    […] recommend reading the Choosing Between Panoramas, Pivots or Pages post for more information about when to use […]

  18. Toledo2 » Blog Archive » 24 Weeks of Windows Phone Design | #12 Designing Panoramas Says:

    […] recommend reading the Choosing Between Panoramas, Pivots or Pages post for more information about when to use […]

  19. Tips Panorama, Pivot dan Page pada Windows Phone | superaca.com Says:

    […] 31 Weeks of Windows Phone Metro Design | #5 Choosing between Panoramas, Pivots and/or Pages. […]

Leave a Reply