Lens design guidelines for Windows Phone
September 30, 2013
Applies to: Windows Phone 8 only
In this topic, we’ll cover best design practices for using lenses and implementing rich media to create consistent, amazing lens app experiences on the Windows Phone. For info about developing lens apps, see Lenses for Windows Phone 8.
This topic contains the following sections.
A lens app is intended to complement the built-in camera, to feel like a natural extension of both the camera and photo viewing experiences. Lenses are useful because they’re a way to map real-world scenarios to an app that specializes in that scenario, such as panorama or group photography. Lenses achieve this by fulfilling two core functions:
UI example: (1) tap the Lens switcher button, (2) choose a lens and capture the moment, (3) confirm and save the picture to the camera roll.
View and experience:
UI example: (1) all photos appear in your camera roll, (2) reopen the photo in the app that created it, (3) experience or edit, (4) save a new photo.
When creating lens apps, it’s imperative that you keep these fundamental points in mind:
Lenses are primarily camera apps, and they launch in the context of the built-in camera experience. Although the camera experience on the device supports both portrait and landscape orientation, it’s important to understand that your lens app will most likely launch when the user is holding their device like a camera (landscape orientation). Therefore, we recommend that your launch screen and the default orientation of the app are set to the landscape orientation.
Lenses are a viewfinder-driven experience. That means that a user who is launching a viewfinder-specific app should immediately land on an experience that makes use of viewfinder properties. There are exceptions to this rule, like if your app requires the user to input credentials or get legal consent from the user to use some aspect of the app.
For more info integrating your app with the built-in camera experience, see Lens extensibility for Windows Phone 8.
Generally speaking, the lens capture experience should be consistent with the built-in camera user experience unless there is a specific need to do otherwise. Consider these points to give your lens experience the consistency it needs:
Gestures (specifically, Swipe left) and the experience should be created with respect to device orientation.
Your app should support a left-pointing arrow icon—the indicator that additional photos are available—with respect to device orientation.
Stock animation for Save and Capture should be consistent.
Your app should support tap-to-capture and a camera hardware button.
Support half-press to focus.
Flash iconography and states should be available where relevant.
Focus brackets should work like they do with the basic camera where relevant.
If a user can take a picture from within your lens app, the picture should immediately be saved in the user’s camera roll. If the app takes multiple pictures during a capture, additional pictures (backing data) should be saved in the app’s local folder, and a representation of these images should be saved in the camera roll.
Because lenses are applicable to a wide array of camera apps, it’s important to distinguish the different types of capture methods available and the unique design guidance that applies to each.
This type of lens app saves your photos directly to the camera roll and then immediately takes you back to the viewfinder.
A traditional capture app
Capture and confirm
This type of lens app requires the user to parse and accept captured images before saving them to the camera roll.
A capture and confirm app
Capture and confirm apps should use a consistent set of icons (Save and Delete) along with animation for confirming and cancelling the storage of the item. Cancel and Save both need to return the user to the viewfinder. These icons are included with the Windows Phone SDK.
Linking back from the viewfinder experience
Although many lens apps will simply store a photo in the user’s camera roll, Windows Phone lenses can capture content with far greater complexity than a traditional photo. Rich media lenses incorporate data from the local folder or from the web to provide a richer and deeper way for the user to engage with the images they have captured.
A rich media lens can store a photo that links back to their app. The photo stored in the camera roll can be shared or edited like any other photo in the camera roll. When viewing photos that represent rich media items in the built-in photo viewer, users can link back to the rich media experience associated with that item.
Rich media open link
The open link should launch an experience tailored to viewing or editing a selected item. It shouldn’t be seen as a generic app launch point. Be sure to enable Save copy only when the user has made a change to the image. For more info about integrating your rich media lens with the built-in photo viewer, see Rich media extensibility for Windows Phone 8.
With rich media apps, it shouldn’t be assumed that the stored image in the camera roll will be there. Users can delete items that are stored in the camera roll, so ensure that your rich media lens can recreate the experience without the representative image that was stored in the camera roll.
Users can share or edit items stored in the camera roll, so avoid using branding elements; let users share their images without dealing with unnecessary visual distractions.
Backing data associated with the captured photos can accumulate in the app’s local folder. A rich media app cannot remove images from the camera roll, but it can clear out data from its local folder. These apps should provide the ability to navigate to any photo captured by the app and give users the ability to delete the backing data associated with the photos. If your rich media lens is creating a new copy of an item from the app, the action should not be Save, but rather, Save copy.
Here are some tips for navigating within a rich media experience:
If you launch into a viewing or editing experience, Back should take you back to the camera roll.
When launching into an editing experience, Save copy should keep the user in the app to show the confirmed changes. Delete should remove the backing data associated with the image.
If your app doesn’t provide a rich media experience, don’t declare a rich media extension in the app’s WMAppManifest.xml file.
Apps that don’t store rich media items shouldn’t offer a Delete option. Instead, they should show items captured in the current session.
Although lenses are powerful apps, their functionality is limited. You can’t delete photos from the user’s camera roll, enumerate other lenses the user has installed, or launch built-in editing experiences in a lens app. These limitations are in place to protect the app user’s personal information and data. Lenses shouldn’t try to mimic every feature of the phone’s built-in photo viewer.
The lens picker requires icons that are a different resolution than the icon that represents the app itself. Your app must provide three icons in the Assets folder, one for each of the possible phone resolutions. The following table describes the names and resolutions for each of these icons.
To learn more about creating icons for each resolution, see Icon templates for Windows Phone 8.
Icon size (pixels)
173 x 173
259 x 259
277 x 277
For more info about phone resolutions, see Multi-resolution apps for Windows Phone 8.
All lenses jump into a viewfinder driven experience and save photos to the camera roll. The following points summarize additional points to keep in mind.
Lens splash screen displays in landscape orientation.
Lens icons support WVGA, HD720p, and WXGA resolutions.
Be consistent with the default camera user experience.
Gesture support: swipe left to preview.
Support portrait and landscape orientations.
Touch to capture (with focus).
Flash icons and states for On, Off, Auto, and Front Facing Camera where relevant.
One picture per capture saved to the camera roll.
If more than one JPG image is created through capture, the additional backing data should be saved in the app’s local folder.
Capture and confirm apps:
Use a consistent set of icons for Save, Save copy, and Delete.
Delete and Save must both return to the viewfinder.
Rich media lenses:
If your app stores additional data for editing or later viewing of a photo, you should consider implementing a rich media experience.
The open link directs users to an experience tailored to viewing or manipulating a selected item.
Check to see if an image exists in the camera roll before opening it (the user could have deleted the image), and gracefully handle the situation if it is missing.
Apps that provide a rich media experience should be able to handle the case when a user links from an item in the camera roll where the data has been deleted in the app.
Rich media lens apps should enumerate any content captured by the app based on backing data in their local folder, not the camera roll.
Rich media lens apps should give users the ability to delete backing data from the device.
If you launch into an editing experience, the save functionality should be called Save copy. Keep the user in the app to show the confirmed changes.
Navigation from the open link:
If you launch into a viewing or editing experience, pressing Back should bring you back to the camera roll.
If your app doesn’t provide a rich media experience:
Apps that don’t store rich media shouldn’t offer a Delete option. Instead, show items captured in that current session.
If your app doesn’t use rich media, don’t declare a rich media extension in the app’s WMAppManifest.xml file.