Try pressing some buttons and moving the analog sticks to see the values change. If you aren’t seeing any information, or the values aren’t changing, check out the compatibility information on GitHub.

Basic Framework

Let’s get organized and build just enough to test & tweak

Our prototype has been structured like an app, organized into several files that each have a specific purpose. We’ve avoided using major frameworks or sophisticated architectural patterns to make a prototype that’s lightweight, flexible, and accessible to a larger audience. If we keep it quick and scrappy, there’s a lot less pain in redesigning and rebuilding our ideas.

app.js

Most of the prototype’s logic is located in app.js. The most important part of this file is our main object, Example, which provides a context for all of the different functions and variables that we’ll need to build the interface. After we declare all of our key functions inside this object, we’ll call Example.load() to begin the execution of our code.

var Example = {
    data: prototypeCarousel,
    container: document.getElementById('prototype'),
    column: document.getElementById('prototype-column'),
    ...
}

Example.load();

data.js

It’s good practice to separate your data from your app’s logic. This makes it a lot easier to test, tweak, and calibrate your interface as you use it. We’ve stored the metadata for our design’s content, the carousel, in data.js:

var prototypeRow = {
  title: 'Row',
  content: [
    {
      eyebrow: '18PX eyebrow 1',
      title: 'Show Title 92px 1',
      summary: 'Lorem ipsum dolor sit'
    },
    {
      eyebrow: '...',
      title: '...',
      summary: '...'
    },
    {...} // etc.
  ]
}

Mapping Button Presses

Organizing all of our buttons and events in one place

The navigation handler is a function that we use to make a clear, organized list of what buttons we’d like to map on the game controller. The switch/case structure used here makes it easy to update and test different configurations on the fly.

navigationHandler: function(event) {
    var button = event.detail.button;

    switch(button) {
        case 'DPAD_RIGHT':
            Example.dpadHandler(button);
            break;
        ...
    }
}

Ultimately, the navigation handler is an organizational tool that will allow us to identify which button was pressed, call the desired function, and pass along the name of the button that was pressed.

One thing you can experiment with on your own is how to map the analog sticks. Unlike input from the direction pad, analog sticks have a wide range of motion, are pressure sensitive, and support a click event. This makes for lot of interesting possibilities for interaction design—after all, game controllers are made to enable diversity in game mechanics.

In this example, we’ve kept the analog sticks as simple as possible. A feature in Controller.js allows us to read analog stick events as if they were the same input from a direction pad. A threshold value can be set to control how far the user should push the analog stick before it fires a direction event.

Handling Direction Events

A simple example that handles interactions with the direction pad

All we’ve done so far in our prototype is map buttons to functions. What we really need to test our design is a function that moves our user’s cursor on the screen. Initially, this sounds pretty easy, but in reality, there are a lot of important details we want to build and test.

We’ll use the dpadHandler function to organize the overall series of events that should take place when the user presses the d-pad. First, it will be tracking the highlighted screen element with the use of the variable index. It has to support cases where our user’s cursor is on the first item in the grid, some arbitrary item in the middle, or at the end.

The if statements will handle the logic that enables the carousel, and the changeCursor function will visibly move our user’s cursor.

dpadHandler: function(button) {
    var index = Example.column.getAttribute('data-selection');
    var selection = document.getElementById('selected');

    if (button === 'DPAD_RIGHT') {
        if (index < Example.data.content.length - 1) {
            index++;
            Example.scroll('next');
            Example.changeCursor('next', index);
        } else {
            Example.scrollOverflow(Example.container, 'post');
        }
    } else { ... }
}

One of the big design details you can experiment with is the scroll function. If you have paid close attention to television apps, it can become frustrating to press a direction button each and every time you’d like to move the cursor from one element to the next.

The solution in many products is to enable a long press on the direction pad. Unlike mobile, the long press is a very natural and commonly used interaction for televisions. To build a long press event, we have to track the time a user first pressed a directional button and routinely check to see if the user has held the button long enough to pass a fixed threshold.

You can look at how we’ve implemented the long press in the scroll method. This function implements all of these design details and gives you a good starting place to experiment. To stop the cursor after a long press, we map the release event of the direction pad to dpadDirectionHold.

Strategies for Cursor Behavior

Building a logical system for the cursor to jump around

Television interfaces have a unique interaction model where selections are statically locked to visible elements on the screen. The user sees this as their cursor, which is generally an outline or highlight around their selected item. Building cursor functionality can become quite challenging. Here are a few approaches for different designs.

One Dimensional List

In our example, we have a 1-dimensional layout: the selection can only move horizontally. Because of this, list traversal was the easiest method. Every item has an index, and you simply keep track of the current index and increment or decrement the index when the user moves the cursor.

Two Dimensional Grid

If your interface is a static grid of uniformly sized items, you can use a method similar to list traversal, but modify it to store two indexes: one for the row and another for the column. Remember, keep it scrappy.

Advanced Layouts

Sophisticated interfaces won’t always come in the form of a list or grid. For example, designing a radial menu on televisions is a reasonable concept given that analog sticks naturally map to a radial layout. A good strategy for enabling this type of advanced cursor movement is to perform collision detection.

The idea behind collision detection is simple. If you have an interface with several interactive elements on the screen, you can take the desired direction of movement from the user’s controller and search in that direction for a selectable interface element. If you’ve ever played Asteroids, you’ve seen collision detection in action.

The most robust method for collision detection that we’ve used on projects is ray casting. With ray casting, you start with the current selection’s position and draw a line in the user’s desired direction of movement until the ray collides with an interface element. Then you move the cursor to that item. Check out this example from JSFiddle for more.

Other Considerations

It’s easy to get lost in the technical complexities of list traversal or ray casting, but keep in mind a few more cursor behaviors that users will still need the interface to account for:

• When and how will you move the cursor to scroll the screen? Do you keep the cursor in the center of the screen, or wait for it to leave the bounds of the interface before scrolling more content into view?
• What happens if there is nothing selectable in the direction the user presses? Does the selection wrap to the beginning, or the next row?
• Is there a need for advanced shortcuts to cut down on repetitive button mashing? For game controllers, will you use the triggers or bumpers?

Creating natural movement

Animating interaction on large format interfaces

With the logic of the cursor movement figured out, it’s time to add animation to create a natural and responsive interface. Like type and color, it’s essential to study and finesse animations on a TV. Fun, lively animations that look great on a phone or laptop can become overwhelming and distracting on a large display.

And while it’s often argued that motion adds personality and polish (see Apple TV’s satisfying parallax motion), it’s better to err on the side of “less is more.” Subtle, well-timed animations will make a more polished experience than fancy, unnecessary flourishes.

While our cursor could simply jump from one item to the next, animating the cursor in and out as we move between items creates a single, cohesive movement that aligns with the user’s single button press.

Maslow’s hierarchy of needs

As we started to figure out what the design principles should be, we needed a better way to visualize them. Back in June, I wrote a Lyft redesign article and talked about their design principles. They used a pyramid shape ( Maslow’s hierarchy of needs) define the importance of order. It inspired me and I decided to give that a try.

I printed out the design principles we created and cut them into pieces. I drew a giant pyramid on the white board and put a sample of Maslow’s hierarchy of needs next to it. Each of us got a set of principles and put them into the pyramid based on the way we wanted to rank them.

Oops, conflicts occur

We realized there were a few conflicts. We can’t decide which is more important, consistency or efficiency? We had a long discussion. At the end, we decided to group consistency and efficiency together. The reason is that it often differs depending on what project you work on and where you are during the process. For example, our engineers prefer consistency because they already built an style library. As designers, we have empathy for our users because of the extra number of clicks they have to go through. We want retention! We want to attract existing users of competitor’s product to our product! We know some legacy patterns are stopping us from accomplish it. Why not explore options that can actually help them run their business more efficiently? What if there is a need to prioritize efficiency over consistency for a specific case?

Here is something I learned from design events:
Don’t be afraid of creating new patterns if specific legacy patterns aren’t working well. Communicate with the engineers and product managers, help them understand the special needs. Hopefully, that way you can get your new design patterns into the next sprint.

Finalize Design Principles

We were so excited! Then, we paused. “Collaboration” exists in every step, we should take it from the pyramid. Beauty is an effective word, but why don’t we make it sound more artistic and fancier?

We had an idea to visualize the pyramid with pictures of examples next to it. I thought about how burgers are made, with bread, meat and sauce. I tried a few ideas and decided that meat is too specific. I replace “Meat” with “Ingredients”, as it’s more broad and presents psychological needs better.

Here is what we ended up with:

• Know your user = Bread (Basic needs)
• Clarity + Consistency & Efficiency= Ingredients (Psychological needs)
• Aesthetics = Sauce (Self-fulfillment needs)