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.
a is a diagram of a layout of a Niagara system, a heterogeneous display device and an interconnecting communications driver;
b is a diagram of a screen navigation hierarchy;
a shows a screen of a user interface definition in a computing platform;
b shows a screen of a user interface definition in a computing platform like that of
a is a diagram for defining a screen layout;
b is a diagram for defining a home screen;
c is a diagram for defining a data bar;
d is a diagram for defining a navigation link button;
e is a diagram for defining a navigation node button;
f is a diagram for defining a navigation list;
g is a diagram for defining a navigation list link button;
h is a diagram for defining a navigation list node button;
i is a diagram for defining a data list;
j is a diagram for defining an alarm list; and
k is a diagram for selecting a data item.
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.
b is a diagram of a screen navigation hierarchy. One may begin with a home page 21 which displays a navigation list 22 having components including heating, ventilation and air condition (HVAC) 23, lighting 24 and refrigeration 25. Also, home page 21 may include an alarm list 26. An example of home page 21 is shown in
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.
a shows a screen 91 of a user interface definition in a computing platform. The screen 91 shows a tree of the various items in a screen layout. The navigation buttons and home 51 screen are shown with the navigation link 92 and title 93. There may be some correlation of
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.
b shows a screen 104 of a user interface definition in a computing platform like that of
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.
a and 3b are illustrative examples of user interface definition in a computing platform. User interface may be significantly more detailed than the present examples.
a is an activity diagram of defining a screen layout starting at symbol 133. A screen type may selected at block or step 134 from a group including home 135, navigation list 136, data list 137 and alarm list 138. Having a home 135 selected, the home screen may be defined at symbol 139. Having a navigation list 136 selected, the navigation list may be defined at symbol 141. Having a data list 137 selected, a data list may be defined at symbol 147. Having an alarm list 138 selected, the alarm list may be defined at symbol 143. After symbol 139, 141, 142 or 143, one may repeat the screen type selection at block 134 and go through the process for a selected screen type. Or one may proceed to exit at symbol 144.
b is an activity diagram 139 of defining a home screen starting at symbol 145 and going to defining a screen title at block 146. A home screen element may be selected at step or block 147 from a group including data bar 148, navigation link button 149 and navigation node button 151, which may be defined at symbols 152, 153 and 154, respectively. After a definition of a selected home screen element, one may return to block or step 147 to select another home screen element at block 147, or to exit at symbol 155.
c is an activity diagram 152 of defining a data bar starting at symbol 156, and going to select a data bar element at block 157 from a group including a data bar item 158 and a data bar clock 159. If data bar item is selected, then an image at block 161 may be selected. After block or step 161, a data item may be selected at symbol 162. After symbol 162, one may repeat the process by returning to block 157, for example, to select data bar clock 159, or exit at symbol 163. If data bar clock 159 is selected, then one may go to symbol 157 to repeat the process, or exit at symbol 163.
d is an activity diagram 153 of defining a navigation link button starting at symbol 164, and going to defining a name at block 165, selecting an image at block 166, and creating a link to an existing screen at block 167. Then, one may exit at symbol 168.
e is an activity diagram 154 of defining a navigation node button starting at symbol 169, and going to defining a name at block 171. Then, an image may be selected at block 172 and a screen type may be selected at block 173. The screen type may be selected from a group including a navigation list 174, a data list 175 and an alarm list 176. If the navigation list 174 is selected, then the navigation list may be defined at symbol 177. If the data list 175 is selected, then the data list may be defined at symbol 178. If the alarm list 176 is selected, then the alarm list may be defined at symbol 179. After a definition at symbol 177, 178 or 179, an exit may be made at symbol 181.
f is an activity diagram 177 of defining a navigation list starting at symbol 182, and going to define a screen title at block 183. Then, a navigational list element may be selected at block 184 from a group including a navigational list link button 185 and a navigational list node button 186. The navigational list link button 185 may be defined at symbol 187. The navigational list node button 186 may be defined at symbol 188. After the definition at symbol 187 or 188, one may go to symbol 184 to repeat the process, or to exit at symbol 189.
g is an activity diagram 187 of defining a navigation list link button starting at symbol 191, and going to define a name at block 192. Then, a data item may be selected at symbol 193. After selecting the data item, a link to an existing screen may be created at block 194. Then, one may exit at symbol 195.
h is an activity diagram 188 of defining a navigation list node button starting at symbol 196, and going to define a name at block 197. Then, a data item may be selected at symbol 198; and at block 199, a screen type may be selected from a group including a navigation list 201, data list 202 and alarm list 203. The navigation list, data list and alarm list may be defined at symbols 204, 205 and 206. After a definition at one of these symbols, one may exit at symbol 207.
i is an activity diagram 178 of defining a data list starting at symbol 208, and going to define a screen title at block 209. Then, a data item may be selected at symbol 211. After selecting the data item, one may repeat doing a selection at symbol 211, as needed, and/or exit at symbol 212.
j is an activity diagram 179 of defining an alarm list starting at symbol 213, and going to define a screen title at block 214. Then, one may exit at symbol 215.
k is an activity diagram 216 of selecting a data item starting at a symbol 217, and going to define a name at block 218. Then, a data item type may be selected at block 219 from a group 221 including boolean, integer, long, double, float, enum, string, boolean point, numeric point, enum point, and string point. After selection of a data item type from group 221, a link to a compatible data source may be created at block 222. Then, one may exit at symbol 223.
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.
Related patent applications include U.S. patent application Ser. No. ______, Attorney Docket No. H0021716-1161.1398101, filed Mar. 25, 2009, entitled “MECHANISM FOR INTERFACING A DISPLAY SCREEN OF ANOTHER TECHNOLOGY WITH A COMPUTING PLATFORM”; U.S. patent application Ser. No. ______, Attorney Docket No. H0021919-1161.1399101, filed Mar. 25, 2009, entitled, “A SMALL SCREEN DISPLAY WITH A DATA FILTERING AND SORTING USER INTERFACE”; U.S. patent application Ser. No. ______, Attorney Docket No. H0022777-1161.1418101, filed Mar. 25, 2009, entitled “An APPROACH FOR ADVANCED USER NAVIGATION”; U.S. patent application Ser. No. ______, Attorney Docket No. H0022474-1161.1419101, filed Mar. 25, 2009, entitled “AN AUTOMATIC CONFIGURATOR OF DISPLAY OBJECTS”; U.S. patent application Ser. No. ______, Attorney Docket No. H0022842-1161.1420101, 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.