Home Box Office, Inc.

J Jordan C Parker

Brandon C Furtwangler

Brendan Joseph Clark

Nathan J E Furtwangler

Steven N Furtwangler

Tyler R Furtwangler

Makarand V Patwardhan

Patrick Finnigan

Jonhenry A Righter

Jesse Corrington

The described technology is directed towards a pre-child user interface element in a user interface tree that draws before the parent element draws, (and thus before any conventional child element of the parent draws). For example, based upon current state data such as whether the parent element has focus, the pre-child may draw a highlight or the like before (so as to be beneath) drawing the representation of the parent element, to indicate the focused state (or and/or other current state or states). The user interface tree maintains a property that it is composable because the parent user interface element code is independent of what any of its pre-child element or pre-children elements do when invoked.

Pre-children in a user interface tree

The described technology is directed towards data-driven navigation, in which a next navigation location depends on variable data associated with an interactive user interface element (rather than a fixed link). The data may be in a hierarchy of data models. A menu contains interactive navigation elements, each bound to a data model. A selected interactive navigation element results in locating a data model associated with the selected element. The data model is used to determine the next navigation location. Also described is hierarchical navigation to one item of a level as well as lateral and peer navigation.

Data-driven navigation and navigation routing

The described technology is directed towards having UI elements structured in a hierarchical configuration, in which parent and child UI elements communicate via a virtualization interface. A change to any parent UI element view propagates to each impacted descendant, e.g., each child, any children of that child and so on, whereby each child can manage virtualization and rendering based upon the change. Focus changes among the UI elements are also handled by propagating information via the virtualization interface.

View virtualization

Determining the rendering of user interface (UI) elements, referred to as views, based upon styleable transitions between possible states of a view. Transitions may include animation, such as to smoothly enter a view into or exit a view out of a scene over a number of rendering frames. Transitions also may be applied to view state changes related to a UI element, such as to indicate hovered over, focused, listening (for speech), selected and/or pressed. View state changes also may be animated.

Configurable stylized transitions between user interface element states

The described technology is directed towards determining the rendering of user interface (UI) elements, referred to as views, based upon styles, in which styles comprise property values such as color value data, font data, border data, position data, and/or animation-related data applied to a view. A view object instance is returned upon request based upon an identifier that is used to select an unstyled view object and a style applied to that view object. The styles may be maintained as a fixed set of styles for a runtime session.

Styling system

The described technology is directed towards normalizing input received from various types of device types for providing the input to user interface (UI) elements in a unified way that reflects the invoke intent of the user. Input from different device types is classified as button input, pointer input or command input, and routed to a corresponding button provider, pointer provider or command provider. Each provider includes logic for communicating input data (e.g., events) to a UI element or elements. Based upon the input events, a UI element can execute a corresponding invoke handler to take an invoke action for that particular event.

Unified input and invoke handling

The described technology is directed towards sharing asynchronous (async) tasks between task chains, including in a way that prevents cancellation of lower-level chain entity from cancelling a shared async task. A shared async task is wrapped in multiplexer code that maintains lower-level entity identities as a set of listeners of the shared async task, and when a listener cancels, only removes that listener from the set of listeners so that the shared async task does not cancel as long as one listener remains in the set. Also described is optimization to share an async task, and wrapping tasks in cancel-checking code that prevents the task from running its work if the task is intended to be cancelled but is queued to run before the cancel request is queued to run.

Asynchronous task multiplexing and chaining

The described technology is directed towards a button repeat system that allows different repeat behaviors (e.g., interval times between repeats) to be customized for any view (user interface element) and for any button. A designer specifies an interval set comprising interval times to use in an associated view to repeat a button that is pressed and held. Using global information across views, a button that is pressed and held may continue to repeat as focus changes among views. The repeating may continue without needing to reset to the first interval time of the interval set of each view as focus changes, so that, for example, a rapidly repeating button does not appear to change its repetition rate as focus changes among views.

Styleable custom button repeat

The described technology is directed towards virtual input devices that take application program-directed input from automation and/or remote devices, such as over a network, instead of via actual user input via a physical device, for example. This allows an automation framework to insert input into an application program, such as for automated testing without modifying any of the application's other components. The virtual input devices may be object instances or the like that receive their input from function calls based upon the type of input and output events, e.g., to simulate keyboard input/output (I/O), mouse or other pointer I/O, voice, gesture, and other command I/O, and so forth.

Virtual input device system

The described technology is directed towards asynchronous models that retrieve view-specified data for a view. A view requests a view model to return view-specified data; in turn, the view model makes one or more requests to a data model to retrieve information corresponding to the view-specified data. The data model communicates with a data source such as a web service or a cache to return the requested information to the view model. The view model may assemble/reformat the information into a data format corresponding to the view specified data format for returning to the view. The requests may be asynchronous, with a promise returned in response until the data or information is returned to fulfill the promise.

Growing community of inventors

Seattle, WA, United States of America

J Jordan C Parker