Browse Prior Art Database

Dynamic UI's based on Relationships and Databases

IP.com Disclosure Number: IPCOM000034029D
Original Publication Date: 2005-Jan-13
Included in the Prior Art Database: 2005-Jan-13
Document File: 3 page(s) / 67K

Publishing Venue

IBM

Abstract

This article describes a way to use a database to store the elements and individual controls of user interface (UI) dialogs, wizards, and configuration files in a common markup so that as a user specifies what behavior he wants to configure, the UI can be dynamically generated based on the UI elements found in the database.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 3

Dynamic UI's based on Relationships and Databases

Traditional client user interfaces (UI's) contain many wizards and dialogs that help users manage an entire operating system. The problem is that these wizards and dialogs, especially when developed by different departments or different companies, don't know about each other. Sure there may be a level of integration where similar UI can be launched from a similar area, but if a user wants to find all occurrences of fields that change the behavior of wireless access, for example, there is no way to do that. The user can only hope that a developer "registered" their wireless access UI along with other wireless access UI. There needs to be a way for a user to query the operating system to find all places where related items are configured.

     This solution uses a database to store the elements and individual controls of UI dialogs, wizards, and configuration files in a common markup so that as a user specifies what behavior he wants to configure, the UI can be dynamically generated based on the UI elements found in the database. The user would type in a topic or behavior, the database would be queried, and any UI element that is related to that topic or behavior would be added to a dynamically generated wizard or dialog. When a UI is installed, it would add its controls into the database (or register its web services, or whatever latest technology is being used) and would provide keywords and synonyms so that similar controls can be grouped together even when the UI's are developed separately. Additionally, when a UI is installed, if it finds controls that are similar to its, then it can reuse those controls in order to simplify the UI for the user.

The user can search for a topic or behavior and the database is queried. A dynamically generated UI with all related controls are shown.

If there are logs or text files where that topic can be configured, a link to those files or logs would show up.

Relationships: Today when a control is changed, it may have a direct impact on another control from the same application or a completely different application. With our invention, a UI could add information so that Control1 is changed, Control3 and Control26 will change as well. Today these controls may reside on different wizard pages or completely different UI's, but now they can be dynamically placed on the same page.

Synonyms can be grouped together so UI's that "configure wireless" or "edit mobile" or "change pervasive" properties can be in one wizard. Ontologies already exist that we can tap into.

The controls can also be ordered by usage, importance, and other criteria based on what the user wants to edit.

The desired behavior would be to combine these UI elements into one wizard/dialog, but at minimum, a dialog could be created with links to all the UI's that affect the topic the user wants to update.

UI's that could take advantage of this could include wizards, dialogs, Java* properties f...