The Score Bug: A Case Study on Creating Digital On-Screen Interfaces.
There’s no doubt that we are witnessing the change of television as we know it. Nowadays most TVs ship with some kind of integrated Smart-TV system. Apple, Amazon, Google and a lot of other specialized companies like Roku are competing for a share of the “Internet TV Box” market. Netflix is now an essential service and many people pay for it with the same stringency as any other basic bill like electric, internet or water. We are also witnessing the migration of live TV to the internet with services like PlayStation Vue and SlingTV.
What is interesting about all those changes is that the content is not evolving at the same pace as the technology that powers the consumption of the content. This is particularly true for two things:
- Reactive Content: Video content is still very static and usually it doesn’t react to the user input.
- Content Layering: A video can be layered with data about the show or event, but yet no one seems to be doing this.
The TV of the future would be both reactive and full of data. It’s hard to imagine a scenario in which this is not true. However, for this to become a reality is necessary to design new interfaces and interactions that can enable those features.
A particular case I always wanted to explore is the “score bug” in sports broadcasts. If you’re not familiar with this TV interface element, is the little score bar that shows the elapsed time and score of some sports events. You can usually find it in one of the corners of the screen.
The score bug is one of those things that are useful, but it doesn’t seem to have evolved since it was created. To be fair, this element works so well that there wasn’t a real incentive to redesign it. However, as explained at the beginning of this case study, TV keeps evolving and we need to create new TV interfaces that are more interactive and insightful.
The Football (Soccer) Score Bug
As you may already know all sports have different types of score bugs. I believe the football score bug makes a good case for several reasons:
- Football is the most watched and followed sport in the world.
- Football is likely the most pirated sport in the world, which clearly pictures the demand of football games through internet.
- Football has a particular context and set of rules that creates some very interesting design constraints.
There are several examples of score bugs that are currently used on football matches broadcasts:
Current score bugs usually have different looks, but they usually show the same information to the viewers: elapsed time, score, team initials or acronym, and jersey color. In some rare cases, score bugs can show tournament specific information like in the first example.
Sometimes football score bugs are also supplemented with additional graphical elements that temporarily show additional information like possession, bookings or corners:
The Case Study
I always wondered why this little element hasn’t evolved through the years. Nowadays the flow of data that can be captured in real-time is so comprehensive that it makes a lot of sense to show it to the viewers. In fact, sports broadcasters already show some of this data as you can see in the Example 3, but they fail to provide this data in a persistent interface.
As a regular football games consumer, I believe the score bug does a great job to inform the viewer about the current status of the match, but what about the whole context of the match? How can the viewers know what team is dominating the match if they join the transmission after the match starts? What if the viewers want to replay a previous goal?
The goal (no pun intended) of this case study is to design a relevant score bug and supplementary interfaces that would: 1) Provide a constant and a persistent flow of data to the user 2) Enable reactive interactions like replaying goals, bookings or near misses.
The Basic Design
As I already mentioned a couple of times, the score bug works pretty well. This means that we don’t need to re-imagine the functionality of the score bug. We just need to improve it and make it more accurate, modular and functional.
My first exploration was creating a classic score bug with the most common functionalities. For this exploration, I started creating a color code system that I could use later for creating additional elements or modifications.
For the color code, I picked two different tones of blue. Blue is a friendly color with the eyes, plays well with the backgrounds of football transmissions and has been widely used in other score bugs.
Nevertheless, color is a challenging aspect of any design, especially with interfaces intended for sports. The fact that almost all competitive sports use color as a way to differentiate teams on the field, creates some constraints on how we can use color to show sports related information. From a design point of view is always important to think about color. Color can help us to convey information more clearly but also can produce confusion and negative feelings. I will give an example of this later.
Now that I had a color scheme that seems to work well, I proceeded to create a basic score bug:
After creating the basic score bug, I started experimenting with additional persistent information that could be contained inside the score bug.
In football, there are different kind of events which modify the dynamics of the game and/or can create special occasions for scoring goals. Those events are:
- Goals: The most important event of a match. Goals determine who wins a game.
- Bookings: There are two types of bookings. Yellow and red cards. They warn about the behavior of the players and condition the continuity of the player on the pitch. Two yellow cards or one red card equals an expulsion which creates a disadvantage for one of the teams.
- Corners Kicks: The corner kicks are set pieces played from the corner of the pitch and that originate when a player of the defending team throws the ball beyond the ending line.
- Free Kicks: The free kicks are set pieces played from any spot in the pitch. They usually originate from fouls against the attacking team.
- Off-Sides: Off-sides are situations in which a player of the attacking team is beyond the line of the last player of the defending team. When a player is caught in off-side the attacking action is interrupted.
There are other events on a football match, but these five are by far the most important.
From the five main events that can happen in a football match, the only two that have prospective effects on the game are goals for obvious reasons, and bookings because they can lead into expulsions.
Based on this I created a first iteration of the score bug that shows the bookings of each team. From a design perspective, our user (the viewer) should always be able to see the information about the events that have prospective effects on the game. This helps the viewers that join a transmission after it starts, and the viewers that need to make a brief interruption and potentially miss a portion of the game.
The 90' Timeline
Having a score bug that persistently shows the most important information of the match, including the bookings, certainly improves the experience of the viewers. This is a simple and very functional design, but football is a sport in which time matters a lot.
In football games every phase of the match changes depending on who is leading and who is losing. For example, if a big team of a major league like La Liga is losing by one goal or is tying, you will very likely see the big team attacking desperately in the last 15 min.
These dynamics are important for the viewers since they change the way the viewers consume the content. Showing some events and data in the context of a timeline can enhance this experience.
In order to provide this information I came up with a persistent timeline design that works as an extension of the current score bug design. This timeline provides contextualized information that is very useful to understand the game.
As you can see in the mockup, the idea of the timeline is to show all events in the context of a 90 minutes match. In this example we can see that the two actions in which Real Madrid scored goals, happened in the first half-time. We also can see that there’s a red card in the second half.
As you already may have noticed, in this timeline it’s impossible to tell which team got the bookings. This is mainly because we can’t color code something that already has an internal color system (yellow and red to indicate the severity of the booking). Of course this is not a problem with the goals, since we can match the color of the ball icon to the color of the jersey.
This is a complex challenge when designing an interface that provides information. You have to show certain data but you have to keep the interface clear, understandable and functional.
Underutilized Screen Space
In order to fix this problem I explored other approaches to show the timeline and expand the information it shows in a way that we can avoid information black-holes like not knowing which team got the bookings.
One important pattern I find out is that the use of screen space can be hugely optimized to include more information. In football games transmissions, usually the top 15% of the screen is always overlaying the fans tribune, but the only graphics that are positioned in that space are the broadcaster logo and the score bug. Here are some examples of that pattern:
As you can see there’s a lot of underutilized space in the top of the screen. We can have additional graphical elements on this space without interfering with the game image.
Based on this pattern I decided to create a more insightful version of the timeline that takes advantage of this space.
The Full Width Timeline
In order to create a dynamic timeline that takes advantage of the top screen space, I decided to use the same concept of the score bug timeline but improve it by making it bigger and by providing an additional layer that expands on the information that is being showed on the timeline.
As you can see, this new timeline respects the color conventions we created at the beginning of the design exercise.
The new parallel light-blue (player or team data) timeline is showing us which team and/or player is the “owner” of any action in the general event timeline. We also kept the consistency of the information by referencing that information with the same acronyms we are using in the score bug (RMA / BAR).
Finally, this is how the full width timeline looks over a transmission image:
Creating Reactive Interfaces
Until this point we have only explored one of the concepts (Content Layering) that I introduced at the beginning. But what about the concept of “Reactive Content”? How can we build a reactive interface on top of this kind of information?
For this particular case there are multiple ways to make the content more interactive and reactive. This interface gives us the ability to feature replays, expand information and even show social feeds about the game.
I want to show an example on how this interface enable the creation of reactive content through an interactive interface. The example I wanted to create was the case in which the viewer wants to replay a previous event of the match, like a booking or a goal. In this case, the timeline is not only providing additional information but also works as a menu to navigate and replay those events. The power of this kind of interface is that unlike the usual menu that is only providing an index of the content, this timeline is giving a situational context. This means that the user can very easily understand the overall state of the game, but also explore further the circumstances of that state.
This is how a navigable timeline looks like:
In this example we are selecting the first event of the timeline which is a yellow card. The selection layer is a white rectangle with some transparency. In my experience, this pattern works better that other alternatives like changing the border color or changing the size of the selected element.
In this particular case, the transparent rectangle works better because we don’t have grids, borderlines or any type of container that can serve to the purpose of showing a selection.
After the viewer selects one of the items in the timeline and click/tap/enter it, a replay box appears on top of the image:
As you can see in this animated prototype, the users can move through the different events of the timeline. When they click/tap/enter an element, the transparent layer takes over the whole screen. This interaction has two main functionalities: 1) Give feedback to the user about their action. 2) Obfuscate the screen as a way to change the attention from the main transmission to the replay box.
In a real life system, the idea of this interaction is to obfuscate the screen, while keeping the main transmission playing in the background.
This is only one example on how the new timeline interface provides a way to interact and react to the content. A more developed system would certainly have other interaction mechanics, but this one is a good validation on how some of this elements can enhance the interactivity.
Design Lessons
After doing these explorations I realize that there are some challenges and interesting points when designing on-screen digital interfaces. Some of those things can be summarized in the following lessons:
- Always take into account the importance of the content logic. The score bug and timeline I designed for this case are specific to football. They certainly don’t fit other sports, which brings an interesting question. How do we create general on-screen interfaces that can provide data and interactive mechanics to any kind of content?
- Designing an interface for a “TV screen” is not the same as designing an interface for an app. This sound obvious but a “TV screen” is nowadays any screen, from a mobile device to a laptop. Is easy to fall in the assumption that an “app to watch TV” shares patterns with other common apps we use in a daily basis.
- You can always use tricks to make your design more clear and functional, but never forget that usually every design decision has long tail effects. Try to evaluate those effects and create measures to mitigate negative effects. For instance, using color code is a smart design decision but once you start to create color relations in your design it’s very hard to go back. Try to understand how this decisions affect the workflow and the extensibility of your design.
Final Comments
As stated in the beginning of the case study, the idea of this design exercise was to explore on-screen interfaces that supplement video content and how this interfaces enable the possibility to interact with the content.
The score bug is by far one of the simplest examples to showcase how added data and reactive content could work with internet TV services like Dish’s SlingTV.
However, if we take the time to explore other examples and other type of content we will find how complex is the process of designing and creating on-screen interfaces that are useful, innovative and easy to understand.
If you read this case study and are interested in exploring this topic further, please feel free to reach me and use any of the ideas proposed here (if you find them useful). I would be happy to provide insights and comments.
