The invention pertains to user interfaces and particularly to user interfaces for displays.
The invention is a system for defining a user interface of a remote display device.
There appears to be a need for a remote display device with a configurable user interface. The remote display may be regarded as a much needed enhancement to a Novar™ building control system platform called Opus™.
The invention is an approach or mechanism for defining the user interface components (i.e., screen layout, screen content, navigation hierarchy) within the building control system. It may be a rendering of that user interface definition on the remote display device. This may be accomplished through the creation of a set of object types. These object types may represent the components of the user interface. A feature of the invention may be that the mechanism has no dependency on either the hardware/software platform of the building control system or the hardware/software platform of the remote display device.
A technical challenge is to develop a dynamically configurable user interface (“UI”) for the remote display device (“display”) of a computing platform (“computer”). In summary, a solution may include an approach for defining the screen layout, the screen content and the navigation hierarchy. This may be achieved through the creation of a set of object types. These object types may represent the components of the user interface. Each object type may have a default look and behavior within the display. An object type may be composed of properties which modify, enhance or extend the object's default look and behavior.
The present approach may utilize the “Extensible Markup Language” (XML). XML may be a general purpose specification for sharing structured data. XML may provide a common format in which the computer and the display can share information. Each object type may be encoded in a XML document using a standardized nomenclature.
The user interface may be composed of screens, screen elements, navigation elements, and data elements. An object type may be defined to represent each of these elements. The user may create the user interface by selecting elements from the available set of object types. The object types selected and their placement within the user interface may define a navigation hierarchy, while the functionality of the object types may define the look and behavior of the user interface.
As components are added to the user interface, the user can modify the look and behavior by editing the components' properties. The user interface definition may then be encoded in XML using the standardized nomenclature and transferred to the display.
Within the display, the user interface definition may be interpreted according to the standardized nomenclature and the components rendered in a manner suitable to the capabilities of the display platform. As the user interface definition is interpreted, modifications of the default behavior may or may not be implemented. This will be dependent upon the capabilities of the display platform (possible constraints may include display screen size, display screen resolution, color versus grayscale, memory, CPU speed, and so forth).
In one approach, the set of object types may include the following items. Screens may include home, navigation list, data list and alarm list object types. The home screen may be an entry point for the user interface and a container for NavLinkButton (navigation link button), NavNodeButton (navigation node button) and DataBar (data bar) objects. The NavigationList (navigation list) screen may be used in defining the hierarchy of the information being presented, and be a container for a list of NavListLinkButton (navigation list link button) and NavListNodeButton (navigation list node button) objects. The DataList (data list) screen may be used to display a list of data values from the computer and the contents may be selected from the available DataItem (data item) object types. The AlarmList (alarm list) screen may display real-time alarm events received from the computer.
Each screen type may have a pre-defined behavior when rendered on the display. Each screen type object may have a “title” property which may be rendered by the display.
Buttons added to the Home screen type may have a pre-defined ordering mechanism. This ordering mechanism may be modified by the implementation of positioning (or coordinate) properties of the button object types. Buttons added to the NavigationList screen type may have a pre-defined ordering mechanism. DataItem object types added to the DataList screen type may have a pre-defined ordering mechanism. Each DataItem object type, when added to the DataList screen, may have a pre-defined behavior.
General navigation elements may include a NavLinkButton and a NavNodeButton. A NavLinkButton may create a navigable link to any screen object in the user interface hierarchy. It may be capable of displaying a user-assigned object name and user-selected image. A NavNodeButton may create a navigable link to a Screen object which exists as a child of the button. It may be capable of displaying a user-assigned object name and user-selected image. These button types may have a pre-defined look or appearance when rendered on the display. The look of these buttons may be modified by the assignment of a unique object name and by the selection of an image. These button types may also have a pre-defined behavior. When these buttons are pressed, the display may navigate to the linked screen. Additional modifiable properties of the buttons may include height and width (size), and horizontal and vertical (or x, y) placement (i.e., location) on a screen (for display).
Home screen elements may include a data bar, a data bar item and a data bar clock. The DataBar may be a user interface element which may contain DataBarItem and DataBarClock objects. The DataBarItem may be a placeholder for a data value from the computer, and content selected from the available DataItem types. It may be capable of displaying a user-assigned name and user-selected image. The DataBarClock may be a placeholder for the current time.
The DataBar may have a pre-defined look when rendered on the display. This look may be modified by properties including orientation (i.e., horizontal and vertical), and location (i.e., top, bottom, left and right). The DataBarItem may have pre-defined behavior. The value of the selected DataItem type may be rendered using that DataItems' modifiers (or facets) which include precision, units of measure, true and false text value, and enumeration range. The DataBarItem look may be modified by assignment of a unique object name and the selection of an image.
Navigation list elements may include a navlistlink button and navlistnode button. The NavListLinkButton may be used in defining the hierarchy of the information being presented (for display); create a navigable link to any Screen object in the user interface hierarchy; be capable of displaying a user-assigned name and a single selection from the available DataItem types. The NavListNodeButton may be used in defining the hierarchy of the information being presented (for a display). It may create a navigable link to a screen object which exists as a child of the button. It may be capable of displaying a user-assigned name and a single selection from the available DataItem types.
These button types may have a pre-defined look when rendered on the display. These button types may also have pre-defined behavior. The value of the selected DataItem object may be rendered using the DataItems' modifiers (or facets) which include precision, units of measure, true and false text value, and enumeration range.
Data items may include objects which represent the primitive data types available in most computers. These objects may be Boolean, Integer, Long, Double, Float, Enum and String. One may note that there may be objects which represent unique data types available in the NiagaraAX Framework. While present in the first approach of the invention, these objects are particular to this approach and would not be part of a generic description of the present system. Such objects may include BooleanPoint, NumericPoint, EnumPoint and StringPoint.
DataItem object types may provide an interface for transferring real-time data between the computer and the display. When a DataItem is added to the user interface definition, it may be associated (or linked) with a data source of a compatible type on the computer. A pre-defined behavior of each DataItem type may be to adopt the modifiers (or facets) of the data source. These modifiers may include precision, units of measure, true and false text values, and enumeration range.
When added to DataBarItem, NavListLinkButton and NavListNodeButton object types, the DataItem interface may allow the value displayed on the DataBarItem, NavListLinkButton and NavListNodeButton, to be updated in real time.
When added to the DataList screen type, each DataItem type may have several pre-defined behaviors as indicated as follows. First, the DataItem may be rendered as a button. This button may display the name assigned to the DataItem when it was added to the user interface and the value of the DataItems' associated (or linked) data source. Second, the DataItem interface may allow the value displayed on the button to be updated in real time. Third, the DataItem interface may allow the data source to be modified in real time if the data source is in a writeable state. Fourth, the DataItem may adopt the readonly or writeable state of the data source with which it has been associated (or linked). This state may influence the look and behavior of the button. If the data source is readonly, the button may have a grayed-out appearance to indicate that the DataList entry is inactive and available only for viewing. If the data source is writeable, the button may have a normal appearance indicating that the DataList entry is active and available for editing. Fifth, the DataItem object type may have an associated editing screen. This screen may be rendered on the display if the button is active and pressed by the display user. Editing screens may be provided for modifying the value of numeric-type DataItems, the true/false state of boolean-type DataItems, the ordinal of enumeration-type DataItems, or the text of string-type DataItems. Sixth, if no editing screen is implemented for a particular DataItem type, any button on any DataList for that DataItem type may appear inactive regardless of the data source's readonly or writeable state.
The following listing is an XML Representation of a user interface definition.
Elements of the invention may involve the NiagaraAX domain. These may be provided by the NiagaraAX-side components. The NiagaraAX components are resident in a so-called NiagaraAX device driver. The components consist of display and navigation definition elements and also a communications driver 311 that transfers information between the NiagaraAX system 312 and the heterogeneous embedded display device 313, as shown in
The communications device driver 311 is responsible for transfer of data between the NiagaraAX system 312 and the embedded display device 313. The driver 311 consists of several parts. One is a low-level driver 314 for transferring packets over the communications link with software resident on both the NiagaraAX system 312 and the embedded display 313. Another is a high-level software component 315 to read and write NiagaraAX objects including data points, alarms and screen definitions/navigation information to/from the low-level driver 314.
The following transfers 316 may be performed between the embedded display 313 and the NiagaraAX system 312. The transfers 316 may include screen definitions from NiagaraAX to the display, screen navigation hierarchy from NiagaraAX to the display, live data from NiagaraAX to the display, user-initiated data updates from the display to NiagaraAX, alarm objects from NiagaraAX to the display, and alarm acknowledgements from the display to NiagaraAX.
Pressing a button for lighting component 24 of navigation list 22 may result in navigation list 27 with a page 41 having items of parking lot lights 42, pharmacy 43 and sporting goods 44. Pressing a button for refrigeration 25 may result in navigation list 27 with a page 45 having items of walk-in cooler 46 and freezer case A 47.
From component HVAC 52 may follow HVAC zones 56. Lighting zones 57 may follow lighting 53. HVAC zones 56 and lighting zones 57 are of type NavigationList 58. Alerts 59 may follow from alarms 54. Alerts 59 may be of type AlarmList.
From data bar 56 may follow temperature 61 and humidity 62. Temperature 61 and humidity 62 may be of type DataBarItem 63. A DataBarClock object type named time of day 64 may also follow from data bar 56. A DataItem 67 object type named outdoor temp (float) 65 may follow from temperature 61 and a DataItem 67 type named humidity sensor (double) 66 may follow from humidity 62.
Objects of type NavListNodeButton 68 may include 1st floor 69, and 2nd floor 71 following from HVAC zones 56. NavListNodeButton 68 type objects parking lot lights 72 and garden center 73 may follow from lighting zones 57.
From 1st floor 69 may be a 1st floor 74 of type NavigationList. Settings 75 and monitoring 76 may be from 1st floor 74 and be of type NavListNodeButton 77. From settings 75 may be DataList 81 type object 1st floor settings 78 and from monitoring 76 may be DataList 81 type object 1st floor monitoring 79. A cool setpoint (double) 82 and a cool mode (boolean) 83 may be from 1st floor settings 78. A zone temperature (float) 84 and damper status (enumeration) 85 may be from 1st floor monitoring 79. Cool setpoint (double) 82, cool mode (boolean) 83, zone temperature (float) 84 and damper status (enumeration) 85 are all DataItem 86 type objects.
Also part of home 51 is HVAC 52 having an image file 96 of “HVAC.png”, and HVAC zones 56. HVAC zones 56 may have a navigation link 97, a title 98, 1st floor 69 and 2nd floor 71. Also part of home 51 is lighting 53 with image file entitled “LightBulb.png” and lighting zones 57. Lighting zones 57 may include navigation link 101, title 102, parking lot lights 72 and garden center 73. Also part of home 51 is alarms 54 with image file 103 and alerts 59.
Home 51 may also include lighting 53 which in turn includes image file 112 and lighting zones 57. Lighting zones may include navigation link 113, title 114, parking lot lights 72 and garden center 73. Home 51 may also include alarms 54. An image file 115 and alerts 59 may be included in alarms 54.
In the present specification, some of the matter may be of a hypothetical or prophetic nature although stated in another manner or tense.
Although the invention has been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the present specification. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the prior art to include all such variations and modifications.
This application is a continuation of U.S. patent application Ser. No. 12/411,193, filed Mar. 25, 2009, and entitled “A SYSTEM FOR DEFINING A USER INTERFACE OF A REMOTE DISPLAY DEVICE”. U.S. patent application Ser. No. 12/411,193, filed Mar. 25, 2009, is hereby incorporated by reference. Related patent applications include U.S. patent application Ser. No. 12/411,165, filed Mar. 25, 2009, entitled “MECHANISM FOR INTERFACING A DISPLAY SCREEN OF ANOTHER TECHNOLOGY WITH A COMPUTING PLATFORM”; U.S. patent application Ser. No. 12/411,183, filed Mar. 25, 2009, entitled, “A SMALL SCREEN DISPLAY WITH A DATA FILTERING AND SORTING USER INTERFACE”; U.S. patent application Ser. No. 12/411,201, filed Mar. 25, 2009, entitled “An APPROACH FOR ADVANCED USER NAVIGATION”; U.S. patent application Ser. No. 12/411,134, filed Mar. 25, 2009, entitled “AN AUTOMATIC CONFIGURATOR OF DISPLAY OBJECTS”; U.S. patent application Ser. No. 12/411,080, filed Mar. 25, 2009, entitled “AN EMBEDDED COMPUTING SYSTEM USER INTERFACE EMULATED ON A SEPARATE COMPUTING DEVICE”; all of which are hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
Parent | 12411193 | Mar 2009 | US |
Child | 15145744 | US |