Collection adaptive focus GUI

[0001] The present invention uses inventions from the following patent applications, which are incorporated herein by reference:

[0002] Collection Information Manager USPTO patent application Ser. No. 09/885078 filed Jun. 21, 2001, Kevin W Jameson.

[0003] Collection Knowledge System USPTO patent application Ser. No. 09/885079 filed Jun. 21, 2001, Kevin W Jameson.

[0004] Collection Extensible Action GUI, USPTO patent application filed contemporaneously herewith, Kevin W Jameson.

[0005] Collection Role Changing GUI, USPTO patent application filed contemporaneously herewith, Kevin Jameson.

[0006] This invention relates to graphical user interfaces for processing collections of computer files in arbitrary ways, thereby improving the productivity of software developers, web media developers, and other humans that work with collections of computer files.

[0007] The Overall Problem

[0008] The general problem addressed by this invention is the low productivity of human knowledge workers who use labor-intensive manual processes to work with collections of computer files. One promising solution strategy for this software productivity problem is to build automated systems to replace manual human effort.

[0009] Unfortunately, replacing arbitrary manual processes performed on arbitrary computer files with automated systems is a difficult thing to do. Many challenging sub-problems must be solved before competent automated systems can be constructed. As a consequence, the general software productivity problem has not been solved yet, despite large industry investments of time and money over several decades.

[0010] The present invention provides one piece of the overall functionality required to improve the productivity of human knowledge workersan adaptable GUI user interface. In particular, the present Collection Adaptive Focus GUI invention has a practical application in the technological arts because it provides a graphical user interface that can dynamically adapt to changes in user work situations, thereby making it easier for users to perform work in more efficient ways.

[0011] Five conceptual models are required to explain adaptive behavior: (1) work situations, (2) work situation change events, (3) work situation adaptation knowledge, (4) adaptive user interfaces, and (5) technical means for using work situation adaptation knowledge to adapt user interfaces in response to work situation change events.

[0012] Conceptual models for work situations and user interfaces are described in this background section. Other conceptual models are described later, in the detailed description.

[0013] Work Environments

[0014] Software work environments are the software circumstances in which knowledge workers carry out their daily work tasks. For example, a command line shell window on an operating system is a typical command line software work environment.

[0015] Software work environments provide access to sets of work operations that are used by humans to accomplish various data processing tasks.

[0016] Work Operations

[0017] Work operations are computer programs, or computer scripts, that carry out computer actions. Typical examples of work operations include printing documents, performing calculations, and processing data files with application programs.

[0018] The default set of work operations made available by a computer operating system is called the default command set of the operating system. In practice, default operating system command sets are always extended with additional programs to provide users with application-specific work operations. Thus the total set of work operations available in a typical command line shell window is the union of the default operating system command set and the additional application-specific work operation set.

[0019] The total number of available work operations in a typical software environment can be large. At least hundredsand often thousandsof distinct work operations are available on modern computers. The complexity of such a large set of work operations imposes a significant knowledge burden on human workers.

[0020] Types of Work Operations

[0021] Four types of work operations are of interest for this discussion: operating system work operations, application program work operations, scripted work process operations, and variant process operations. These four types of work operations are presented in approximate order of increasing complexity.

[0022] Operating system work operations are the fundamental set of work operations that are available for use in work situations. These operations are provided by the operating system in the form of individual computer programs. In most operating systems, a shell window command line user interface provides access to these work operations.

[0023] Application-specific work operations provide additional functionality for accomplishing application-specific work. These work operations are normally provided by individual application programs. In most operating systems, a shell window command line user interface provides access to these application-oriented work operations.

[0024] Scripted work process operations provide process-level functionality to user interfaces. Scripted work process operations are normally provided by scripts, batch files, or custom programs that involve more complexity than individual operating system and application work operations. In most operating systems, a shell window command line user interface provides access to scripted work operations.

[0025] Variant process work operations provide variant process-level functionality to user interfaces. Like scripted process operations, variant process work operations are normally provided by scripts, batch files, and custom programs. In most operating systems, a shell window command line interface provides access to variant process work operations.

[0026] Work Events

[0027] Work events are used to invoke work operations. Specifically, work events are computer signals that cause work operations to be carried out. Work events are usually implemented by command line interfaces or GUIs (graphical user interfaces).

[0028] Here are some examples of work eventsclicking a GUI menu choice, clicking a GUI toolbar button, or typing a computer command line in a shell window. In these examples, a human initiates the work event; in turn, the work event invokes a work operation to perform a desired computational action.

[0029] In sequence: humans invoke work events, work events invoke work operations, and work operations perform computational work such as processing data filesthus work proceeds within a software work environment.

[0030] Work Processes

[0031] Work processes are sequences of work operations. Sequences of work operations are useful because individual work operations are usually too small to completely perform routine work tasks. Sequences of work operationswork processesare implemented by means such as batch files, scripts, and computer programs.

[0032] Work processes have two important characteristics that limit productivity and increase software development costs: narrowness of function, and brittleness of behavior.

[0033] Narrowness of function means that work processes can be used only to solve the original application that motivated their construction. They break, and do not produce the desired result if they are used for anything even slightly different than the original application. Narrowness of function is usually caused by development teams that try to save time and money by designing and building a minimally optimal solution for the motivating problem at hand.

[0034] Brittleness of behavior describes what happens when narrow work processes are applied to problems that differ from the original application. Total functional failure is the usual resultmost work processes are too brittle to handle even small variances in process inputs.

[0035] Narrowness of function and brittleness of behavior reduce productivity and increase costs because they prevent existing work processes from being reused on different problems. Instead, special variant work processes must be constructedat additional costto solve the different problems.

[0036] Variant Work Processes

[0037] Variant work processes are work processes that differ from each other in small but significant ways. Variant processes are typically required to solve variant work problems.

[0038] One example of a variant work problem involving minor differences is the problem of compiling source code modules with various compilation options enabled (same compiler, different options). Another example, this time involving major differences, is compiling source code modules for different computing platforms (different compilers, different options, different command sequences).

[0039] A third example is upgrading existing work processes with various combinations of new software programs from different software vendors. Still another example is modifying an existing work process to enable testing activities in personal home directories instead of in team or site working directories.

[0040] Variant work processes are important because they increase software project costs and schedules. They are also difficult to avoid because many project factors drive the demand for variant work processes. As a result, variant problems and processes are ubiquitous in software work situations, even though they are costly, undesirable, and unwanted.

[0041] Work Situations

[0042] Work situations are another name for work circumstances. Work situations can be usefully described by answers to these familiar six questions: Who What Why Where When and How

[0043] For example, consider a work situation in which a programmer must debug a production program after normal working hours.

[0044] The work situation is defined by answers to the six questions: Whothe programmer, operating in a debugging role. Whatthe program to be debugged. Whenafter normal working hours. Wherein the programmer's home directory. Whyto debug the program. Howusing the programmer's favorite set of debugging tools, and special after-hours tools to access the company repositories after normal working hours.

[0045] The answers could also indicate the character of the work situation, as follows:

[0046] WhoThe role of debugger could indicate that personal program options for debugging should be used in preference to system default program debugging options.

[0047] WhatThe name of the program to be debugged could indicate that special methods or debugging processes for that particular program should be made available to the programmer.

[0048] WhenThe time of after normal working hours could indicate that appropriate time-sensitive special security permissions, file access methods, or computer resource constraints should be used.

[0049] WhereThe location of a home directory could indicate that personal software programs should be used in preference to system default programs.

[0050] WhyThe purpose of debugging could indicate that work operations should run in debug mode, if possible.

[0051] HowPrevious answers could indicate how software processes within the work situation should be implemented to fit the particular needs of the work situation.

[0052] Work situations are complex. As shown above, work situations have six degrees of freedom in which to vary. This varianceand six degrees of freedom is a lot of itincreases software project costs because it adds to project complexity and drives the demand for costly special variant work processes.

[0053] Variant Work Situations

[0054] Variant work situations are work situations that differ in small but significant ways. The main sources of variance in variant work situations are variant work processes, which are in turn driven by variant work problems.

[0055] Variant work situations are important because they determine the work events, work processes, and work operations that are required by human users to accomplish the work at hand.

[0056] Multiple Work Situations

[0057] Multiple work situations are not the same as variant work situations. Multiple work situations differ in major ways, and so are not considered to be variants of each other. In contrast, variant work situations differ in minor ways, and are commonly viewed as close variants of each other.

[0058] As an example of the difference between multiple and variant work situations, consider a programmer who works on several different things during a routine day: on a website, on a program, and on a document. Since each work situation is significantly different they are called multiple work situations, not variant work situations.

[0059] Multiple Variant Work Situations

[0060] Multiple variant work situations are comprised of multiple instances of normal variant work situations. Multiple variant work situations are important because they accurately reflect the work patterns of typical human workers in the information industry. That is, human workers are usually involved in multiple work situations, each with (possibly many) variant forms.

[0061] It follows that to encourage maximum productivity, effective user interfaces must support the model of multiple variant work situations.

[0062] This concludes the background discussion on models for multiple variant work situations. In sequence: work environments offer user interfaces; user interfaces offer work events to humans; humans use work events to invoke work processes; work processes execute work operations; and work operations perform useful work.

[0063] The discussion now turns to the main subject of the current invention, how adaptive GUI user interfaces can adapt to new work situations to improve human productivity.

[0064] The Purpose Of User Interfaces

[0065] User interfaces are software programs that provide humans with access to work events and work operations, thereby enabling the human workers to accomplish their desired work goals within a software environment.

[0066] In sequence: user interfaces provide work events to human workers; human workers invoke work events; work events invoke work processes; work process invoke work operations; and work operations process data filesthus work is accomplished with the help of user interfaces.

[0067] The main goal of user interfaces is to facilitate human productivity by making it both convenient and efficient for humans to accomplish work. To this end, various kinds of user interfaces have been created over the years to improve user productivity.

[0068] Adaptive User Interfaces and Work Situations

[0069] For optimal human productivity, user interfaces should support multiple variant work situations, as modeled by the six Who, What, When, Where, Why and How questions. User interfaces should also adapt to new work situations, thereby providing users with sets of work events that are precisely tuned to to new variant work situations.

[0070] User interfaces should, but they don't.

[0071] Instead, current user interfaces provide only limited support for multiple variant work situations and adaptive behavior. Many problems must be solved in order to build adaptive GUI interfaces that can adapt to multiple variant work situations.

[0072] Problems to Solve

[0073] The Adaptive Focus GUI Problem is an important overall problem that must be solved to improve the adaptability of GUI interfaces. It is the problem of how to detect and how to react to changes among multiple variant work situations.

[0074] Some interesting aspects of the Adaptive Focus GUI problem are these: changes in work situations can be driven by four types of inputswho, what, where, when, and why; models for representing and managing change events for all five types of inputs are required; a model for representing and managing multiple variant processes is required; and the GUI display must be adapted and updated in real time as changes to work situations occur.

[0075] The Work Purpose Adaptation Problem (why) is another important problem that must be solved to enable the construction of adaptive user interfaces. It is the problem of modeling and managing purpose-sensitive changes in work situations. For example, if the purpose of a work situation is changed from debugging to production, all purpose-sensitive aspects of an adaptive user interface must be updated to reflect the change. For instance, work roles may contain purpose-sensitive variant work operations within the role.

[0076] Some interesting aspects of the Work Purpose Adaptation Problem are these: an arbitrary number of user-defined purposes are possible; each purpose can call for variant behaviors in the other five aspects (where, what, who, when, how) of the work situation; each purpose can affect the functionality of an adaptive GUI interface.

[0077] The Work Location Adaptation Problem (where) is another important problem that must be solved to enable the construction of adaptive user interfaces. It is the problem of modeling and managing location-sensitive changes in work situations. For example, when users change directories into a particular computer filesystem work areasuch as a directory for working on websitesan adaptive user interface should detect and react to the change by displaying and enabling web site work operations on the GUI interface.

[0078] Some interesting aspects of the Work Location Adaptation Problem are these: arbitrary numbers of user-defined work locations are possible; the behavior of many thingswork roles, events, operations, processesmay vary with location; work locations can be given symbolic names; work locations can be associated with attributes and properties; work locations may be directly associated with named sets of attributes and properties; work locations can inherit properties from ancestor locations in computer filesystems; and all location-sensitive adaptations may be customized for site, team, and personal use.

[0079] The Work Object Type Adaptation Problem (what) is another important problem that must be solved to enable the construction of adaptive user interfaces. It is the problem of modeling and managing changes in work situations that are sensitive to work object types. For example, websites, programs, documents are all examples of different types of work objects. An adaptive user interface should provide website work events for working on work objects of type website; program work events for working on work objects of type program; document work events for working on work objects of type document; and so on.

[0080] Collections are a useful model for work objects and types of work objects. Collections are sets of computer files that can be manipulated as a set, rather than as individual files. Collection are comprised of three major parts: (1) a collection specifier that contains information about a collection instance, (2) a collection type definition that contains information about how to process all collections of a particular type, and (3) optional collection content in the form of arbitrary computer files that belong to a collection. Collections are further described in the related patent applications listed at the beginning of this document.

[0081] Some interesting aspects of the Work Object Type Adaptation problem are these: adaptation should be performed according to the type of work object; arbitrary numbers of user-defined work objects and work object types are possible; each work object may be comprised of a collection of multiple computer files; work objects, if implemented as collections, may be comprised of one primary object and multiple sub-objects, each with a distinct type. Further, selection of a particular work object using an adaptive interface should cause an associated role to be used; special variant versions of normal processes to be used; additional work operations for the particular work object to be used; and all work object adaptations may be customized for site, team, and personal use.

[0082] The Work Role Adaptation Problem (who) is another important problem that must be solved to enable the construction of adaptive user interfaces. It is the problem of modeling and managing role-sensitive changes in work situations. For example, if a programmer changes from a debugging role to a documentation role in a work situation, an adaptive GUI user interface should remove debugging work events from the interface and should add documentation work events.

[0083] Some interesting aspects of the Work Role Adaptation Problem are these: arbitrary numbers of user-defined roles are possible; arbitrary types of roles are possible (each specifying arbitrary changes to the menus, toolbars, and underlying methods used by the user interface); roles may have platform dependent behavior; particular roles can be associated with particular types of work objects; and roles may be customized for site, team, and personal use.

[0084] The Work Time Adaptation Problem (when) is another important problem that must be solved to enable the construction of adaptive user interfaces. It is the problem of modeling and managing time-sensitive changes in work situations. For example, some work operations may become unavailable after normal working hours (e.g. for security reasons). An adaptive GUI user interface should detect and react to these changes by removing affected work events from the GUI display.

[0085] Some interesting aspects of the Work Time Adaptation problem are these: arbitrary numbers of time-sensitive, user-defined work events are possible; the behavior of many thingswork roles, events, operations, processesmay vary with time; and all time-sensitive adaptations may be customized for site, team, and personal use.

[0086] The Work Method Adaptation Problem (how) is another important problem that must be solved to enable the construction of adaptive user interfaces. It is the problem of modeling, managing, and adapting user interface implementation methods to fit other changes in work situations. Note that methodsthe sixth question of howare not change inputs to a work situation, but instead are change consequences.

[0087] For example, suppose a work situation provides work events to compile a program in two different ways (using two different compilers) called Compiler-A and Compiler-B. Because the two methods have two different names, they can both coexist in the same work situation; programmers can use either compiler in the same work situation. Now suppose the purpose of the work situation changes from debugging to production, thereby requiring changes in the variant work processes for Compiler-A and Compiler-B. (To be precise, the change would consist of turning off compiler debugging options, and turning on optimization options, in both compilation methods.) This example shows that the work method adaptation problem is not the same as the previous five problems: work methods must be adapted as a consequence ofnot as a cause ofother changes in work situations.

[0088] The Work Object Instance Adaptation Problem is another important problem that must be solved to enable the construction of useful adaptive user interfaces. It is the problem of adapting user interfaces in accordance with peculiar characteristics of particular work objects. Note this problem calls for adapting the interface to data contained within particular work objects, rather than to the types of particular work objects.

[0089] Some interesting aspects of the Work Object Instance Adaptation Problem are these: arbitrary numbers of work objects may be involved; arbitrary combinations of other work situation value specifiers (such as role values and time values) may be involved.

[0090] The Work Situation Focus Actions Problem is another important problem that must be solved to enable the construction of useful adaptive user interfaces. It is the problem of performing useful focus loss and focus gain actions when a GUI adapts from one work situation to another work situation. Actions performed as focus is removed from a work situation are called Focus Loss Actions. Actions performed as focus is placed on a work situation are called Focus Gain Actions.

[0091] Some interesting aspects of the Work Situation Focus Actions Problem are these: arbitrary numbers of focus gain and focus loss actions may be involved; actions can be specified in a variety of places including various full and partial situation definition files, context definition files, collection type definition files, collection specifier files, role definition files, and timeset definition files; actions may be implemented in various ways including internal GUI subroutine calls, externally spawned commands, or as more complex menu choice definitions. (Contexts are further described in the related patent applications listed at the beginning of this document.)

[0092] The Partial Situation Expansion Problem is another important problem that must be solved to enable the construction of useful adaptive user interfaces. It is the problem of how to expand a partial situation definition into a full situation definition using predefined partial situation expansion policies.

[0093] Some interesting aspects of the Partial Situation Expansion Problem are these: each partial situation policy must specify a method of calculating all major full situation values from a single partial situation change value; an arbitrary number of partial situation expansion policies may be defined; partial situations can be expanded using specific match values that cause whole named full situations to shortcut the expansion process; partial situations can be expanded using situation values that are derived from previously defined situation values; and partial situations can be expanded using situation values that are explicitly specified by partial situation policies.

[0094] The Customized Adaptation Data Problem is another important problem that must be solved to enable the construction of useful adaptive user interfaces. It is the problem of how to represent and manage all site, project, team, and individual customizations for data used by a Collection Adaptive Focus GUI.

[0095] Some interesting aspects of the Customized Adaptation Data Problem are these: arbitrary numbers of work situations and partial work situations may be customized; arbitrary numbers of site, team, project, and individual customizations may be involved; customizations can be platform dependent; customizations can be shared among GUI users; and centralized administration of shared customizations is desirable.

[0096] The Sharable Adaptation Data Problem is another important problem that must be solved to enable the construction of useful adaptive user interfaces. It is the problem of sharing user-defined adaptation data among all users and machines in a networked computing environment.

[0097] Some interesting aspects of the Sharable Adaptation Data Problem are these: arbitrary numbers of users may be involved; users may be organized into groups of related users that share the same adaptation data; individual customizations to shared group adaptation data values may also be shared; centralized administration of data sharing rules is desirable.

[0098] The Scalable Adaptation Data Storage Problem is another important problem that must be solved to enable the construction of useful adaptive user interfaces. It is the problem of how to manage large quantities of multi-platform adaptation data in a networked computing environment.

[0099] Some interesting aspects of the Scalable Adaptation Data Storage Problem are these: arbitrary quantities of adaptation data may be involved; adaptation data can be accessed by any computer on the network; groups of related adaptation data values can be identified, and can be shared among many different users and platforms; centralized administration of stored adaptation data is desirable.

[0100] As the foregoing discussion suggests, creating adaptive graphical user interfaces for multiple variant work situations is a complex problem involving six degrees of freedom. No competent general solution to the overall problem is visible in the prior art today, even though the first graphical user interfaces were created over 30 years ago.

[0101] General Shortcomings of the Prior Art

[0102] The following discussion is general in nature, and highlights the significant conceptual differences between the file-oriented, application-centered user interface mechanisms of the prior art, and the novel collection-oriented, adaptive-focus graphical user interface represented by the present invention.

[0103] Prior art approaches lack support for adaptive behavior. This is the largest limitation of all because it prevents prior art approaches from adapting to particular work situations and thereby improving human productivity.

[0104] Prior art approaches lack support for understanding multiple variant work situations. As a consequence, they cannot detect changes in work situations, and cannot adapt accordingly.

[0105] Prior art approaches lack support for adapting themselves in response to changes in user work purposes (why).

[0106] Prior art approaches lack support for adapting themselves in response to changes in user work locations (where).

[0107] Prior art approaches lack support for adapting themselves in response to changes in user work objects (what).

[0108] Prior art approaches lack support for adapting themselves in response to changes in user work roles (who).

[0109] Prior art approaches lack support for adapting themselves in response to changes in user work times (when).

[0110] Prior art approaches lack support for adapting their work methods (how) in response to changes in work roles, objects, locations, times, and purposes.

[0111] Prior art approaches lack support for customizing large numbers of work situations involving various purposes, locations, objects, roles, times, events, operations, and processes, thereby making it impossible to simultaneously serve the customization needs of human workers that each participate in multiple variant work situations.

[0112] As can be seen from the above description, prior art user interface approaches have several important limitations. Notably, they do not support adaptive behavior, multiple variant work situations, collections, or customized work situation adaptation knowledge.

[0113] In contrast, the present Collection Adaptive Focus GUI invention has none of these limitations, as the following disclosure will show.

[0114] A Collection Adaptive Focus GUI is a graphical user interface that dynamically adapts to changes in work situations, thereby providing human workers with a more productive user interface.

[0115] In operation, a Collection Adaptive Focus GUI receives work situation change events, and responds by adapting itself to new work situations, thereby providing human workers with work events, work operations, and work processes that are specifically matched to the newly changed work situation. All adaptation knowledge used by the GUI is customizable and extensible.

[0116] A Collection Adaptive Focus GUI is therefore a novel graphical user interfaceadaptive, customizable, extensible, sharable, and scalablethat enables human workers to be more productive, in ways that were not previously possible.

[0117] The main object of an Collection Adaptive Focus GUI is to provide a GUI user interface that can adapt to changes in multiple variant work situations, and thereby provide human workers with a more productive user interface.

[0118] Another object is to provide support for multiple variant work situations, thereby making it possible for humans to construct work situation representations to fit their computational needs.

[0119] Another object is to provide support for adapting the user interface to changes in user work purposes.

[0120] Another object is to provide support for adapting the user interface to changes in user work locations.

[0121] Another object is to provide support for adapting the user interface to changes in user work objects, especially where the work objects are collections.

[0122] Another object is to provide support for adapting the user interface to changes in user work roles.

[0123] Another object is to provide support for adapting the user interface to changes in user work times.

[0124] Another object is to provide support for adapting user interface work methodswork operations and processesin accordance with changes in work roles, objects, locations, times, and purposes.

[0125] Another object is to provide support for managing customized definitions of multiple variant work situations.

[0126] Another object is to provide support for managing customized definitions for work roles, objects, locations, times, and purposes.

[0127] As can be seen from the objects above, Collection Adaptive Focus GUIs can provide many benefits to human knowledge workers. Collection Adaptive Focus GUIs can help to improve human productivity by optimally adapting to changes in multiple variant work situations, in ways that were not previously possible.

[0128] Further advantages of the present Collection Adaptive Focus GUI invention will become apparent from the drawings and disclosures that follow.

[0129] FIG. 1 shows a sample prior art filesystem folder in a typical personal computer filesystem.

[0130] FIG. 2 shows how a portion of the prior art folder in FIG. 1 has been converted into a collection 100 by the addition of a collection specifier file 102 named cspec FIG. 2 Line 5.

[0131] FIG. 3 shows an example physical representation of a collection specifier 102, implemented as a simple text file such as would be used on a typical personal computer filesystem.

[0132] FIG. 4 shows four major information groupings for collections, including collection type definition 101, collection specifier 102, collection content 103, and collection 100.

[0133] FIG. 5 shows a more detailed view of the information groupings in FIG. 4, illustrating several particular kinds of per-collection-instance and per-collection-type information.

[0134] FIG. 6 shows a logical diagram of how a Collection Information Manager Means 111 would act as an interface between an application program means 110 and a collection information means 107, including collection information sources 101-103.

[0135] FIG. 7 shows a physical software embodiment of how an Application Program Means 110 would use a Collection Information Manager Means 111 to obtain collection information from various collection information API means 112-114 connected to various collection information server means 115-117.

[0136] FIG. 8 shows an example software collection datastructure that relates collection specifier and collection content information for a single collection instance.

[0137] FIG. 9 shows an example collection type definition datastructure, such as might be used by software programs that process collections.

[0138] FIG. 10 shows a more detailed example of the kinds of information found in collection type definitions.

[0139] FIG. 11 shows a simplified architecture for a Collection Adaptive Focus GUI 130.

[0140] FIG. 12 shows a simplified algorithm for a Collection Adaptive Focus GUI 130.

[0141] FIG. 13 shows a simplified architecture for a Module Adaptive Response Manager 131.

[0142] FIG. 14 shows a simplified algorithm for a Module Adaptive Response Manager 131.

[0143] FIG. 15 shows a simplified architecture for a Module Get Full Situation Change 140.

[0144] FIG. 16 shows a simplified algorithm for a a Module Get Full Situation Change 140.

[0145] FIG. 17 shows an example full situation name table Lines 1-6 and a corresponding symbolic full situation definition file Lines 7-17.

[0146] FIG. 18 shows a list of possible situation values for use in full and partial situation definition files.

[0147] FIG. 19 shows an example full situation definition file for working on a program collection and its four associated library collections.

[0148] FIG. 20 shows an example full situation definition file for working on a new HTML document.

[0149] FIG. 21 shows an example situation type name table Lines 1-4 and two situation type definition files beginning on Lines 5 and 13 respectively.

[0150] FIG. 22 shows a simplified architecture for a Module Set Full Situation Change 200.

[0151] FIG. 23 shows a simplified algorithm for a Module Set Full Situation Change 200.

[0152] FIG. 24 shows a simplified algorithm for a Module Set Search Rule Situation Changes 201.

[0153] FIG. 25 shows a simplified algorithm for a Module Set Lookup Situation Changes 210.

[0154] FIG. 26 shows an example context name table.

[0155] FIG. 27 shows an example base directory name table.

[0156] FIG. 28 shows an example role name table Lines 1-5 and two example role definition files beginning on Lines 6 and 10 respectively.

[0157] FIG. 29 shows an example timeset name table Lines 1-5 and an example timeset definition file Lines 6-26.

[0158] FIG. 30 shows examples of typical focus variables and their values.

[0159] FIG. 31 shows an example focus group name table Lines 1-14 and two example focus group definition files beginning on Lines 15 and 20 respectively.

[0160] FIG. 32 shows an example GUI layout name table Lines 1-4 and two example layout definition files beginning on Lines 5 and 11 respectively.

[0161] FIG. 33 shows an example GUI menu choice definition that uses a focus variable substitution technique to dynamically construct a shell command for later execution.

[0162] FIG. 34 shows a simplified architecture for a Module Expand Partial Situation 150.

[0163] FIG. 35 shows a simplified algorithm for a Module Expand Partial Situation 150.

[0164] FIG. 36 shows an example partial situation policy name table Lines 1-4 and an example partial situation policy definition file Lines 5-28.

[0165] FIG. 37 shows an example partial situation policy definition file that contains partial situation blocks that use specific partial situation values Lines 14-15, 23-24.

[0166] FIG. 38 shows a simplified algorithm for a Module Expand Partial Situation Role 155.

[0167] FIG. 39 shows a simplified algorithm for deriving partial situation values from the definition files of previously determined situation values.

[0168] FIG. 40 shows a simplified event data structure containing both incoming event data Lines 3-5 and expanded full situation data Lines 6-13.

[0169] FIG. 41 shows an example collection specifier that contains work situation value specifiers Lines 4-6 that override work situation values calculated using the main method of calculating work situation values.

[0170] FIG. 42 shows an example full situation definition file containing focus-gain and focus-loss action specifiers.

[0171] 100 A collection formed from a prior art folder

[0172] 101 Collection type definition information

[0173] 102 Collection specifier information

[0174] 103 Collection content information

[0175] 104 Per-collection collection processing information

[0176] 105 Per-collection collection type indicator

[0177] 106 Per-collection content link specifiers

[0178] 107 Collection information

[0179] 110 Application program means

[0180] 111 Collection information manager means

[0181] 112 Collection type definition API means

[0182] 113 Collection specifier API means

[0183] 114 Collection content API means

[0184] 115 Collection type definition server means

[0185] 116 Collection specifier server means

[0186] 117 Collection content server means

[0187] 121 Adaptive Data Storage Means

[0188] 130 Collection Adaptive Focus GUI

[0189] 131 Module adaptive response manager

[0190] 132 Module work situation focus loss manager

[0191] 140 Module get full situation change

[0192] 141 Module get situation change type

[0193] 142 Module get named full situation

[0194] 150 Module expand partial situation

[0195] 151 Module get partial situation policy

[0196] 152 Module expand partial situation context

[0197] 153 Module expand partial situation base directory

[0198] 154 Module expand partial situation collection

[0199] 155 Module expand partial situation role

[0200] 156 Module expand partial situation timeset

[0201] 200 Module set full situation change

[0202] 201 Module set search rule situation changes

[0203] 202 Module set situation context

[0204] 203 Module set situation base directory

[0205] 204 Module set situation collection

[0206] 210 Module set lookup situation changes

[0207] 211 Module set situation role

[0208] 212 Module set situation timeset

[0209] 213 Module set situation focus variables

[0210] 214 Module set situation focus variable groups

[0211] 250 Module Redisplay GUI layout

[0212] Overview of Collections

[0213] This section introduces collections and some related terminology.

[0214] Collections are sets of computer files that can be manipulated as a set, rather than as individual files. Collection are comprised of three major parts: (1) a collection specifier that contains information about a collection instance, (2) a collection type definition that contains information about how to process all collections of a particular type, and (3) optional collection content in the form of arbitrary computer files that belong to a collection.

[0215] Collection specifiers contain information about a collection instance. For example, collection specifiers may define such things as the collection type, a text summary description of the collection, collection content members, derivable output products, collection processing information such as process parallelism limits, special collection processing steps, and program option overrides for programs that manipulate collections. Collection specifiers are typically implemented as simple key-value pairs in text files or database tables.

[0216] Collection type definitions are user-defined sets of attributes that can be shared among multiple collections. In practice, collection specifiers contain collection type indicators that reference detailed collection type definitions that are externally stored and shared among all collections of a particular type. Collection type definitions typically define such things as collection types, product types, file types, action types, administrative policy preferences, and other information that is useful to application programs for understanding and processing collections.

[0217] Collection content is the set of all files and directories that are members of the collection. By convention, all files and directories recursively located within an identified set of subtrees are usually considered to be collection members. In addition, collection specifiers can contain collection content directives that add further files to the collection membership. Collection content is also called collection membership.

[0218] Collection is a term that refers to the union of a collection specifier and a set of collection content.

[0219] Collection information is a term that refers to the union of collection specifier information, collection type definition information, and collection content information.

[0220] Collection membership information describes collection content.

[0221] Collection information managers are software modules that obtain and organize collection information from collection information stores into information-rich collection data structures that are used by application programs.

[0222] Collection Physical RepresentationsMain Embodiment

[0223] FIGS. 1-3 show the physical form of a simple collection, as would be seen on a personal computer filesystem.

[0224] FIG. 1 shows an example prior art filesystem folder from a typical personal computer filesystem.

[0225] FIG. 2 shows the prior art folder of FIG. 1, but with a portion of the folder converted into a collection 100 by the addition of a collection specifier file FIG. 2 Line 5 named cspec. In this example, the collection contents 103 of collection 100 are defined by two implicit policies of a preferred implementation.

[0226] First is a policy to specify that the root directory of a collection is a directory that contains a collection specifier file. In this example, the root directory of a collection 100 is a directory named c-myhomepage FIG. 2 Line 4, which in turn contains a collection specifier file 102 named cspec FIG. 2 Line 5.

[0227] Second is a policy to specify that all files and directories in and below the root directory of a collection are part of the collection content. Therefore directory s FIG. 2 Line 6, file homepage.html FIG. 2 Line 7, and file myphoto.jpg FIG. 2 Line 8 are part of collection content 103 for said collection 100.

[0228] FIG. 3 shows an example physical representation of a collection specifier file 102, FIG. 2 Line 5, such as would be used on a typical personal computer filesystem.

[0229] Collection Information Types

[0230] FIGS. 4-5 show three main kinds of information that are managed by collections.

[0231] FIG 4 shows a high-level logical structure of three types of information managed by collections: collection processing information 101, collection specifier information 102, and collection content information 103. A logical collection 100 is comprised of a collection specifier 102 and collection content 103 together. This diagram best illustrates the logical collection information relationships that exist within a preferred filesystem implementation of collections.

[0232] FIG. 5 shows a more detailed logical structure of the same three types of information shown in FIG. 4. There is only one instance of collection type information 101 per collection type. There is only one instance of collection content information per collection instance. Collection specifier information 102 has been partitioned into collection instance processing information 104, collection-type link information 105, and collection content link information 106. FIG. 5 is intended to show several important types of information 104-106 that are contained within collection specifiers 102.

[0233] Suppose that an application program means 110 knows (a) how to obtain collection processing information 101, (b) how to obtain collection content information 103, and (c) how to relate the two with per-collection-instance information 102. It follows that application program means 110 would have sufficient knowledge to use collection processing information 101 to process said collection content 103 in useful ways.

[0234] Collection specifiers 102 are useful because they enable all per-instance, non-collection-content information to be stored in one physical location. Collection content 103 is not included in collection specifiers because collection content 103 is often large and dispersed among many files.

[0235] All per-collection-instance information, including both collection specifier 102 and collection content 103, can be grouped into a single logical collection 100 for illustrative purposes.

[0236] Collection Application Architectures

[0237] FIGS. 6-7 show example collection-enabled application program architectures.

[0238] FIG. 6 shows how a collection information manager means 111 acts as an interface between an application program means 110 and collection information means 107 that includes collection information sources 101-103. Collectively, collection information sources 101-103 are called a collection information means 107. A collection information manager means 111 represents the union of all communication mechanisms used directly or indirectly by an application program means 110 to interact with collection information sources 101-103.

[0239] FIG. 7 shows a physical software embodiment of how an application program means 110 could use a collection information manager means 111 to obtain collection information from various collection information API (Application Programming Interface) means 112-114 connected to various collection information server means 115-117.

[0240] Collection type definition API means 112 provides access to collection type information available from collection type definition server means 115. Collection specifier API means 113 provides access to collection specifier information available from collection specifier server means 116. Collection content API means 114 provides access to collection content available from collection content server means 117.

[0241] API means 112-114, although shown here as separate software components for conceptual clarity, may optionally be implemented wholly or in part within a collection information manager means 111, or within said server means 115-117, without loss of functionality.

[0242] API means 112-114 may be implemented by any functional communication mechanism known to the art, including but not limited to command line program invocations, subroutine calls, interrupts, network protocols, or file passing techniques.

[0243] Server means 115-117 may be implemented by any functional server mechanism known to the art, including but not limited to database servers, local or network file servers, HTTP web servers, FTP servers, NFS servers, or servers that use other communication protocols such as TCP/IP, etc.

[0244] Server means 115-117 may use data storage means that may be implemented by any functional storage mechanism known to the art, including but not limited to magnetic or optical disk storage, digital memory such as RAM or flash memory, network storage devices, or other computer memory devices.

[0245] Collection information manager means 111, API means 112-114, and server means 115-117 may each or all optionally reside on a separate computer to form a distributed implementation. Alternatively, if a distributed implementation is not desired, all components may be implemented on the same computer.

[0246] Collection Data Structures

[0247] FIGS. 8-10 show several major collection data structures.

[0248] FIG. 8 shows an example collection datastructure that contains collection specifier and collection content information for a collection instance. Application programs could use such a datastructure to manage collection information for a collection that is being processed.

[0249] In particular, preferred implementations would use collection datastructures to manage collection information for collections being processed. The specific information content of a collection datastructure is determined by implementation policy. However, a collection specifier typically contains at least a collection type indicator FIG. 8 Line 4 to link a collection instance to a collection type definition.

[0250] FIG. 9 shows an example collection type definition datastructure that could be used by application programs to process collections. Specific information content of a collection type definition datastructure is determined by implementation policy. However, collection type definitions typically contain information such as shown in FIGS. 9-10.

[0251] FIG. 10 shows example information content for a collection type definition datastructure such as shown in FIG. 9. FIG. 10 shows information concerning internal collection directory structures, collection content location definitions, collection content datatype definitions, collection processing definitions, and collection results processing definitions. The specific information content of a collection type definition is determined by implementation policy. If desired, more complex definitions and more complex type definition information structures can be used to represent more complex collection structures, collection contents, or collection processing requirements.

[0252] Work Situation Terminology

[0253] This section defines various terms that are used in this document.

[0254] Work situations are the unions of work purpose (why), work location (where), work object (what), work role (who), work timeset (when), work methods (how).

[0255] Work purposes (why) are represented by contexts in a Collection Knowledge System (see the related patent application at the beginning of this document).

[0256] Work locations (where) are working directories in a computer filesystem. Work locations are called base directories in this document, because they serve as a base of operations for a Collection Adaptive Focus GUI.

[0257] Work objects (what) are collections that are operated on by a Collection Adaptive Focus GUI.

[0258] Work roles (who) are sets of work operations that are made available by a Collection Adaptive Focus GUI. Roles are defined as sets of GUI operations, menu choices, buttons, and various other graphical user interface elements. Work roles allow human workers to access various sets of related work operations in a convenient, organized manner.

[0259] Work timesets are sets of time-dependent work situation values. Work timesets are means for changing work situations in particular ways at particular times. A Collection Adaptive Focus GUI adapts itself in accordance with work situation change events that are specified with timesets.

[0260] Work methods (how) are the means by which a Collection Adaptive Focus GUI carries out work operations. Typical work methods include GUI callback functions and parameterized command lines that are executed in spawned child execution processes that are outside of the main Adaptive Focus GUI thread of execution.

[0261] Work focus variables are key-value pairs that store parameter values for use in GUI work method (how) templates. Work method templates contain placeholder variable names that are replaced at runtime with values from corresponding focus variables. Focus variables allow one command template to be reused with many different variable values.

[0262] Work focus variable groups are sets of related focus variables that are managed as a single group. Usually members of a focus variable group are related by a common purpose.

[0263] Full Work Situations are work situations that are fully specifiedthat is, specific values are provided for a context (why), a base directory (where), a collection (what), a role (who), a timeset (when), and optionally, for focus variables and focus groups.

[0264] Partial Work Situations are situations that are not fully specified. One or more of the normal situation specifiersa context, a base directory, a collection, a role, or a timesetare omitted from the situation definition. Partial work situations must be expanded into full situations before they can be used to adapt a GUI to a new work situation.

[0265] Work Situation Change Events are computational signals that initiate changes to the current user work situation. For example, situation change events could be explicit requests to change to a new work situation, or to change a context, a base directory, a collection, a role, a timeset, a focus variable, or a focus variable group. Normally, change events are initiated by human working that click GUI menu choices or toolbar buttons. In contrast, time change events are initiated by the system clock, and do not require human input.

[0266] A Full Situation Change Event is an event that provides a full situation name in a work situation change event.

[0267] A Partial Situation Change Event is an event that requests a change in only one of the normal work situation specifiers (context, base directory, collection, role, timeset). Partial situation change events must be expanded into full situations before they can be used to adapt a GUI to a new work situation.

[0268] An Initial Invocation Change Event is the first change event in a user working session. When users first invoke an Adaptive Focus GUI, the GUI adapts itself according to the initial invocation change event. Typically the initial invocation change event requests the restoration of the most recently stored previous work situation, so that users can start their new session where they left off in their previous session.

[0269] A Loss Of Work Situation Focus occurs whenever a GUI adapts itself to a new work situation. A loss of focus occurs for the old work situation, and a gain of focus occurs for the new work situation.

[0270] Focus Gain Actions and Focus Loss Actions are performed when a Collection Adaptive Focus GUI changes from an old work situation to a new work situation. A Focus Loss Action is performed for the old work situation, and a Focus Gain Action is performed for the new work situation. Focus Actions can be implemented by internal function calls, external spawned commands, lists of menu choices, or by other executable computation methods known to the art.

[0271] An Adaptive Response is a set of adaptive actions executed in response to a work situation change event, to adapt a GUI to a new work situation. Adaptive actions may be internal (affecting only the GUI itself, or may be external (affecting the external runtime environment in some way, such as by manipulating files, by sending mail, or performing other actions external to the GUI program).

[0272] Adaptive Data is any data used to adapt a Collection Adaptive Focus GUI to a new work situation. Adaptive data typically includes work situation change event data, work situation data (including both full and partial situation data), GUI role and layout data, and GUI action data. Typically, adaptive data is stored in an Adaptive Data Storage Means.

[0273] An Adaptive Data Storage Means is a data storage means used to store adaptive data. Several specific means are possible, including ASCII files in a hierarchical computer filesystem, relational databases, and Collection Knowledge Systems. (For more information on Collection Knowledge Systems see the related patent applications at the beginning of this document.) Adaptive data storage means can be context-sensitive, which means that the same data query can produce different results, depending on the value of a context token provided in the query. Collection Knowledge Systems are context sensitive Adaptive Data Storage Means.

[0274] Collection Adaptive Focus GUI

[0275] A Collection Adaptive Focus GUI has four major components.

[0276] One component is a graphical user interface application framework, which provides software means for creating a particular GUI user interface. Software subroutines for constructing GUI interfaces are usually provided by the operating system.

[0277] A second component is a software means for receiving, interpreting, and adapting to work situation change events. This adaptive software component contains algorithms that distinguish a Collection Adaptive Focus GUI from other GUI applications.

[0278] A third component is a set of adaptive knowledge for specifying work situations, adaptation policies, and various corresponding GUI configurations. A store of adaptive knowledge contains custom, user-defined work situation information.

[0279] A fourth component is a storage mechanism for storing and managing adaptive knowledge information. This discussion contemplates an Adaptive Data Storage Means 121 to manage the adaptive knowledge.

[0280] The following discussion explains the overall architecture and operation of a Collection Adaptive Focus GUI.

[0281] Collection Adaptive Focus GUI Architecture

[0282] FIG. 11 shows a simplified architecture for a Collection Adaptive Focus GUI 130.

[0283] Module Adaptive Focus GUI 130 receives incoming work situation change events FIG. 40, and adapts its GUI interface in response.

[0284] Module Collection Knowledge System 121 stores adaptation knowledge in the form of policies that define how an Adaptive Focus GUI 130 should adapt to particular combinations of work situation change events.

[0285] In operation, Module Adaptive Focus GUI 130 proceeds according to the simplified algorithm shown in FIG. 12.

[0286] First, Module Adaptive Focus GUI 130 receives and interprets a work situation change event. Second, it adapts its GUI interface in accordance with adaptation policies and information stored in Collection Knowledge System 121.

[0287] Module Adaptive Response Manager

[0288] FIG. 13 shows a simplified architecture for an Adaptive Response Manager 131.

[0289] Module Adaptive Response Manager 131 oversees the interpretation of work situation change events and adaptive GUI responses that are specified by adaptation policy knowledge.

[0290] Module Work Situation Focus Loss Manager 132 performs adaptive actions in response to loss of focus on the current work situation, which is caused by incoming work situation change events.

[0291] Module Get Full Situation Change 140 interprets incoming work situation change events, and in response, produces new full work situation definitions in accordance with stored adaptation knowledge.

[0292] Module Set Full Situation Change 200 implements the required adaptive response (the new work situation) by calculating new GUI operational and display parameters (e.g. new menus, toolbars, working directories, and so on).

[0293] Module Redisplay GUI Layout 250 completes the adaptive response by displaying the new GUI layout (menus, buttons, etc) on a computer display screen.

[0294] Operation

[0295] In operation, Adaptive Response Manager 131 proceeds according to the simplified algorithm shown in FIG. 14.

[0296] First, Adaptive Response Manager 131 passes an incoming work situation change event FIG. 40 to Module Work Situation Focus Loss Manager 132, which performs useful focus loss actions required by the GUI as GUI focus is lost from the current work situation and is subsequently gained by a new work situation.

[0297] Focus loss actions such as cleanup actions or logging actions could include internal data structure manipulations, updating visible GUI labels with loss of focus indications, or saving current work situation data to external files or databases. Logging actions could include logging the change in focus, saving or logging data from the old and new work situations involved, or logging other interesting data such as the time of the change, the user involved, or other interesting information.

[0298] Next, Adaptive Response Manager 131 passes the incoming work situation change event to Module Get Full Situation Change 140 for interpretation. In response, Module Get Full Situation Change 140 produces a new full situation definition that specifies an appropriate adaptive response to the incoming change event.

[0299] Next, Adaptive Response Manager 131 passes the new full situation definition to Module Set Full Situation Change 200. This module uses the new full work situation to replace the existing GUI layout configuration with a new layout configuration, thereby adapting the GUI to the new work situation. Focus gain actions such as logging are also performed by Module Set Full Situation Change 200.

[0300] Finally, Adaptive Response Manager 131 calls Module Redisplay GUI Layout 250 to update the physical computer screen on which the Adaptive Focus GUI 130 is displayed, thereby offering human workers a new set of work events and work operations specifically chosen for the new work situation.

[0301] Module Get Full Situation Change

[0302] FIG. 15 shows a simplified architecture for Module Get Full Situation Change 140.

[0303] Module Get Full Situation Change 140 interprets incoming work situation change events, and in response, produces a new full work situation definition that describes the desired adaptive GUI response to the incoming change event.

[0304] Module Get Situation Change Type 141 determines a change event type for an incoming change event. The type value can indicate either a full work situation change event or a partial work situation change event.

[0305] Module Get Named Full Situation 142 uses incoming work situation change event data to obtain a desired target full situation name, and to return a named, full situation definition.

[0306] Module Expand Partial Situation Policy 150 uses an incoming partial work situation change event and a partial work situation policy definition to expand the partial work situation change event into a full work situation definition.

[0307] In operation, Module Get Full Situation Change 140 proceeds according to the algorithm shown in FIG. 16.

[0308] Module Get Situation Change Type 141 is called to determine if the incoming change event represents a named full work situation change event, or if it represents a partial work situation change event.

[0309] If the incoming change event is for a change to a new full situation by name, Module Get Full Situation Change 140 passes the incoming situation name to Get Named Full Situation 142 for conversion into a full work situation definition. Get Named Full Situation 142 first obtains a full situation name from the incoming change event. Next, it looks up the obtained full situation name in a situation name table, obtains a full situation definition file, and returns a corresponding full situation definition from the obtained full situation definition file.

[0310] Situation Name Table

[0311] FIG. 17 shows a situation name table Lines 1-5 and a symbolic description of a full situation definition Lines 7-17. FIG. 18 shows various possible situation values that can be used in situation definition files.

[0312] Recall that full situation definitions are comprised of the union of a context value (contexts are further described in the related patent application, Collection Knowledge System), a base directory value, a collection value, a role value, a timeset value. Optionally, multiple focus variable and focus group definitions may also be included in full situation definitions.

[0313] FIG. 17 Line 9 provides a one-line documentation string for user convenience. Line 10 defines the situation type, which is explained in a section below. Line 11 defines a situation context value, for performing data lookups in a Collection Knowledge System 121. Line 12 defines a situation base directorya working directoryfor an Adaptive Focus GUI. Line 13 defines a situation collection name to specify the default target collection of Adaptive Focus GUI commands. Line 14 defines a situation role, which specifies a particular set of work operations to be made accessible through a Collection Adaptive Focus GUI interface. Line 15 defines a situation timeset, which specifies various Adaptive Focus GUI adaptations that should be carried out at particular times.

[0314] FIG. 17 Line 16, if present, defines an optional focus variable (a key-value pair) for use in performing substitutions into Adaptive Focus GUI menu choice templates FIG. 33. At command execution time, focus variable names in work operation command templates are replaced with corresponding focus variable values, to produce executable commands. Similarly, FIG. 17 Line 17, if present, defines a group of focus variables for use in performing command substitution operations.

[0315] Situation Definitions

[0316] In operation, any module that performs a lookup operation using a name table and corresponding definition files must proceed in two steps. First, a symbolic name token is used as a lookup key into Column 1 of a name table, to obtain a definition filename from Column 2 of the name table. Second, the definition filename value is used to locate a complete definition for the original name value. Readers should realize that this sequence is specific to name tables; other data storage methods such as relational databases are possible, and would use lookup sequences that are different than the lookup sequences described here for name tables.

[0317] Returning now to the operation of Module Get Named Full Situation 142, it obtains a desired full situation name from the incoming change event, and looks up the name in Column 1 of a name table FIG. 17 Lines 1-6. Supposing that the new situation name was sit-my-program, Get Named Full Situation 142 would find a match on Line 5, and would thus obtain a definition filename of sit-my-program.def.

[0318] FIG. 19 shows a definition file sit-my-program.def for the situation named sit-my-program on FIG. 17 Line 5. This definition describes a situation for a programmer who wants to work on a main program collection and its four associated library collections. Lines 6-11 define the mandatory values for a full situation; Lines 12-17 define optional focus variables and focus groups.

[0319] As a practical example of useful adaptation, note that FIG. 19 Lines 12-17 associate specific GUI toolbar buttons with each of the program and library collections that are part of the situation. Associating collections with buttons makes it easy for programmers to switch GUI work situations among a set of collections simply by pressing toolbar buttons.

[0320] FIG. 20 shows another example situation definition file. This time, the definition file is for creating a new HTML document in a working directory where new HTML documents are created.

[0321] To complete its function in this example, Module Get Named Full Situation 142 would pass the full situation definition from FIG. 19 back to its caller, Module Get Full Situation 140.

[0322] Full Work Situations

[0323] The purpose of full work situations is to model human work circumstances. So in practice, human workers would define custom work situation definitions for each of their habitual work situations.

[0324] After defining custom work situations, human workers could easily switch among them by using GUI menus or toolbar buttons to initiate situation change events. In response, an Adaptive Focus GUI would modify visible GUI menus and toolbar buttons to support the new work situations.

[0325] Thus a Collection Adaptive Focus GUI interface can provide human workers with an optimal set of work operations for their custom work situations.

[0326] Situation Types

[0327] Situation types are a means for sharing default values among situation definition files. Sharing values is useful because it reduces knowledge maintenance costs and makes it easier to create sets of similar work situations definitions.

[0328] As one example of sharing, if a programming site has only one project to work on, then most situations will share the same base directory for the project. As second example, if a programmer always works as a programmer, and never as a manager or a documenter or web developer, then all of the relevant work situations will share the same programmer role. A third example of sharing would be a site policy that required all work situations to use a particular set of company focus variables.

[0329] FIG. 21 shows a situation type name table Lines 1-4, and two situation type definition files Lines 5-12 and Lines 13-16.

[0330] In operation, situation type definitions are used to define situation values that are not completely defined by named full situation definitions. For example, consider the named situation definition described eariler in FIG. 19, sit-my-program.def. FIG. 19 Line 11 defines the value st-default for the situation timeset. The value st-default means that a corresponding shared value from a situation type must be used as the actual timeset value.

[0331] Continuing, Get Named Full Situation 142 reads FIG. 19 Line 11, obtains the value st-default from Column 2, and recognizes that the st-default value must be replaced with a value from a situation type definition.

[0332] Get Named Full Situation 142 continues by using the situation type value st-default FIG. 19 Line 11 as a lookup key into a situation type name table FIG. 21 Line 3. Column 2 provides the definition filename st-default.def, which is shown by FIG. 21 Lines 5-12. Finally, Get Named Full Situation 142 looks up the type definition timeset value FIG. 21 Line 10, and obtains the desired timeset value ts-company to use in the original situation definition file FIG. 19 Line 11.

[0333] Situation types make it possible for sites to share common values among all situation definitions at a site; they also reduce knowledge maintenance costs because only one copy of each shared situation type value must be maintained.

[0334] Module Set Full Situation

[0335] FIG. 22 shows a simplified architecture for Module Set Full Situation Change 200.

[0336] Module Set Search Rule Situation Changes 201 implements situation change values that affect search rules formulated by an underlying Collection Knowledge System 121.

[0337] Module Set Situation Context 202 implements a new situation context by changing the internal context value that is used by a Collection Adaptive Focus GUI to perform knowledge lookups in an underlying Collection Knowledge System 121.

[0338] Module Set Situation Base Directory 203 implements a new situation base directory by changing the current working directory of a Collection Adaptive Focus GUI.

[0339] Module Set Situation Collection 204 implements a new situation collection by changing the current internal collection name used by a Collection Adaptive Focus GUI, thereby making the new collection the default target of GUI commands and work operations.

[0340] Module Set Lookup Situation Changes 210 implements situation changes that use lookups to obtain new situation values. In general, these kinds of situation changes use situation change values as lookup keys into a Collection Knowledge System 121, in order to obtain additional information for adapting a GUI to a new situation.

[0341] Module Set Situation Role 211 implements a new situation role value by changing the current internal role value, and by performing a lookup on the new role name to obtain further role information from a role definition file.

[0342] Module Set Situation Timeset 212 implements a new situation timeset by changing the current internal timeset value, and by performing a lookup on the new timeset name to obtain further timeset information from a timeset definition file.

[0343] Module Set Situation Focus Variables 213 implements focus variable settings for a new situation by defining new focus variable names and values, or by overwriting old values for known focus variable names.

[0344] Module Set Situation Focus Groups 214 implements focus variable group settings for a new situation by defining new groups of focus variable names and values, or by overwriting old values for known focus variable names. Focus variable groups are named groups of focus variables that have been grouped together for user convenience.

[0345] Operation

[0346] In operation, Module Set Full Situation Change 200 proceeds according to the algorithms shown in FIG. 23 to FIG. 25.

[0347] First, Module Set Full Situation Change 200 calls Module Set Search Rule Situation Changes 201 to implement new situation changes that affect the search rules used by an underlying Collection Knowledge System 121. Module Set Search Rule Situation Changes 201 proceeds according to the algorithm shown in FIG. 24.

[0348] Module Set Situation Context 202 uses the incoming context name as a lookup key into Column 1 of a context name table FIG. 26, to ensure that the incoming context name is valid. If a match is found, the incoming context name is stored in an internal GUI variable. If no match is found, the incoming context name is invalid, and is rejected.

[0349] Module Set Situation Base Directory 203 uses the incoming base directory token as a lookup key into Column 1 of a base directory name table FIG. 27. If a match is found, the corresponding physical filesystem directory from Column 2 is used as the new physical base directory. If no match is found, the incoming base directory token is treated as a physical directory pathname. Module Set Situation Base Directory 203 completes its function by making an operating system subroutine call to change the current working directory of the GUI.

[0350] Module Set Situation Collection 204 inspects the current base directory for a collection name that matches the incoming collection name. If a match is found, the incoming collection name is stored in an internal GUI variable. If no match is found, the incoming value is rejected.

[0351] Second, Set Full Situation Change 200 calls Module Set Lookup Situation Changes 210 to oversee implementation of the remaining new situation changes. Module Set Lookup Situation Changes 210 proceeds according to the algorithm shown in FIG. 25.

[0352] Module Set Situation Role 211 uses the incoming role name as a key to perform a lookup in a role name table FIG. 28 Lines 1-5. If a match is found, the incoming role name is stored in an internal GUI variable; otherwise the incoming role name is rejected. In addition, data from a corresponding role definition file such as FIG. 28 Lines 6-9 or FIG. 28 Lines 10-14 is loaded into the GUI for further use in adapting the GUI to the new situation. In particular, role definitions specify GUI layouts FIG. 28 Lines 7, 11 that are used to adapt the GUI to the incoming situation.

[0353] Module Set Situation Timeset 212 uses the incoming timeset name as a key to perform a lookup in a timeset name table FIG. 29 Lines 1-5. If a match is found, the incoming timeset name is stored in an internal GUI variable; otherwise it is rejected. In addition, data from a corresponding timeset definition file such as FIG. 29 Lines 6-26 is loaded into the GUI for further use in adapting the GUI to the new situation.

[0354] Module Set Situation Focus Variables 213 uses incoming focus variable names and values to set the values of internal focus variables within the GUI. FIG. 30 shows examples of some typical focus variables and their values. User-defined focus variables are possible; users can define whatever focus variables they need in order to support user-defined GUI command templates.

[0355] FIG. 33 shows an example GUI menu choice definition that uses a focus variable substitution technique to dynamically construct an operating system shell command for later execution. In operation, when a menu choice is selected by a user, a Collection Adaptive Focus GUI substitutes the value of focus variables into command line templates such as shown in FIG. 33 Line 7, thereby forming a valid command line that can be executed to fulfill the function of the menu choice. FIG. 33 Line 7 specifies that the value of a focus variable named filename be substituted into the template in place of the filename placeholder string.

[0356] Module Set Situation Focus Groups 214 uses incoming focus group names as keys to perform lookups in a focus group name table FIG. 31 Lines 1-14. For each focus group name that is found, a corresponding focus group definition file such as FIG. 31 Lines 15-19 or Lines 20-25 is used to set focus variables and values.

[0357] This completes the description of how new situations are set by Module Set Full Situation Change 200. Discussion continues with an explanation of how new situation values are used to update the display of a Collection Adaptive Focus GUI.

[0358] Module Redisplay GUI Layout

[0359] After a new set of situation values has been set in place by Module Set Full Situation Change 200, Module Adaptive Response Manager 131 completes the GUI adaptation process by calling Module Redisplay GUI Layout 250 to update the GUI display layout. A GUI layout defines a set of menus, toolbars, and other GUI functions to be made available to users through a Collection Adaptive Focus GUI.

[0360] FIG. 32 shows a layout name table Lines 1-4 and an example layout definition file FIG. 32 Lines 5-10, and Lines 11-17.

[0361] Operation

[0362] In operation, Module Redisplay GUI Layout 250 obtains the name of a layout from a role definition file. For example, FIG. 28 Line 7 specifies that a layout named layout-manager be used for the manager role named on FIG. 28 Line 4 of the role name table.

[0363] Continuing, Module Redisplay GUI Layout 250 uses the layout name layout-manageras a key into Column 1 of a layout name table such as shown in FIG. 32. A key match occurs on FIG. 32 Line 4 in the layout name table, which specifies that a file named layout-manager.def is the layout definition file FIG. 32 Lines 11-17 for the layout-manager layout name. FIG. 32 Lines 14-17 in the layout definition specify the menubar and toolbars that comprise the layout.

[0364] Module Redisplay GUI Layout 250 reads information from the layout definition, dynamically constructs a new GUI layout, and updates the computer display screen with a corresponding new GUI layout. Details of constructing menus and toolbars are well described in the prior art, and so are not explained here.

[0365] This concludes the explanation of how a Collection Adaptive Focus GUI reacts to incoming full situation change events. Discussion now continues with partial situation change events. The main thing to remember about partial situation change events is that the main goal is to expand them into full situation descriptions; then they are treated identically to the full situations that were described above.

[0366] Partial Situation Changes

[0367] A Partial Situation Change Event is an event that requests a change in only one of the normal work situation specifiers. For example, a GUI user might want to change only the base directory, or only the collection, or only the role within a current work situation.

[0368] The main problem posed by partial situation change events is to determine which GUI adaptations should be made in response to the partial change event. The essential problem is determining how to calculate a full situation change event from a partial situation change event, according to local policies for performing such transformations.

[0369] Once a full situation change has been calculated, it is implemented identically to the full work situations that were described previously.

[0370] Partial Situation Policies are policies that describe how to expand a partial situation change event into a full situation change event. Partial situation policies are implemented by situation policy name tables FIG. 36 Lines 1-4 and situation policy definition files FIG. 36 Lines 5-28 that describe user-defined expansions.

[0371] Partial Situation Policy Definitions

[0372] FIG. 36 shows a partial situation policy name table Lines 1-4, and an example partial situation policy definition file Lines 5-28.

[0373] FIG. 36 Line 7 specifies a line of text that describes the policy. Line 8 specifies a situation type that can be used to fill in default situation values, as described previously. Lines 10, 21, 23, 25, and 27 are the starting lines of partial situation blocks.

[0374] Partial Situation Blocks are contained within partial situation policy definition files. A 1-to-1 association exists between partial situation blocks and major situation values. There are five major valuescontext, base directory, collection, role, timesetso there are five partial situation blocks in a situation policy definition file. For each kind of incoming partial situation change event, an corresponding partial situation block is used to expand the partial event into a full situation.

[0375] For example, FIG. 36 Line 10 Column 2 contains the token context, so the block beginning on Line 10 specifies expansion policies for partial situation context change events. Similarly, the Line 21 block specifies information for base directory changes, the Line 23 block for collection changes, the Line 25 block for role changes, and the Line 27 block for timeset changes.

[0376] Most of the lines in partial situation blocks are identical to lines used in full situation definitions. For example, the partial situation block FIG. 36 Lines 11-17 are the same as the full situation lines in FIG. 17 Lines 11-17.

[0377] Only one special line is not the same. FIG. 36 Line 18 installs a named full situation if specific matching values of partial changes are detected; this specific mechanism will be described in a later section below.

[0378] There are three methods of expanding partial situations into full situations: using specific partial situation values, using normal partial situation values, and using derived situation values. Expansion using specific values is the simplest method, so it will be discussed first.

[0379] Expansion Using Specific Values

[0380] Expansion using specific values is a convenient mechanism for associating an incoming change valuesuch as a specific base directory or collectionwith a previously defined, named, full situation. Making these associations is a useful thing to do because it promotes reuse of existing full situation definitions.

[0381] For example, suppose that all users require the role-manager GUI role whenever they work in a particular filesystem directory called manager-info. Then it would make sense to define a partial situation policy to implement this behavior. That is, whenever GUI users changed into the special base directory manager-info, a Collection Adaptive Focus GUI would switch to the GUI role-manager role.

[0382] FIG. 36 Line 18 shows how a specific context value can be associated with a full situation name. Column 1 contains the token spec-value, which stands for specific value. Column 2 is the specific value to match. Column 3 is a full situation name that can be found in a full situation name table FIG. 17.

[0383] FIG. 37 shows several examples of specific value matches for base directories Lines 14-15 and roles Lines 23-24. As one example, FIG. 37 Line 14 specifies that whenever an incoming partial situation change calls for changing to directory c:manager-info, the partial situation change should be immediately expanded to the full situation named sit-manager named in FIG. 17 Line 6. As a second example, FIG. 37 Line 24 specifies that whenever an incoming partial situation change calls for changing the role to role-manager, the partial situation change should be immediately expanded to the full situation named sit-manager FIG. 17 Line 6.

[0384] Expansion Using Normal Values

[0385] A second way of expanding partial situations is to create a new full situation by assembling individual situation values, one by one.

[0386] During normal expansion, one value is always knownthe incoming change value that triggered the partial situation change. The other four values required to create a full situation must be determined using an appropriate partial situation block such as shown in FIG. 36 Lines 10-19.

[0387] In operation, a full situation is created by augmenting the incoming partial situation value with other values obtained from the partial situation block associated with the incoming partial situation value. As can be seen from FIG. 36 Lines 11-17, the format of a partial situation block is identical to that of full situation definitions as shown in FIG. 17 Lines 11-17.

[0388] Full situations are constructed identically in both cases, with the exception that partial situation expansion obtains one value from the incoming partial situation change event. In contrast, all situation values are defined by full situation definition files such as shown in FIG. 17 Lines 7-17.

[0389] FIG. 18 shows a table of possible situation values that can appear in partial situation blocks and in full situation definitions.

[0390] Expansion Using Derived Values

[0391] The main idea behind derived values is to automatically determine some situation values from previously set situation values. Derived situation values are a mechanism for creating chains of related situation values.

[0392] For example, suppose that it was desirable to set a role-manager situation role value whenever users worked on a collection of type manager-info. Then it would make sense to define a partial situation expansion policy that derived a role value role-manager from a collection type value of manager-info.

[0393] FIG. 39 shows a simplified algorithm for deriving various situation values from other situation values. In general, a derived situation value is obtained from a type definition file associated with a previously set situation value.

[0394] For example, suppose a timeset definition required that a particular context value and a particular role be set into place at a particular time (0900 hours). FIG. 29 Lines 11-12 show how such a policy goal could be achieved. Specifying derived values for other situation values is achieved in a similar way.

[0395] Timeset definition files can specify derived context, basedir, collection, role, focus variable, and focus group values. Collection type definition files can specify derived role, focus variable, and focus group values. Role definition files can specify derived focus variable and focus group values. Context, base directory, focus variable, and focus group values are not used to derive other situation values, because they currently have no definition or type definition files in which to store derived value information. Implementing definition files for these situation values would remove the limitation.

[0396] This concludes the description of how partial situations are expanded into full situations. Discussion now continues with the operation of the expansion process.

[0397] Module Expand Partial Situation

[0398] Module Expand Partial Situation 150 is called by Module Get Full Situation Change 140 if the incoming change event represents a partial work situation change event, and not a change to a named full situation. In such a case, the incoming partial work situation change event must be expanded into a full situation definition by Module Expand Partial Situation 150.

[0399] FIG. 34 shows a simplified architecture for Module Expand Partial Situation 150.

[0400] Module Get Partial Situation Policy 151 first obtains the current partial situation policy by looking up the current partial situation policy name in a situation policy name table FIG. 36 Lines 1-4 to obtain a partial situation policy definition file FIG. 36 Lines 5-28.

[0401] The current partial situation policy name is a configuration attribute of a Collection Adaptable Focus GUI, and is normally read from an initialization file containing initial configuration options at GUI invocation time. Changing the current partial situation policy name is possible; the new policy name replaces the old policy name in internal GUI variables, and may be saved in a current preferences file.

[0402] Module Expand Partial Situation Context 152 calculates a new full situation from an incoming context value.

[0403] Module Expand Partial Situation Base Directory 153 calculates a new full situation from an incoming base directory value.

[0404] Module Expand Partial Situation Collection 154 determines a new full situation from an incoming collection value.

[0405] Module Expand Partial Situation Role 155 calculates a new full situation from an incoming role value.

[0406] Module Expand Partial Situation Timeset 156 determines a new full situation from an incoming timeset value.

[0407] Each of the expansion modules 152-156 can use one of the three expansion techniques that are described below: specific value expansion, normal value expansion, or derived value expansion.

[0408] Operation

[0409] In operation, Module Expand Partial Situation 150 proceeds according to the algorithm shown in FIG. 35.

[0410] First, Module Expand Partial Situation 150 calls Module Get Partial Situation Policy 151 to obtain a policy definition file for expanding the incoming partial situation change event into a full situation.

[0411] Module Get Partial Situation Policy 151 obtains the current partial situation policy name from the GUI runtime environment using a prior art mechanism such as a configuration file, an environment variable, or a user-defined GUI variable.

[0412] Next, the module looks up the current partial situation policy name in a partial situation policy name table, to obtain a partial situation policy definition file such as shown in FIG. 36 Lines 5-28.

[0413] Next, the module selects a partial situation block to match the incoming type of change (context, base directory, collection, role, timeset). For example, using the partial situation blocks shown in FIG. 36, the block beginning at Line 10 would be selected for incoming context changes, the block at Line 21 for base directory changes, and so on. The selected block is passed back to the calling module Expand Partial Situation 150 for further use.

[0414] Continuing, Module Expand Partial Situation 150 now calls a corresponding subordinate module to expand the incoming partial change into a full situation change. To perform the expansion, the called subordinate module uses the partial situation policy block that was previously selected by Module Get Partial Situation Policy 151.

[0415] Module Expand Partial Situation Context 151 receives an incoming context value, and uses a partial situation block such as the one starting on FIG. 36 Line 10 to calculate and return a new full situation.

[0416] Module Expand Partial Situation Base Directory 152 receives an incoming base directory value, and uses a partial situation block such as the one starting on FIG. 36 Line 21 to calculate and return a new full situation.

[0417] Module Expand Partial Situation Collection 153 receives an incoming collection value, and uses a partial situation block such as the one starting on FIG. 36 Line 23 to calculate and return a new full situation.

[0418] Module Expand Partial Situation Role 154 receives an incoming role value, and uses a partial situation block such as the one starting on FIG. 36 Line 25 to calculate and return a new full situation.

[0419] Module Expand Partial Situation Timeset 155 receives an incoming timeset value, and uses a partial situation block such as the one starting on FIG. 36 Line 27 to calculate and return a new full situation.

[0420] Finally, Module Expand Partial Situation 150 receives the expanded partial work situation (now a full work situation definition), and passes it to Module Get Full Situation Change 140 for further use in adapting the GUI to the new work situation.

[0421] Situation Overrides Using Work Object Data

[0422] In addition to calculating work situation values from full situation definitions or from partial situation policies and partial situation change events, work situations can also be influenced by work situation values contained within work objects.

[0423] For example, FIG. 41 shows an example collection specifier that contains work situation value specifiers Lines 4-6 identical to those found in full situation definitions such as shown in FIG. 17.

[0424] Work situation value specifiers found inside specific collection specifier files FIG. 41 Lines 4-6 override work situation values obtained from other sources such as role, timeset, and focus variable definition files. This override convention provides users with a convenient means of asserting particular custom situation values for particular collections.

[0425] Without the ability to specify particular work situation values within a collection specifier 102, human workers are limited to using the work situation values that are normally calculated from collection type definition files.

[0426] Actions on Focus Gain or Loss

[0427] The main idea of focus gain and focus loss actions is to provide a means for specifying and executing useful actions at work situation tear down (focus loss) and set up (focus gain) times. For example, a GUI could send out time-stamped log events whenever a work situation lost or gained focus. From the log entries, statistics could be calculated on work situation usage, on the average time that work situations held focus, and so on.

[0428] FIG. 42 shows an example full situation definition file that specifies focus gain and focus loss actions. In particular, FIG. 42 Lines 10-15 specify lists of actions to be executed when focus on the FIG. 42 situation definition is gained or lost by a Collection Adaptive Focus GUI.

[0429] For example, the menu choice implementation c-rep-checkout-lock described in FIG. 33 could be specified as a focus gain action FIG. 42 Line 12 to be executed whenever the GUI changes to the sit-my-program.def work situation defined in FIG. 42.

[0430] Focus gain and focus loss actions can also be specified in situation type definitions, partial work situation policy definitions, in context definition files, in role definition files, in collection specifier files, and in timeset definition files.

[0431] For example, focus gain actions stored in collection specifier files could be executed when a GUI focused on the host collection, and focus-loss actions could be executed when a GUI changed from the collection to a new collection.

[0432] Further Advantages

[0433] As can be seen from the foregoing discussion, a Collection Adaptive Focus GUI can adapt itself to changes among multiple variant work situations. In particular, the Collection Adaptive Focus GUI invention described here is capable of responding to events that involve changes in purpose (why, context), location (where, base directory), work object (what, collection), work role (who, role), and chronological time (when, timeset). Thus a Collection Adaptive Focus GUI provides a practical and useful means for adapting and optimizing graphical user interfaces to changes in multiple variant work situations, a capability that was not previously known to the prior art.

[0434] Conclusion

[0435] The present Collection Adaptive Focus GUI invention provides practical solutions to thirteen important problems faced by builders of adaptive graphical user interfaces. The problems are these: (1) the overall Adaptive Focus GUI problem, (2) the Work Purpose Adaptation problem, (3) the Work Location Adaptation problem, (4) the Work Object Type Adaptation problem, (5) the Work Role Adaptation problem, (6) the Work Time Adaptation Problem, (7) the Work Method Adaptation Problem, (8) the Work Object Instance Adaptation Problem, (9) the Work Situation Focus Actions Problem, (10) the Partial Situation Expansion Problem, (11) the Customized Adaptation Data Problem, (12) the Sharable Adaptation Data Problem, and (13) the Scalable Adaptation Data Storage Problem.

[0436] As can be seen from the foregoing disclosure, the present Collection Adaptive Focus GUI invention provides human users with a practical means for precisely adapting their graphical user interfaces to specific work situations, using adaptation representations, models, and methods that were not previously available.

[0437] Ramifications

[0438] Although the foregoing descriptions are specific, they should be considered as example embodiments of the invention, and not as limitations. Those skilled in the art will understand that many other possible ramifications can be imagined without departing from the spirit and scope of the present invention.

[0439] General Software Ramifications

[0440] The foregoing disclosure has recited particular combinations of program architecture, data structures, and algorithms to describe preferred embodiments. However, those of ordinary skill in the software art can appreciate that many other equivalent software embodiments are possible within the teachings of the present invention.

[0441] As one example, data structures have been described here as coherent single data structures for convenience of presentation. But information could also be could be spread across a different set of coherent data structures, or could be split into a plurality of smaller data structures for implementation convenience, without loss of purpose or functionality.

[0442] As a second example, particular software architectures have been presented here to more strongly associate primary algorithmic functions with primary modules in the software architectures. However, because software is so flexible, many different associations of algorithmic functionality and module architecture are also possible, without loss of purpose or technical capability. At the under-modularized extreme, all algorithmic functionality could be contained in one software module. At the over-modularized extreme, each tiny algorithmic function could be contained in a separate software module.

[0443] As a third example, particular simplified algorithms have been presented here to generally describe the primary algorithmic functions and operations of the invention. However, those skilled in the software art know that other equivalent algorithms are also easily possible. For example, if independent data items are being processed, the algorithmic order of nested loops can be changed, the order of functionally treating items can be changed, and so on.

[0444] Those skilled in the software art can appreciate that architectural, algorithmic, and resource tradeoffs are ubiquitous in the software art, and are typically resolved by particular implementation choices made for particular reasons that are important for each implementation at the time of its construction. The architectures, algorithms, and data structures presented above comprise one such conceptual implementation, which was chosen to emphasize conceptual clarity.

[0445] From the above, it can be seen that there are many possible equivalent implementations of almost any software architecture or algorithm. Thus when considering algorithmic and functional equivalence, the essential inputs, outputs, associations, and applications of information that truly characterize an algorithm should be considered. These characteristics are much more fundamental to a software invention than are flexible architectures, simplified algorithms, or particular organizations of data structures.

[0446] Practical Applications

[0447] An Adaptive Focus GUI can be used in various practical applications.

[0448] One possible application is to improve the productivity of human knowledge workers, by providing them with a practical means for accessing work operations that are well-adapted to particular work situations that involve collections, spreadsheets, word processing documents, databases, web documents, or other project-file oriented applications.

[0449] Another application is to improve the usability of modern GUI interfaces by reducing the total number of visible GUI controls to an optimal set that is well-adapted to the current work situation.

[0450] Another application is to centralize the administration of work situation information within a community of users. One central store of full situation definitions, partial situation policies, and other adaptive knowledge can be accessed by many users through use of Adaptive Focus GUIs. This strategy shifts the burden of understanding and maintaining the knowledge from the many to the few.

[0451] Work Situation Change Events

[0452] The foregoing disclosure described change events as being initiated by humans using GUI controls such as menus or toolbar buttons, or by timeset events initiated by the system clock. However, other event sources and event restrictions are also possible.

[0453] Work situation change events can be generated and sent by other programs to an Adaptive Focus GUI. For example, a program that completes a processing action that is being monitored by an adaptive GUI could send a completion event to the GUI. In response, the adaptive GUI could provide users with a visual indication of program completion.

[0454] Work situation change events can also be restricted to be simpler than the full set of events described previously. For example, a simpler Adaptive Focus GUI could disallow events of one or more types, such as timeset events, or context events. This would simplify GUI implementation, at the cost of reduced functionality.

[0455] Situation Specifier Values

[0456] The foregoing discussion identified several possible sources of work situation value specifiers: full work situation definitions, partial work situation policies, three means of partial situation expansion, and work situation value specifiers contained within collection specifier instances FIG. 41 Lines 4-6.

[0457] However, other sources of value specifiers may also be used. For example, a GUI could obtain value specifiers by querying an external database or by communicating with a situation value server over a network.

[0458] Adaptive Knowledge Stores

[0459] The foregoing discussion identified an Adaptive Data Storage Means 121 as a preferred means for storing adaptation knowledge used by an Adaptive Focus GUI. However, other storage means are also possible.

[0460] For example, a relational database might be used to advantage, especially where large amounts of well-structured adaptive knowledge must be stored. As another example, a network adaptive knowledge server could provide adaptive knowledge to Collection Adaptive Focus GUIs, using a client-server protocol means. As a third example, adaptive knowledge might be stored and provided to GUIs using an XML markup language representation and a web server protocol such as HTTP.

[0461] Another important implementation of an Adaptive Data Storage Means 121 is a Collection Knowledge System, which contains internal knowledge search rules and client/server mechanisms useful for customization, sharing, and scalability. For more detailed information on Collection Knowledge Systems, see the related patent application Collection Knowledge System listed at the beginning of this document.

[0462] As can be seen by one of ordinary skill in the art, many other ramifications are also possible within the teachings of this invention.

[0463] Scope

[0464] The full scope of the present invention should be determined by the accompanying claims and their legal equivalents, rather than from the examples given in the specification.