In the past few weeks I’ve tried to get familiar with building apps for Windows Phone 8 using C# and Xaml. As is my practice, I usually start out with reading – documentation on Windows phone design principles, Microsoft Academy Video tutorials and some sample apps. For each sample app, I try to identify the corresponding controls used to implement each feature and its usage context. In building my first app for Windows Phone, armed with some theoretical knowledge, I decided to use Nokia Trailers as my benchmark and implement my main menu screens using the Panorama Control. Over the course of 4 weeks, turned a pivot control actually did the job better. This post generally discusses reasons why the panorama control might not be suitable for apps data-rich content especially whilst maintaining simplicity.
Windows Phone Panorama
As defined by msdn , Panoramic experiences are a part of the native Windows Phone look and feel. Unlike standard apps that are designed to fit within the confines of the phone screen, panoramic apps offer a unique way to view controls, data, and services by using a long horizontal canvas that extends beyond the confines of the screen. These inherently dynamic views use layered animations and content so that layers smoothly pan at different speeds, similar to parallax effects.
Panoramas are great for displaying graphic background and minimal text or data content. An attribute that made the panorama control appealing to me was the extended background image that seemed to “tell a story” linking each item page within the panorama and providing a warm sense of continuity to the user. Another thing the panorama has going is the nice loading animation that Microsoft has added to it. Its content appear to animate in a rush from the right of the screen. Finally, I thought the option of having panorama slide screens with arbitrary developer-specified length was quite nifty and provided more control on what content to display.
Are Panoramas are Overrated ? Probably
Whilst building Trivia Monkey, I realized a few characteristics of the panorama made it quite unsuitable for my needs. Trivia Monkey uses alot of text data – basically trivia questions across different categories which players can answer. As described in this article, panoramas are best suited to magazine apps, music apps, movie apps etc and cannot handle large amounts of data. Here are other reasons I think panoramas are overrated.
Animation Benefit goes away when you are regularly “loading” the panorama content
On loading my app for the first time, it fetches data (generates its database of content or fetches from a server) and has to display a “content loading” holder for a couple of seconds. This means sometimes the animation benefit is lost on the user. Alternately I could attempt to prefetch my data in some other phase or only display my panorama when data fetching is complete. But it was my first screen and I wanted a swipeable panorama showing to let users know the app isn’t stuck.
In essence, when your panorama content may take a while to loadup, the panorama might lose some benefits.
Adds cognitive load on the designer and the user.
Sometimes, due to large differences in the content of each panorama slide page, they can appear disjoint , contradictory or difficult for the user. E.g when items are not horizontally aligned across panorama slide pages. This matters because at any given time, an edge of the next slide page is always peeking into the current slide page. Its just how the panorama is designed. Whilst this design feature of panoramas give an idea of continuity, if the items in each page are not designed to flush, it detracts from the UI feel . Aligning these content can be fairly troublesome for the designer/developer – especially if you use data bindings which you can only preview at run-time.
Much less space to display and organize content.
I found myself scrounging for space to describe each item in my lists and to organize content. Boo . The panorama UI guidelines are good, but there just a HUGE waste of meager screen real estate by that large Panorama title. Not suitable.
Theme Compliance Troubles
One additional overhead of using fancy background images in your panorama control is the optimizations you have to do for both light and dark themes. Whenever you apply a background image that’s dark, your text must be light in order to be legible. This situation is further complicated as users change from light to dark theme and the default text colour changes automatically . To handle this, you may
– “listen” for changes in the current theme to ensure your text is visible
– Force a legible text color for each background,
– Use transparent background overlays for each of your texts to ensure they are visible irrespective of the current background
– Implement deep theming .
A Pivot Can do the Job.
In most of the Windows Phone design documents, developers are encouraged to use the Panorama Control as a landing page and then use pivots after to provide more content. For apps with data-rich contents (especially with lists) and multiple views, the panorama might be just an extra layer of obstruction (clicks and taps) between users and content they need. In such cases leveraging the data-friendly high performance pivot might be the right way to go. I have written a short post that highlights the transition from using panoramas for the Trivia Monkey app to using Pivots. With proper design, pivots still offer a rich interface , nice scroll animations for each pivot page swipe – and more space to layout content.
“It cuts the fat” .
Overall, I think the pivot does a better job and gives a better experience. You be the judge .
Hopefully, this has been helpful!