Browse Prior Art Database

User Interface Chunking: Defining an entire software application user interface through distinct and independent snippets. Disclosure Number: IPCOM000198228D
Publication Date: 2010-Jul-31

Publishing Venue

The Prior Art Database


For many systems administrative software applications today, the end-user is presented with an incredibly large amount of data and information. The software designers make decisions about how to organize and categorize this information and present it on the user interface. These decisions may or may not match the way in which users themselves conceptualize the information. Even if it might match the way in which 50-60% of the users work, there would still be a significant number of users who would be required to figure out the designers organization scheme on top of trying to get their own work accomplished.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 31% of the total text.

Page 1 of 11

User Interface Chunking: Defining an entire software application user interface through distinct and independent snippets.

The overall user interface would be defined in terms of the smallest distinct 'chunks' that the user would interact with. Each chunk would have properties associated with it, such as:
a label for display purposes
a plain description
a distinct url or function that would provide content or perform an action, and additional metatags to help better provide search results using these meta-tags instead of simple literal searches of the display label.
a category to help indicate which chunks may optionally be grouped together in some way on the UI.

The content of a chunk should be able to act independently. Specifically, if the chunk is shown as a search result and the user interacts with the chunk to display its content, then all necessary UI components should be included in the content for the user to save, cancel, etc.

The definitions of the content and scope of the chunks would be somewhat subjective and would be based on what the users of the application would want or need to interact with. Such a chunk could be the UI components needed to show information about a particular piece of hardware, for example. A chunk could also represent a single action, such as powering a server on or off. The action could be performed immediately upon executing the url, or could present confirmation or request for addition input from the user. A chunk could also be larger in scope such as a table showing all hardware contained in a system, and available actions for the hardware. Using a URL affords great flexibility in how each chunk is defined or behaves, as executing a url could initiate a very wide range of possible actions and allows for providing any type of content.

When the user initiates a search to find relevant information, the application could show all of the matching chunks, which the user could then interact with to show the chunk content or perform the action defined by the chunk.

One main difference from existing architectures is that the chunks as a whole define all of the content for the user interface, and the user interface would be populated and built from the list of chunks. Important to note is that this list of chunks would be the single source for the user interface to build and obtain its content. And because each chunk represents a distinct independent task, chunks can be arranged in numerous ways, and many different UI designs and arrangements would be possible with a single list without needing to modify any the content of any of the individual chunks. This also enables the smallest possible components (or really whatever the designer decides to define as a chunk) to be fully searchable and to serve as building blocks for other parts of the UI.

For example, a single chunk could be used in many ways on the same web console:
Shown in result list of a user search





Used to define a content page of...