A User Experience Designer's job can be summarized in five words: We design solutions to problems.

Be it a problem that is already known, or one that is yet to be discovered, we try to find optimal ways to solve issues. We talk to users, look for their needs, design ways to fill these needs, test our solution, and repeat. This cycle known as the User-Centred Design is the core of our discipline. Once we're done with this cycle (or until management says it's enough) we end up with a product that helps the user fix whatever problem they had, while having a good experience. We can categorize these products in three groups:

• Products that end up worsening the users' lives
• Products that bring their users to normality
• Products that improve their users' lives

I won't talk much about the first group, as they shouldn't make it out of the User-Centred Design cycle (except when seen as objects of art or study, like Jacques Carelman's Impossible Objects). However, I'd like to discuss more about the second and third groups.

Products that restore normality

Let's start by stating something that might be obvious, then go from there: We humans are social creatures. We tend to live by what we call Social Norms. We are influenced by what other people do, or by things we are expected to do. These norms affect the way we behave, dress, and live. And when we deviate from them, we may start looking for ways to restore normality. Products that fall into this category make us go from our non-standard, unnormalized way to one that falls into social norms.

An example of this is the Football tape: a plastic tape that can be made into a ball. While the product itself is not a bad idea, and it bring the users to normality (having a ball), it does not consider their context nor does it make this better than having a real ball.

Examples of these products can be seen throughout the evolution of the COVID pandemic during the last two years. From the start, we looked for ways to go back to normality:

• Online meetings that replaced in-person ones
• Virtual classrooms or conference rooms where attendants had to take their own virtual seats
• Corona online concerts

Even when trying to replace their physical counterparts, these products just wouldn't fill our needs. We were so used to an in-person context that we even brought its restrictions to the virtual world. Yes, these products kind of give us what we lost while not being inherently bad. They do help us solve a problem we have at hand. But, what if we could do more than this?

Products that improve their users' lives

You could discuss that products from the previous category also improve their users lives. While that might be true, and we don't want to leave any product behind, I want to focus more on the type of product that does more just restore normality. Not only do these bring their users to balance with social norms, but they also help us go well beyond them (Plus Ultra!). These are the products that become objects of study, and that give us a "Wow!" factor.

Going back to our pandemic examples, we can see a few cases where novel solutions were implemented, taking us to a better position than if we tried to restore normality:

• Game worlds where we could create new experiences with our loved ones (E.g. Nintendo's Animal Crossing)
• Flying around in a virtual world to attend a conference room, without seat restrictions
• Attending Ariana Grande's Fortnite concerts while dressed as your favourite character

These products don't try to imitate their real-world counterpart. They embrace the context they exist in, and create a solution based on the restrictions and flexibilities it has. This allows us to create new experiences that probably wouldn't have existed had we stayed in normality.

So where would that leave your product, if it stayed away from normality and embraced its context?

Why not use HTML + CSS + JS?

See, using these common web technologies is not as efficient as we might expect. In fact, using these technologies can result in our applications overloading CTV devices. A great way to avoid this is by using a tool that employs our devices to their full extent, such as WebGL. This tool helps us overcome performance-related difficulties. It also allows us to:

• Create easy-to-deploy applications because of its cross-platform nature.
• Do automatic memory management and hardware-accelerated 2d and 3d graphics.
• Avoid issues with vendor-specific technology implementation. Looking at you, Safari!

But, WebGL is not the easiest tool to use or understand. Luckily for us, some tools allow us to use most of WebGL's features while using only JavaScript.

Lightning is one of these tools. It's a highly optimized framework that utilizes both CPU and GPU to use all our CTV devices to their fullest. It uses a lot of Object-Oriented Programming concepts at its core. It also has a lot of out-of-the-box tools that help us solve compatibility issues with any CTV platform.

We now understand why we're interested in using Lightning. Let'start by installing everything we'll need to create our first app.

Installing Lightning CLI and creating our first project

The official Lightning docs are divided into roughly 4 different sections:

• Lightning CLI: a Command Line Interface tool used to create and run new Lightning apps.
• Lightning SDK: a set of tools and plugins we can use to develop Lightning apps
• Lightning UI: a set of components commonly found in TV apps.
• Lightning Core: API reference for all the features included in Lightning.

To create our new project, we'll need to install the CLI by using either npm or Yarn. We can do so using the following commands:

npm install -g @lightningjs/cli

# or using yarn
yarn global add @lightningjs/cli

We can then verify that it has been properly installed by using lng -version, which should display a message similar to this:

Lightning-CLI 2.5.1

Let's now create our first project. We can do so by using lng create. The CLI will then guide us through a series of questions about our new project. This was my configuration:

? What is the name of your Lightning App? My First App
? What is the App identifier? (reverse-DNS format) my.first.app
? In what (relative) folder do you want to create the new App? (leave empty to create in current working dir) myFirstLightningApp
? Do you want to enable ESlint? No
? Do you want to install the NPM dependencies now? Yes
? Do you want to initialize an empty GIT repository? No

This command will install all the dependencies our project needs, so it may take some time to finish.

Once this is finished we can open our directory by using cd myFirstLightningApp. Make sure to change myFirstLightningApp to whatever you called your folder. You can now run your app by using lng dev. If everything was done right, you should see the following message:

Starting up http-server, serving ./build
Available on:
  http://127.0.0.1:8080
  http://192.168.1.10:8080

Congratulations! You have now created your first Lightning app. Try opening a web browser and navigating to localhost:8080 to check it out. Your browser should display something like this:

And that's it! Our first Lightning app is ready to be tested using any web browser. Still, it's lacking some things. There are no interactions, no flashy effects, and not much is happening. To do that, we'll start by learning Lightning's most important concepts. We'll do this by configuring and developing more elements in our first app. See you in the next lesson!

• You can read JS / Object oriented languages (Python, C++, C#, Java, etc)
• You are familiar with writing functions (https://stackoverflow.com/a/4709224)

Introduction

A few weeks ago, I was working on an application where I had to control a button's visibility. From the moment I started, I knew the following things:

• My button could be either visible or invisible.
• If any key was pressed while my button was invisible, it would become visible.
• When my button became visible, a 3-second timer would start.
• If the timer expired, the button would then become invisible.
• if a key was pressed while my button was visible, the timer would restart.

We could explain this logic using the following diagram:

I decided it was good enough, so I started coding right away. My code looked something like this:

// Code simplified for explanation purposes
function onKeyPress() {
  if(button.visible) {
    restartTimer();
  } else {
    button.visible = true;
  }
}

function restartTimer() {
  if(timer.exists) {
    timer.delete();
  }

  timer = new Timer("3 seconds");
  if(timer.elapsed) {
      button.visible = false;
  }
}

I wasn't really feeling the result. My beautiful button was popping in and out of the screen without much of a transition or animation. I knew the designers in my team wouldn't be happy with my work, so I decided to add some fanciness to my work. I opted for a 1s opacity transition, then got back into coding. I ended with something like this:

// Code simplified for explanation purposes
function onKeyPress() {
  if(button.visible) {
    restartTimer();
  } else {
    // Wait for transition to complete.
    waitTransition("1 second", "opacity=1")
    button.visible = true;
  }
}

function restartTimer() {
  if(timer.exists) {
    timer.delete();
  }

  timer = new Timer("3 seconds");
  if(timer.elapsed) {
    waitTransition("1 second", "opacity=0")
      button.visible = false;
  }
}

Yet, this introduced a new bug to my code. Can you spot it? Try going back to the code and see if you can find it.

Did you spot it? Don't worry if not! It took me some time to find it. Here's a clue: What would happen if you pressed a key while a transition is happening? Since you pressed a key, the timer should restart and button's opacity should go back to 1.

Where should I add this? I decided to add a new isFadingOut property to my button, so my code now looked like this:

// Code simplified for explanation purposes
function onKeyPress() {
  if(button.isFadingOut) {
    waitTransition("1 second", "opacity=1");
    button.visible = true;
  }
  else if(button.visible) {
    restartTimer();
  } else {
    // Wait for transition to complete.
    waitTransition("1 second", "opacity=1")
    button.visible = true;
  }
}

function restartTimer() {
  if(timer.exists) {
    timer.delete();
  }

  timer = new Timer("3 seconds");
  if(timer.elapsed) {
    // Wait for transition to complete.
    button.isFadingOut = true;
    waitTransition("1 second", "opacity=0")
    button.isFadingOut = false;
      button.visible = false;
  }
}

This ended up creating a new list of bugs, most of them caused by a race condition. This was getting out of hand! Now I had to deal with several timers at the same time. What if I had to add a new fadingIn state? How much would that mess up my code? I decided it was time to change the way I approached the problem.

State Machines save the day.

You may have noticed that the opacity transition created a new element in our diagram:

This diagram represents a State Machine. It is one of the ways how one can be drawn. State machine are a great tool to visualize all the states and transitions in our application. Every circle represents a state, while every arrow is a transition between states. They also help us see all the different inputs needed for a transition between states to happen. All in all, they are a great way to untangle almost any sort of boolean mess

This is all great but, how do I use them?

One of the ways in which we can implement a State Machine is using enumerators. They don't exist in JavaScript natively, but we can simulate one using an object:

const buttonStates = {
  // You could also map these to a number instead of the same string,
  // but this is personal preference as it's easier to debug.
  fadingOut: "fadingOut",
  visible: "visible",
  invisible: "invisible"
};

We can then store the current state of our button in a property:

// start with a default state
button.state = buttonStates.visible;

We'll need to add a new function in charge of transitioning between states:

function changeState(newState) {
  button.state = newState;

  if(newState === buttonStates.visible) {
    clearTransitions();
    waitTransition("1 second", "alpha=1");
    restartTimer();
  }

  if(newState === buttonStates.fadingOut) {
    waitTransition("1 second", "alpha=0")
  }
}

Finally, we need to adapt both our previous functions to take our new state into account:

function onKeyPress(){
  if(button.state === buttonStates.visible) {
    restartTimer();
  }

  if(button.state === buttonStates.invisible) {
    changeState(buttonStates.visible) 
  }

  if(button.state === buttonStates.fadingOut) {
      changeState(buttonStates.visible)
  } 
}

function restartTimer() {
  if(timer.exists) {
    timer.delete();
  }

  timer = new Timer("3 seconds");
  if(timer.elapsed) {
    changeState(buttonStates.fadingOut)
  }
}

This is not only easier to debug, but it also makes it simpler to add new States to our button. As an example, you could add a new fadingIn state by:

1. Adding it to our enumerator
2. Adding a new if statement both in changeState and restartTimer.

Once this is done, you may notice this logic won't easily clash with what we previously did. Every state has a different behaviour that is split into its own block.

When do I use them?

As I mentioned, State machines are a great tool for several use cases. They are implemented in day-to-day tools and can be seen in modern libraries such as xstate. However, they shouldn't always be used. There are some cases where a State Machine may even make our logic more complicated. Here's a list of pros and cons I've found while working with them:

Pros:

• They make apps easier to debug, by separating each state into its own block
• It's easy to add new states into your application
• They make your code easier to read.

Cons:

• They have a learning curve, people who are not familiar with them may find them confusing.
• Not the best way to implement that on-off button you're working on.

Learn more about State Machines

Using enums and if/else statements is not the only way to create a state machine. This is only one of the approaches you can take to do it. Here's a list of places where you can learn more about them:

• Finite-state machines on Wikipedia
• XState's docs
• State machines in game development
• This great explanation I found on Stackoverflow while writing this article

Hey! Thank you for reading my article. If you learned something new or enjoyed my daily dev struggles, please follow me on Twitter: @robruizrdevs.

See you soon! :)