Patent Application
20130055147
Embodiments of the subject matter described herein relate generally to data processing systems and techniques, such as systems and processes that use a common network-based platform to support applications executing on behalf of multiple tenants. More particularly, embodiments of the subject matter relate to the generation and presentation of a secondary graphical user interface (GUI) element alongside a primary GUI element, where the content of the secondary GUI is related to, supplements, or is otherwise associated with the content of the primary GUI element.
Modern software development is evolving away from the client-server model toward network-based processing systems that provide access to data and services via the Internet or other networks. In contrast to traditional systems that host networked applications on dedicated server hardware, a “cloud” computing model allows applications to be provided over the network “as a service” supplied by an infrastructure provider. The infrastructure provider typically abstracts the underlying hardware and other resources used to deliver a custom-developed application so that the customer no longer needs to operate and support dedicated server hardware. The cloud computing model can often provide substantial cost savings to the customer over the life of the application because the customer no longer needs to provide dedicated network infrastructure, electrical and temperature controls, physical security and other logistics in support of dedicated server hardware.
Multi-tenant cloud-based architectures have been developed to improve collaboration, integration, and community-based cooperation between customer tenants without sacrificing data security. Generally speaking, multi-tenancy refers to a system wherein a single hardware and software platform simultaneously supports multiple user groups (also referred to as “organizations” or “tenants”) from a common data store. The multi-tenant design provides a number of advantages over conventional server virtualization systems. First, the multi-tenant platform operator can often make improvements to the platform based upon collective information from the entire tenant community. Additionally, because all users in the multi-tenant environment execute applications within a common processing space, it is relatively easy to grant or deny access to specific sets of data for any user within the multi-tenant platform, thereby improving collaboration and integration between applications and the data managed by the various applications. The multi-tenant architecture therefore allows convenient and cost effective sharing of similar application features between multiple sets of users.
A customer relationship management (CRM) application may be deployed using a multi-tenant architecture. A CRM application can be used to track sales activity, the progression of potential sales deals, sales team quotas, and the like, using various GUI screens, pages, and elements. For example, a CRM application may generate and display a variety of primary views, pages, or screens that provide relevant information, such as a “Case Detail” view, an “Account Detail” view, an “Opportunity Detail” view, a “Contact Detail” view, or the like. These primary views typically represent common or frequently used GUIs that together form the core functionality of the CRM application.
A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures.
The exemplary embodiments presented here relate to various techniques for processing and presenting information in the context of the use and manipulation of GUIs, web pages, and interactive displays associated with a computer-implemented system or application, such as a software-based system, a database system, a multi-tenant environment, or the like. The described subject matter could be implemented in connection with two or more separate and distinct computer-implemented systems that cooperate and communicate with one another, e.g., a client (end user) system and a server or cloud-based system. Although the subject matter presented here could be utilized in connection with any type of GUI-based application, the exemplary embodiments described here can be implemented in conjunction with a virtual customer relationship management (CRM) application in a multi-tenant environment.
Turning now to
A “tenant” or an “organization” generally refers to a group of users that shares access to common data within the database 130. Tenants may represent customers, customer departments, business or legal organizations, and/or any other entities that maintain data for particular sets of users within the system 100. Although multiple tenants may share access to the server 102 and the database 130, the particular data and services provided from the server 102 to each tenant can be securely isolated from those provided to other tenants. The multi-tenant architecture therefore allows different sets of users to share functionality without necessarily sharing any of the data 132.
The database 130 is any sort of repository or other data storage system capable of storing and managing the data 132 associated with any number of tenants. The database 130 may be implemented using any type of conventional database server hardware. In various embodiments, the database 130 shares processing hardware 104 with the server 102. In other embodiments, the database 130 is implemented using separate physical and/or virtual database server hardware that communicates with the server 102 to perform the various functions described herein.
The data 132 may be organized and formatted in any manner to support the application platform 110. In various embodiments, the data 132 is suitably organized into a relatively small number of large data tables to maintain a semi-amorphous “heap”-type format. The data 132 can then be organized as needed for a particular virtual application 128. In various embodiments, conventional data relationships are established using any number of pivot tables 134 that establish indexing, uniqueness, relationships between entities, and/or other aspects of conventional database organization as desired.
Further data manipulation and report formatting is generally performed at run-time using a variety of metadata constructs. Metadata within a universal data directory (UDD) 136, for example, can be used to describe any number of forms, reports, workflows, user access privileges, business logic and other constructs that are common to multiple tenants. Tenant-specific formatting, functions and other constructs may be maintained as tenant-specific metadata 138 for each tenant, as desired. Rather than forcing the data 132 into an inflexible global structure that is common to all tenants and applications, the database 130 is organized to be relatively amorphous, with the pivot tables 134 and the metadata 138 providing additional structure on an as-needed basis. To that end, the application platform 110 suitably uses the pivot tables 134 and/or the metadata 138 to generate “virtual” components of the virtual applications 128 to logically obtain, process, and present the relatively amorphous data 132 from the database 130.
The server 102 is implemented using one or more actual and/or virtual computing systems that collectively provide the dynamic application platform 110 for generating the virtual applications 128. The server 102 operates with any sort of conventional processing hardware 104, such as a processor 105, memory 106, input/output features 107 and the like. The processor 105 may be implemented using one or more of microprocessors, microcontrollers, processing cores and/or other computing resources spread across any number of distributed or integrated systems, including any number of “cloud-based” or other virtual systems. The memory 106 represents any non-transitory short or long term storage capable of storing programming instructions for execution on the processor 105, including any sort of random access memory (RAM), read only memory (ROM), flash memory, magnetic or optical mass storage, and/or the like. The server 102 typically includes or cooperates with some type of computer-readable media, where a tangible computer-readable medium has computer-executable instructions stored thereon. The computer-executable instructions, when read and executed by the server 102, cause the server 102 to perform certain tasks, operations, functions, and processes described in more detail herein. In this regard, the memory 106 may represent one suitable implementation of such computer-readable media. Alternatively or additionally, the server 102 could receive and cooperate with computer-readable media (not separately shown) that is realized as a portable or mobile component or platform, e.g., a portable hard drive, a USB flash drive, an optical disc, or the like.
The input/output features 107 represent conventional interfaces to networks (e.g., to the network 145, or any other local area, wide area or other network), mass storage, display devices, data entry devices and/or the like. In a typical embodiment, the application platform 110 gains access to processing resources, communications interfaces and other features of the processing hardware 104 using any sort of conventional or proprietary operating system 108. As noted above, the server 102 may be implemented using a cluster of actual and/or virtual servers operating in conjunction with each other, typically in association with conventional network communications, cluster management, load balancing and other features as appropriate.
The application platform 110 is any sort of software application or other data processing engine that generates the virtual applications 128 that provide data and/or services to the user devices 140. The virtual applications 128 are typically generated at run-time in response to queries received from the user devices 140. For the illustrated embodiment, the application platform 110 includes a bulk data processing engine 112, a query generator 114, a search engine 116 that provides text indexing and other search functionality, and a runtime application generator 120. Each of these features may be implemented as a separate process or other module, and many equivalent embodiments could include different and/or additional features, components or other modules as desired.
The runtime application generator 120 dynamically builds and executes the virtual applications 128 in response to specific requests received from the user devices 140. The virtual applications 128 created by tenants are typically constructed in accordance with the tenant-specific metadata 138, which describes the particular tables, reports, interfaces and/or other features of the particular application. In various embodiments, each virtual application 128 generates dynamic web content (including GUIs, detail views, secondary or sidebar views, and the like) that can be served to a browser or other client program 142 associated with its user device 140, as appropriate.
The runtime application generator 120 suitably interacts with the query generator 114 to efficiently obtain multi-tenant data 132 from the database 130 as needed. In a typical embodiment, the query generator 114 considers the identity of the user requesting a particular function, and then builds and executes queries to the database 130 using system-wide metadata 136, tenant specific metadata 138, pivot tables 134, and/or any other available resources. The query generator 114 in this example therefore maintains security of the common database 130 by ensuring that queries are consistent with access privileges granted to the user that initiated the request.
The data processing engine 112 performs bulk processing operations on the data 132 such as uploads or downloads, updates, online transaction processing, and/or the like. In many embodiments, less urgent bulk processing of the data 132 can be scheduled to occur as processing resources become available, thereby giving priority to more urgent data processing by the query generator 114, the search engine 116, the virtual applications 128, etc. In certain embodiments, the data processing engine 112 and the processor 105 cooperate in an appropriate manner to perform and manage various techniques, processes, and methods associated with the generation, provision, manipulation and/or operation of GUIs and GUI elements, as described in more detail below with reference to
In operation, developers use the application platform 110 to create data-driven virtual applications 128 for the tenants that they support. Such virtual applications 128 may make use of interface features such as tenant-specific screens 124, universal screens 122 or the like. Any number of tenant-specific and/or universal objects 126 may also be available for integration into tenant-developed virtual applications 128. The data 132 associated with each virtual application 128 is provided to the database 130, as appropriate, and stored until it is requested or is otherwise needed, along with the metadata 138 that describes the particular features (e.g., reports, tables, functions, etc.) of that particular tenant-specific virtual application 128. For example, a virtual application 128 may include a number of objects 126 accessible to a tenant, wherein for each object 126 accessible to the tenant, information pertaining to its object type along with values for various fields associated with that respective object type are maintained as metadata 138 in the database 130. In this regard, the object type defines the structure (e.g., the formatting, functions and other constructs) of each respective object 126 and the various fields associated therewith. In an exemplary embodiment, each object type includes one or more fields for indicating the relationship of a respective object of that object type to one or more objects of a different object type (e.g., master-detail, lookup relationships, or the like).
As described in greater detail below in the context of
Still referring to
As mentioned above, a user of a client device 140 can access, manipulate, and otherwise interact with a virtual application hosted by a cloud-based system, such as a multi-tenant architecture of the type described previously. In certain non-limiting embodiments, a web browser of a client device 140 can be utilized to access, manipulate, and otherwise interact with a hosted customer relationship management (CRM) application. The virtual application may be configured to generate and provide any number of GUIs, GUI elements, web pages, resources, and/or displays as needed to support the desired functionality. For the exemplary embodiments presented here, GUI displays and screens are configured for rendering as web pages such that the GUI displays and screens can be presented in a conventional manner using a web browser running on a client device 140. In this regard,
The GUI display 200 depicted in
The primary GUI element 202 represents the main view, page, or window that is currently selected, highlighted, or focused. The exemplary embodiment shown in
The primary GUI element 202 is populated with primary content 212 that is related to, associated with, relevant to, or otherwise linked to the Acme, Inc. account. The primary content 212 may include any type of information (static, dynamic, read-only, active, or the like). For example, the primary content 212 could include any or all of the following, without limitation: data; active links to online resources, web pages, or database objects; menus; tabs; forms; controls; or the like. Some or all of the primary content could be revised, changed, modified, deleted, and/or supplemented by the user via manipulation with the primary GUI element 202 and/or via manipulation with the web browser application itself. In this regard, the GUI display 200 may accommodate user-entered data for purposes of making changes or otherwise modifying the primary content.
The secondary GUI element 204 is populated with secondary content 214 that is contextually related to the primary content in some way. For example, some or all of the secondary content 214 may be influenced by, determined by, or controlled by some or all of the primary content 212. In practice, the secondary content 214 is associated with, linked to, or dependent on the primary content 212 such that the secondary content 214 supplements and enhances the primary content 212 without interfering with or obscuring the primary content 212 itself. For this particular example, the secondary GUI element 204 includes a sidebar component or a sidebar view that is associated with a database object of a CRM application. Consequently, for this example the secondary content 214 will also be related to, associated with, relevant to, or otherwise linked to the Acme, Inc. account. The secondary content 214 may include any type of information, including that described above for the primary content 212. Moreover, some or all of the secondary content could be revised, changed, modified, deleted, and/or supplemented by the user via manipulation with the secondary GUI element 204 and/or via manipulation with the web browser application itself. In this regard, the GUI display 200 may accommodate user-entered data for purposes of making changes or otherwise modifying the secondary content. In certain implementations, some or all of the secondary content is provided by a third party (i.e., an entity other than the entity that maintains and provides the hosted application). In such implementations, the secondary content can be pushed to the host system as needed to update the secondary GUI element 204. Thus, changes and modifications to the secondary content need not be the result of user interaction with the GUI display 200.
For certain exemplary embodiments, the primary GUI element 202 and the primary content 212 are associated with a first domain. The first domain may, for example, be associated with a first entity (such as the entity that maintains and provides the hosted application and the primary content 212). Thus, the user manipulates the client device such that the web browser is directed to a web page associated with the first domain (e.g., by providing a uniform resource locator (URL) or another network address associated with the first domain) to establish communication with the first domain. The web browser accesses and/or downloads the desired page (or hypertext markup language (HTML) document) available at the addressed location on the first domain, and displays or otherwise presents the content of that web page in association with the primary GUI element 202.
This description assumes that the secondary GUI element 204 and the secondary content 214 are associated with a second domain that is different than the first domain. The second domain may, for example, be associated with a second entity or any third party other than the entity that maintains and provides the hosted application and the primary content 212. Indeed, the secondary content may be maintained by a third party source or entity in a manner that is independent of the primary content. In practice, the web browser application may be directed to a web page associated with the second domain (e.g., by providing a URL or another network address associated with the second domain) to establish communication with the second domain. The web browser accesses and/or downloads the desired page (or HTML document) available at the addressed location on the second domain, and displays or otherwise presents the content of that web page in association with the secondary GUI element 204. In an exemplary embodiment, therefore, the GUI display 200 presented within the web browser on the client computing device includes primary content 212 obtained from (or associated with) the first domain, along with secondary content 214 obtained from (or associated with) the second domain. This can be accomplished by configuring and formatting the secondary GUI element 204 as an inline frame (e.g., an HTML iframe element) within the page corresponding to the primary GUI element 202. Of course, the specific manner in which the secondary GUI element 204 is configured, implemented, and rendered may vary from one embodiment to another, and techniques other than HTML iframes may be employed in this context.
As described in more detail below, one or more display characteristics of the secondary GUI element 204 can be configured by the user. In other words, the appearance, arrangement, features, functionality, and/or other characteristics of the secondary GUI element 204 are customizable to suit the needs and desires of the user. To this end,
Although any number of parameters could be subjected to customization, the exemplary embodiment presented here accommodates user-configurable display regions and user-configurable display dimensions (sizing) for the secondary GUI elements. In this regard,
It should be appreciated that a secondary GUI component need not span the entire width or height of the display (as shown in
As mentioned above, it may be desirable to allow certain characteristics, features, and settings of the GUI displays to be user-configurable. In preferred exemplary embodiments, therefore, a user or a system administrator can customize and configure secondary GUI elements for use with primary GUI elements. In this regard,
The custom sidebar configuration process 600 may begin with the selection or identification of a primary page, resource, detail view, GUI element, or any displayable feature (task 602). This example assumes that task 602 selects a primary page (e.g., a web page having a specific URL) that corresponds to, includes, or is otherwise associated with primary content to be rendered in connection with a GUI display. The process 600 may also select or identify a secondary page, resource, detail view, GUI element or any displayable feature to be used in connection with the custom sidebar component (task 604). This example assumes that task 604 selects a secondary page (e.g., a web page having a specific URL) that corresponds to, includes, or is otherwise associated with secondary content to be rendered in connection with the GUI display. Notably, the identified secondary page should be related to, associated with, or relevant to the primary page in some manner.
The process 600 may continue by selecting or identifying a display region, position, or location for the custom sidebar component (task 606). As mentioned above with reference to
It should be appreciated that the process 600 may also enable the user to select or identify other customizable, variable, flexible, or configurable features, characteristics, or functions of the custom sidebar component (task 610). For example, the process 600 could support user-configurable color schemes, themes, fonts, or the like. As another example, the process 600 could allow the user to define and deploy multiple secondary GUI elements in one custom sidebar component, as explained above with reference to
In an exemplary embodiment, tasks 602, 604, 606, 608, and 610 are associated with user interaction with a client device. In particular, the process 600 can be performed in connection with the presentation of various GUI screens in a web browser running on the client device. In practice, the process 600 can be implemented as a feature of the hosted virtual application itself, such that the user can quickly and easily configure custom sidebar components for detail views, pages, and GUI components generated by the virtual application. Accordingly, the process 600 could be executed in connection with the presentation of one or more configuration screens that include fields, menus, active control buttons, and/or other GUI features that allow the user to make selections, create user-entered data, etc.
After selecting, identifying, or otherwise designating the desired configuration options and preferences, the process 600 initiates the configuration and creation of the custom sidebar component (task 612). In association with task 612, the process 600 generates the necessary configuration data for the custom sidebar component. In turn, the configuration data can be received by the system that hosts the virtual application such that the configuration data can be applied when generating and providing the custom sidebar component for rendering at the client device. In this regard, the user-specified configuration data may be sent from the client device (e.g., as a completed browser-based form or document) to a server device for processing and implementation as needed. As described above, the user-specified configuration data defines or determines certain display characteristics of the custom sidebar component, including, without limitation: the display region for the custom sidebar component, relative to the primary GUI element; and the designated display dimension(s) for the custom sidebar component. Moreover, the user-entered configuration data may identify a primary GUI element, a primary page, and/or primary content (from any number of possible candidates) for purposes of linking to the custom sidebar component. In this regard, at least one variable display characteristic or feature of the custom sidebar component is defined or influenced by the user-specified configuration data.
In response to the request for the primary page, the process 700 identifies or retrieves a secondary page of the web-based application that is associated with, linked to, or otherwise paired with the requested primary page (task 704). The secondary page includes or is associated with secondary content that is contextually related to the primary content of the primary page. The process 700 may continue by generating a GUI (e.g., a web page) for display at the user device. To this end, the illustrated embodiment of the process 700 generates a primary GUI element that includes at least some of the primary content associated with the primary page (task 706), and generates a secondary GUI element that includes at least some of the secondary content associated with the secondary page (task 708). The process 700 generates and provides an appropriate GUI (web page) that includes the primary GUI element and the secondary GUI element (task 710). In certain embodiments, this GUI is provided to the client device and rendered such that the primary and secondary GUI elements are concurrently displayed with one another.
The primary and secondary content may be static, dynamic, active, pushed, read-only, editable, etc. The specific characteristics, parameters, and behavior of the primary and secondary content may vary from one scenario to another, depending on various factors such as, without limitation: the particular functionality and purpose of the virtual application; the purpose of the primary and secondary pages; and/or the content type. The illustrated embodiment of the process 700 addresses a few common scenarios where the primary content or the secondary content may be altered. For example, if the process 700 detects changes made to the primary content (the “Yes” branch of query task 712), then the secondary GUI element could be refreshed to update the secondary content that is currently displayed (task 714). The detected changes may, for example, result from user interaction with the primary GUI element (e.g., the entry of new data, the deletion of existing data, the modification or revision of existing data, or any user-entered data that is obtained through interaction with the displayed page). Alternatively, changes to the primary content could be initiated without any user interaction. For example, the client device and/or the hosting server system could initiate changes to the primary content in certain situations.
In practice, updating the secondary content is typically performed in accordance with the changes made to the primary content. In other words, changes to the secondary content are contextually related to, or otherwise influenced by, the detected changes made to the primary content. Thus, the secondary GUI is refreshed to populate the secondary GUI element with updated secondary content that tracks the updated primary content in some manner. In certain embodiments, the primary content can be updated in response to changes made to the secondary content. In other words, the primary GUI is refreshed and updated to reflect changes to the content of the secondary GUI.
The process 700 also contemplates changes or updates to the secondary content. Changes to the secondary content could be obtained from the user, from the client device, and/or from the server system as explained above with reference to the primary content. Notably, updates and changes made to the secondary content need not always be related to or responsive to updates and changes made to the primary content. In other words, updates and changes to the secondary content can be independent of updates and changes to the primary content. For example, the secondary content could be maintained and provided by a third party content source that is unaffiliated with the entity that maintains and hosts the virtual application and that maintains and provides the primary content. Accordingly, the secondary content might be updated and modified at any time, and then pushed to the secondary GUI element such that the most current secondary content is available to the user. If the process 700 detects changes or updates to the secondary content (the “Yes” branch of query task 716), then the process 718 may obtain the updates (task 718) and refresh the secondary GUI element to provide the updated secondary content (task 720).
The web-based virtual application could be designed to support the use of secondary GUI elements with any number of pages, detail views, and primary GUI elements. For this reason, the process 700 contemplates a scenario where a different primary page is requested. In this regard, if the process 700 receives a request for a new primary page of the virtual application (the “Yes” branch of query task 722), then the current GUI page is replaced with a different GUI page that includes a corresponding primary GUI element and a corresponding secondary GUI element that is linked to the new primary GUI element (task 724). The replacement GUI elements are generated, provided, and rendered as described in more detail above for the previous iteration of the process 700. Of course, different primary and secondary GUI elements can be provided and rendered in an ongoing manner as the user engages in his or her usual workflow with the web-based application.
The various tasks performed in connection with any process described above may be performed by software, hardware, firmware, or any combination thereof In practice, portions of a process may be performed by different elements of the described system, e.g., a client device, a server system, or a functional module or component thereof It should be appreciated that a described process may include any number of additional or alternative tasks, the tasks shown in the figures need not be performed in the illustrated order, and a described process may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the illustrated tasks for a particular process could be omitted from an embodiment of the process as long as the intended overall functionality remains intact.
The foregoing detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, or detailed description.
Techniques and technologies may be described herein in terms of functional and/or logical block components, and with reference to symbolic representations of operations, processing tasks, and functions that may be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as being computer-executed, computerized, software-implemented, or computer-implemented. It should be appreciated that the various block components shown in the figures may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices.
When implemented in software or firmware, various elements of the systems described herein are essentially the code segments or instructions that perform the various tasks. The program or code segments can be stored in a tangible non-transitory processor-readable medium in certain embodiments. The “processor-readable medium” or “machine-readable medium” may include any medium that can store or transfer information. Examples of the processor-readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable ROM (EROM), a floppy diskette, a CD-ROM, an optical disk, a hard disk, or the like.
While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application.
This application claims the benefit of U.S. provisional patent application Ser. No. 61/528,317, filed Aug. 29, 2011, the content of which is incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 61528317 | Aug 2011 | US |
