Fire represents a huge leap forward in mobile UX (user experience). As a developer, you’ll want to design the best customer experience possible for this new platform.  To help you achieve that, we’ve outlined the core design principles that will allow you to take advantage of Fire’s unique Dynamic Perspective features. The good news is that if you are an Android developer your app will work on Fire with little or no work, and as you will see, just a few modifications to your app’s UX will let it better take advantage of what the Fire SDK has to offer.

Design Principles

At the core of the Fire UX is the following principle: connect the real world to the digital world, with immersive experiences and rewarding moments. While it’s easy to dive into the deep end and use everything the Dynamic Perspective SDK and Firefly SDK have to offer, the real question you should be asking yourself is: “how will each Fire feature improve the user’s experience?” 

Here are three best practices for designing with the Dynamic Perspective SDK.

Supporting One-Handed Shortcuts with Dynamic Perspective

One way users will interact with the UI elements in Fire-optimized apps is through one-handed shortcuts. You are probably already familiar with incorporating gestures into your UX designs, but what makes Fire unique is the one-handed shortcuts that are driven by a user’s physical interaction with the device. The unique head tracking capability tracks the position of the user’s head relative to the device and when combined with other sensor inputs enables the entire UI to respond to how the device is held, moved and where the user looks.

To help illustrate this, let’s look at the orientation of the device itself.

Here you can see we have the three axes you’ve come to expect in 3D space: x, y and z. By moving the phone along a particular axis the user is able to trigger a gesture. There are three main gestures the user will come to rely on.

Peek

A Peek is triggered when the user subtly rotates the phone around the Y-axis. By slightly angling the device, the perspective of the Dynamic Perspective UI shifts to reveal contextual content.  

Here you can see on the home screen, the device is being held at the default orientation directly facing the user and the top status bar is hidden.

When the user angles the phone to the right, it enables the peek gesture, which will begin to display contextual information such as the top status.

It’s important to keep the following in mind when adding peek experiences to your own app:

• Show things that help the user in the moment. The best way to think of this is mouse-overs on desktop computers that reveal contextual tooltips.
• Reveal secondary information that the user may be looking for, but don’t ‘hide’ primary information on peek.
• Reward close inspection.
• Peek gestures work best in the primary panel.

Tilt

Rotating the phone around the Y-axis will trigger a Tilt. While Peek is a subtle movement, Tilt is at the far end of the movement’s spectrum. Tilt is designed to pull open the left and right panels.

Tilting the phone to the far right on the home screen you will pull up the Left panel. Left panels are typically used for menus and navigation, such as in the below example from the Fire home screen:

For many, this will represent a totally new way of interacting with a digital device and its intention is to invoke a sense of playfulness and delight for the user. In addition to the left panel, there is a right panel, which we’ll talk about more in the next section. You can use a tilt gesture in the opposite direction, moving the right side of the phone towards you, to pull up the right panel. These gestures become intuitive for users since they are facsimiles of how we would interact with physical objects in the real world.

While it’s important to be playful in your design, it’s critical that you don’t make the user work too hard to understand your app’s UX. The key goal is to make the primary UI clean and visually easy to scan by distilling it down to only the essential information.

Working with Fire’s Panels

Fire apps consist of three different panels that help tie the entire experience together for the user. These are the Left Panel, Primary Panel and Right Panel. Let’s take a look at each one and how they work.

Primary Panel

The primary panel is the main application space where most of the action takes place. Here you can see in the Maps app that we are presented with a standard Android View that displays the main UI of the App.

Left Panel

As we discussed in the previous section, the left panel contains quick navigation, refinement controls, sort controls, and other contextual controls. User actions on this panel change the view in the primary panel.

The left panel should contain your app’s actions that are not key to the primary interaction of the app. Core UX should always be contained within the primary panel.

Right Panel

The right panel helps users discover new things or perform essential tasks more quickly without leaving the current context.

The right panel is always contextual whereas the left panel is constant throughout the app. This means that the right panel can also be used for quick summaries, actions tied to what is being displayed on the primary view, or additional shortcut actions that wouldn’t make sense to be exposed in the left panel. The right panel is a good place to positively surprise the user with information that is delightful in the moment, but which they didn’t know to expect. For example, the Amazon MP3 app surfaces song lyrics in the right panel.

By taking advantage of these panels, you’ll also be integrated into the system-wide gesture events. A great place to start is by going through the phone’s default apps such as Email, Maps, Messaging and even the Silk Browser to see how they are setup.

Designing for the Home Carousel

The next important thing to also consider is how your app will look on the home screen carousel. Each app is represented in the carousel with two parts—an icon on top and a widget below the icon.

In the image above, the highlighted red area is your app icon and the area highlighted in green is the widget area.  The widget allows you to expose content without needing the user to launch the app. Text and images can be presented in a grid or list.

The widget communicates with your app using an intent. When the user taps an item in the grid or list, the intent you defined for the item is sent. If you do not provide a widget for your app, the system displays a default widget that shows “Customers Also Bought” content related to your app.

Be creative with this space and use it to drive user engagement.  You could use it to help users quickly launch your app.  Or, use the space to expose a summary of past activity the user may be searching for again.

Now Is the Time to Submit Your Apps for Fire

Create immersive apps that respond to the way a customer holds, views and moves the phone. We have updated Appstore Developer Select, Amazon Mobile Ads API, and Amazon Testing Services with more incentives:

• Amazon Developer Select: Optimize your apps for Fire phone and get enhanced merchandising and 500,000 Amazon Coins incentives for your customers. Get the details here.
• Amazon Mobile Ads API: Developers earn $6 for every thousand interstitial ads displayed across any supported device in August and September (up to one million impressions per app per month) when they distribute their apps on Fire phones and send the first ad request from a qualified app. Get the details here.
• Amazon App Testing Service: Most android apps just work on Amazon devices.  Test your app's compatibility in 90 seconds by dragging and dropping your Android APK into our testing tool. Sign up for a free developer account to test your app's look and feel on devices and get the results within 6 hours.  Test your app now.

Now is the time to submit your apps and games! Apps that are submitted by July 18 and approved will be in the Amazon Appstore when Fire ships on July 25.

Fire Developer Resources:

• Get a free Amazon Appstore developer account
• Fire Getting Started Guide
• SDK downloads
• Amazon Apps & Services Blog

Jesse Freeman (@jessefreeman)

Our guest blogger today is Jason Mark, co-founder of Gravity Switch, a Design and Usability firm that has worked on projects for Disney, The Guggenheim, Dartmouth and Yale. In this post, he demonstrates exactly how important good design and the right screenshots are to your app.

Below are 7 apps. Can you tell which is targeted to women only? For doctors only? The most popular? And can you figure out which was made by a $2B company and which is home grown?

Please spend no more than one minute looking at the screenshots below and see if you can identify where they came from. Try to be aware of WHY you think this way.

Which is:

• For women
• For doctors
• Most popular
• $2B company
• Home grown

How did you do?

Studies have shown that within seven seconds of meeting someone, you’ve made at least TWELVE judgment calls about them. You have formed an impression of how wealthy they are, how educated, how liberal or conservative, how intelligent, how much fun, and more.

All in just seven seconds.

The same thing happens when a prospective client first sees your app icon and your screenshots. When a reviewer posts a screenshot or someone sees your paid advertisement, prospective customers are forming a lasting impression about things you many never have realized or intended. How trustworthy are you? How capable are you? How expensive are you? Are you a good fit for them?

If you haven’t given thought to these things, you’re missing a critical opportunity. If you’re not clear about what story you’re telling, then your audience will make up their own story and it definitely won’t be the one you intend.

The truth is, I don’t know which of these is for women, or which is a $2B company, but when I show this test to people they always have an opinion. And you probably did too. You probably *thought* you knew the answer to at least one or two of those questions.

Which is really what brand is all about, remember: Your brand is not what you say it is. Your brand is what other people say it is.

The right way to approach brand

Asking if you should make your icon green or blue is like asking if you should use a list or an array. It's not a committee decision to be made by amateurs. It’s a decision that should be made by trained experts who understand negative space, typography and color theory. 

While code is about functionality, design is about intent. It’s about what we want people to feel, and what do we want them to do (see: http://www.webdesignerdepot.com/2013/05/design-emotions-usability/ ).

A great designer starts by understanding your intent.  What do you want people to know, feel and do?  Once those things are understood, the details around how you accomplish those goals via colors and fonts is much easier.  You’ve already established the criteria – your intent – so it’s easier to make decisions on the details.

A great designer understands how margins and colors can convey the correct messages. They listen and reflect back where you’re going visually. They won’t ask which concept you like best, they’ll remind you of your goals and ask you which one “works” best, or if you have a really great designer they’ll TELL you which one works best. If you’re “stuck in the how" maybe it’s time you took things up a couple of levels.

You can find Jason on the following sites.

http://GravitySwitch.com

http://JasonOnDesign.com

One Game, Everywhere

Gone are the days where you can make a game and publish it to a single platform and expect to be successful. Like any business that sells consumer products, you need to go where the people are. That means the games you make should run on a multitude of different platforms and accept any number of different input types. There’s also one more catch: your players expect to be able to share their game data across all of these different platforms, especially if they are paying for your game multiple times. With that in mind I have outlined what I call “responsive game design,” which is modeled loosely after some of the core concepts of responsive web design. It’s also a framework that will help you think about enabling your games to scale across multiple platforms.

Applying Responsive Design Concepts To Games

On the web, responsive design is a set of guidelines and best practices that help websites scale from desktop to mobile. Web developers discovered early on that it was too difficult to maintain separate designs for desktop and mobile so this solution allows a site to re-adjust to any resolution based on a set of ideal screen sizes. While responsive design on the web focused solely on adapting a site’s visual design based on common viewports, the notion of responsive game design builds on this concept to include other key aspects you need to consider when making multi-platform games.

Responsive game design can be summed up in the following key requirements:

1. Game graphics and UI support multiple resolutions
2. Game mechanics work across multiple types of input
3. Publish to multiple platforms with the same codebase
4. Saved data is synced across all platforms

While most of these are already best practice for games in general, the collection of them represent a guideline for game designers moving forward to help reach the broadest audience possible.

1. Scaling Game Visuals Across Different Resolutions

If you come from desktop game development this is not going to be a big shock to you since it’s common practice to support multiple-resolutions and varying computer performance. While mobile development is relatively new in this space, over the past few years, mobile device resolutions have tended to normalize around a few key aspect ratios (3:2, 4:3 & 16:9) allowing the same desktop game concepts to be applied:

• Build for aspect ratios not fixed resolutions
• Create simplified, dynamic UI that can adapt to different resolutions
• Have degradable graphics that can adapt to the power of the device

It’s also important to note that optimizing a game’s graphics goes well beyond just the resolution. Each system has different performance so being able to dynamically scale the game’s visual effects across these different platforms is critical as well. Especially when dealing with high pixel density displays, you could actually end up pushing incredibly high resolutions on devices that can’t fully support them. Also you may need to tone down specific special effects on mobile verses desktop or perform special optimizations when going to TV to account for slower display refresh rates. Make sure that you take into account these limitations and plan accordingly.

2. Supporting A Single Control System Across Different Input Types

A single game can support three types of input (mouse + keyboard, controller and touch) based on the device they are on. While thinking through each of these inputs, game designers should consider how their game will work going from desktop to tablet to phone and TV. Will the controls hold up on a system without physical buttons or should the gameplay be simplified a bit to account for the lowest common denominator?

It’s completely possible to have games work with a single input mechanic but a lot of planning and consideration must go into the overall design of the game. Most devices accept a game controller at this point so while not ideal, players can still plug one in if virtual controls are too frustrating. It’s especially important to take into account that not everyone who plays your games will have access to a controller. The Fire TV ships with a remote by default so if you want to capture the largest audience possible you’ll want to make sure you support the remote out of the box. You can still publish a controller only game but keep in mind that each input limitation you place on your game shrinks your potential audience accordingly.

3. Publishing a single game from the same codebase.

For years, developers had leaned on C++ as a cross platform solution to making games that work across multiple platforms. A successful port could be anything above 50% core reusability. I still know developers who build their own game engines that allow them to manually port from platform to platform but that process can be time consuming and if you are a small indie developer, the additional bug testing time may not possible to maintain across all the devices you want to support. That is why it is critical to find a cross publishing solution you feel comfortable with.

The most popular game engine today for indies is Unity 3D. From there other solutions, which grow in complexity, are Unreal Engine, CryEngine. There also some smaller more specialized game engines like GameMaker Studio. If pre-built game frameworks are not your thing, consider some cross compilers like HaXe, Monkey and CocoonJS. Either way there are many options and each will have some kind of impact on your end result or the platforms you can reach so do your research while designing your game.

4. Saving State Across Devices

What good is having a game that can be played on multiple platforms but the player needs to restart their progress every time? A key component to the responsive game design concept is allowing a single game session to extend across different devices allowing your player to start on one platform and continue on another. Imagine being able to play a Fire TV game at home then continuing your game on the go on any mobile device?

Steam was one of the first game publishing platforms to introduce cloud based game saving and since then more companies have offered similar solutions. The biggest issue is that these services are platform specific. For a developer to support different platforms, they would have to roll their own solution. However, built into our GameCircle API is WhisperSync, which can be used to not only have cross platform leaderboards but also sync game data across different mobile devices.

By adding GameCircle’s WhsperSync to your game, you can leverage this to let your players go from mobile (iOS, Android and FireOS) to the Fire TV for the full 10-foot experience then sync their game data back across all of these devices. While GameCircle doesn’t support PC syncing today, being able to have a consistent saved game mechanism for your mobile and Fire TV builds is a huge advantage for your players and a step in the right direction.

Where Do We Go From Here?

While this is just the foundation for a larger concept in game design, it’s up to you as the game designer to help define and shape the future of what gaming on multiple platforms means to the player. At Amazon we are incredibly focused on the customer and we build tools to help you as the developer serve them better. Over the next few years we will see more and more games that reach across platform walls to enable a gamer to pick the device and play style they want and with the correctly designed game, that player will have the same experience no matter where they choose to play your game.

Resources:

• GameCircle https://developer.amazon.com/public/apis/engage/gamecircle
• Amazon Fire TV https://developer.amazon.com/public/solutions/devices/fire-tv
• Publishing to Amazon Appstore https://developer.amazon.com/public/support/submitting-your-app

- Jesse Freeman (@jessefreeman)

If you have decided on publishing an interactive periodical title, congratulations! Having an interactive periodical means that users can scroll articles on a page, play a music sample, manipulate a map, or otherwise interact with your content in ways that are just not possible with static content. While interactive publications are more work than simply rendering a PDF replica of your print publication, they are often well worth the extra effort. Interaction can drive deeper engagement with the content, more time per page, better reader usage reporting and other advertiser-friendly benefits.

In this two-part series on Interactive Periodical Publishing on Kindle Fire I will discuss some of the technical considerations for those who will write their own periodical application or who will use a publication platform such as Woodwing or Adobe. The first part introduces thoughts on layouts, resolutions and interactions, and part two will cover how to submit your periodical app to the Amazon Appstore to minimize time investment on your end and optimize user experience.

A 10,000 Foot View of Layouts

If your content is text-centric, you can look into using a fluid layout (Liquid Layout) design. The Wall Street Journal app for Android and iOS uses a set of relative layout templates into which the daily text of the newspaper flows. Once your templates are set, you can simply stream content and the templates handle the layout.

WSJ can flow text into templates easily

If your periodical is image-heavy, or you wish to exercise more exacting creative control, you can probably constrain your digital layout work to two fixed aspect ratio layouts, one for the 4:3 aspect ratio iOS tablets, and another 16:9 layout for Android tablets. True, not all Android tablets are 16:10, but if you are comfortable with a small amount of letterboxing, non-standard devices can be accommodated. 

Table 1

WIRED Magazine has precise layout needs

Working with Resolutions

Publication platforms like those from Adobe can take a specific layout from InDesign and generate multiple renditions in which you can bundle images that are specific to the screen resolution of the target device. This can help reduce total package size and reduce asset scaling artifacts. Other platforms ask that you submit the largest assets you have, and will then scale down the assets to match the screen resolution of the target device. If you write your own app, you can make either choice, or even stream appropriate images to your app if your application returns the properties of the device on which is it running. If you do write your own app, please be aware that periodicals are often read in both landscape and portrait orientations. Your app should accommodate accordingly.

Building Interactions

If you are creating your own app, you can use just about anything you want to create interactions; Native code, Java, HTML, even HTML5. If you are using a platform like Adobe, you still have a fair amount of flexibility within the scope of the tools and webkit provided by the platform. In either case, be aware that the code you put onto any single page will use heap memory, and if you cache multiple heavy pages at the same time, you could find yourself running short on memory and fighting with the garbage collector should you ever hit onPause(). Avoiding this usually requires coordination between the content folks (who usually don’t think about heap size) and the IT group (who usually don’t think about editorial requirements). If you can flatten some of your non-interactive elements to PDF, you can save a good deal on file size and memory usage.

That covers (at a very high level) some of the important considerations to keep in mind when designing your periodical app. The next installment of this series will cover submitting your app to the Amazon Appstore, setting up In-App-Purchasing for subscriptions and individual issue sales and more.