Cable Application User Experience Guide
5.2010 v2CableLabs® 3
Contents
1 Intro ... 51.1 Introduction and Overview ... 6
1.2 Goals ... 8 1.3 Audience ... 8 1.4 Background ... 8 2 UE Design Basics ... 11 2.1 Visuals ... 12 2.2 Consistency ... 12 2.3 Voice ... 13 2.4 Application Model ... 13 2.4.1 Bound Applications ... 13 2.4.2 Unbound Applications ... 14
2.4.3 Application Life Cycle ... 15
2.4.4 Bound Application Prompts ... 16
3 Interactive Design ... 17 3.1 Interactions ... 18 3.2 Navigation Paradigms ... 18 3.3 Input Devices ... 18 3.3.1 Focus Keys ... 19 3.3.2 Reserved Keys ... 19 3.3.3 UDLR ... 19 3.3.3 Select Key ... 21 3.3.5 Exit Key ... 21 3.3.6 Color Keys ... 22 3.3.7 Number Keys ... 22 3.4 Behavioral Model ... 22
3.5 Designing With a Sense of Safety ... 23
3.6 Error Trapping ... 23 4 Visual Design... 25 4.1 Visual Model ... 26 4.2 Visual Hierarchy ... 16 4.3 Window Stack ... 29 4.4 Focus ... 30 4.5 TV Safe Colors ... 31
4.6 Fonts and Font Sizes ... 32
4.7 Drawing Considerations ... 32
4.8 Graphics Containers ... 33
4.9 Graphics Over Video ... 33
4.10 Scaled Video ... 33
4.11 Translucency ... 34
5 Application Development ... 35
5.1 Load Times ... 36
5.2 User Interaction Timing ... 36
5.3 Focus Management ... 36
5.3.1 Requesting and Yielding Focus ... 37
5.3.2 Highlights ... 37
5.4 Preventing Image Burn-in ... 37
5.5 Title Safe Area ... 38
6 Typical Use Cases ... 39
6.1 Case 1: Bound Application Presentation ... 40
6.2 Case 2: Application Window Priorities ... 42
6.3 Case 3: Bound Application Prompt Time-out ... 43
6.4 Case 4: Bound Application Obscured by Unbound Application ... 44
7 Examples ... 45
8 References ... 46
9 Terms and Definitions ... 47
10 Abbreviations and acronyms ... 48
This user guide is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. This document may contain references to other documents not owned or controlled by CableLabs. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document. Neither CableLabs nor any member company is responsible to any party for any liability of any nature whatsoever resulting from or arising out of use or reliance upon this document, or any document referenced herein. This document is furnished on an “AS IS” basis and neither CableLabs nor its members provides any representation or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular purpose of this document, or any document
referenced herein.
© Copyright 2010 Cable Television Laboratories, Inc. All rights reserved.
CableLabs® 5
Intro
Introduction and Overview
Goals
Audience
Background
1.1 Introduction and Overview
The cable industry has worked collaboratively through CableLabs to identify common interaction patterns, and visual patterns, found in their navigation systems. Since each cable MSO uses a slightly different on-screen navigator, this effort was critically important to pave the way for a healthy ecosystem of applications developers for cable applications.
Following the norms established in this guide document will benefit your application and leverage the existing behaviors that consumers have established through the use of their on-screen program navigators. Consistent behavior for the interactive cable TV experience is critically important to the overall success of the ecosystem. Creating an open environment for application developers to apply their creativity starts with a solid platform. The Cable Applications User Experience Guide document is the design platform.
This document describes a set of guidelines and conventions for the development and deployment of well-behaved cable applications. Well-behaved applications, by adhering to these guidelines, will create a consistent and recognizable user
experience (UE) for interactive television viewers. While these guidelines are voluntary, all application developers are strongly encouraged to embrace them in order to provide all viewers with a familiar and intuitive user experience, regardless of the specific service they are using.
This effort originated from the desire to define a cable industry convention to announce and launch television
enhancements. It quickly became clear that program enhancements were only a part of the picture, and that a more complete set of UE guidelines would be required, addressing all types of applications, both program-related and non-program program-related. In this document, we use the term “cable application” to mean all interactive applications that are deployed on a cable television system. This includes software developed according to the OCAP
specification [OCAP] (branded for the viewer as “<tru2way>” applications). It also includes applications developed according to the ETV-BIF specification [ETV-BIF] and any other language specifications that are generally supported by cable platforms in the future.
Intro
CableLabs® 7
The term “cable platform,” as used in this document, refers to the viewer’s system on which these applications execute. This platform is nominally a set-top box connected to a television, but other cable platforms may include a digital TV, a game console, or home computer, connected to the cable network.
This document is intended to provide common terminology and guidelines for all interactive cable applications, regardless of implementation details. When appropriate or necessary, we will refer to specific implementation cases, but these guidelines should apply generally to the class of applications and platforms supported by the OpenCable initiative.
The audience for this document is application designers and creators, as well as the more technically oriented developers and engineers. It may also be useful to test teams and customer support staff. It is important to establish terminology, concepts, and paradigms for the viewer’s user experience so that all stakeholders share a common understanding of the goals and framework in which they will be producing interactive cable applications.
Intro
1.2 Goals
This document is intended to provide a simple set of guidelines for the development of interactive TV applications on cable TV - regardless of the implementation details. This reference is not intended to be your only source of information. CableLabs provides a rich set of technical references for developers of interactive cable TV applications. In addition to guidelines for designing a successful application, this reference contains illustrations of completed applications, and a few use case scenarios to help you understand the interactions. Finally, this document provides you with a set of product images from the top cable TV service providers to help you understand the context of the interactive TV environment where your application will be used by consumers.
1.3 Audience
The audience for this document is anyone involved in the creation of interactive TV applications. Product managers, programmers, designers, user experience professionals, engineers and developers will all benefit from these interaction and visual design guidelines. This document helps establish terminology, concepts, and
paradigms for a viewer’s user experience so that all stakeholders share a common understanding of the framework in which they will be producing interactive cable applications.
1.4 Background
As companions to these User Experience Guidelines, CableLabs, its members, and other industry participants have collaborated to develop application developer guidelines and operational guidelines. These
documents address specific technical issues for building, executing, delivering, and hosting applications. These guidelines are available through CableLabs; see the reference section. In addition to these, CableLabs has also made available information on the current state of interoperability among ETV User Agents. The present document is primarily concerned with ‘bound’ applications – those applications that are delivered to a home via digital programming that applications are associated with. In the simplest scenario, interactive application code and assets, like bitmaps and data, are embedded into a digital program at origination, and distributed along with the
CableLabs® 9
programming as it flows from programmer, to service provider, and on to cable receivers in the home. Applications can be tightly synchronized with the underlying video, and updated with real-time data. Applications can send messages back to an application server, via the cable return channel. Details about the end to end environment are provided in the operational guidelines. There are a number of application
development kits available to developers of both ETV and OCAP applications, and we can expect that over time CableLabs and other organizations will provide more and more extensive developer support services. See a list of useful links in the reference section. Some amount of application testing may always be done by individual service providers, but mechanisms to centralize and streamline interoperability testing may evolve to facilitate very quick iterations between development, verification, execution, and refinement phases. CableLabs has defined a suite of ‘Stewardship and Fulfillment Interfaces’ (SaFI) to aid integration of applications with service provider infrastructure. These interfaces may be used to provide metadata
about applications, normalize messaging, and gather responses and measurement data. Again, see the reference section for links to these interfaces.
While the cable industry has adopted both ETV and tru2way™ as interoperable interactive platforms, much of the material in our family of guidelines is applicable to any application format, for example Flash, HTML, or other formats that may become relevant to cable.
However, there are details that are specific to ETV and OCAP. For instance, ETV supports three ‘profiles’ that correspond to the capabilities of categories of devices. Baseline, Full, and Advanced profiles allow applications to be optimized for limited capability legacy cable receivers, more capable devices, and advanced devices such as tru2Way ™ . For OCAP, a set of ‘Well-Behaved Application’ APIs are available to allow applications to easily implement the principles described in the guidelines. These technical details will be provided in the Application Developers’ Guidelines.
UE Design Basics
Visuals
Consistency
Voice
Application Model
Bound Applications
Unbound Applications
Application Life Cycle
Bound Application Prompts
This section describes some of the basic principles of design for interactive television. These principles should be followed to provide the user with the simplest, most intuitive user experience, while leaving plenty of room for creative expression by the designer.
2.1 Visuals
The graphical presentation of your application, or visual design, should follow certain system constraints, and some guidelines provided in this document, in order to improve the user experience – especially for those users that are new to TV-based interactions. The visual design guidelines found in this document are not overly restrictive. Those items that have been determined to be most critical to the user’s consistent ease-of-use, and highest degree of recognition, are defined. It is the intent of this guidelines document to allow for ample creative freedom while still enabling fast recognition, and fast execution of the interactive application.
Designing visuals for TV is not the same as designing for a computer screen, web apps, or print media. The Visual Design section of this document goes into great detail on how to deal with color specification, layout, type sizes, line weights, etc. A good understanding of this area will result in designs that have a quality appearance on the TV screen.
2.2 Consistency
One of the best ways to encourage the adoption of new behaviors is to encourage repetition. Repetition will only come about when the interaction patterns in the community of applications on TV behave in the same way. A consistent navigational paradigm is paramount. Developing applications for interactive TV in America is faced with the challenge of varying navigational paradigms across the collection of video service providers serving their customers. CableLabs has worked with this community of video service providers to define a minimal common set of controls and design norms to help establish ease-of-use, and ease of adoption by the interactive TV user. Following these basics will help ensure that your application will work best when deployed across numerous cable systems. The simplest of these is the adherence to the use of Up, Down, Left, Right and Select as the primary input buttons for navigating your app. The second is the use of clearly labeled buttons which indicate their highlight state with a bright yellow fill (specified later in this guideline document). Another very consistent interaction is to adhere to the expected behavior that pressing “Exit” will result in dismissing the entire application display and
CableLabs® 13
return the user to the presentation state prior to launching the application.
2.3 Voice
The personality of an interactive TV application will come across to the user through the visuals and interaction patterns in the design, but an even more powerful expression of personality will be in the written words in the interface. Your application should have text labels and text which are familiar and expected. The tone of the written voice should be friendly and helpful. You should always avoid sounding too technical, and avoid insider ‘lingo’ or technical acronyms. Labels and reference to controls should be very obvious in nature. For instance, the inclusion of a button which will play an On Demand video should have a descriptive word for the action, and some descriptive text for what the user would see after pressing the button. In this case “Play video” is a perfectly acceptable label for a control.
2.4 Application Model
Cable applications fall into one of two categories–bound or unbound. These categories have technical distinctions as well as conceptual differences. While the viewer will not necessarily be aware of these differences, the creators of the applications must have a good conceptual understanding of them in order to design effectively for a cable platform.
2.4.1 Bound Applications
Bound applications are associated with the currently tuned channel. They start executing and may present a user interface without any action by the viewer. Because these applications are designed to enhance the current broadcast, they are sometimes referred to as program enhancements. Some bound applications start and end within a program (e.g., on half-hour boundaries) and offer opportunities related to that program (such as voting on a reality show). Others exist entirely within a 30-second commercial break, and may provide additional product information or links to long-form advertising, using an existing Video-on-Demand (VOD) system. Some bound applications may persist on a channel regardless of the current programming (such as a customizable news ticker).
UE Design Basics
Figure 1 - Bound Application Example
All of these applications share the
characteristics that they are associated with the currently tuned channel, and that if the viewer changes channels, then the bound application will be terminated (unless it is also associated with the newly tuned channel). When the viewer changes the channel, and the same application is available on the new channel, it is allowed to remain on screen to maintain continuity of the user experience. Applications can detect that the channel has changed, but are not required to acknowledge it in any visual manner. Often, bound applications that are signaled on multiple channels have channel-specific logos or other visual elements in their GUI. It is important to note that the user will likely not be expecting a bound application to appear over the current video programming. The design of this initial “prompt” or “call to action” should be designed with that in mind. Keep in mind that most users still view television viewing as a passive activity. Interacting with Enhanced TV Programming will take some learned behaviors. The prompt, or call-to-action, should be simple, clear, inviting, and present a message that will lead to a positive experience.
2.4.2 Unbound Applications
Unbound applications are not associated with any particular broadcast or on-demand service. They execute independently of the selected channel and are controlled by the network operator through the OOB (out of band) communications channel.
The most common unbound application is the basic program guide that allows the viewer to browse the services and programs available through the cable network. This is typically called the Navigator (shown in Figure 2a). Another example is an on-screen alert for an incoming phone call (a “Caller ID” application shown above in Figure 2b). Unbound applications present a unique opportunity for user engagement. These applications can be launched from menus within the Navigator, or from another application. The omnipresent nature of the unbound application makes it ideal for deeper engagements which do not rely upon the connection to a specific piece of television programming. Examples of this would be games, guide extensions, network portals, or utility programs.
CableLabs® 15
Figure 2:
Unbound Application Examples
a) Example Navigator b) Example Caller-ID Alert
2.4.3 Application Life Cycle
The network operator controls the execution of applications on a cable platform by sending signals to the platform. This process of signaling is central to the application life cycle. The most basic steps in the cable application life cycle are: being downloaded to the platform, executing, being paused, and being terminated. While the viewer may not be aware of these phases explicitly, the developer should understand the life cycle to properly design a cable application.
For example, there are latencies associated with retrieving and downloading application content over the cable network. These latencies can affect the user experience and must be taken into account when designing an application.
Delays in loading application content can be especially problematic on older cable devices with limited memory and slower processors. Various techniques are typically deployed to mask the time required for loading new assets when changing states or during the startup phase of an application.
A developer should define a timeline for the application and identify points for start of download, start of application, when
to pause, when to resume and application termination. The timeline should consider users tuning in the middle of the timeline and specify how long in the program they want to allow the new user to launch the application. Timeline should also be marked for any trigger events planned to be used in the application. It is recommended that the application goes into pause state when it has no active UI to present on screen. A developer also needs to consider that their application can be paused, lose focus or be terminated if the user accesses any other application related to service navigation such as guide, program/network info or other high priority application/service such as emergency alert messages. In most cases, the application will resume or can be launched again when the other pre-emptive high priority application goes away. The application can lose its state if it is pre-empted by other high priority applications. For more details about the definition of application life cycle and how it influences application behavior, see [OCAP] and [ETV-AM].
UE Design Basics
2.4.4 Bound Application Prompts
When a bound application gains focus it may become visible at the top of the window stack. When an application becomes visible it shall provide an
unambiguous visual cue that an interactive application is presently available by displaying a ‘prompt’. A prompt has the following characteristics:
• A prompt shall incorporate a standard graphic icon. The icon will be defined and provided by the cable industry as a uniform mark indicating interactivity. • A prompt may incorporate branding or
other messaging communicating the source or content of the interactive application. These visual elements are added at the discretion of the application provider.
• A prompt provides a clear ‘call to action’. By convention, if a viewer presses the ‘select’ or equivalent key while the prompt is visible, the main body of the application will be presented.
• If a viewer presses ‘exit’ while the prompt is visible, the application will immediately become invisible, and will enter the suspended or terminated state. • If there is no viewer input after an
application defined time-out period, not to exceed 30 seconds, the application will immediately become invisible, and will enter the suspended or terminated state. Applications that are bound to very short content segments, such as a 30 second advertisement, are not required to display a prompt.
Figure 3: Bound Application Prompt
Interaction Design
Interactions
Navigation Paradigms
Input Devices
Behavioral Model
Designing With a Sense of Safety
Error Trapping
3.1 Interactions
The User Interface is the most critical touch point between your application and your viewer. The Interaction must be simple, relevant and responsive. It’s important for the application to display only the necessary actionable buttons with a minimum of text. Buttons should be self-evident with the expected result. Make the interaction possible in the fewest number of steps. If the viewer must input information, provide feedback and on-screen instruction. If your application requires external data, keep the interaction as simple as possible to avoid latency issues. Design your application interaction model with the input devices in mind.
3.2 Navigational Paradigms
The layering of application windows can be particularly difficult to manage on TV. They are easy to deal with on a PC or Mac – you simply click on the application window to bring it to the foreground. Since most cable platforms do not include a mouse or other pointing device, the viewer cannot easily use an on-screen pointer to select one window over another. The common input device for TV is the remote control. You need to remain within the predefined set of remote
control keys, found in Table 1, to perform all of your user interactions – including the switching or dismissing of any overlapping windows. Therefore, very simple and logical paradigms must be in place for navigating between applications.
This section establishes a common set of actions that a well-behaved cable application should observe, based on the remote control keys available to the viewer.
3.3 Input Devices
The familiar remote control is the typical input device for cable applications. In the future, new input devices may appear that offer other convenient and effective modes to interactive with your TV. Keyboards, touchscreen, gyroscopic devices and other forms of input are in wide use on other platforms, and may find their way to TV one day. Remote controls are by no means identical, therefore we must define a set of buttons, or ‘keys’, that are available on all devices, and describe conventions for their use. The following subsections provide specific guidance on the use of remote control buttons.
Interaction Design
Figure 3: Bound Application Prompt
CableLabs® 19
3.3.1 Focus Keys
Although there may be many keys on a remote control, only a small number of those keys are guaranteed to be seen by an application. This set of keys is known as the focus keys, as they are always available to the application with focus. The complete set of focus keys is defined in the Table 1.
3.3.2 Reserved Keys
• Applications SHOULD rely solely on the use of the Focus Keys.
All other keys on the remote control are typically reserved by the MSO’s Navigator application. Most cable platforms allow applications to “reserve” certain key events. Others deliver these key events only to the top application in the stack. For those platforms that allow the reservation of key events when the application is not on the top of the stack, these guidelines govern the use of those reservations.
• Applications SHALL reserve the Focus Keys only when they are in focus and at the top of stack.
• Applications SHALL release the reservations on any keys in the Focus Key group when they lose focus. • Applications SHALL release the
reservations on any keys in the Focus Key group whenever requested by another application.
3.3.3 UDLR
LEFT/RIGHT/UP/DOWN arrows are commonly used for navigation within a UI screen. A visual highlight that moves among specific elements within the screen in response to LEFT/RIGHT/UP/DOWN key presses should be used to provide focus and orientation within the screen. In addition, arrow graphics should be provided on the screen as visual cues to the user indicating possible navigation. If navigation is not possible in a given direction, an arrow graphic in that direction should not be shown. In all cases, it should be made obvious to the user prior to pressing a LEFT, RIGHT, UP or DOWN arrow key as to where the highlight will move. For instance, in the visual below, navigation to the left, right, up or down from the highlighted text is possible and is indicated by the four arrow graphics in and surrounding the highlight.
Table 1: Focus Keys
Key Name
Up Arrow
Down Arrow
Left Arrow
Right Arrow
Select
Exit
Colored Key 0
Colored Key 1
Colored Key 2
Colored Key 3
Page Up
Page Down
LEFT and RIGHT arrow keys may be used for spinner control (equivalent of a drop down box on the web) within a highlighted UI element on a screen. Specifically, pressing LEFT and RIGHT arrow keys allow users to browse through options in the spinner control.
For short lists of items that fit on a single UI screen, when you are at the topmost item, a graphical up arrow is not displayed and when you are at the bottommost item, a graphical down arrow is not displayed. For long lists of items that exceed the space available on a single UI screen, a circular navigation paradigm (i.e., pressing the DOWN arrow key when the last item in a list is highlighted brings the focus back to the first item in the list and pressing the UP arrow key when the first item in a list is highlighted takes the focus to the last item in the list) may be implemented. However, a graphical up arrow is not shown on the topmost item even though an UP arrow key press will take the user to the bottommost item, and similarly, a graphical down arrow
is not displayed on the bottommost item even though a DOWN arrow key press will take the user to the topmost item. Instead, up and down carat (^) graphics placed outside the list of highlightable items should be shown on the screen to indicate that additional pages of items are available. In other words, up and down carat graphics are only needed when the number of items in a list on a screen exceeds the number of items that can be displayed on the screen. 1. An up carat arrow is displayed when there are more items above the fold.
2. A down carat arrow is displayed when there are more items below the fold. Showing carat arrows depends only on the above two conditions and not on whether a list of items is circular or non-circular.
CableLabs® 21
3.3.4 Select
In this document, we use the term “SELECT button” on the remote control as the main input mechanism for the viewer to interact with a bound or unbound application. In different systems with different remotes, the actual remote control input button may be labeled as “SELECT,” “OK,” “ENTER,” or “OK/SELECT”. “OK” & “SELECT” are by far the most common labels on remotes in use today.
Pressing the ‘SELECT’ or equivalent remote control button generally indicates a viewer’s choice to take action on the currently highlighted UI element. Some examples of highlighted actions are: confirming a menu choice, casting a vote, requesting information, or navigating to a new overlay -- the behavior depends on the
application context.
In some systems, if no UI elements are available, pressing the “OK” button” will display the Interactive Program Guide.
Applications MAY present on-screen instruction such as “Click OK” to clearly help the viewer while others rely on the viewers learned behavior that pressing the “SELECT button” will initiate an action tied to the highlighted on-screen UI element. HINT: Some app designers have avoided calling out the specific remote key name unless they are able to identify it via set-top box/user agent query and dynamically replace it.
3.3.5 Exit
The EXIT button is one of the most commonly used features on the remote control. It allows viewers to clear the screen of any overlays and watch full video. When applying the EXIT action to ITV interfaces, the viewer’s learned EXIT behavior can be leveraged. When the EXIT button is pressed, and the application has a single visual layer, the application will hide.
If there are multiple applications running at Because there are no items above Locking Status, an up carat arrow is not displayed.
A down carat arrow is displayed because there are more items below Lock Recordings.
Note in this card that Locking Status has moved above the fold. Therefore, an up carat arrow is displayed to indicate that there are more items above Lock Channels.
A down carat arrow is displayed because there are more items below Lock Purchases.
3.3.6 Color Keys
Interactive Cable TV applications MAY make use of the special Colored Keys. These Colored Keys are available on certain remote controls, but it must be made clear that a developer cannot rely on these keys being available. Therefore, the Interactive Cable TV application developer MUST ensure that the application adheres to the “Select / Arrow” paradigm described above.
3.3.7 Number Keys
An exception to general key reservation rules is use of the number keys (0-9). Unless specifically designated within an application,
use of number keys will retune the set top box to the channel designated taking the user away from the application. However, in instances where an application would need to use number keys for a) text or numeric input or b) specific functionality, EBIF allows for designation of the number keys.
3.4 Behavioral Model
In developing guidelines for well-behaved cable applications, the overall goal is to ensure that the viewer always has an intuitive and familiar user experience. There is an inherent conflict in this endeavor between a tight constraint on the design of this user experience (to provide maximum standardization across applications developed by different providers) and allowing the designers of interactive applications maximum flexibility to create innovative user experiences.
In these guidelines, we attempt to stake out a position in the middle of that spectrum by providing strong recommendations for cable application behaviors, but not imposing onerous design restrictions on
the developers.
Interaction Design
the same time – for example, Caller ID with a bound programmer application – EXIT will first remove the application with focus, then each remaining application will require an EXIT press to remove all.
Applications MAY display an EXIT UI element on their ITV applications, or MAY assume viewers have learned that the ‘EXIT’ button will hide the application. In all cases, the EXIT functionality must be a responsive part of the application whether it is displayed on the interface or not.
CableLabs® 23
3.5 Designing In A Sense Of Safety
And Confidence
Viewers tune to television for entertainment, information and community. Interactive television can successfully support the experience if the applications add value, make viewing options easier or are an enhancement to content. An application should create a sense of confidence and security through relevancy, interest and functionality that delivers the expected result. Keeping the applications simple and clear through consistent button labels, on-screen descriptions or instruction is critical. In applications where a viewer inputs data or an order, timely and clear feedback must be provided. If a cost for interacting is required, the cost and where it is billed should be clearly visible. An “opt-in” button or sometimes a double “option-in” or confirmation will provide a clear message that the viewer’s information or purchase is safely processed.
There are many solutions to providing Help. In most cases, a Help system will not be necessary – especially if the application is simple in design, logical in the interaction flow, and consistently presented.
3.6 Error Trapping
Errors should be presented to the user as friendly alerts with instructive text for how to remedy the issue, rather than as grievous errors for which the user is made to feel responsible.
Depending on the context, different alert messages will be presented to the user. In general, the user should not be directed to call the cable operator for support unless there is a specific corrective action that the cable operator must take in order to restore service to the customer. In the event that a corrective action on the part of the cable operator is required, the user should be provided with a descriptive identifier of the issue, such as a system error number, along with instructions to contact the cable operator and provide the descriptive identifier. In cases where the system will correct itself or the user can take a particular action to correct the issue, an explanation of the issue should be provided, and the user should be asked to try again.
In addition to alert messages provided to the user in response to application and system errors or faulty user actions, informative messaging and/or visual cues regarding unavailable services should be provided
to the user. Examples include placing a “Program Unavailable” graphic in a video pane for which no video is available and graying out program titles that a user cannot view (such as a high-definition program on a standard-definition receiver).
CableLabs® 25
Visual Design
Visual Model
Visual Hierarchy
Window Stack
Focus
TV Safe Colors
Fonts and Font Sizes
Drawing Considerations
Graphics Containers
Graphics Over Video
Scaled Video
Translucency
4.1 Visual Model
In order to understand the interactive behavior of cable applications, it is important to have a visual model for how the viewer perceives these applications in the television environment. This section explains central elements of the appearance of cable applications.
These elements form a framework in which the application designer can develop interactive applications that provide a common user experience for all viewers. The viewer will not necessarily be cognizant of this framework, but it will lead to a consistent behavior of applications and allow seamless transitions between applications that are created by different designers and content providers. Following these guidelines for visual
consistency is the first opportunity to educate the consumer, and make them comfortable with the concept. Presenting frames, titles, text, buttons, and other basic controls in a consistent manner will lead to faster adoption of the new user behaviors that are necessary for the marketplace to grow.
Visual Design
4.2 Visual Hierarchy
Cable platform hardware has two visual planes: the video plane and the graphics plane. Cable applications render all of their graphics in the graphics plane, and the currently selected video stream is rendered to the video plane. The video plane is always below the graphics plane, which allows for cable applications to render graphics that overlay and blend to the video presentation. On most cable platforms, the video plane supports the scaling and positioning of the video presentation. On platforms that support such scaling, the application has the option of surrounding the video with its graphic presentation.
This is important: it is possible to have multiple applications executing simultaneously on a cable platform, and therefore multiple applications can be visible at the same time. Each application executing on the platform can create and display a single window at any given time. These windows are similar to overlapping windows on a PC, except that they have no consistent visual representation, such as the use of a title bar or enclosing frame. The window contents are completely determined by the application’s designer. And this is very important… since the primary control device
Figure 4A Visual Model
CableLabs® 27
Figure 4B Visual Hierarchy
…the application designer can develop
interactive applications that provide a
common user experience for all viewers
.
What the System
sees (layering logic)
What’s being layered
(video and graphics)
What the User
sees
What the System
sees (layering logic)
What’s being layered
(video and graphics)
What the User
sees
is the remote control, there is no way for a user switch between windows the way a user can on a Windows or Mac computer. The navigation between on-screen windows must be designed into the application at design time. And, since your application can be presented without any foreknowledge of another application, there will be no practical way to design that feature in. An application may render multiple visually distinct objects within its window, which can give the impression of layering within the window. However, those layers all render within the application’s single window. Objects within the window move together visually when the window changes position with respect to other application’s windows. The diagrams in Figure 4A,B,C,D illustrate this visual hierarchy. In these diagrams, there are multiple applications running in windows above the video plane. In Figure 4D, the viewer would not see the voting application as it would be completely obscured by the full screen Navigator application above it. The Navigator, in turn, is partially obscured by the Caller ID application, which is the front most application in this stack.
What the System
sees (layering logic)
What’s being layered
(video and graphics)
What the User
sees
Figure 4C Visual Hierarchy
What the System
sees (layering logic)
What’s being layered
(video and graphics)
What the User
sees
CableLabs® 29
4.3 Window Stack
To mange this collection of windows, a window stack is maintained. The top of the stack is the window closest to the viewer, and the bottom of the stack is the window closest to the video plane. Windows closer to the top of stack are said to be above windows lower in the stack. When the window stack is rendered to the screen, a window may be obscured by any pixels rendered in a window above it. If the pixel rendered above is opaque, it will be completely obscured. If the pixel has some level of transparency, then it will be blended with the windows (or video) in the stack below it.
An application should request focus - which may be denied if higher priority applications are currently in-focus/at the top of the stack. The Monitor application should resolve requests to insure higher priority applications have focus. Without some control, the stack could continually shuffle as applications fight over positions in the window stack.
Figure 5:
Figure 6A: Showing Focus
the core navigation system, your application and many others.
Typically, an action associated with the highlighted element occurs when the Select Key is pressed. (See 3.3.4, Select Key for a description of this key on the remote control.) The application must highlight a user interface element when it is in focus. When the application loses focus, then the highlighted user interface element should be returned to its un-highlighted state. Some examples are show in Figures 6A and 6B. When an application no longer needs to be in focus, it may yield focus to other visible applications in the stack. An application MAY have visual components on the screen when yielding focus, though by doing so allows other applications to obscure part or all of the yielding application. If no other application desires focus, the current application retains focus. Since bound applications are typically inserted at the bottom of the stack, they will only receive focus once all unbound
…this guideline will greatly enhance the user experience as the user
navigates between the core navigation system, your application
and many others.
Visual Design
4.4 Focus
The application at the top of the stack is said to be in focus and receives most of the signals from the remote control (see 3.3.1 Focus Keys). The window with focus must be clearly identified to the viewer, so that it is obvious what effect the key pressed on the remote will have when they are transmitted to the application with focus. It is the responsibility of each application to indicate that it has focus by highlighting a user interface element within its window. The method of indicating focus is left up to the application designer, and will depend on the user interface paradigm employed within the application. The guideline for indicating focus is to apply a yellow highlight to the default selected control. It is important that a yellow fill be applied to the control being highlighted. Alternatively, a bold yellow outline may be used, when the fill presents design difficulties. Following this guideline will greatly enhance the user experience as the user navigates between
CableLabs® 31
Figure 6B
applications have yielded focus. The methods and rules for requesting, receiving, and yielding focus are explained in section 5.3.1, Requesting and Yielding Focus.
4.5 TV Safe Colors
Televisions have different display
characteristics than do computer monitors. Standards have been developed throughout the years of television production which have aided artists, designers, and television producers in creating the correct color balance in television graphics. Most of the work done in this area has been for the benefit of broadcast television graphics. Graphics generated in the set top box located in the consumer’s home is a slightly different set of considerations. In the case of ITV applications, the graphics color space is determined by the display characteristics of the television display, along with the capabilities of the set top box graphics display processor.
Color is typically expressed in RGB values, ranging between 0 and 255 for each of the red, green, and blue component colors. If you are not careful in the way that you specify your colors, you may wind up with excessively bright colors which can cause unintended effects. For instance, specifying white type on a black graphics background should be done with care. Specifying White as 255, 255, 255 against a field of Black as 0, 0, 0, will create a combination that is of too high a contrast for a television display. The result will a ‘noisy’ presentation of text against the background. You can lessen the harshness of this presentation by reducing the contrast by reducing the White specification to 220, 220, 220, or lower. You can apply some easy rules for maintaining a quality presentation. For instance, the brightest white should be no more than RGB 235, 235, 235. Some TV navigation products limit the RGB value of white to 220, 220, 220. Conversely, if you goal is to present a pure black, you can specify RGB 0, 0, 0. Depending upon
the contrast and luminance handling of the display device, the zero values may be converted to a minimum base of 16. In that case, specifying RGB 16, 16, 16 may actually result in a luminance of 30+, resulting in your black field appearing as gray.
A general rule which will keep you ‘safe’ is to limit the maximum value of any of the three Red, Green, or Blue values to no more than 235. A very bright yellow for instance would be RGB 235, 235, 0. Backing off to a lower maximum may produce yet better result. A value of RGB 220, 0, 220 will create a very bright, yet acceptable, purple.
4.6 Fonts and Font Sizes
Fonts used by interactive cable applications are dependent upon the fonts embedded within the cable set top box found in the consumer’s home. All of these devices, or their display engines have a default san-serif font. Humanist and Tiresias are examples of fonts available to interactive cable applications. It is recommended that your application not use point sizes smaller than 16 point. Headlines or type used for emphasis should be between 22 and 24 point.
4.7 Drawing Considerations
There are many considerations for the use of graphics on a television screen. This document is not intended to be a comprehensive guide to such considerations, but a small number of issues are
worth mentioning.
• Colors are defined by Red, Green, and Blue (RGB) values between 0 and 255. It is recommended that applications SHOULD restrict those values to the range 16-240 in order to provide the best representation on NTSC televisions. The color black, therefore, has an RGB value of 16, 16, 16. The color white has an RGB value of 240, 240, 240.
• Applications SHOULD avoid the use of horizontal lines which are 1 pixel wide. This will cause flickering on interlaced displays.
For a more detailed set of guidelines for the use of graphics and text on televisions, refer to a formal reference such as Digital Video and HDTV, by Charles Poynton.
CableLabs® 33
4.8 Graphics Containers
The use of a background panel, or graphics container, for your interactive application will help ensure optimal readability for the user. The unpredictable nature of the design of the video source means that a consistent background color for your typography will create a message that can be easily read and acted upon. Your graphics can be specified with translucency, or opaqueness, but you should consider the overall size and position of the container and since it will likely occlude some of the underlying video. When done carefully, this can be tightly integrated with the source video to have the interactive overlay feel as though it is part of the video experience – while still retaining maximum readability for the interactive experience.
4.9 Graphics Over Video
A designer can overlay graphics on the video plane using ITV standards. This can take the form of icons, logos, or other graphical assets. One very important design consideration is the appearance of the edge of these graphics over the video plane. With a typically variegated background presented in the video, the graphics overlaid on the video should be carefully constructed and placed. Depending upon the edge color in
the graphics overlay, the graphical object may warrant the inclusion of a drop shadow or a stroke outline in a contrasting color. Any additional shadow or edge added to your graphic to improve the visibility of the graphic should be incorporated with the graphic to ensure maximum control by the designer. Graphics over video are not automatically anti-aliased. As such, the edge of the graphics over video may appear very coarse. Careful selection of foreground and background color can help minimize the impact of a ‘ragged edge’ to the graphics. In addition, the use of straight horizontal and vertical lines will further enhance the edge of the graphic to appear sharp.
4.10 Scaled Video
Some cable receivers are capable of scaling the video presentation. A common usage of this capability is to ‘shrink’ the video presentation, place it in the upper right corner of the display, and ‘wrap’ the application UI around the left side and bottom of the display. Even on those devices that support this capability, the available sizes and placements of the scaled video may be constrained, and the visual performance of the transition from full to scaled, in terms on number of video frames or other attributes, is defined by the
underlying platform. Applications that wish to take advantage of this capability may be written to accommodate these different levels of support.
4.11 Translucency
Some cable receivers only support a single transparency value: applications may set pixels to be either fully opaque or fully transparent. Other devices allow several degrees of translucency to allow blending of application graphics with the video or graphics underneath. Still other devices allow up to 256 (8 bit) translucency values. Translucency can enhance the appearance of your presentation and give it a feel of higher quality, while allowing some of the underlying video to remain recognizable. When measured as a percent of the original graphics fill color, a translucent fill between 75% and 85% will allow a reasonable amount of background video to show through, while still retaining sufficient readability of any text or graphics in the foreground. A tricky exception to this is when your interactive application is presenting over video which already contains broadcast graphics of some type – as found in many news programming on television today. In this case, translucency applied to the background of your interactive
application may introduce a visual conflict between the foreground application and the underlying video. As always, good design judgment should be used when creating an overlay application under these circumstances. Careful placement, and / or the use of an opaque background may provide the proper design solution.
Application Development
Load Times
User Interaction Timing
Focus Management
Preventing Image Burn-in
Title Safe Area
5.1 Load Times
Bound application resources are interleaved with audio and video packets within a digital program stream, and the bit rate at which resources are transmitted can be configured. A higher bit rate allows for more data to be transmitted within a given amount of time, and therefore a shorter load time for an application, or the time it takes to deliver application resources to a receiver. Since bandwidth is always a precious resource, there is a trade-off between keeping the bit rate of an application low and optimizing application load performance. Simple applications generally should be transmitted at a bit rate of 100 Kbs or less. This topic will be addressed in more detail in the CableLabs Operational Guidelines.
5.2 User Interaction Timing
• When an app requests viewer input, if no response is given, it SHOULD time out and should be removed from the display after a period of inactivity – usually between 6 and 10 seconds. • If an application response to a viewer
action will take longer than 2 seconds, that application should display a visual indication that it received the
request and is taking action. The on-screen display should be a simple indication that the user action has been recognized, and that something is happening. Consumer research has shown that delays in excess of 2 seconds can lead to the consumer pressing more buttons, or becoming frustrated. A simple on-screen “Loading . . . .”, “One moment please”, or “Processing” message will set the right expectations.
5.3 Focus Management
Only one application can have focus at any time, and it will always be the application at the top of the visible window stack. Unbound applications can ask to be placed at the bottom of the stack or at the top of the stack. Bound applications will typically ask to be placed at the bottom of the stack, or be placed there by the platform, and will only receive focus when no other application is above it on the stack, or when the applications above it yield focus.
An application yields focus when it is willing to give up focus to any application that is waiting to receive it. This typically occurs in the MSO’s Navigator application, which likes to have focus even when the viewer
This section defines several specific guidelines for applications to follow.
Application
Development
CableLabs® 37
is watching full screen video with no UI displayed. The Navigator does this so that it can use the focus keys to activate UI elements.
5.3.1 Requesting and Yielding Focus
In the behavioral model for cable
applications, focus and visibility are tightly coupled. Only the top-most application on the stack can have input focus and is guaranteed to be visible.
There are cases in which an unbound application, such as the Navigator, will wish to stay active and in focus even when not displaying a visible user interface (usually to trap certain key events).
• When an unbound application does not have a visible user interface, or does not wish to consume any Key Events, it SHOULD yield focus to other waiting applications in order to allow lower priority (e.g. bound) applications to run.
5.3.2 Highlights
• When in focus and on the top of the stack, applications SHALL use a visual highlight on one or more visual elements to indicate that they have
focus. Typically, this will be an interface control which is the preferred default interaction. For instance “OK” versus “Cancel”. The treatment for the highlight state is a yellow focus color – either as a fill or outline.
• When an application is not in focus, it SHALL remove any visual highlights from user interface elements that indicate focus within that window.
5.4 Preventing Image Burn-in
Screen burn-in, colloquially known as screen burn, is a permanent disfigurement of areas on an electronic display such as a CRT display or computer monitor or television screen caused by cumulative non-uniform usage of the pixels.
LCD-type displays are also susceptible to permanent burn-in, but generally less so than plasma-type displays. In the case of LCDs, the mechanics of the generally transient image persistence become so severe that pixels permanently lose their ability to return to their relaxed state. All major LCD manufacturers’ warranties exclude coverage for burn-in (permanent image persistence) as a result.
Both plasma-type and LCD-type displays exhibit a similar phenomenon called transient image persistence, which is sometimes confused with screen burn but is not permanent. In the case of plasma-type displays, transient image persistence is caused by charge build-up in the pixel cells (not cumulative luminance degradation as with burn-in), which can be seen sometimes when a bright image that was set against a dark background is replaced by a dark background only; this image retention is usually released once a typical-brightness image is displayed and does not inhibit the display’s typical viewing image quality.
5.6 Title Safe Area
Because some televisions do not display all of the pixels on the edges of the screen, it is important to limit the display of user interface elements to only that portion of the screen that is guaranteed to be visible on all televisions. The visible area varies from TV to TV. While most new flat panel HD TVs show more pixels than earlier tube-type and projection TVs, they do not consistently show all pixels.
• Applications SHOULD restrict all drawing to the ITV Safe areas as described in the Cable Application Developer Guidelines [GL-DG].
Figure 7: Title Safe Areas Screenshot: A screenshot showing
examples of the current common practice of extending text crawl and other text elements beyond the traditional Title Safe Area. The figure also shows the traditional Title Safe (yellow), Action Safe (red) and the new ITV Safe (green) Areas.
Application
Development
Title Safe Action Safe ITV Safe
Pixel WxH* Upper Lower WxH* Upper Lower WxH* Upper Lower
Aspect Left Right Left Right Left Right
Ratio Corner Corner Corner Corner Corner Corner
(x,y) (x,y) (x,y) (x,y) (x,y) (x,y)
Designing on square 512x384 6448 373.431 376x432 3224 607.433 538x404 31.38 388.441 640 x 480 canvas
Typical Use Cases
Bound Application Presentation
Application Window Priorities
Bound Application Prompt Time-out
Bound Application Obscured by Unbound Application
Typical Use Cases
This section describes a set of typical use cases for cable applications. These cases are not intended to be an exhaustive list of all possible viewer scenarios, but they are intended to illustrate the conceptual models and guidelines of the previous sections of this document. They cover common situations that the viewer will likely experience while interacting with cable applications.
Each case is presented as a scenario, with sample screen images of each step. A description of the viewer action and discussion of the system behavior is indicated.
6.1 Case 1:
Bound Application Presentation
A bound application is launched, interrupted, and dismissed.a) Joe is watching a show on Channel 5. b) Joe tunes to channel 2 where a bound application (Voting) is signaled. The Navigator shows an information bar for 5 seconds.
In this instance, the Voting application prompt is not displayed, as the Navigator has indicated that all pixels outside the Info Bar are transparent to video.
c) Once the Navigator’s Info Bar is dismissed, the Voting application’s prompt becomes visible, advertising the availability of the voting opportunity connected to the program on channel 2. The application relies on the standard interaction of pressing “select” on the remote control to interact with the programming.
CableLabs® 41
d) Joe presses Select on the remote, which causes the Voting application to remove the prompt and bring up its primary interface. A question is presented in a dialog box to which the viewer can respond. Note that a default interaction is indicated by the yellow highlight on the “Yes” option for this voting application. The user need only press “Select” to continue. Pressing the right arrow button will highlight the “No” option. As with every enhanced TV application, pressing “Exit” on the remote control should clear the screen of any display graphics provided by this app.
e) While the Voting application user
interface is still on the screen, an unbound application (CallerID) is triggered to notify Joe of an incoming phone call. The Caller ID application pre-empts and obscures the Voting application.
In this instance, the Voting application GUI would be visible, although it may choose to either remove its GUI altogether or simply “dim” the graphics (in this case by making them more translucent) when it is informed that it no longer is on the top of the stack. In the case that it remains visible, it should remove any visual highlights which indicate Focus.
f) Joe dismisses the Caller ID application by pressing Exit on the remote, which brings the Voting application back into focus.
g) Joe then decides to dismiss the Voting application after all by pressing Exit a second time. This causes the presentation to return to full screen TV, with no overlays, and Joe is retuned to watching channel 69.
Figure 8:
Typical Use Cases
6.2 Case 2:
Application Window Priorities
An unbound application with multiple UI elements in its window is interrupted.a) Gina is watching a show on channel 2. b) Gina presses the Guide button, which brings up the Navigator application.
c) While the Navigator is displayed, the Caller ID application is signaled, causing it to display itself.
When the Caller ID application becomes visible and the Navigator loses focus, the Navigator will dim the highlight on its grid. The Caller ID dialog is visible over the Navigator menu.
d) At this moment, Gina presses the “Menu” button on the remote. This brings up the navigator’s Main Menu. When the Main Menu is displayed, the Caller ID application is not visible in the stack. This is because the Main Menu is part of the Navigator’s presentation layer. It will move to the top of the display stack, obscuring the Caller ID application altogether.
e) While this is occurring, a second phone call comes in, which again causes the Caller ID application to display its GUI. When the Caller ID application re-asserts itself, both applications are again visible, with the Caller ID window on top of the Navigator’s window. Also, at this point, the Navigator will un-highlight the button in the Main Menu, and visually dim the other UI elements, to indicate that it is not
Figure 9:
CableLabs® 43
d) Mary ignores the prompt and after a few moments, it times out and disappears. When the prompt times out without
a user interaction, this is equivalent to the viewer selecting ‘EXIT’ and the application is suspended or terminated. The application may present itself again only if Mary tunes away and then selects this channel again.
6.3 Case 3:
Bound Application Prompt Time-out
A bound application is launched but times out without interaction.a) Mary is watching a show on channel 5. b) Mary tunes to channel 2 where a bound application (Voting) is signaled. The Navigator shows an information bar for 5 seconds, during which time the Voting application waits for the screen to become clear.
In this instance, the Voting application prompt is not displayed, as the Navigator has indicated that all pixels outside the Info Bar are transparent to video.
c) Once the Navigator’s Info Bar is dismissed, the Voting application’s prompt becomes visible, advertising the availability of the voting opportunity connected to the program on channel 2.
Figure 10:
6.4 Case 4:
Bound Application Obscured by
Unbound Application
A bound application is launched but times out without ever being seen.
a) Joe is watching a show on channel 5. b) Joe presses the Guide button, which brings up the Navigator application.
c) While the Navigator is displayed, the program changes to a commercial break, where a bound application is signaled. The bound application makes itself visible and places itself at the back of the stack, but it is obscured by the Navigator, so is not seen by the user.
d) The commercial break completes, and the associated bound application is terminated without ever being seen.
Figure 11: Bound Application Obscured by Unbound Application
CableLabs® 45
Figure 12: Various EPGs
Examples
Figure 13: COX Remote
Figure 14: Generic Remote
References
REFERENCES
[OCAP] OpenCable ApplicationPlatform Specification, OCAP 1.1 Profile, OC-SP-OCAP1.1.2-090930, September 30, 2009, Cable Television Laboratories, Inc. [ETV-BIF] Enhanced TV Binary
Interchange Format 1.0, OC-SP-ETV-BIF1.0-I05-091125, November 25, 2009, Cable Television Laboratories, Inc. [ETV-AM] Enhanced TV Application
Messaging Protocol 1.0, OC-SP-ETV-AM1.0-I05-091125, November 25, 2009, Cable Television Laboratories, Inc. [GL-DG] Cable Application
Developers Guideline, CL-GL-DG-V01-100205, February 5, 2010, Cable Television Laboratories, Inc.
[GL-ETV-OG] Enhanced TV Operational Guidelines, OC-GL-ETV-OG-V02-091223, December 23, 2009, Cable Television Laboratories, Inc.
[GL-ETV-AIG] ETV Application Interoperability Guidelines, CL-GL-ETV-AIG-V01-100219, February 9, 2010, Cable Television Laboratories, Inc.
[ITV] ITV Safe Area for Text and Graphics Over Video, by Walt Klappert and David Preisman, March 29, 2005 Version 1.00 [SaFI] CableLabs Stewardship
and Fulfillment Interfaces http://cablelabs.com/ advancedadvertising/ specifications/safi.htm
Reference Acquisition
CableLabs Specifications:Cable Television Laboratories, Inc.,
858 Coal Creek Circle, Louisville, CO 80027; Phone 303-661-9100; Fax 303-661-9199; Internet: http://www.cablelabs.com /
