Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/10—Office automation; Time management
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/954—Navigation, e.g. using categorised browsing
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
  • G06F16/972—Access to data in other repository systems, e.g. legacy data or dynamic Web page generation
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

• Portal computing systems combine disparate resources into an integrated interface. Users interact with the resources via user interface elements on portal pages, which may be embodied in web browser windows. Portal systems allow a user to view and interact with information and tools from a wide variety of sources such as word processing programs, spreadsheet programs, databases, and other sources.
• portal computing systems can improve workflow by allowing workers to more easily access resources and information needed to perform their jobs. For example, role- based portal systems strive to improve workflow by providing user interfaces that allow a worker with a particular job role to access data and resources usually associated with the particular job role.
• a role-based portal system may provide a number of pre-defined roles, where the included resources and information represent the developer's "best guess" of the resources needed to perform each particular job role.
• an executive role may include resources that enable the user to access company- wide strategic information such as competitive analyses and profitability forecasts.
• a manager role may include resources for project management and/or people management.
• a developer role may include software development tools.
• role-based portal systems may not accurately reflect the particular work goals of particular users. For example, two different managers may have different responsibilities associated with particular work goals, and so need to access a different set of resources and information. A single pre-defined role cannot typically meet the needs
• a role-based system may include a product manager role, a sales manager role, an engineering manager role, and so on.
• a data object includes task data for performing a work role, portal environment data to present information to a user via a portal, and meta-data descriptive of the work role.
• the task data may include data associated with one or more application programs, documents, and/or life and work events for performing the work role.
• the portal environment data may include navigation data, view data, and page data for performing the work role.
• the view data may include Iview data.
• the meta-data may include community data, collaboration data, context data, workset description data, job role data, subscription data, taxonomy data, user data, and search domain data.
• the meta-data may include data for populating a generic portal page with content.
• the data object may be assigned to a user profile for a portal user. At least some meta-data from the data object may be copied to the user profile. The copied meta- data may be used to personalize the user's portal environment. Personalization may include, e.g., activating a subscription for the user, activating a membership in a community for the user, and/or displaying personalized information to the user.
• the data object may be created as a result of obtaining employee work practice information, grouping the employee work practice information according to work role, and creating the data object to include task data for performing the work role. Creating the data object may also include associating meta-data with the data object and/or associating portal environment data with the data object.
• At least some meta-data may be assigned to the data object from a job role or user profile.
• One or more overview pages may be provided for the data object.
• the data object may be assigned to one or more user profiles. At least some meta-data from the data object may be transported to the user profile.
• a user interface includes a search area for searching for workset information, a work area for viewing workset information (e.g., one or more services associated with a particular workset), and an assignment area for assigning workset data to a user.
• the work area may facilitate modifying workset information.
• the work area may include a workset detail area.
• one or more data objects ' directed to particular work goals may be generated.
• the data objects may be assigned to user profiles associated with users having the work goal.
• Each of the data objects may be used to generate a portal page including content for achieving the work goal.
• the portal page may include an integrated view.
• Each of the data objects may include task data for achieving the particular work goal, and generated portal pages may include user interface elements associated with the task data.
• a first portal page may be displayed to a portal user, where the first portal page includes user interface elements for accessing content related to a plurality of work roles.
• the first portal page may include overview information for one or more of the particular work roles.
• the first portal page may include user interface elements for accessing one or more generic portal pages.
• a second portal page may be displayed in response to selection of a user interface element associated with a particular work role, where the second portal page includes user interface elements associated with the particular work role.
• the second portal page may include overview information for the particular work role, user interface elements for performing tasks associated with the particular work role, and/or status information associated with the particular work role.
• a workset-based portal system may increase employees' efficiency by integrating needed resources according to particular work intents and related work goals.
• Worksets may be used to provide specified content to users, where the content is related to the work goal of the workset. Once a set of worksets has been developed, they may be used to design workspaces for other employees (such as new hires) based on the expected employee responsibility.
• FIG. 1 illustrates the semantic structure of a workset-based portal system.
• FIG. 2 shows a two-level tab structure for accessing worksets, generic portal pages, and associated tasks.
• FIG. 3 is a flow chart showing a process for developing content for a workset- based portal system.
• FIG. 4 illustrates clustering content into worksets for presentation on workspaces.
• FIG. 5 shows worksets and associated tasks for a user with a job role of sales manager.
• FIG. 6 is a representation of a workspace page for a user with a job role of sales manager.
• FIG. 7 is a representation of a monitor task page for a budget workset.
• FIG. 8 is a representation of a home page and an associated login task.
• FIG. 9 is a representation of a workset development page.
• FIGS. 10A and 10B are representations of different workspace pages, each having a task linked to a collaborative space.
• FIG. 11 is an alternate representation of a workspace page for a user with a role of sales manager.
• FIG. 12 is a block diagram illustrating an example data processing system.
• FIG. 13 is a block diagram illustrating an example workset-based portal system.
• Like reference symbols in the various drawings indicate like elements.
• Workflow refers to the tasks that an employee performs, as well as the manner in which the tasks are performed.
• workflow includes accessing one or more application programs via the employee's computer, providing data for the one or more applications programs, and processing data.
• a sales manager may access one or more competitor web sites using an Internet browser, view a display including product data such as price, and store and/or process competitor product data using another application program such as a spreadsheet program.
• Workflow is efficient when a user can access needed information and resources with minimal effort. Workflow is inefficient when a user must spend time finding and/or switching among particular information and resources.
• Portal systems may improve a user's ability to access information and resources.
• role-based portal systems that seek to present standardized sets of tasks for particular roles are generally not flexible enough to accurately model a user's actual work intent, and thus do not provide optimally efficient workflow for a user.
• the following terms are used to describe various aspects of the current disclosure:
• Job role refers to a user's job title. Manager, engineer, and administrator are examples of job roles.
• Work role refers to a coherent set of tasks and responsibilities directed to achieving a particular work goal.
• Work intent refers to a user's intent in performing one or more tasks. For example, a user's work intent may be to develop a budget.
• Work goal refers to the goal associated with the user's work intent. For example, if the user's work intent is to develop a budget, the work goal may be a completed budget.
• Workset refers to one or more data objects including content for achieving a particular work goal or small set of work goals.
• the workset may include content such as a budget spreadsheet program, as well as the portal environment for presenting content to the user.
• Worksets may include additional elements, as described below.
• Task refers to an item of portal content assigned to a workset. Tasks may be associated with other tasks; for example, a first-level task may be associated with one or more second-level tasks, which may in turn be associated with third-level tasks.
• the present techniques and systems provide workset-based portal systems to enable more efficient workflow. Workset-based portal systems present a user with workspaces that are targeted to the user's specific work intents and/or dominant activities, rather than providing a comprehensive list of tasks for a particular job role. In a workset- based portal system, a workspace is a portal page or part of a portal page supporting a coherent set of tasks.
• a workset-based portal system is based on the recognition that a user with a particular job role performs a number of different work roles, where each work role consists of a number of tasks directed at achieving a particular work goal.
• a sales manager job role
• job role may perform various different work roles related to budgeting, team leading, key account management, promotion management, and market watching.
• Each of the work roles involves performing one or more tasks.
• a workset is developed for each work role.
• the workset includes the tasks and corresponding portal environment for performing the particular work role, which may be bundled into one manageable data object.
• the workset thus reflects the user's work intent rather than stereotypical job titles, standard business objects, or business processes.
• each workset defines a complete working environment for a given work role using a hybrid collection of elements including tools, information, communication and collaboration features, and user interface requirements. These elements may include a navigation structure; visual components such as views
• Iviews or “integrated views” referring to a basic unit of portal content that can be used to display information or interact with the portal user
• pages information and application services
• work artifacts such as business objects, procedures, interest profiles, and subscription rules
• a workset may include data related to some or all of the following elements: communities (communities that associated users may want to participate in), context information (information about attributes associated with the workset; for example, attributes that users associated with the workset typically would have), description (brief description of the work intent/work goal of the workset), information/resource collection (one or more bodies of information that associated users may use as resources for achieving the work goal), name (a human-understandable name for the workset), job roles (job roles typically associated with the workset; when a job role is assigned to a particular user, he may be associated with all worksets typically associated with the job role), subscriptions (e.g., a list of resource objects the user may want to subscribe to), navigation structure (the navigation structure provided by the workset, to be combined with other navigation structures including those provided by any other assigned worksets to produce a navigation structure for the particular workset-based portal user), taxonomies (e.g. particular classifications the user may be interested in), and users (users associated with the workset;
• a workset may include pre-defined search domains.
• the search would include the pre-defined search domains.
• the user may be provided with a choice of search domains.
• Some portal-based systems provide tasks organized in life and work events, where the life and work events model a work sequence; for example, according to best practices.
• a life and work event portal system is described in pending U.S. Patent Application Serial Number 10/137,212, filed April 30, 2002, entitled “Processing Life and Work Events," inventors Botscheck et al., which is incorporated by reference in its entirety.
• a workset may include such a work sequence.
• Worksets may include meta-data that may be used for personalization of portal content for the particular user.
• worksets may include meta-data chosen from a corporate taxonomy of interests.
• a product support engineer may be assigned a customer feedback workset including tasks related to customer feedback for a particular customer.
• Meta-data associated with the workset may include an industry identifier for the particular customer chosen from the corporate taxonomy.
• the meta-data may be used in a number of ways.
• the product support engineer may automatically be made a member of an interest-based community for that particular industry.
• the meta-data may be used to activate a subscription.
• the user may automatically subscribe to policy documents related to the customer service workset once he is associated with the workset.
• Worksets can be an important source of context meta-data for personalization of a user's portal environment.
• Each workset may have associated context meta-data such as a stereotypical profile for a user assigned to the workset.
• the context data could include information such as skills, licenses, expertise, and education of a typical user to whom the workset is assigned.
• the associated context data may be assigned to his user profile.
• the context data may then be used to personalize the user's portal environment. For example, particular content may be pushed to the user as a result of the personalization.
• one or more subscriptions and/or one or more memberships in a community may be activated based on context meta-data.
• Worksets may include state-less and/or state-full information or services. State- less content is generally directed to portal services and user interface elements.
• An example of a state-less service is a particular application that may be used to perform a task.
• a state-less service may be a spreadsheet program for developing a budget. Worksets including state-less content may be used to deploy targeted content to portal users.
• a state-full service is one that represents the current state of a working process.
• instantiated content e.g., a particular instance of a spreadsheet program with a budget for a particular department on a particular date
• state-full content include: current artifacts that have been created (e.g., business objects, procedures, interest profiles, and subscription rules), folders and taxonomies that have been created, the current state of a workset (when a lifecycle is defined for the workset), a current collaborative network in terms of contacts and teams, and current team or project work.
• Worksets including state-full content may be used to transfer a current work state from one user to another.
• state-full content such as personal or collaborative project work, instantiated work events, and other content may be provided to the new sales manager via the workset-based portal system.
• State-full content can also serve as a template for creating similar worksets (for example, for creating team rooms).
• Users interact with worksets via one or more workspaces (e.g. portal pages or portions of portal pages) including user-interface elements.
• a workspace is a spatial arrangement of services and information that together support a coherent set of tasks.
• Each workset includes user-interface elements associated with that workset and that are displayed in the workspace for enabling tasks associated with the workset.
• a workspace can include a number of components, which may include integrated views (Iviews), for presenting content to the user.
• a workspace may include structured information (e.g. applications) and unstructured information, may offer social experience (e.g., users may share opinions, interact with other users via a chat function, share lessons learned, and may determine how many users have accessed particular workspaces), and may offer direct access to related actions or information.
• FIG. 1 shows the relationship between a user's job role, assigned worksets, tasks, and workspaces.
• a user 100 has a job role which generally describes his overall work responsibilities. Typical job roles include manager, engineer, developer, sales person, administrator, etc.
• Worksets 110A, 110B, and HOC are associated with three different work roles of the user.
• the worksets include tasks that enable the user to perform the work role.
• Workset 110A includes a number of tasks 120, such as tasks A, B, and C, which are presented to the user on a workspace 130A.
• Workset HOB includes tasks F and G, which are presented to the user on a workspace 13 OB.
• Tasks H and I may be second-level tasks associated with first-level tasks F and/or G, or may be first-level tasks presented in workspace 13 IB for clarity's sake.
• Workset HOB also includes tasks H and I, which are presented to the user on a workspace 13 IB.
• Workset 1 IOC includes tasks B, D, and E, which are presented to the user on a workspace 130C.
• workspace 130A may include on or more Iviews on a portal page.
• a particular component such as a task presented on a particular Iview may be presented on more than one workspace.
• a particular task may be relevant to two different worksets assigned to a user. Rather than associating the task with only one workset (e.g., to avoid duplication), it may be associated with both worksets so that the user does not have to switch among workspaces to access that particular task.
• task B is included in both workset 110A and in workset 110C, and may be presented to the user on both workspace 130A and workspace 130C.
• the workspace may include a menu structure such as a two-level tab structure.
• the menu structure enables the user to quickly find the desired task or service.
• the first level tabs may provide access to generic portal pages such as a home page, as well as workspaces associated with worksets.
• the second level tabs may provide access to tasks and sub-tasks associated with the corresponding portal page.
• FIG. 2 shows a two-level tab structure 200 that may be used for navigation among workspaces associated with generic portal pages, worksets, and tasks.
• First level tab 210 corresponds to a home page.
• second-level tabs include a news tab 220, a my Work tab 221, a travel tab 222, a myTeams tab 223, a services tab 224, and a support tab 225.
• First level tabs 211-215 correspond to worksets 1-5, which may each have corresponding second-level tabs directed to tasks for performing the work role of the workset.
• Workset 1 of FIG. 2 may be a customer service workset, and may be associated with a travel task. However, a travel task may better be presented to the user on a generic portal page such as the home page associated with upper-level tab 210, since travel is associated with many different types of worksets across a number of different job roles. Therefore, Workset 1 of FIG. 2 may populate the travel task associated with second-level tab 222 with travel-related content rather presenting travel-related content on a workspace associated with Workset 1.
• a workset may be associated with a particular news task (e.g., industry news), which may be better presented on a generic portal page, such as a news page associated with second- level tab 220 of FIG. 2.
• a generic portal page such as a news page associated with second- level tab 220 of FIG. 2.
• the content may be presented on multiple pages, such as a portal page associated with the workset, as well as a generic portal page.
• the content may include additional components, or additional content for a component already associated with a generic portal page.
• a component such as a travel task may be added to a generic portal page such as a home page.
• content may be added to a component already associated with the generic portal page (e.g., a particular contact may be added to a contact list already associated with a home page or other page).
• a workset may populate content to generic portal pages in a number of ways. For example, nodes may be added to generic navigation structures such as a home page structure via navigation merging. The workset then may define only the fragment that is to be added, using predefined identifiers as upper nodes.
• an application program interface may be defined to add content to one or more generic portal pages.
• an API may be used to add content associated with particular collections (such as collections of business objects, contacts, communities, reports, search domains, etc.) to particular portal pages.
• Worksets may include elements such as services, flags, and meta data to support collaboration among portal users.
• Supported collaboration tools may include shared spaces such as team rooms, and communication tools such as web meetings.
• Worksets may also support community spaces and conversation channels.
• worksets may support activity-based communities (e.g., all software designers), or strategic communities spanning a number of different job roles.
• Collaborative spaces may be included in workspaces associated with particular worksets, or on more generic portal pages.
• a Workset 1 of FIG. 2 may include a web meeting task.
• User interface elements related to the web meeting task may be presented to the user on a workspace related to Workset 1, or on a more generic portal page such as a my Work page associated with second-level tab 221 of FIG. 2.
• a workset-based portal system typically should provide worksets associated with a large area of responsibility which can also be considered as an embedded work role (that is, a subset of the user's job role).
• a workset may be a small but reasonable chunlc of work that would be assigned to a person, which includes tasks performed by some job roles but not others.
• a user's assigned worksets should reflect the user's different work intents directed to different work roles. By providing worksets to performing different work roles, the system reduces the amount of time the user spends searching for particular resources and switching among portal pages. [0069] In contrast, a workset-based portal system that splits coherent work across multiple worksets may result in decreased efficiency. If a user is switching among worksets too frequently, the portal design may not accurately model his optimum workflow and may need to be altered. In such a case, the worksets may be reflecting a technical (backend) concept or application model rather than particular work goals.
• a set of worksets may be developed by obtaining information about employee work practices. The information may be obtained by interviewing employees about their particular job goals and the information and resources they use during their work day. Additionally, data related to the employee's computer use, phone user, interaction with others (e.g., meeting data), and other data may be used to develop worksets. [0071] Referring to FIG. 3, worksets may be developed by obtaining work-related data for one or more employees.
• worksets may be developed by determining the tasks or actions that employees take while at work (310). This determination may be made by interviewing employees and by collecting data about employee activities (e.g., by collecting data related to employee computer use, employee phone use, employee interaction with other employees, and other data related to the employee's activities while at work).
• employee tasks may be grouped in work roles (320), where the tasks in a particular work role are directed to a goal or a number of related work goals of the work role.
• the tasks for a particular work role may be grouped in a number of levels, for ease of access and use.
• a work role may include first-, second-, and third-level tasks, etc (or alternately, tasks, sub-tasks, sub-sub-tasks, etc.).
• a workset is developed for each work role, including the tasks associated with the work role, and the portal environment (330).
• a workset may be implemented as a single data object with the elements needed to provide access to information and resources for achieving the work goal or goals.
• the workset may be labeled with an expression that reflects the goal or goals (340).
• the workset may be assigned to the employee, as well as other users of the workset-based portal system (350). Worksets may be assigned to a specified user by adding the worksets to a user profile for the specified user.
• a workset-based portal system may be directed to a particular business or industry. In order to develop worksets for a particular business, the following methods may be used. The development team may evaluate the overall information system scenario for the business in order to understand the applications, services, and information a workset-based portal system will be presenting to users.
• the development team may endeavor to understand the company's overall business goals and needs (the company's "big picture”). The development team may ascertain which employees will potentially be users of the portal system, the reasons they may need to use the system, and the benefits the portal system will provide for those business and the users.
• the developers gather information on particular work intents and work roles of potential users. Developers may interview potential users on-site, and observe them as they work. Alternately, developers may obtain user information remotely; for example, by conducting phone or email interviews, and by obtaining data related to the user's computer use.
• interviews help the developer learn about what is important to the user during the course of performing the user's work roles.
• a potential user interview may include questions such as:
• the developer may also determine how the user manages content by ascertaining:
• the developer may obtain information related to how the user analyzes accessed information. For example, the developer may ask questions such as:
• the developer may also obtain information related to the user's personal interests. For example, the developer may ask the user:
• the developers use the data to determine the user's responsibilities
• the developers create sub-structures that group the content according to the employee's work intent for performing particular work roles.
• the content for a work role (or a set of related work roles) is used to build the workset.
• a first user 410 and a second user 420 perform a number of tasks 430.
• the tasks can be simple or complex; they may include a large or small set of services, or may correspond to a single interaction step.
• the workset developer groups the tasks into worksets such as worksets 440, according to the particular work goal of the grouped tasks.
• Worksets 440 include portal environment information as well as task information.
• the developers endeavor to present the optimum amount of content in a workspace: the workspace should present maximum functionality while staying focused on the particular workset or task.
• the amount or presentation of content presented to user in a workspace should not be visually or intellectually overwhelming.
• Workset A and Workset B each present tasks to a user via a single workspace 450.
• Workset C presents tasks to a user using two workspaces 450, to avoid overwhelming the user by presenting a workspace with too many tasks.
• Some worksets may be dominated by certain types of activities, such as searching, monitoring, dispatching, collecting, problem solving, etc.
• the types of activities offered in a workspace may influence the design of the workspace.
• Workspace design may be analogized to apartment design: workspaces may be optimized for certain activities in the same way that rooms in an apartment are optimized for certain activities (e.g., a kitchen is optimized for cooking, a dining room is optimized for eating, etc.).
• the workset developers may also build collaborative structure for the user and others. The developers determine the groups and teams the user belongs to, the user's personal networks, and other collaborative activities. The developers may define communities to include users or activities that have a common theme. [00127] FIG.
• the assigned worksets may be developed by interviewing the user or using other data acquisition methods to determine his work roles and related tasks, and/or may be existing worksets that are assigned to the sales manager based on his current or projected work roles.
• Each workset is directed to one or more work roles of the sales manager, and may be given a name describing the particular work role of the workset.
• the user is associated with the worksets budgeting (510), team leading (520), key account management (530), promotion management (540), and market watching (550).
• budgeting (510) is associated with second-level tasks monitoring (511), planning (512), and approving (513).
• Team leading (520) is associated with task assignment (521), hiring (522), and communicating (523).
• Key account management (530) is associated with selling products (531), improving relationships (532), sending product information (533), tracking order fulfillment (534), and negotiation (535).
• Promotion management (540) is associated with create promotions (541), run promotions (542), track status (543), and analyze impact (544).
• Market watching (550) is associated with monitoring/analyzing key figures (551), watching competitors (552), market analysis (553), and creating sales/promotion strategies (554). [00129] The grouping of tasks to a particular workset may differ from company to company and even across a particular company.
• a budgeting workset may include monitoring (511), planning (512), and approving (513) tasks, while for a different company, a budgeting workset may include only planning and approving tasks, while monitoring tasks may be part of a different workset.
• a workspace including user interface elements for one or more worksets may be presented to an employee.
• the workspace may be a portal page that the user may access using an Internet browser. Referring to FIG.
• a workspace 600 for a sales manager includes a two-level tab structure 610 including first-level tabs for a home page 611, a budget management workset 612, a team lead workset 613, an account management workset 614, a promotion management workset 615, and a market watch workset 616.
• the tabs in tab structure 610 allow the user to navigate among a number of different worksets and generic portal content.
• Workspace 600 is designed so that the sales manager can efficiently access those resources needed to fulfill his job responsibilities. By providing a structure such as that of workspace 600, the sales manager may work more efficiently.
• Workspace 600 shows the first- and second-level tasks presented when the user chooses budget management tab 612.
• a monitor task 620, a plan task 630, and an approve task 640 associated with the budget management workset are presented on workspace 600.
• Workspace 600 shows second-level tasks associated with the first-level tasks.
• Second-level tasks “Monitor Ql” 621, “Monitor Q2" 622, “Monitor Q3" 623, and “Monitor Q4" 624 are associated with monitor task 620.
• a second-level task "Plan 2003" 631 is associated with first-level plan task 630.
• a second-level "Level 1" approval task 641 and a second-level "Level 2" approval task 642 are associated with approve task 640.
• Second-level tasks are presented on workspace 600 with the associated first-level tasks for ease of navigation, but need not be presented on workspace 600. That is, workspace 600 may present more or fewer task levels than shown.
• Monitor task page 700 includes a page area 710 A with a presentation of second-level task monitor Q 1 , as well as six third- level tasks.
• a user may select a projected task 711 A to view a projected budget for Ql .
• a user may select an actual task 712A to view actual spending for Ql .
• a user may select a chart task 713 A to view a chart of projected spending for Ql, or a chart task 714A to view a chart of actual spending for Ql .
• a user may select a data task 715 A to access data related to projected spending for Ql , or a data task 716 A to access data related to actual spending for Ql .
• a workspace 800 may include a home page 810, including second level tabs for generic tasks.
• home page 810 includes second-level tabs for a login task 820, a travel task 830, a news task 840, and a directory task 850.
• a page area 825 of workspace 800 includes a username field 821 and a password field 822, associated with login task 820. In other implementations, login may not be required or may be performed differently.
• an employee's workflow when an employee's workflow includes tasks from a particular workset, other worksets and/or tasks may be assigned to the employee. For example, when an employee such as a sales manager is associated with a "budget" workset, a subscription to a company finance policy may be automatically activated. In another example, when an employee such as a sales manager is associated with a "market watch" workset, a subscription to an industry news service may automatically be activated.
• the subscription task may be presented on a workspace with the appropriate workset (e.g., the finance policy task may be presented on the workspace including tasks associated with the "budget" workset), or may be presented in another appropriate manner (e.g., the industry news service task may be presented on a news page). The presentation may be determined manually or automatically.
• a system of workset-based content administration may be used.
• Worksets may be chosen from a content repository (e.g., one or more databases), then assigned to new or existing users.
• a particular workset may be modified prior to assigning the workset to a user.
• New worksets may be created, using content from existing worksets or other content.
• User interface 900 may be used for assigning worksets to a user profile for a new employee with a job role of "HR Administrator."
• a developer or other user may choose between different sources of available content for a new role or workset by choosing one of the tabs in a tab structure 911.
• the user may choose to search among worksets by selecting the "Workset" tab.
• Other available tabs in a tab structure 911 include a service tab, a role tab, ad a page tab.
• a user may choose either a search function 912 or a browse function 913.
• a user may choose to search for worksets that are assigned to particular job roles. In FIG.
• a search by job role may produce one or more worksets associated with one or more job roles.
• the job roles and associated worksets may be displayed in a search display area 920.
• One or more worksets may be selected from search display area 920.
• a user has selected a "Workset Alpha" associated with a "Sales Administrator” role.
• a work area 930 is provided for assigning and/or modifying content.
• Work area 930 includes a first area 931 including a representation of Workset Alpha, which includes Service A, Service B, and Service C.
• Work area 930 includes a second area 932 including a representation of a service Omega which is also assigned to the Sales
• Work area 930 includes a third area 933 including a representation of the "Sales Administrator" role.
• a detail area 940 includes details about service Omega.
• the details include the type of service (here, "launched"), the URL of the service, how the service should be displayed by the portal (here, a new window will be created), and whether the window can be minimized, deleted, or moved.
• the user may modify the content in area 930 and/or assign it to a user profile.
• Assignment area 950 shows content that is assigned to the user profile.
• a number of worksets and services including service Q, workset Beta (which includes services G and H), and Workset Alpha have been assigned to the user profile of the HR Administrator.
• workset-based content administration provides for efficient and flexible development and maintenance of a workset-based portal system. Rather than developing entire roles for individual users, worksets (or parts of worksets) may be re-assigned to many users. Once a comprehensive workset-based portal system is in place, new worksets need only be developed when new work roles are created. Even then, portions of existing worksets may be used in creating a new workset directed to a particular new work role. [00145] Referring to FIGS. 10A and 10B, worksets may be used for collaboration among employees.
• a workspace 1 OOOA for a sales manager may include a team lead workset 1010.
• Team lead workset 1010 includes a projects task 1020, which includes a Company A task 1030 and a Company B task 1040.
• Company A task includes a MRS (i.e., Marketing Requirements Specification) task 1031, a Product A Feedback task 1032, and a product sourcing task 1033.
• Company B task 1040 includes a presentation task 1041.
• Company A may be a current customer and Company B may be a prospective customer.
• Certain tasks in workspace 1000A may be collaborative.
• Product A Feedback task 1032 may involve collaboration between the sales manager and others.
• FIG. 10B an implementation of a workspace 1000B for a product support engineer is shown.
• Workspace 1000B includes a Product A workset 1050, including a development task 1060 and a customer feedback task 1070.
• Development task 1060 includes a Revision 1.0 task 1061 and a Revision 1.1 task 1062.
• Customer Feedback task 1070 includes a Company A task 1071 , a Company X task 1072, and a Company Y task 1073. Selecting Product A Feedback task 1032 of FIG. 7 A and Company A task 1071 of FIG.
• the page may be a team or collaborative room, which may include tasks related to feedback data (e.g., Company A requests for software support), tasks related to collaboration (e.g., web meeting services, requests for comments), tasks related to customer communication (e.g., Company A contacts), and other tasks.
• Collaborative content may also be collected in a collaborative workspace such as a workspace associated with team rooms task 1025 of FIG. 10A.
• a workspace 1100 may be used to present worksets and tasks similar to those presented in workspace 600 of FIG. 6 and monitor task page 700 of FIG. 7.
• Workspace 1100 includes an expandable file list 1110 including a home page 1111 , a budget workset 1112, a team workset 1113, a key accounts workset 1114, a promotion workset 1115, and a market workset 1116.
• Budget workset 1112 includes a monitor task 1117, a plan task 1118, and an approve task 1119.
• Monitor task 1117 includes a Q 1 task 1120, a Q2 task 1121 , a Q3 task 1122, and a Q4 task 1123, which has been selected.
• Workspace 1100 includes a presentation area 1140 with a first title space 1141 indicating the workset name and first level task name.
• a second title space 1142 includes a second level task name.
• Area 1140 includes a projected budget amount task 1144, an actual budget amount task 1145, a project budget graph task 1146, an actual budget graph task 1147, a projected budget data task 1148, and an actual budget data task 1149.
• Each task may be presented in an I view.
• Area 1140 includes a user-selectable link 1150 to Ql task 1120, a user-selectable link 1151 to Q2 task 1121, and a user-selectable link 1152 to Q3 task 1122.
• Many other presentations may be used.
• an effective presentation of a workspace provides for efficient navigation and ease of use among logically arranged worksets, tasks, and generic portal pages.
• FIG. 12 is a block diagram illustrating an example data processing system 1200.
• the data processing system 1200 includes a central processor 1210, which executes programs, performs data manipulations and controls tasks in the system 1200.
• the central processor 1210 is coupled with a bus 1215 that can include multiple busses, which may be parallel and/or serial busses.
• the data processing system 1200 includes a memory 1220, which can be volatile and/or non-volatile memory, and is coupled with the communications bus 1215.
• the system 1200 can also include one or more cache memories.
• the data processing system 1200 can include a storage device 1230 for accessing a medium 1235, which may be removable, read-only or read/write media and may be magnetic-based, optical-based, semiconductor-based media, or a combination of these.
• the data processing system 1200 can also include one or more peripheral devices 1240(l)-1240(n) (collectively, devices 1240), and one or more controllers and/or adapters for providing interface functions.
• the system 1200 can further include a communication interface 1250, which allows software and data to be transferred, in the form of signals 1254 over a channel 1252, between the system 1200 and external devices, networks or information sources.
• the signals 1254 can embody instructions for causing the system 1200 to perform operations.
• the system 1200 represents a programmable machine, and can include various devices such as embedded controllers, Programmable Logic Devices (PLDs), Application Specific Integrated Circuits (ASICs), and the like.
• Machine instructions also known as programs, software, software applications or code
• These instructions when executed, enable the machine 1200 to perform the features and function described above.
• machine-readable medium refers to any computer program product, apparatus and/or device used to provide machine instructions and/or data to the machine 1200, including a machine-readable medium that receives machine instructions as a machine-readable signal. Examples of a machine-readable medium include the medium 1235, the memory 1220, and/or PLDs, FPGAs, ASICs, and the like.
• machine-readable signal refers to any signal, such as the signals 1254, used to provide machine instructions and/or data to the machine 1200.
• FIG. 13 is a block diagram illustrating an example workset-based portal system.
• Users of client devices 1300 can access data over a network 1310 through a portal 1320.
• the network 1310 can be any communication network linking machines capable of communicating using one or more networking protocols.
• the network 1310 can be a local area network (LAN), metropolitan area network (MAN), wide area network (WAN), enterprise network, virtual private network (VPN), the Internet, etc.
• the clients 300 can be any machines or processes capable of communicating over the network 1310.
• the client devices 1300 can be Web Browsers and can be communicatively coupled with the network 1310 through a proxy server.
• the portal 1320 provides a common interface to program management services.
• the portal 1320 receives requests from the client devices 1300 and generates data views 1325 (e.g., Web pages) in response.
• the portal 1320 can implement a workset-based system to personalize the common interface and the data views 1325 for a user of a client device 1300.
• a user has one or more associated worksets that allow personalized tailoring of a presented interface through the generated data views 1325.
• the portal 1320 communicates with a workset system 1330 that consolidates multiple application services.
• the portal 1320 receives data 1335 from the workset system 1330 for use in fulfilling the requests from the client devices 1300.
• the workset system 1330 provides integrated application services and other resources to enable efficient user workflow.
• the workset system 1330 communicates with enterprise base systems 1340 to obtain multiple types of data 1345.
• the enterprise base systems 1340 can include various existing application services, such as human resource management systems, financial management systems, project management systems, time management systems, and electronic file and/or mail systems.
• the workset system 1330 can consolidate and integrate the data and functionality of such systems into a single tool.
• the portal 1320, workset system 1330 and enterprise base systems 1340 can reside in one or more programmable machines, which can communicate over a network or one or more communication busses.
• the base systems 1340 can reside in multiple servers connected to an enterprise network
• the portal 1320 and the workset system 1330 can reside in a server connected to a public network.
• a user of the system can access and manage resources through a single portal from anywhere that access to a public network is available.
• Portions of this disclosure discuss presentations for roles, worksets, and associated tasks. Different presentations may be used.
• the current specification uses the term "workset" to a top level grouping of tasks that may be associated with a role, the terms may be used differently. For example, rather than a workset and one or more task levels, one or more workset levels may be used, and the term task may refer to the lowest level action.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Business, Economics & Management (AREA)
• Human Resources & Organizations (AREA)
• Strategic Management (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Entrepreneurship & Innovation (AREA)
• Economics (AREA)
• Data Mining & Analysis (AREA)
• General Engineering & Computer Science (AREA)
• Marketing (AREA)
• Operations Research (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• General Business, Economics & Management (AREA)
• Remote Sensing (AREA)
• Radar, Positioning & Navigation (AREA)
• Development Economics (AREA)
• Educational Administration (AREA)
• Game Theory and Decision Science (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Information Transfer Between Computers (AREA)

Priority Applications (1)

Applications Claiming Priority (8)

Publications (1)

Family

ID=56290372

Family Applications (2)

Family Applications Before (1)

Country Status (4)

Families Citing this family (12)

Family Cites Families (3)

• 2002
  • 2002-12-24 EP EP02028971A patent/EP1367513A3/de not_active Withdrawn
• 2003
  • 2003-01-07 EP EP03729305A patent/EP1490800A2/de not_active Ceased
  • 2003-01-07 JP JP2003558620A patent/JP2005514693A/ja active Pending
  • 2003-01-07 AU AU2003225474A patent/AU2003225474A1/en not_active Abandoned
  • 2003-01-07 WO PCT/IB2003/001637 patent/WO2003058371A2/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events