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.
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.
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.
“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:
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.
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.
Pages are great for content generation. Think of note taking apps, drawing or sketching, chat or communication apps and games as well.
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.
Pages are great for showing details of a previously selected item in a list or another object in a Panorama or Pivot.
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.