Patent Application
20070192694
It is sometimes desirable to implement a user interface that enables the user to review and/or enter properties for a group of elements. Typically, a grid control would be used to display the elements concisely and provide an efficient way for the user to enter property values as desired.
The grid control illustrated in
It should be noted that grid control 100 represents a very basic example. In some instances, the elements contained in the table of properties may be hierarchical in nature. In this case, the user interface may show a nested property list to enable the user to edit properties of child elements underneath top-level elements.
The appearance of grid control 200 is relatively neat at least because the child elements have the same structure as their associated parent element. In the illustrated example, all three contain a Name, a Type, a Length, a Modifier, and an Inheritance property. Because all of the elements throughout the hierarchy have the same set of properties, they all fit neatly into the grid control and share the same set of headers in row 230.
Certainly, scenarios are conceivable wherein child elements do not have the same property list as their parents. Further, other scenarios are conceivable wherein top-level elements X and Y have an identical structure, but the child elements of element X have a different set of properties, and the child elements of property Y have still another set of properties. In this situation, the elements no longer fit neatly into a grid control because the child elements do not share the same headers as the top-level elements.
One way to address the described challenge is to add a column for every property of every element throughout the hierarchy. This solution does not scale well when the elements can have any random set of properties, because the number of columns in the grid can quickly grow too large to be reasonably useful, and the grid can become very sparsely populated, very wide and difficult to read.
Another potential solution is to nest grid controls, with each nested grid control having its own set of headers and columns. This works reasonably well for relatively small data sets. However, the display can become unreadable very quickly because the headers at each level begin competing for the user's attention. When multiple nodes are extended, the grid becomes difficult to navigate and difficult to read.
Another challenge that arises in the context of property displays pertains to property lists that are dynamic and can be changed on a dependent basis. For example, scenarios are imaginable wherein an element's property list is dynamic and can change based on the value of another property or set of properties within the element or within a related element. For example, an element of type “car” may have the following properties: Make, Model, and Year. The system may be configured such that as soon as the user sets the values of these properties, additional, more specific properties show up for that element. For instance, if the user sets the Make to “Ford,” the Model to “Mustang,” and the Year to “1969,” two new properties may appear for the user to fill in, such as IsConvertible and IsRestored. However, if the user sets Make to “Honda,” Model to “Civic,” and Year to “2005,” then the IsCovertible and IsRestored properties do not appear, but instead another property called HasHybrideEngine appears instead.
The described type of dynamic user interface is difficult to model in a grid control. Even using nested grids as described above, the interface becomes quite noisy and busy, because entire columns of data will appear and disappear as the user adjusts the properties of the entity. Thus, the interface can be very difficult to read and confusing to use.
The discussion above is merely provided for general background information and is not intended for use as an aid in determining the scope of the claimed subject matter. Further, it should also be emphasized that the claimed subject matter is not limited to implementations that solve any or all of the disadvantages of any currently known systems noted in this section.
A computer-implemented user interface includes at least two hierarchically related element nodes. One node is a parent element node that is associated with a first set of property value components. Another node is a child element node that is associated with a second set of property value components. The first set of property value components is different than the second set. A property value component contained in at least one of the first and second sets is directly identified with a property identifier.
This Summary is provided to introduce, in a simplified form, a selection of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Embodiments are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with various embodiments include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, telephony systems, distributed computing environments that include any of the above systems or devices, and the like.
Embodiments may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Some embodiments are designed to be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules are located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 310 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 310 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 310. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 330 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 331 and random access memory (RAM) 332. A basic input/output system 333 (BIOS), containing the basic routines that help to transfer information between elements within computer 310, such as during start-up, is typically stored in ROM 331. RAM 332 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 320. By way of example, and not limitation,
The computer 310 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into the computer 310 through input devices such as a keyboard 362, a microphone 363, and a pointing device 361, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 320 through a user input interface 360 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 391 or other type of display device is also connected to the system bus 321 via an interface, such as a video interface 390. In addition to the monitor, computers may also include other peripheral output devices such as speakers 397 and printer 396, which may be connected through an output peripheral interface 395.
The computer 310 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 380. The remote computer 380 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 310. The logical connections depicted in
When used in a LAN networking environment, the computer 310 is connected to the LAN 371 through a network interface or adapter 370. When used in a WAN networking environment, the computer 310 typically includes a modem 372 or other means for establishing communications over the WAN 373, such as the Internet. The modem 372, which may be internal or external, may be connected to the system bus 321 via the user input interface 360, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 310, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
The dynamic property editor 400 is composed of an optional header 402 and a body 404. The header 402 illustratively provides context about the elements within the control 400. The body 404 contains a list of elements and their corresponding properties. In the case of
Each element illustratively includes several components. A first component is an element name 406 (identified as 429 in the child element). An optional icon 408 may be provided in order to establish a visual context as to the type of the element. Another icon identified as 410 supports the minimization or re-display of an element. Each element also includes a property list generally designated by arrow 412. For each property in the property list, a property name 414 and a property value 416 are provided.
As is indicated by the property value box associated with Property1 in
In accordance with one embodiment, the property list 412 is dynamic in that it is configured to change based on the values set within the list of properties. For example, Property3 might disappear when a predetermined value is selected as Property2. In accordance with one embodiment, an algorithm is applied to account for the disappearance or addition of property information. For example, if a property is eliminated, the algorithm will illustratively change the display in order to encourage neatness and efficient use of space. This may involve changing the size of body 404. As is generally indicated by optional link 420, means can be provided to enable a user to add a new element to control 400.
A dynamic property editor as described can be used as a standalone control or as a child control within another hierarchical control, such as a tree-grid control.
The dynamic property editor control is illustratively configured to apply an algorithm to automatically lay out the properties it contains according to the widths of the controls. For example, if the control shown in
An algorithm is illustratively applied to determine the optimal positioning of the sub-properties. Those skilled in the art will appreciate that the precise details of the algorithm will vary depending on the preferences associated with a given application. In general, the algorithm is configured to layout property controls such that a good balance is struck between widths of the controls and the total number of lines spanned by the controls. Optimally, each control should be wide enough to provide enough space to comfortably enter data into the control but short enough so that the controls do not span across more lines than necessary.
Thus, means are provided for neatly displaying properties in a hierarchical system wherein each node in the hierarchy can contain multiple properties and these properties can be of different types and appear or disappear depending on certain environmental dependencies. Child nodes in the hierarchy can contain different properties from their parents and their children. Siblings in the hierarchy can contain different sets of properties from one another. Properties of a node can come and go depending on the values of other values on that node.
In accordance with block 706, altering the configuration of the element node comprises adding to the element node, or removing from the element node, a second property name that is positioned proximate to a second property value component. In accordance with block 708, altering the configuration of the element node comprises reformatting a visual characteristic of the element node. In accordance with block 710, altering the configuration of the element node comprises creating, eliminating, adding to, or removing from, a limited set of values that can be assigned to a property value component contained within the element node.
Those skilled in the art will appreciate that subtle alterations to the proposed display techniques can be made without departing from the scope of the present invention. As an example of one such change, it isn't required that a property name identifier appear directly to the left of its corresponding property value or property control box. For example, one could just as easily arrange for the name identifier to appear above or even to the right of value or control. Placement to the right might be desirable, for example, in the context of right-to-left reading languages such as Arabic. This is just one example of subtle modification to be considered within the scope of the present invention.
Those skilled in the art will also appreciate that the use herein of terms such as “property” and “property editor” are intended to be broadly construed. In general, the term “property” is intended to illustrate application of the described information display techniques. Without departing from the scope of the present invention, the same or similar techniques could just as easily be applied to support other uses of editing other configurations of data. Specifically, the same or similar techniques can be applied to support ways of configuring data for which it could not be said to include properties of a given node or object.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
