Patent Application
20110078103
The disclosure relates to a system and method for providing user interface (UI) control for software applications, in particular, UI control based on application context and rules.
Modern enterprises such as governmental organizations and private businesses typically use computer systems to manage their operations. Software applications designed to run on these computer systems may have a variety of user interfaces. In some situations, one software application that involves user interactions may need to vary the user interface according to different user groups, business units and/or operations to be performed, etc. For example, a tax processing application may have only one backend tax engine but may have different UIs according to different types of taxes being processed (e.g., personal income tax, corporate tax, sales tax). Therefore, in some cases, after a business software application is delivered to a customer, the customer may need to customize the UI layout and UI element properties according to the customer's specific business requirements, which cannot be covered by the business application out of the box.
Typically, when a software application is delivered, the application user interface is fixed. In some cases, the software vendor may provide some a plurality of user interface templates for a software application so the software application may have different UIs by default for different business requirements. However, using current technology, neither the fixed UI nor the default UIs can fulfill all specific requirements of customers. Efforts to change the situation have not been successful so far for several reasons. First, from a software application developer's point of view, it is difficult to foresee all customer requirements for UI layout and/or UI display properties during the development phase of a software application for all potential customers. It is either too expensive or too many different preferences or even requirements for UIs by a large amount of customers. Second, some UI changes are business-context related. When a new business requirement arises, UI changes may be needed. These UI changes cannot be foreseen before the business application is delivered. Third, the business application may be improved continuously after delivery to a customer, that is, UI changes may be needed with the continuous usage of the business application.
Therefore, presently, any changes for a user interface of a delivered software application beyond the templates provided by default is difficult and need involvement of a software developer to re-program the software application (e.g., change software code of the software application). Accordingly, there is a need in the art for providing user interface (UI) control for software applications that can adapt to customers' needs without application developers' involvement or coding changes after the software applications have been delivered to customers.
Embodiments of a method and system provide a rule based user interface control for a software application user interface. At configuration time of an installed software application, the method may provide a design-time environment for defining a rule for a UI element to be displayed in the software application. The rule may affect a value of a property of the UI element. The method may further persist the rule in a rule engine. Then at runtime, upon receiving from the software application a request to determine the value of the property of the UI element, the method may retrieve the rule from the rule engine by a runtime service, evaluate the rule to determine the value for the property of the UI element and set the value for the property according to the evaluated rule. Next, the method may return the set value for the property to the software application for displaying the UI element according to the set value.
In one exemplary embodiment, the application 102 may be implemented based on a model view controller (MVC) design pattern to ensure a clear distinction between application logic and presentation logic. The MVC design pattern may allow a software application to compartmentalize the user interface, business logic, and flow logic so these components of the software application can be readily reused and more easily maintained. The UI layout 106 and UI element properties may be defined in the view part of the pattern and the view modifier 108 may be implemented as a controller.
The rule based UI control framework 110 may comprise a design-time portion 116 and a runtime service 114. The design-time portion 116 may comprise design-time tools such as a configuration tool 118, a rule definition 120 and a rule binding 122. In design-time, the design-time portion 116 may facilitate creation of rules that control how UI elements may be displayed in the application 102. In runtime, the runtime service 114 may execute the created rules to determine values of the properties associated with the UI elements. The configuration tool 118 may comprise a user interface that helps a user to create rules. The rule definition 120 may help defining what conditions need to be included in a rule.
In one embodiment, a rule may be defined to take into consideration of application contexts, and may affect a UI property of a corresponding UI element. The application contexts may include application parameters and business contexts. Application parameters may include data applicable to the application as a whole. For example, a shared application may contain an application parameter tracking how many users currently are logged in, an application parameter representing a system time, and/or an application parameter representing a current user. The business context may be data objects representing relevant data for business operations. For example, in an flight booking application, information corresponding to flight may be considered as business context, such as, but not limited to, carrier ID, flight number, departure and arrival time and destination, etc. In an expense claiming application, information such as, but not limited to, expense type, amount, currency and place may be considered as business context. Accordingly, for example, in an application for air travel management, a rule may be defined as “if carrier id=LH(Lufthansa), then set the UI element as read-only” (LH may be short hand id for Lufthansa); in another application for customer relationship management, a rule may be defined as “if business partner is ‘BP1’ and contract object is ‘CO1,’ then set the UI element visible but read only.”
Once a rule is defined in the rule definition 120, the rule binding 122 may assign (e.g., bind) the rule to a UI element by defining a linkage between the newly defined rule and the UI element.
The rule engine 112 may provide a storage for the defined rules and assignment (binding) of the defined rules to UI elements. As shown in
The rule based UI control framework 110 may control the application user interface based on the rules. In design-time, a user may use the design-time tools of the design-time portion 116 to configure and assign rules to UI elements in a view (e.g., a display of a UI) of the application 102. Defined rules may be persisted in the rule engine 112. In runtime, before displaying the view, the view modifier 108 of the application 102 may send the runtime service 114 a list of UI elements to be displayed in the view. In response, the runtime service 114 may retrieve defined rules associated with (e.g., assigned to) each UI element in the list from the rule engine 114 and evaluate the retrieved rules. Based on the evaluation result, the view modifier 108 in the application 102 may set the values for the properties of corresponding UI elements to be displayed accordingly.
In embodiments, a rule may be implemented in a decision table, decision tree, formula or any other rule type provided by the rule engine 112. For example, an decision table may be used to define a rule where a selected application context may be used as a source to determine the UI property of a UI element. Embodiments of the present invention may define rules to take any view and/or controller context into consideration as a part of impacting facts for UI element properties(e.g. visible/invisible, mandatory/optional, enable/disable etc). In one embodiment, by using different rule expression type (e.g. decision table or formula), users of the design-time tools may determine how the context will affect UI element properties by maintaining content of a defined rule in the rule engine 112. Different user groups may provide their own rules for UI logic in the view to satisfy their own needs.
In one embodiment, the rule definition 120 may take advantage of rule engine to model the presentation logic of UI layout by rules instead of using program code. The input of the rule may be the business context (e.g., relevant business data (Lufthansa as a carrier vs. to use American Airline as the carrier) for an operation of the application (e.g., displaying flight information)) or application parameters (e.g., system time, current user), and output the rule may be UI elements properties' values.
In one embodiment, the configuration tool 118 may be implemented as a what you see is what you get (WYSIWYG) design environment. Implementation may be achieved via, for example, an application programming interface (API) of an application development environment. In one embodiment, the configuration tool 118 may retrieve a UI layout for the application 102, determine a MVC context, evaluate application parameters and UI element properties for a view of the application 102. By using the information retrieved, the configuration tool 118 can visualize the application 102's view and UI layout in a way of WYSIWYG (e.g., display the UI layout and corresponding UI elements accordingly in the configuration tool 118). Therefore, using the configuration tool 118, for each UI element, a user can choose a corresponding application parameter and/or business context and/or MVC context that may contribute to certain UI element property (e.g. visible/invisible) and determine how the UI element looks in the view of the application 102. In one exemplary embodiment, a decision table in rule engine 112 may used. In this decision table, the source fields may be selected context(s) and target fields may be selected UI element properties. Different users may maintain the decision table values according to their own business requirements. The decision table together with it's content may be persisted by the rule engine 112. The rule based UI control framework 110 may act as a bridge that links the application 102 and the rule engine 112, and may extend the flexibility of UI control for the application 102.
Design-time tools (e.g., the configuration tool 118, the rule binding 112 and the rule definition 120) of the design-time portion 116 may provide the functionalities to assign/reassign/remove a rule to certain UI element. In one embodiment, instead of or in addition to a WYSIWYG design environment, a testing mode may be provided to check the runtime behavior on how assigned (e.g., bound) rules affect an application UI.
After the function 204 to retrieve existing context available in the application, the rule based UI control framework 110 may perform another function 206 to retrieve existing rules and the assignments for each rule assigned to UI elements stored in a rule repository 208 that may locates in a rule engine 112. Thereafter, at a step 210, the available context objects and rules may be displayed to the user 230 to let the user 230 to take an overview of existing rules/assignments.
The user 230 may decide at a decision step 212 to take one of the following actions: to create a new rule 218, to assign an existing rule to a UI element 214, or to exit 222. If the user 230 selects to create a new rule 218, a design interface (e.g., the configuration tool 118) for the new rule may be displayed and the user 230 may interact with the design interface to create a new rule. In one embodiment, creation of the new rule may also include assigning the new rule to at least one UI element. Upon finishing creating the new rule, the rule based UI control framework 110 may update the rule engine repository at a step 216. If the user 230 selects to assign an existing rule to the UI element 214, the user 230 may select existing rule(s) and assign the rule(s) to certain UI element(s). Upon finishing the action 214, the rule based UI control framework 110 may update the rule engine repository at the step 216. If the user 230 selects to exit 222, the user may have finished the interaction with the application and may end the application.
At step 314, the application 102 may evaluate the attributes for UI elements to be displayed in a view of the application 102. The application 102 may invoke run time services in the rule based UI control framework 110 (e.g., the runtime service 114 in
The application hierarchy 402 may comprise application configuration 403 as a root. The application configuration 403 may be used as a configuration root template for a series or a variety of software products containing common components provided by a software company. The common components may be configured together to form a particular UI layout. The application configuration 403 may comprise an instance 404 of the application configuration. The instance 404 may be one specific configuration for the application configuration 403. The instance 404 may comprise one or more variants 406 (only one shown) for the application configuration 403. Each variant 406 may contain configuration for a group of components in a specific layout and/or step. Thus, different variants 406 may correspond to different UI layouts. In one embodiment, a user may choose one variant to be displayed according to a business context at runtime.
The variant 406 may comprise a main view 408. The main view 408 may be referred to as the main view for a specific lay out (e.g., a main view in the airline business application ZFPM_FDT_FLIGHT/MAIN). The main view 408 may comprise a sub view 410. The sub view 410 may by a part of the main view 408 and may contain a subset of components to be displayed on the main view 408. In one embodiment, the sub view 410 may be a frame or a tab displayed in the main view 408. In one or more embodiments, the sub view 410 may be referred to as a container. The sub view 410 may comprise a component 412 for the sub view 410 and the component 412 may comprise a view 414 (e.g., a view coded named V_MAIN for the airline business application ZFPM_FDT_FLIGHT). The view 414 may comprise a list of elements 416 (e.g., including a UI element 416a) for the view 414. In one embodiment, the view 414 may be implemented as a view in the MVC pattern and each UI element may be implemented as a configurable building block and may be implemented in an object oriented programming language (e.g., Java or C#), or other suitable non-object oriented programming languages.
The window 418 may be a user interface for creating a rule and assignment. The window 418 may include an information label 419. The information label 419 may show the name of the component, the name of the view and the element associated with the rule being worked on. In one embodiment, the window 418 may be a pop up window when a user right clicks an element in the hierarchy 402 and invokes a “create a rule” command form the pop up menu, so these context information may be provided to the window 418 and displayed automatically. In the example shown in
The window 418 may comprise a drop down box 430 to let the user to select a context that may be taken into consideration for the rule. Once the user selects a context (e.g., FLIGHTS), context attributes available for the selected context may be shown in an area 422 of the window 418. The area 422 may also show application parameters pertinent to the whole application 401 (e.g., current user, system time). In one embodiment, the business context and application parameters may be displayed side by side with the context attributes available for the selected context in the drop down box 430.
The window 418 may further include displays for element properties 423, source columns 424, target columns 426, a decision table 428 and functional buttons 430. The element properties 423 shows properties for a selected UI element (e.g., the UI element 416a selected in the view 414 from the hierarchy 402). The source columns 424 may contain source context objects. A source context object may be selected from either the application parameters or context attributes available for the selected context. For example, when the selected context is “FLIGHTS,” a source context object “CARRID” may be selected from the list of the available context attributes shown in the area 422. The target columns may contain properties of the UI element to be affected. For example, “enabled” may be added to the target columns for the UI element 416a. Thus, a rule may be created and saved in the decision table 428. For example, “if carrier_id=LH (Lufthansa), then set it read-only.” The decision table 428 may contain function buttons (e.g., add a row, delete a row). And the window 418 may also contain functional buttons (e.g., save, cancel). The window 418 may provide an easy way of rule customization based on a decision table.
Moreover, in a detailed display section, the rule engine workbench 500 may further comprise a plurality of functional buttons 510 for a decision table. The functional buttons include functions to manipulate data rows inside the decision table, for example, to insert a row, to append a row, to remove a row, to copy a row, to move a row up or down, to export data to an excel spreadsheet or to import data from an excel spreadsheet. The decision table may include context attributes 512 (e.g., application contexts or view contexts) and configurable properties 514. Each row in the decision table may represent how configurable properties of the UI element may be affected by the context attributes. For example, the sample rule represented in
In one or more embodiments, the business application implementing rule based UI control may be a composite application. In the composite application, each UI element may be implemented as a generic building block that may be used in a variety of applications. The UI element may be programmed (e.g., coded) using one of the objected programming languages, such as Java, C#, or scripting languages, such as Java script, PHP, or other suitable programming technologies, such as JSP, ASP.NET, Java Servlet. In one embodiment, the software vendor may create rules for UI elements and deliver the rules as part of the software application. In another embodiment, the software vendor may create rules for UI elements and deliver the rules as additional content for the software application. In this embodiment, no changes to the application or the rule based UI control framework need to be redeployed, just adding new content to the rule engine in a customer working site. In yet another embodiment, a rule may comprise a logic affecting one or more UI elements. The logic may determine the manner a UI element may be displayed (e.g., a group of UI elements and one UI element displayed after another in a view; a group of UI elements that each displayed relative to another with respect to time and/or position).
It should be noted that the rule-based UI control according to the present invention differs from the traditional software application that varies UI based on roles of operators. In the traditional software application, the logic that controls what should be shown for a particular role is typically programmed in the source code and compiled into the application. Thus, the logic is fixed during the development phase of the traditional software application. Further, for the traditional software application, operators with the same role will always get the same UI layout, even under different business contexts (e.g., using either Lufthansa or American Airline as the carrier wont' make any difference for the UI).
On the contrary, a software application based on the rule-based UI control according to the present invention may just enable the ability to vary UI according to rules. No rules need to be delivered with the software application. A customer can use the design-time configuration tool to define rules to meet whatever requirements (e.g., using Lufthansa as the carrier, the corresponding UI element may be read only; using American Airline as the carrier, the corresponding UI element may be editable). In one embodiment, users' roles may be part of the application parameter and/or business context and a customer may define rules according to users' roles and/or other business context information. But, still, the rules may be stored in the rule engine instead of compiled into the software application.
In one embodiment, the business application may be implemented based on rule engines, as known in the computer science field and provided by vendors such as SAP® and the like. The business application may also be built using web technology. In one or more embodiments, the end users (e.g., governmental agencies, corporations and businesses) may customize the rules for UI elements in the business applications according to the present invention. The rules may be created and maintained by the end user. This allows the end user to modify any rules as changes occur in the criteria related to the business criteria. In addition, as new needs may arise, the end user may generate new rules.
Embodiments of the present invention may provide software applications that may control user interface based on application context and rules. In one embodiment, the rule based UI control framework may take advantage of rule engine to define and persist rules for UI element of business application. The UI logic may be defined and encapsulated in the rule that is stored in a rule engine (e.g. by using common rule engine expressions like: decision table, decision tree, formula, etc). This framework can take application parameters and business context as decision factors for application UI layout and UI element properties. As UI control may be persisted and executed by rule engine, no programming enhancement is needed for application UI adjustment, changes can be delivered as rule engine content instead of code adjustment.
By using rule based UI control framework according to the present invention, business application developer, 3rd party middleware provider and customer may enhance or differentiate application user interface to fulfill their specific business requirement. These kind of enhancement may be achieved code-free. Also, these kind of enhancement may still be flexible enough to also take into the consideration of application parameters and context.
The processor 802 is a programmable processor that executes instructions residing in the memory 804 to receive and send data via the I/O device(s) 806. The instructions may perform the operations of the application context and rule based UI control described herein. The term programmable processor as used herein is any programmable microprocessor or processor or combination of microprocessors or processors that can operate on digital data, which may be special or general purpose processors coupled to receive data and instructions from, and to transmit data and instructions to, a machine-readable medium. According to one embodiment of the present invention processor 802 is an Intel microprocessor.
Memory 804 is a machine-readable medium that stores data that is processed by processor 802. The term machine-readable medium as used herein is any addressable storage device that stores digital data including any computer program product, apparatus and/or device (e.g., a random access memory (RAM), read only memory (ROM), magnetic disc, optical disc, programmable logic device (PLD), tape, hard drives, RAID storage device, flash memory or any combination of these devices). This may include external machine-readable mediums that are connected to processor 802 via one or more I/O device(s) 806.
The I/O device(s) 806 may be one or more input/output interfaces that receive and/or send digital data to and from an external device. Interfaces as used herein are any point of access to an external device where digital data is received or sent, including ports, buffers, queues, subsets thereof, or any other interface to an external device.
It should be understood that there exist implementations of other variations and modifications of the invention and its various aspects, as may be readily apparent to those of ordinary skill in the art, and that the invention is not limited by specific embodiments described herein. Features and embodiments described above may be combined with and without each other. It is therefore contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the basic underlying principals disclosed and claimed herein.
