Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000198228D
Publication Date: 2010-Jul-31

Publishing Venue

The IP.com 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. Based on the terms used at the user's company, and their own background, categories may or may not help them find the task they need to accomplished. User studies have hinted that it is difficult to locate relevant information in the wide-scoping administration consoles. This is likely due, at least in part, to the predefined structure imposed on the user. Another usability and design challenge exists during initial user interface development, when the design may still need to be tweaked. In these early stages, its critical to be able to easily rearrange pieces of the overall UI in order to optimize the usability. Basing the user interface structure around a single master listing of all the low-level user interface snippets or "chunks" with all of their key associations (e.g., semantic tagging, url, nav category, etc.) would help facilitate more usable and easily customizable design. Finally, it is important that the same user interface design not be implemented in two different places in the application. For example, if date and time settings can be shown in multiple places within a UI console, then those settings should always come from a single source. This is not just an issue of consistency for users, but also one for the designer needing to try to maintain multiple chunks of similar code scattered about.

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...