The embodiments of the present invention relate to software and, more particularly, to methods for providing a contextual view of a specified process step based on the current process step.
Workflow, business process, and electronic data entry based systems allow an enterprise to formalize the processes by which the enterprise achieves its business objectives. Such systems provide step-by-step descriptions of tasks which should be performed as part of the work, so that individuals or groups within the enterprise can be assigned individual (or groups of) tasks. The tasks may be dependent or independent upon one another.
The embodiments of the present invention relate to software and, more particularly, to methods for providing a contextual view of a specified process step based on the current process step.
Implementation of the embodiments of the present invention involves performing or completing selected tasks or steps manually, semi-automatically, fully automatically, and/or a combination thereof Moreover, depending upon actual instrumentation and/or equipment used for implementing an embodiment of the disclosed methods, several embodiments could be achieved by hardware, by software, by firmware, or a combination thereof.
The embodiments of the present invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the embodiments of the present invention only, and are presented in order to provide what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the embodiments of the present invention. In this regard, no attempt is made to show structural details of the embodiments in more detail than is necessary for a fundamental understanding of the invention. The description taken with the drawings makes apparent to those skilled in the art how the several embodiments may be embodied in practice. Identical structures, elements or parts which appear in more than one figure are preferably labeled with a same or similar number in all the figures in which they appear. In the drawings:
FIGS. 3A-B are schematic illustrations of an embodiment for providing different data based on the current process step, in accordance with the present invention;
FIGS. 4A-B are schematic illustrations of an embodiment for providing different data based on the current process step and the role, in accordance with the present invention;
FIGS. 5A-B are additional schematic illustrations of providing different data based on the current process step and the role, in accordance with the present invention;
FIGS. 6A-B are schematic illustrations of an embodiment of abstraction, in accordance with the present invention;
FIGS. 7A-B are schematic illustrations of another embodiment for providing different process step views, in accordance with the present invention;
FIGS. 8A-B are flow diagrams of embodiments in accordance with the present invention;
In the following description, numerous specific details are provided to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art, however, will recognize that the embodiments may be practiced without one or more of these specific details, or with other equivalent elements and components, etc. In other instances, well-known components and elements are not shown, or not described in detail, to avoid obscuring aspects of the invention or for brevity.
The following disclosure provides a brief, general description of a suitable computing environment in which the embodiments of the present invention may be implemented. Those skilled in the relevant art will appreciate that the embodiments may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, network computers, mini computers, mainframe computers, and the like. The embodiments may be practiced in distributed computing environments where tasks or modules are performed by remote processing devices, which are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. The embodiments may be practiced in hardware, programmable devices, and other equivalents. Referring to the figures, as illustrated in
Referring to
In an embodiment of the invention, the indication of relevancy is received by using one or more of the following methods, or an equivalent thereof:
1) The relevancy of each element is determined by a set of rules operated on the process step and/or on one or more elements within the process step. US patent application No. 20060107197, entitled “Role-dependent action for an electronic form”, which is incorporated herein by reference, is an example of the relevancy by role approach.
2) Implementing the process elements as business objects associated with operations, wherein the operations may be prioritized. US patent application No. 20050288945, entitled “Object based navigation”, which is incorporated herein by reference, is an example of associating operations with business objects.
3) The indication of relevancy may be received by using a web service, wherein the web service stores the indication of relevancy for at least one element and/or for the entire process step. The web service may be a Service Oriented Architecture (SOA) or Enterprise Service Oriented Architecture (ESOA).
4) The data that is indicating the relevancy may be stored as content fragments, where the fragments are pieces of reusable content and/or metadata that can be used in multiple documents, pages, or any artifacts that are managed by the system. US patent application No. 20050149862, entitled “System and method for context sensitive content management”, which is incorporated herein by reference, is an example of the content fragments approach.
5) Storing the indication of relevancy of each element and/or a process step in a tag. The tag is a data structure that makes it possible to adapt the content to different scenarios by using the tag's data. The tag's data may be stored hierarchically, for example to correspond with multiple values of a user's context. Optionally, the tag may be implemented as a function, which may be used by scripts or other programmable tools. An element may have no tags, one tag, or more than one tag. The tags may be embedded or not embedded in the clement.
Hierarchic tags may be better understood if treated similarly to an access-rights tree, wherein a user has to meet all the conditions along a branch in order to have access to a leaf node.
In an embodiment of the invention, all the different tags in the system have the same structure. As a result, the same weighting, same tag matching mechanism, same context analysis, same properties analysis and/or same management may be used for all elements featuring tags. Using the same structure for all or most of the tags in the system makes it possible to easily analyze the context and deduce the relevancy. Moreover, the same tag handling mechanism may be used in order to reduce computation time, increase compatibility and agility, reduce software development time, and increase the data integrity of the result as there are less transformations and deductions.
In an embodiment of the invention, the tags are built as an array. In an alternative embodiment, the tags are built hierarchically. Hierarchic tags may enable the system to associate or relate the different tags to each other (using tags as values in the hierarchy) and by that help understand the context. Referring again to
A hierarchic tag branch may be weighted. According to the weight of the branch, the weights of specific elements in the branch may be changed. For example, if an item has a high weight and its branch has a low weight, the weight of the item may be reduced and vice versa. When changing the weight of an element, the branch weight can indicate if the change is reasonable. In an embodiment, the depth of an item in a branch may indicate the significance of the item. As the item is closer to the root, it may be more significant, and optionally its weight should be taken more seriously.
There are cases wherein an element does not have an indication of relevancy. In that case, the relevancy decision usually depends on the context of the problem to be solved and/or on the characteristics of the process to be performed, and does not affect the scope of the present invention. For example, it is possible to decide that an element without an indication of relevancy is relevant to the user, or alternatively, decide that an element without an indication of relevancy is not relevant to the user.
Optionally, an indication of the user context is received, and the step of providing the user with the contextual view of the specified process step is further based on the received indication of the user context. As illustrated by
An indication of the user context may be provided to the algorithm that determines the contextual view of the specified process step in relation to the current process step. In that case, the contextual view of the specified process step provided to the user is comprised of elements that are relevant to the current process step and to the user's context. For example, a process step element may be relevant to a current process step, but when considering the user context it may turn out that the process step element is not relevant to the specific user and therefore should not be provided to the user in spite of the current step being what it is.
The user context may be selected from a large variety of context types. A detailed discussion about exemplary possible contexts is disclosed below.
For example, when the user context is a user role, different roles viewing the same process step may be supplied with different content.
In an option of the method, the received indication of relevancy of at least one element of the specified process step is an indication of relevancy to an element within the current process step. This option enables the system to further focus the user on information relevant to the task at hand. For example, the system may provide in the specified process step more details relevant to the element the user is working on compared with the details provided about the other elements.
In an optional embodiment of the invention, the system receives the current process step and the specified process step. Optionally, the current process step is set by a user as illustrated by 101a and 101b in
In an embodiment of the invention, the specified process step is an abstract view of at least two process steps. Referring to
Referring again to
Referring again to
The process described above may be, for example, a business process, workflow, learning process such as e-learning process, software wizard or any other process having more than one process step and an indication about the current process step.
The process step itself and/or the process step element may be implemented as one of the following examples: field, tab, window, note, text, image, widget, action, link, and a set of process step elements.
The contextual view provided to the user may be a device dependent view. US patent application No. 20050154741, entitled “Methods and computer systems for workflow management”, which is incorporated herein by reference, is an example of a method and system that provide the user a device dependent view by using self descriptive parts that identify what data is relevant to what device. In an embodiment of the invention, the step of providing the user with the contextual view is based on a self descriptive part that specifies details for generating the contextual view. In that case, the self descriptive part specifies details for generating a corresponding device independent representation for the contextual view.
In an embodiment of another aspect of the invention, the following method is used for providing the user with a contextual view of a process comprising at least two process steps, wherein during execution, one of the process steps is a current step of the process. Referring to
There may be a plurality of process step views. For example, step 132b may include a process step view of its own and provide the user with other process step views when steps other that 132b are the current step of the process.
The process step comprising the process step view may comprise at least two process step views associated with the same current step of the process. In this case, the method may receive an indication of the user context, and based on the received indication of the user context, select the process step view to be provided to the user.
The user context may be selected from a large variety of context types. A detailed discussion about exemplary possible contexts disclosed below.
This option enables the system to further adapt the provided content to the context. Referring to an example illustrated by
In an embodiment of the invention, prior to the step of providing the user with a process step view, a step of setting the relevant process step view to each current step of the process is executed. Setting the relevancy of each process step view to the various current steps, and, optionally, to additional parameters, is illustrated by component 188b in
Optionally, at least one of the process steps may have an abstract view of at least two process steps.
The process may be for example a business process, worlflow, e-learning process, software wizard or any other process having more than one process step and an indication about the current process step.
The process step itself and/or the process step view element may be implemented as one of the following examples: field, tab, window, note, text, image, widget, action, link, and a set of process step elements.
The process step view provided to the user may be a device dependent process step view. The device dependent process step view may be implemented by utilizing descriptive parts that identify which data is relevant to which device. The self descriptive part specifies details for generating the contextual view.
It is to be understood that although
In an embodiment of another aspect of the invention, the following method is used for providing a user with the relevant content.
(a) Providing the user with a toolbar, the toolbar comprising at least two navigable elements representing process steps. It is to be understood that any type of process steps indication may be used instead of the process toolbar. The process toolbar is referred to in the figures by reference numbers 130, 130a, 160, and 160a.
(b) Receiving a user's choice of one of the navigable elements.
(c) Providing the user with content about a process step represented by the navigable element, wherein the provided content is adapted to the user based on a current step of the process.
Optionally, the toolbar is a visual representation of the process. The visual representation may be a graph, flowchart, snapshot, process flow, etc. Optionally, the process is a business process, workflow, an e-learning process and/or a software wizard. Optionally, the provided content is further adapted according to the context of the user. Optionally, the content provided to the user comprises at least two versions, and adaptation of the provided content to the user comprises choosing one version from the at least two versions.
Above described embodiments supply the user with a contextual view of a process step. The following list includes types of contexts, examples of contexts and methods for deriving contexts. The list, or its equivalents, may be used in the embodiments of the present invention.
a) The context may be relevant Business Data, such as, user role, user's current and past projects, other projects of the user's company, user profile, other people in the user's role/project/department, user's company and company profile, user level of experience (for example novice, intermediate, expert) with the system, user's level of expertise related to the client selected by the user, meta-data associated with the user, and sources outside the user's environment such as user's profile on the web.
b) The context may be a physical status of the user, such as, for example, whether the user is hard of hearing, near-sighted or far-sighted. The system may take into account the user's temporary physical or mental status, for example, whether the user is distracted, nervous or tired. The user's temporary physical or mental status may be inferred from a measure of pulse or respiration rate of the user, a skin conductivity of the user, visual and vocal expressions of the user, user speed of activity or frequency of interaction with the device.
c) The context may be the user's current task and the user's goal, which is either an ultimate goal or a sub-goal, and to which the user seeks information relevant to achieve that goal.
d) The context may be user privileges and authority information.
e) The context may be the amount and type of resources available for the task at hand (for example, the current project's budget).
f) The context may be data from the user's device and application environment, such as, active programs in the user's environment, any menus, tabs or other controls selected by the user, documents in the user's environment, user's mailbox, schedule, preferences, available hardware and/or device, active documents and web-pages, and deriving the context from analyzing the text the user is working on.
g) Contexts may include a variety of types of information about devices within the computing system, such as device types, named users of the devices, device location, device capabilities, interaction methods, software platforms, the amount of free storage on a device, information about devices, data, and applications to which a particular device has access, information about connection bandwidth available to a device, information about network type, the latency to transfer data over a transmission medium and availability of differing network technologies, and information on whether a user has a device.
h) The context may be data about the user's physical environment, such as location, time and environmental conditions, such as temperature, speed, loudness, background noise, lightness or darkness, the weather, or nearby equipment. Such data may be measured by appropriate sensors or otherwise inferred.
i) The context may be the existence and/or identity of nearby users, for example, whether the user is alone or with someone else.
j) The context may be inferred from metadata, such as, user company's connections with other companies and financial data, information about other users that are associated with the user, and data about people related to the user. For example, the system may use information about the groups the user is a member of and about other members of such groups. Such information may be derived, for example, from a user's contact list or from distribution lists of which the user is a member.
k) The context may be history and logs, such as, history of user activity, history of user interaction with the system, and history of activity of the system receiving the data. For example, the system may provide information based on the user's most recent accesses to the system or the user's most frequent types of interaction with the system.
The following are examples of context derivation methods from various sources, such as user input, user profile, organizational databases, sensors, status of applications and devices in use:
a) The context may be based upon the user identity or function, wherein predefined contexts are stored for each user or class of user. The user identity may either be defined explicitly by using a user identifier such as log on ID for each user of the system, or implicitly by having a stored set of context definitions for each terminal able to access the system and assuming that the user for each terminal is always the same user or class of user.
b) A context definition may be based on the information requested by the user or the information sent for display in response to a request. Further, where the context definition is based on the information requested, the context definition may be based on either or both of the type of information requested and/or the actual value of the information requested.
c) The context of the application may be deduced from other available information including other user inputs to the application, dialogue between a user desktop and the application, or, where the application is run on a remote server, dialogue between a user terminal and the application, or dialogue between a web browser client and the application server or web server. The context of the application can of course be deduced based on more than one source of available information.
Although the present invention has been described in considerable detail with reference to certain embodiments thereof, other embodiments are possible. Therefore, the spirit and scope of the appended claims should not be limited to the description of the embodiments contained herein.
It is appreciated that certain features of the embodiments, which are, for clarity, described in the context of separate embodiments, may also be provided in various combinations in a single embodiment. Conversely, various features of the embodiments, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.
It is to be understood that the embodiments are not limited in their applications to the details of the order or sequence of steps of operation or implementation of the methods set in the description, drawings, or examples.
Any citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the embodiments of the present invention.
While the embodiments have been described in conjunction with specific examples thereof, it is to be understood that they have been presented by way of example, and not limitation. Moreover, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims and their equivalents.
Any element in a claim that does not explicitly state “means for” performing a specific function, or “step for” performing a specific function, is not to be interpreted as a “means” or “step” clause as specified in 35 U.S.C. § 112, ¶ 6.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/716,490, filed on Sep. 14, 2005, which is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
60716490 | Sep 2005 | US |