Patent Application
20170185612
The field generally relates to designing web pages.
A webpage is a hypertext markup language (HTML) document on the World Wide Web which includes text, graphics, audio, and/or video, etc. Usually, a solution package includes webpages designed and packaged for a specific business process. For example, a recruitment management solution package includes webpages designed and packaged for a recruitment process. The solution package is provided by vendors. Different customers have different design and content requirement(s) for the same business process. Customers may need to contact the vendor to edit or customize webpage(s) within the solution package. Contacting vendors and customizing webpages may be an arduous and a time consuming task specifically when the solution package is provided as cloud deployment. Moreover, the customers are restricted to static design of the webpages within the solution package and cannot experiment, modify, or flexibly enhance layout of the webpages by themselves.
Various embodiments of systems, computer program products, and methods for dynamically designing webpages are described herein. In an aspect, a request for designing a webpage is received. Based upon the request, a metadata related to the webpage is identified. Based upon the identified metadata, one or more widgets for designing the webpage is rendered. A selection of a widget from the one or more widgets is received from a user. Multiple sections of the webpage and the widgets positioned in corresponding sections are identified. The identified widgets of the webpage are integrated with one or more security rules.
The above methods, apparatus, and computer program products may, in some implementations, further include one or more of the following features.
One or more widgets may be stored in a widget library.
The multiple sections may include a header, a footer, and a body of the webpage.
The metadata may define a business process related to the webpage.
A request for rendering the webpage may be received. A context related to the webpage may be identified Based upon the context, the one or more security rules to be applied on the webpage may be identified. Based upon the identified one or more security rules, a layout for rendering the webpage may be dynamically generated. Based upon the generated layout, the webpage may be rendered.
The context may include one or more of a log-in information of a user accessing the webpage, a business role or a designation of the user accessing the webpage, a business process for which the webpage is created, and a business process state.
An action performed on the webpage may be identified. Based upon the action, an event may be generated and one or more widgets to be updated in the webpage may be identified. The generated event may be sent to the identified one or more widgets. The one or more widgets may update its data upon receiving the event.
The action may include one of addition of data, deletion of data, updating data, and selection of a user interface component on the webpage.
These and other benefits and features of various embodiments will be apparent upon consideration of the following detailed description of embodiments thereof, presented in connection with the following drawings.
The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Like reference symbols in the various drawings indicate like elements.
Embodiments of techniques for dynamically designing webpages within a solution package are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
“Entity” or “object” refers to a “thing of interest” for which data is to be collected. For example, an entity may be a customer, an employee, a candidate, an offer letter, an item of stock, a sales order, a purchase order, etc. The entity may be related to a business process. For example, the entity “candidate” may be related to the business process “recruitment management (RCM).” The entity comprises one or more attributes or properties that characterize one or more features of the entity. For example, the entity “customer” or “candidate” may comprise attributes such as name, age, sex, nationality, etc.
“Business process” refers to a set of linked procedures or activities which are collectively executed (in series or parallel) to realize a business objective or goal. For example, a business process “recruitment management” (RCM) may comprise three linked procedure namely “requisition creation,” “requisition preparation,” and “approval” which are executed in series to realize “recruitment” process. At any point of time the business process may be a distinct procedure or step. A current procedure or a step of the business process at any instance of time is referred as “business process state”. “Requisition creation”, “requisition preparation,” and “approval” are three states of the business process “RCM.”
“Business application” or “solution package” refers to a software program which is used to execute a business process, i.e., perform the procedures or steps of the business process. The business application may be an “on premise” application or may be provided as “on-cloud” solution. The business application may be interactive and includes one or more graphical user interfaces (GUIs). A user can query, modify, and input data and analyze results instantaneously though the one or more GUIs. A graphical user interface (GUI) of the business application comprises a webpage.
“Webpage” refers to a web document, e.g., hypertext markup language (HTML) document, on the World Wide Web. A webpage may comprise at least one of text, graphics, animation, video, audio, etc. The webpage may be designed according to a specific business process or requirement. Typically, the webpage is classified into one or more sections including, for example, a header, a footer, and a body or content. The header may include a broad and an abstract level information related to the webpage, the footer may include concluder elements such as a save button, a cancel button, a continue button (to go to next webpage), etc. The body may include various information related to the business process for which the webpage is designed and fields for receiving user's input. In an embodiment, the body may comprise multiple sections for receiving input or information related to the business process. For example, the body of the webpage related to the recruitment management may comprise sections such as “requisition information,” “position information,” “organization information,” “location information.” “personal information,” etc. In an embodiment, the body may include one or more configurable and/or non-configurable UI portlets. Portlets refer to pluggable UI components displayed in a web or an enterprise-portals. The non-configurable UI portlets have fixed code and cannot be edited such as non-configurable webpage images, videos, etc. The header, the footer, and the body of the webpage may comprise one or more widgets.
“Widget” refers to an application or a component of an interface, which enables a user to perform a function or access a service. Widgets are displayed in the graphical user interface (GUI), e.g., as a button, a scroll bar, labels, and check boxes, etc. The widgets are configured or defined by developers or vendors and stored in a widget library. Widgets may be configured based upon the business process in which it is used. For example, for recruitment management (RCM), widgets such as “action button” widget, “insight” widget, “prepare requisition” widget, “candidate source analysis” widget. “field missing” widget, “customizable field summary” widget, “business process progress” widget, “action link” widget, “configuration UI form” widget, etc., may be configured or used. Some widgets are universal which may be deployed or used in multiple business processes/applications. For example, “insight” widget, “action button” widget, “fields missing” widget, “business process” widget, etc., are generic widgets. Some widgets are specific to the business process. For example, widgets such as “prepare requisition” and “candidate source analysis” are specific to recruitment management (RCM).
“Action button” widget may include various buttons like save, cancel, submit, etc. “Insight” widget may provide detailed or insight information related to an entity in context, e.g. if the entity is “requisition”, the “insight” widgets can be configured to provide information like “average salary offered for similar position,” etc. “Prepare requisition” widget may enable editing or additional inclusion of data to an already created “requisition.” “Candidate source analysis” widget is enabled to provides a chart showing a source from where a candidate is recruited (e.g., percentage of applicant from different sources) such as 30% candidates from/through internal referral, 20% from job boards, and 30% from agency sourcing etc. “Customizable field summary” widget may render different fields based on the entity in context. The “customizable field summary” widget is enabled to be customized for displaying different number of fields for different entity. “Field missing” widget may be enabled to display the number of fields (e.g., essential fields in the body) which do not contain any data or value, i.e., have missing value. “Business process progress” widget may be enabled to display graphical view of the business process and indicates a current state of the business process. “Action link” widget may be a collapsible widget which is enabled to contain various clickable icons. The icons may be mapped to different actions which may be triggered on click of the icons, e.g., when “create notes” icon is clicked, it opens up an editor through which notes can be entered. “Configuration UI form” widget may be enabled to provide a “configurable form” which includes fields for receiving data from a user. The “configuration form” is a specific instance of “configurable UI form” widget. “Customizable field summary” widget may be enabled to contain fields specific to the entity for which the webpage is created. For example, if the entity is “requisition,” then the “customizable field summary” widgets may include fields, e.g., requisition-name, location, department, position #, etc. Similarly, if the entity is “candidate” then the “customizable field summary” widgets may include fields like candidate's first name, email, address, phone #, eligible_for_interview, etc. “Customizable field summary” widget may have different number of fields based on configurations. For some pages (configuration) there may be 4 fields in “customizable field summary” and for some pages there may be 8 fields. Therefore, the type of fields and number of fields may be customized.
“Page designer tool” or “page layout tool” refers to a tool for designing webpages. The page layout tool may include predefined widgets which can be used for designing webpages. For example, different widgets may be used for designing the header, the footer, and the body or content of a webpage. The page layout tool may also be communicatively coupled to various rule engines to apply predefined rules or security rules on the designed webpages. Typically, the predefined rules or security rules are applied while rendering the webpage at runtime. The rules may be related to a profile or a role of a user accessing the webpage, the business process for which the webpage is designed, the entity related to the webpage, the business process state, etc. For example, there may be multiple job profiles (i.e., roles) in an organization such as an executive (Tier 1), a manager (Tier 2), and a chief executive officer (Tier 3). The rule related to the job profile or role of the user, may be: if <role>=“Tier 1” then hide “customizable field summary” widget. An example of the rule related to the business process may be: if <business process>=RCM, then display “prepare requisition” and “candidate source analysis” widget. Similarly, the rule related to the entity (e.g., candidate in RCM) may be: if <candidate's date of birth> is ≦“16 years”, the populate field “eligible_for_interview” in the “customizable field summary” widgets as “not eligible.” The page layout tool may also be referred as an “administrator page.”
Once the widgets are positioned on the webpage, the page layout tool 110 integrates the widgets to their corresponding section. The page layout tool 110 also integrates the widgets to various predefined rules or security rules. In an embodiment, the predefined rules may be integrated to the widgets. In an embodiment, integrate may refer to one of a configure and an apply operation. There may be a predefined rule R1 defined as {R1=“disable widgets when working in an offline mode”} and there may be widgets W1 and W2. In an embodiment, integrating the predefined rule R1 to the widgets W1 and W2 may imply “applying” predefined rule R1 to the widgets W1 and W2 as {APPLY R1 to widgets W1 and W2}. “APPLY” may be a logical operation to link the predefined rule R1 to the widgets W1 and W2 so that the widgets W1 and W2 are rendered according to the predefined rule R1. Therefore, the widgets W1 and W2 would be disabled whenever the user works in the offline mode. In an embodiment, integrating the predefined rule R1 to the widgets W1 and W2 may imply “configuring” the predefined rule R1 within the widgets W1 and W2 as (CONFIGURE R1 into widgets W1 and W2). A “CONFIGURE” operation may include or embed the predefined rule R1 within code of the widgets W1 and W2 so that the predefined rule R1 becomes a part of the widgets W1 and W2, and the widgets W1 and W2 may be executed according to the embedded predefined rule R1. Based upon the predefined rule(s), the one or more widgets may be hidden, disabled, or displayed differently on the webpage. In an embodiment, the predefined rules may be defined or configured by the user (e.g., customer). The page layout tool 110 is communicatively coupled to a rule_and_security_check engine 130 to apply various rules on the webpage. The rules may be related to the business process, the business process state, a log-in information of the user or role of the user, i.e., widgets to be displayed to the user based upon the user's role in the organization (role based permission or RBP), etc. In an embodiment, the rules may be applied, at runtime, while rendering the webpage.
The rule_and_security_check engine 130 may also include various security checks related to the webpage. The customer or user can define various security checks to be performed while displaying widgets on the webpage, e.g., from where the widgets would retrieve its data, how the widget would behave, what data widget would display based on current state of the business process, what “action button” to be displayed, etc. Based upon the rules and security checks, it may be determined if any feature or widget is enabled or disabled (restricted) for the user or company. In an embodiment, there may be separate rule engine and security check engine.
One the rules are integrated and the webpage is designed, the page layout tool 110 enables customers to save the designed webpage. The designed webpage is saved and stored in a page layout library 140. Therefore, customized webpages may be created and stored in the page layout library 140 for later reuse. The page layout library 140 may store one or more predefined page layouts or webpages (provided by vendors based upon the business process) which can be used directly.
For rendering the webpages (e.g., the webpage 200 of
At process block 440, the page layout backend service invokes page layout template store (e.g., the layout library 130 of
In an embodiment, the backend callback service may implement a function getRuntimeFilteredComponentData( ) to retrieve filtered data for each component based upon various rules and security checks for corresponding UI component or widget. The filtered component data may be returned to the backend callback service which, in turn, may return final data for the component or widget to the page layout backend service. The above process may be repeated to calculate final data related to all the widgets of the page layout (i.e., final data=CData+final data). The final data of all the widgets may be used to generate a final page layout for the webpage. Once the final page layout including all the widgets is returned to the page layout backend service, the page layout backend service may return the final webpage layout along with all components to the page layout rendering service. The page layout rendering service then renders the webpage using the final page layout.
In an embodiment, if there is any change in the webpage, e.g., any field is updated or modified, any button is selected or clicked, etc., then one or more fields may be updated based on these changes. For example, if any data is removed, then the “missing field” widget in the header may be updated. Once any change occurs, the page layout controller 510 listens to the change (e.g., through an event generated or triggered by the event handler 530). The page layout controller 510 may then retrieve or fetch the details of the change by calling the UI renderer 500 through a method (e.g., “getRequiredFields( )”) to get or retrieve all essential (required) fields. The missing fields may then be counted, and the “missing filed” widget may be updated in the header. Based upon the change, the page layout controller 510 may update the webpage (layout of the webpage) and communicate the changed layout of the webpage to the page layout template store 520 for storing the updated webpage.
When the component C2 is clicked or selected in the header 630, the “missing field” (essential fields which have missing values) may be listed or displayed. The fields are listed under their respective section name or heading. For example, when the “name” field in the section 1 has a missing value, then the “name” field may be displayed under the section 1 in the list of missing fields. In an embodiment, when the section 1 is selected from the list of missing fields, the event handler 600 again generates another event which is communicated to the section 1 of the body section 620. The section 1 may then communicate with the UI renderer 500 (
Embodiments enable users (e.g., customers or end users) to design, create, modify, or update webpages dynamically based upon their requirements. The users or customers can easily select widgets (e.g., vendor provided predefined widgets) using UI operations such as drag-&-drop operation to design the webpages. The webpages can be easily created or modified, using basic UI operations, directly on the cloud. The users can design their customized webpages, save it, and reuse it later. Therefore, the embodiments provide an extendable, scalable, and flexible framework for dynamically designing the webpages. The framework allows customers to be creative to experiment with various design options according to their business requirements without contacting vendors and spending money and time. The customers are presented with widgets allowable for their business purposes. In case, a customer tries to use wrong widget in their webpage, an error message may be displayed. Various rules can be configured for widgets so that a widget's behavior changes based upon the configured rules. For example, the widget's behavior may change based upon a nature of the business processes, entity for which the widget is used, log-in information of the user running the webpage, the process state, or business logic, etc. Various predefined rules or security rules may be automatically applied while rendering the webpage at runtime.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” includes a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” includes physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic indicator devices: magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open Database Connectivity (ODBC), produced by an underlying software system, e.g., an enterprise resource planning (ERP) system, and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the one or more embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the embodiment are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the embodiments, as those skilled in the relevant art will recognize. These modifications can be made to the embodiments in light of the above detailed description. Rather, the scope of the one or more embodiments is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
