When creating an app for TV, it is a common misconception to assume that the same UX will work for both mobile platforms and Fire TV. The experience on Fire TV requires you to think about designing for the 10-foot experience as well as taking into account different control interfaces, like a remote and voice capabilities.
From a customer perspective, one of the most frustrating TV experiences is being forced to input text using a remote, like when entering a username or password.
Amazon provides features, like Login with Amazon, to improve the experience in a scenario like this, yet there are times when customers still need to input text.
In the example below, which replicates a common app login interface, the customer needs to go through two EditText controls and then click on the sign up button to complete the process.
Below is an example of the EditText to set up WiFi networks in the Fire TV settings. As you can see, above the text field is a label that reminds users what text they should enter.
As a developer, you can make this UX more pleasant for your customers by using some extra parameters to the EditText control, which come in handy on Fire TV devices.
Let’s explore the additional parameters in detail. In the picture below, the configurable elements have been highlighted.
The description labels (1) and (5) offer a way to describe the purpose or the context of the input. In the example of a username field, a label like “Enter your username” or “Username” would work well. For a login email, “Enter your login email” or “Email” would be better suited.
The placeholder label can also display a practical example to help customers understand what kind of information needs to be added, separate from the description label, and it would disappear as soon as the user starts typing. For an email field, it could be “firstname.lastname@example.org” or for a username field “john.doe.”
Label (2) is useful to indicate the current step in a process of entering multiple inputs, like email and password, for example. By indicating the current step and the total number of steps in the process, the customer gets a better idea of how long it will take to complete the whole process.
Finally, button labels (3) and (4) give the opportunity to customize the Back and Play/Pause button labels. Unless there are good reasons to do so, it is best to leave them with the default labels.
Setting these parameters is simple, as outlined in the code below:
EditText userNameEditText = findViewById(R.id.usernameEditText); // gets the view
Bundle extras = userNameEditText.getInputExtras(true); // set params through bundle
extras.putString("label", "This is a description label"); // 1 - top of the input dialog
extras.putString("description", "This is the main description"); // 5 - bottom of the input dialog
extras.putString("backLabel", "Example of Back Label"); // 3 - back button label
extras.putString("nextLabel", "Example of Next Label"); // 4 - next button label
extras.putInt("fieldNumber", 3); // 2 - current step
extras.putInt("fieldCount", 5); // 2 - total number of steps
Besides labeling the input fields, make sure the layout on which the EditText is displayed seamlessly transitions from one input field to the next using the Play/Pause and Back button. This makes the interface easy to navigate, improving the chances that the customer will go through all the input fields. In the example of the login interface, the EditText objects are children of a LinearLayout.
This implementation is straightforward and can act as a quick win for apps that require user inputs with a keyboard.