The current explanation is based on the Design Propopal written by me for Building STEM DIVERSE TV of AnitaB .org

Refer to Github Repo Files to get Raw version of all the Design Templates used in this proposal

All MockUps are Designed using AdobeXD

TV celebrates content by making it front and center. Whether you’re looking for movies, games, or TV, it’s about finding and enjoying content with the least amount of friction.

We have an entire living room or other rooms dedicated and focused around the TV. TV is colorful, guided by ambient movement, with immediate access to content. These qualities define the experience of TV and form the foundation of Android TV’s design.

As a potential user of TV Apps myself, I prefer to have these following features which I think has already been satisfied based on the App Design explained above.

• People often use TV in a relaxed mindset. Casual consumption is the primary use case of Android TV.

• While searching for content, every part of the experience should be simple. New content should be easy to discover.

• The default action should be one click away.

• Minimize the number of navigation steps required to perform actions. Build apps with the fewest screens possible between app entry and content immersion.

• Avoid making users enter text whenever possible, and use voice interfaces when you require text input.

• Because anyone in a trusted household might have access to it, app content should be appropriate for mixed audiences.This makes a TV an inherently shared device.

• Place controls, like the search action, in locations that don’t overlap with other clickable elements.

• Categories can be traversed on the vertical axis, and items within each category can be browsed on the horizontal axis.

Every point of the above mentioned user stories are considered while building the APP UI and correspondingly REST API is designed. And I think you will witness them while going through the proposal.

Users come for content and stay for the app. Hence it really matters how user friendly and intuitive you build the app. According to me the main focus of building a TV app revolves around these three building blocks.

Now let’s dive into the technical discussions of the App design.

You can view all the Mockups mentioned below here at highest quality possible.

As TV is quite different from Mobile there are several design principles which are quite different and they must be considered while building the app for TV. For example we should make an app so that we can navigate the application only using ↑↓→← direction keys, instead of touchpad navigation. Because the user uses a remote controller, and cannot use the “touch screen” function with TV.

Navigation: TV should provide the shortest possible path to content. Place the fewest screens possible between the viewer and content. When screens are necessary, they are consistent and simple to operate with an input device.

Information density: Due to the viewing distance of the TV, users may not be able to process as much information on TV as they would on a computer or mobile device. Limit the amount of text and reading on TV screens.

Hence my App mockups follow all these principles in order to make UI as User Friendly as possible.

Colors on TV can look very different from colors on computer or mobile devices, and some color combinations may not work on both.

Using colors two to three levels darker than those used a mobile device is recommended. Alternatively, we can use colors from the 700-900 range of the material color palette.

I have opted to go with Darker UI as it will reduce the Eye Strain and Makes users stay for the content for a longer duration.

TV WHITE: Pure white (#FFFFFF) can be very harsh on a bright TV screen. Light gray (#EEEEEE) is recommended as the default text color on dark backgrounds.

And so does the remaining colors and each color has its own significance.

Here is the Colour Pallete I had used for the whole Design.

This explains how the user interacts with each of the UI elements and how they respond to each element.

The MVP will contain the following features explained below with mocks and backend.

Here is a basic overview of the flow of the app. Basically shows all the screens and interlinks between them in brief.

The Structure of the App is basically divided into three segments

1. BrowseView: where the user browses for the content.

2. InAppSearch: where users search for the content.

3. ConsumptionView (Player): where user watches(consumes) the content.

Go Here to view it at higher resolution.

*The mentioned figures are available below in the further discussion,(Use figure numbers)

Splash screen presented as soon as the app launches. It basically enables us to load the background content in the meantime. So that the user will be presented with the homepage with at least partially loaded content.

*The Logo used is provided by Anna and however it can be changed in future if necessary.

[Figure 1.0] SplashScreen

This is the place where users land up for the content.

HomePage can be structurally divided into three parts.

1. TitleRow: up top where Titles of the each page can be displayed in a row

2. BrowseRow: Browse Row organizes content into categories. These categories are displayed in the form of horizontal lists, which are stacked vertically on top of one another. By default, only one row scrolls horizontally at a time.

3. SideLane/BrowseLane: where major controls for Activity shifting lies.

[Figure 2.1] Home with TittleRow and BrowseRow

On hitting the left button the D-Pad user can navigate into the SideLane which looks like this.

[Figure 2.5] BrowseLane/SideLane

The BrowseRow will be containing only few number of videos of the content, so after reaching at the end of the each row there will be an option to SEE ALL from that content

[Figure 2.3] SEE ALL

Later on clicking on SEE ALL , a new page opens displaying all the content related to the corresponding topic/category. I like to call it GridView.

[Figure 2.4] GridView

In-app search provides a consistent search experience for all participating Android TV apps. Users may quickly search across apps that contain large amounts of information.

Invoking in-app search is simple. Press the microphone button on your controller or select the on-screen search button from the SideLane.

[Figure 3.1] Search

On making a Search, the search results will be stacked as a row in the bottom, so that users quickly select one to watch. Also, enabling auto search will help to uplift the user experience.

[Figure 3.2] Search Results

There is also a provision to integrate Google Assistant with the search which makes it more user intuitive. However it might not be possible for the version1 of MVP.

Because there are many reasons users pause content, provide multiple avenues for users to quickly pick up from where they left off. Continue watching Row will help us to achieve this.

[Figure 2.2] Continue Watching

The Consumption View is where the user will engage with or watch content. Users will spend most of their time in this immersive experience.

Transport Controls give users control of the content currently playing.

1. The controls are displayed by pressing any navigational button on an Android TV controller.

2. The center action is focused by default, so it should be the most commonly used action. In most cases, this action is Play/Pause.

3. To Keep the number of available actions to a minimum, I have added quick shortcuts to go to next and previous content.

[Figure 4.0] ConsumptionView (Player)

Here is a list of libraries and programming practices that I would like to propose and would follow while building the Android App.

The leanback library provides a templated UI so developers can focus on the important parts of their app.

When using leanback, content is shown in rows. Leanback supplies a rectangular card view, ImageCardView, to easily display content. The card size scales when selected and has shadows to accent the content. This is great for content such as movie posters and album art.

API Reference:

androidx.leanback.app

androidx.leanback.database

androidx.leanback.graphics

androidx.leanback.media

androidx.leanback.preference

androidx.leanback.system

androidx.leanback.widget

androidx.leanback.widget.picker

Refer Leanback, for a complete description about the library.

Player Constitutes the major section of the app. Because, it is where the user will engage with or watch content. Users will spend most of their time in this immersive experience. It's better to have an inbuilt player instead of opening another app to play videos.

ExoPlayer is an open source project that is not part of the Android framework and is distributed separately from the Android SDK. ExoPlayer’s standard audio and video components are built on Android’s MediaCodec API, which was released in Android 4.1 (API level 16). Because ExoPlayer is a library, you can easily take advantage of new features as they become available by updating your app.

ExoPlayer supports features like Dynamic adaptive streaming over HTTP (DASH), SmoothStreaming and Common Encryption, which are not supported by MediaPlayer. It's designed to be easy to customize and extend.

Here is small snippet which explains the initialisation procedure for Exoplayer

In version 1 of the MVP, mostly we might be added content from the youtube directly. Basically embedding sources from youtube into the Exoplayer.

Here is how we can extract the source link from youtube and play them in exoplayer.

However, in ExoPlayer every piece of media is represented by MediaSource. The ExoPlayer library provides MediaSource implementations for several stream types:

• DashMediaSource for DASH.

• SsMediaSource for SmoothStreaming.

• HlsMediaSource for HLS.

• ProgressiveMediaSource for regular media files.

Images form the major part of the App and hence we need to make sure loading images into Imageviews goes frictionless.

Glide is a fast and efficient open source media management and image loading framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface.

Retrofit is a REST Client library (Helper Library) used in Android and Java to create an HTTP request and also to process the HTTP response from a REST API.

REST Client in our case is the Retrofit library that is used on the client side (Android) to make HTTP requests to the REST API.

Here is small snippet as proposed in the Retrofit documentation

RxJava provides an opportunity for making parallel network calls efficiently and easily.

RxJava is a Java VM implementation of Reactive Extensions: a library for composing asynchronous and event-based programs by using observable sequences.

Of course, Kotlin being the android-first language it's obvious that it will be beneficial for future sustainment of the project. Basically, less code, more robustness, better safety, and a strong community.

As everyone knows about the perks of shifting towards Kotlin, I would like to stop the Kotlin discussion here and move towards dependency injection.

Coming to MVVM, MVVM combines the advantages of separation of concerns provided by MVP, while leveraging the advantages of data bindings. The result is a pattern where the model drives as many of the operations as possible, minimizing the logic in the view. MVVM being itself a suggested architecture by Google Developers, it's quite obvious to have such advantages

Usage of dependency injection frameworks gives you various benefits that improve the app performance and allowing the app features to stay decoupled, helps us in testing components individually. And there are several more advantages that make up my whole proposal if I continued explaining… Hence, Keeping the advantages aside let me explain which framework I am going to opt for.

There are two major types of Dependency Injection frameworks available right now.

1. Dagger2

2. Koin

Out of Dagger and Koin, would prefer to go with Koin, and Koin has its own reasons and perks for opting it over Dagger. I will list them briefly below.

**However, I am quite experienced in working with Dagger2 also. Hence it's ok for me to work on any of them. So we can discuss this further in the community bonding period and proceed further based on discussions.

Since Koin isn't a dependency injector but a service locator with a clever reified trick that you can use to manually perform dependency injection, the boilerplate will scale disproportionally.

This below stats might give a small idea.

To make the situation clearer, let me give more details on the Koin framework.

• Koin DSL allows you to declare your components graph, through functions and constructor dependency injection.

• Koin is a real DI container which manages all components instances and definitions. We don't use any introspection or proxy mechanism. It's all about pure function resolution.

• Service Locator is only needed in Activity/Fragment classes, to inject your components (lazily or not) due to the fact we can’t inject them by a constructor.

The thing is that frameworks like Koin reduce the 90% boilerplate thanks to the reified trick, making it very interesting.

That summed with the problems that annotation processing brings, increasing compile times and making it harder to do an incremental compilation in modules makes me want to re-evaluate if Dagger is worth it.

I mean having to add one line per each class that I want to add to the service locator is way better than having to re-compile all the graphs every time I do a clean build…

Testing is the most important step of the development life cycle as it will help us to verify the functionality of all the features of the app. Here is a list of libraries which I will be using for testing.

• Functional tests with Espresso

• Unit tests with Mockito

• Checkstyle, FindBugs and PMD

In order to make it dev-ops friendly firstly I would like to use a Trunk based approach during the development of the app.

Here, We only have one main branch. Then, we would branch off master when doing any features and anything that gets merged into master should be ready to ship to users. The image given can explain it in a better way.

I made this optional, as it might not be possible to implement it for the first version of MVP.

Fastlane is a great tool that developers can use to automate their release process & significantly reduce their release cycle times. The 4 major features offered by Fastlane are:

• AUTOMATE SCREENSHOTS: Automatically generate localized screenshots for the app store.

• BETA DEPLOYMENT: Easily distribute beta builds to testers.

• APP STORE DEPLOYMENT: Publish a new release to the app store in seconds.

• CODE SIGNING: Reliably and consistently code sign your app–no more headaches.

Since Fastlane allows plugins, there is no restriction on the capabilities.

Most apps that work on Android will also work on Fire TV because Fire TV is built on Android. The only difference is with services — for Fire TV, you'll want to use Amazon services instead of Google services (see How Fire TV Development Differs from Android TV Development). Hence building an Android App based on Android 5.1 / Android 7.1 will work on FireOs5 / FireOs6 seamlessly.

Ultimately this is the basic approach and you must relate it to your requirements.

I hope my explanation gives you a basic idea upon the various design guidelines that one must follow while building for TV.

Thats the End for now.

I will try to add more about the Backend in the upcomming days. Untill then Keep Exploring.

Designed with ❤ by Nitish Gadangi