Framer – Medium | Emil Widlund

How our team at EA uses Framer to prototype the Battlefield game franchise.

Prototyping User Interfaces is starting to get easier than ever. Triple-A games usually have a lot of progression and persistence layers built into them, which requires quite a lot of screens. In order to build solid menu flows, that people really understand, there has to be a way of testing them early.

So, how can design teams that are responsible for a game UI, incorporate prototypes into their workflows? Well, there are a few great prototyping tools out there like Origami & Framer, that have great support for phones and such. Some of them also have good compatibility for desktop prototyping, but almost none of them are compatible with prototyping a gamepad/TV environment.

The design team I belong to at Uprise (an EA-studio with focus on User Interfaces) faced this problem recently, as we were working on the Battlefield Franchise UI. We have our platform running on Xbox One, Playstation 4 and PC, so we had to come up with a solution for prototyping our designs in a gamepad/TV environment. Our solution: Framer Library.

Framer Library is an open source JavaScript framework for high fidelity prototyping. We use it with a custom module that enables gamepad-support and a whole lot of other handy features.

We are using Framer in combination with the excellent State Management library MobX. With these two libraries, we can build solid, customized prototypes. Any crazy idea we might have is now limited by JavaScript, not by an application, which often is the case. If it’s doable with JavaScript, we can build a high-performant prototype of it with the use of Framer’s wonderful APIs. On top of that, Framer has amazing documentation over at http://ift.tt/2qg8eJz. As you might see, Framer is written in CoffeeScript, but we are using JavaScript & ES6 to gain flexibility.

In order to create a gamepad-compatible prototype, there were a few fundamental components that we had to build on our own.

Gamepad API

The Gamepad API is responsible for capturing input from a connected gamepad, and turn them into events. We can then fire certain functions when buttons are being pressed. An example of a library we can use for this would be Gamepad.

Focusable Elements

In order to “focus” elements on the screen (since we don’t have a cursor or touch input to rely on), we need elements on the screen which can be focused. A “focusable” always have a clear, pre-defined state which the user clearly can see as selected. A focusable box for instance could be black as default, but as soon as it is selected, we switch the box’ state to “focused” which perhaps is white. This is how we declare a focusable:

• animationOptions
  Defines the animation when going from the focused state back to the default state.
• focusProperties
  Essentially the equivalent of a Framer state. Properties defined in this object are properties which will be applied when focusing the layer.
• actions
  This array contains actions that will be fired when the keyCode specified is pressed on the gamepad. The label is used in the prototype footer where contextual labels & button icons usually goes. That’s the area where the user can see which buttons to press to perform actions like “Back”, “Apply Filter”, “Read More”.

Focus System

The Focus System keeps track of all focusable elements within the current view. It also receive navigation-events from the Gamepad API, and figures out which focusable should be selected. We’re capturing all focusables’ X & Y positions relative to the viewport and by using Pythagoras Theorem we can calculate which the closest is.

Action Handler

When we have a focusable selected and press “A” on the Xbox Controller, we might want to trigger a certain function. It’s up to the Action Handler to keep track of all actions that are bound to the selected focusable. It also handles actions that are bound to a view (like “Back” which would transition back to the previous view).

App Wrapper

This is the heart of the prototype. It handles all transition logic, initializes FocusSystems & renders an appropriate canvas to show your prototype on. It’s built as an extension of Framer’s FlowComponent, which makes it incredibly easy to transition between screens. We can also define our own transitions!

Grid

We have a grid which we use to define sizes, margins, paddings, etc for components. 24 columns within the safezone. The safezone is 90% of the viewport. This is to ensure that the content rendered won’t be clipped due to different TV-manufacturing standards. So, on all views we have, we always import a safezone and mount our layers & components onto it, and then we define sizes and margins with the grid. Here’s an example of the grid class:

We use the getWidth & getHeight methods to define sizes and margins for our components. Who doesn’t love perfectly aligned UI elements?

Components

Of course, we need components that are built to be used in a TV Prototype. So yeah, we pretty much just extend the components offered by Framer, to build our own cards, buttons, lists, popups, etc. Most of these components are extensions of the Focusable class, as you would want to be able to focus them.

These are the primary building blocks we built to support our needs. We also built a small server that serves mocked data to be used in any of our prototypes; like game assets, profile information, recommendations, etc.

We might publish our core modules that we built for this purpose, so you can get a better insight of how we approached this. I hope that you found this article somewhat interesting, and inspired you to take gamepad/TV prototyping to the next level. Let me know down in the comments if you have any questions or similar.

Next time I’d love to do more of a practical tutorial with a lot more code examples. See you by then! Cheers.

I’m on Twitter.

Designing & building UI-prototypes tailored for gamepad environments was originally published in Framer on Medium, where people are continuing the conversation by highlighting and responding to this story.