Abstract: 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.

Abstract: 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.

Abstract: The described technology is directed towards a platform-independent user interface (UI) system. Views and other objects at the platform-independent UI system level perform layout, scrolling, virtualization, styling, data binding via data models and/or readiness. Input handling and output to a display tree are also performed at this level. An abstraction layer processes the display tree into function calls to objects of the underlying platform to render visible output.

Abstract: 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.

Abstract: 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.

Abstract: The described technology is directed towards an object-oriented programming (OOP) system and library that maps conventional object-oriented concepts such as class hierarchies, interfaces, and static methods and properties onto a prototypal object system such as JavaScript®. Various functions of the OOP system are called to create a class-like structure that is instantiated into an object instance upon request. The OOP system allows for use of a wrapper pattern to wrap selected objects with added functionality such as validation and tracing, and to provide enhanced functionality with respect to properties, such as to call a function associated with a property when the property's value changes, and/or to lazily generate property values only when accessed.

Abstract: 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.

Abstract: 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.

Abstract: The described technology is directed towards an asynchronous dispatcher including control logic that manages a queue set, including to dequeue and execute work items from the queue on behalf of application code executing in a program. The dispatcher yields control to the program to allow the program and application code to be responsive with respect to user interface operations.

Abstract: The described technology is directed towards a structured logging technology in which events corresponding to program execution are received in a structured format and logged based upon filtering of those events. A log handler is associated with a filtering mechanism that determines whether each event matches filtering criteria and is thus to be logged by the log handler. The log handler provides matching logged events to an event sink, such as an analytic tool that consumes the events for analysis.

Abstract: The described technology is directed towards conditional wrapper that wraps part(s) of a selected program object with added logic, such as to perform validation and/or tracing on part(s) the object; the wrapper may be multi-functional in this regard. The wrapper logic is selectively added to one or more selected object parts by the object creator at object creation time based upon conditional data. During runtime, the added logic may be run before the wrapped part of the object (e.g., a function) is executed and/or after execution of the object part. Validation and/or tracing operations may be run before the part of the object is executed as well as after the part of the object is executed. Objects that do not meet the conditional data criteria are created and returned without any added wrapping logic.

Abstract: The described technology is directed towards a factory identification system, in which a factory object is provided with a factory identifier (ID) that specifies information regarding a desired object that is more specific than specifying an interface. Additional construction parameters such as an object ID may be provided to further describe the desired object. Also described are object caching and reuse, and tagging the object with information that may be preserved and later used to recreate an object.

Abstract: 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.

Abstract: The described technology is directed towards 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.

Abstract: In at least some embodiments, input provided by a single source generates events representing multiple source types through a mapping process, e.g. a touch input generates both touch and mouse events. By configuring the system to not recognize certain gestures, messages associated with the events of the different source types are then interleaved and provided to an associated application for processing. Efficiencies are gained by configuring the system to interleave the messages associated with the source types because messages of one source type can be processed sooner than if the messages of the one source type were queued up and sent in a non-interleaved fashion.

Abstract: 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.

Abstract: 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.

Abstract: The described technology is directed towards having document files (e.g., a JSON object) associated with objects of a computer program. The document files may include validation information that is used during runtime to validate one or more parts of the object via validation code such as a validation function. For example, a function of an object may have one validation function that during runtime validates whether the input parameter(s) are valid (their types and/or values are correct), and another validation function that during runtime validates whether the return values from the function are valid. Also described is processing the document files into more easily readable documentation, e.g., without any source code.

Abstract: 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.

Abstract: 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.