In many cases, it is desirable for a first application to be able to cause certain content to be displayed in the context of a second application. For example, a development tool application may wish to cause information about a task created in the development tool to be displayed in the context of an email client application, or a travel application may wish to cause status information about a flight tracked by the travel application to be displayed in the context of a calendar application. This is sometimes referred to as “injecting” the content; the application injecting the content is sometimes referred to as the “originating application,” while the application into which the content is injected is sometimes referred to as the “host application.”
In a first “forms” approach to content injection, in its role as a host application, a particular application defines one or more types of forms that originating applications can use to display content. For each form type, a list of fields is established for which an injecting application can specify values. For example, an email client application can define a task form for use by originating applications that includes 6 fields common to most tasks. An originating application can use the task form by explicitly selecting it, and specifying values for some or all of its six fields.
In a second “fully specified” approach to content injection, an originating application can fully define the rendering of the injected content, such as by generating an HTML version of the content, or a bitmap of the content.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
A facility for injecting content into host applications is described. The facility receives from an originating program a content payload specifying (1) two or more elements of content, and (2) a relative significance among at least two of the elements of content. The facility also receives from the originating program information identifying a host program in the context of which the content of the received content payload is to be rendered. The facility determines a rendering strategy based at least in part on the identity of the host program. The facility uses the determined rendering strategy to generate a rendered version of the content of the received content payload, and causes the generated rendered version of the content of the received content payload to be displayed in the context of the identified host program.
The inventors have recognized significant disadvantages attending the conventional approaches to content injection discussed above. They have recognized that the forms conventional approach to content injection provides very little control to the originating application, in terms of both substance and form. In terms of substance, if a form has not been defined by the intended host application that includes all the fields that an originating application wishes to specify, the originating application must choose between injecting no content and selecting a form defined by the host application that allows the originating application to specify a proper subset of the desired set of fields, in both cases preventing the originating application from providing certain information that would be useful to the user of the host application. In terms of form, the forms approach provides the originating application with little or no control over how the elements of the form are rendered, including such factors as spatial arrangement of the elements, relative size of the elements, relative importance of the elements, etc. This limits the ability of the originating application to arrange the injected content in a way that is easily understood and digested by the user of the host application.
The inventors have further realized that the forms conventional approach to content injection requires a very high level of collaboration between the developers of different applications. Each application that can serve as an originating application must be developed and updated in a way that is attentive to all of the forms made available by any other application into which it is desirable to inject content. Similarly, each application that can serve as a host application must be developed and updated in a way that is attentive to the kinds of forms favored by any other application from which is desirable to be able to receive injected content.
The inventors have also identified significant disadvantages of the fully specified conventional approach to content injection. First, giving the originating application full control over the appearance of the injected content has the effect of depriving the host application of any control over the appearance of injected content. This prevents the host application from coordinating the appearance of the injected content with the visual style of the host application, often making the injected content visually discordant with the appearance of the host application. Also, in many cases, permitting the originating application to fully specify the injected content provides to the originating application too great a measure of programmatic control over the host application, in many cases permitting uncontrolled, unmonitored access to host application data structures and other state, arbitrary Internet locations, etc.
In response to recognizing the foregoing disadvantages, the inventors have conceived and reduced to practice an improved software and/or hardware facility for cross-application content injection (“the facility”). In some examples, the facility allows the originating application to specify content of a wide variety of types, as well as specifying a significant level of organizational information among the different elements of such content. Also, the facility allows the host application a significant degree of control over the visual style with which the elements of the injected content are displayed. While the description below generally refers to the injected content being displayed in the context of the host application, those skilled in the art will appreciate that, in various examples, the facility causes the injected content to be rendered in a variety of other ways, including being outputted as synthesized and/or composited speech, rendered in a variety of other audio forms, etc.
In some examples, the originating application can define the injected content in a manner that is indifferent to the identity of the host application, and/or to the platform on which the host application is executing on behalf of the user. (The “platform” refers to the output presentation mechanism being used by the instance of the host application being used by the targeted user, generally the operating system on which this instance of the host application is executing. Where this host application instance is executing on a server and communicating its output to the user's computer system via a protocol such as HTML, the host application instance is sometimes referred to as executing on a platform corresponding to this output protocol.) In some examples, the facility provides a set of standard renderers—one per supported platform—that can be used to render injected content on behalf of any host application. In some examples, a host application into which content is to be injected provides a host configuration resource that specifies visual style information—that is coordinated with the host application's native visual style—for application to the injected content by the facility's standard renderer for the appropriate platform. When using the facility's standard renderers (also called “host configuration controlled renderers”), in some examples the host application can apply a “style cleanup” resource to the rendered version of the injected content produced by the shared renderer to further adjust visual style information of the rendered version of the injected content to better coordinate with the visual style of the host application. In some examples, a host application is also free to provide its own custom renderer for any platform.
In some cases, the content generated for injection by the originating application is described as being provided in a “content payload” data structure. In some examples, the originating application can include in or with the content payload logic for determining whether to include certain information among the injected content, and/or determining how to organize elements of the injected content. In some examples, the originating application can include in or with the content payload information electing a particular rendering strategy among multiple rendering strategies made available by the host application. For example, a host application may make available two rendering strategies each corresponding to a different host configuration resource provided by the host application.
In some examples, the originating application can include in or with the content payload information for maintaining the integrity of the contents of the content payload over time. For example, in some examples, the facility enables the originating application to specify a time at which the currency of the content payload information will expire, and after which the injected content should no longer be displayed by the host application. In some examples, the facility enables the originating application to further specify a mechanism—such as a URL—usable by the host application and/or the content injection mechanism to retrieve an updated version of the injected content, such as at the time the injected content expires, or at a later time at which the host application is prepared to display the injected content.
By performing some or all of the ways described above, the facility provides a universal mechanism for originating applications to provide a wide variety of information for injection and make recommendations about how it is to be organized for display, and for host applications to coordinate the visual style of the injected content with their own native visual style. The facility further permits an application to do this with few or no dependencies on the identities of the other applications with which it will operate as an originating and/or host application. Also, to a great degree, an application can operate as an originating and special host application without regard for the platform on which the injected content will be displayed.
Also, by performing in some or all of the ways described, the facility meaningfully reduces the hardware resources needed to generate, route, render, and present injected content, including, for example: reducing the amount of storage space needed to store related information; and reducing the number of processing cycles needed to perform these processes. This allows programs making use of the facility to execute on computer systems that have less storage and processing capacity, occupy less physical space, consume less energy, produce less heat, and are less expensive to acquire and operate. Also, such a computer system can perform the content injection process with less latency, producing a better user experience and allowing users to do a particular amount of work in less time.
Those skilled in the art will appreciate that the acts shown in
Among resources 610 provided by a first host application are a host configuration 611 for the first host application, and a style cleanup resource 612 for the first host application. Among the resources 620 provided by the second host application are a first host configuration 621 for the second host application, and a second host configuration resource 623 for the second host application. Among the resources 630 provided by the third host application are a custom iOS renderer 631 for the third host application, and a custom Android renderer 632 for the third host application.
Extending the example shown in
While
Table 1 below shows the content payload provided in the first rendering scenario. The same content payload is used for other rendering scenarios discussed above, in some cases adjusted in certain ways as described there.
In some examples, the originating application generates the content payload in accordance with a payload schema defined in connection with the content injection mechanism. Certain details of this sample payload are discussed in greater detail below.
When the content injection mechanism receives the content payload, it identifies the rendering strategy shown in row 802, and invokes the standard HTML renderer to render the payload, passing the renderer the first host configuration resource provided by the first host application shown Table 2 below.
Table 3 below shows the HTML generated by the standard HTML renderer using the first host configuration resource for the first host application. This rendered version of the content payload shown in Table 1 will be displayed by the first host application, in the context of the other visual information displayed by the first host application.
By comparing the HTML shown in Table 3 to the payload shown in Table 1 and the host configuration resource shown in Table 2, the relationship between these data items can be discerned. For example, it can be seen that the payload specifies the actions “Set due date”, “Comment”, and “View” in lines 89-112, 113-141, and 142-146 of Table 1. These actions occur in the HTML in lines 126-127, 129-130, and 132-133 shown in Table 3. The formatting of these actions in the HTML is affected, for example, by the contents of the host configuration resource in line 3 of Table 2, which specifies that actions specified by the payload are to be oriented in a vertical direction; the structure of lines 125-134 in Table 3 reflects this vertical orientation, with its use of an inline-table made up of buttons and intervening vertical separators.
Table 4 below shows the style cleanup resource for the first host application.
It can be seen that the style cleanup resource specifies a box-shadow attribute for the ac-pushButton and ac-linkButton styles used in the rendered HTML content shown in Table 3.
To cause the style cleanup resource to be applied to the rendered HTML content when the rendered HTML content is displayed by the first host application, the content router causes the lines shown in Table 5 below to be added to the rendered HTML content shown in Table 3 above.
The string “skypeCard.css” in line 2 of Table 5 refers to and incorporates the host style cleanup resource shown in Table 4.
Table 6 below shows the first host configuration resource for the second host application.
When the facility invokes the standard Android renderer, passing it the first host configuration resource for the second host application, the standard Android renderer generates a rendered version of the payload shown in Table 1 above in a format suited for the Android platform. In order to facilitate comparison of this rendered version of the payload to the rendered version shown in Table 3 above of the payload, Table 7 below artificially shows the version the payload rendered for the second application using the first host configuration resource for the second application in HTML form.
By comparing Table 7 to Tables 2, 3, and 6, one can discern that the version of the payload rendered for the second application shown in Table 7 differs from the version of the payload rendered for the first application shown in Table 3 in ways that result from differences between the first host configuration resource for the first host application shown in Table 2 and the first host configuration resource for the second host application shown in Table 6. For example, one way that Table 6 differs from Table 2 is that line 70 of Table 6 specifies an actionOrientation of “Horizontal”, in contrast to the actionOrientation of “Vertical” specified in line 2 of Table 2. This has the effect of, in lines 144-151 of Table 7, arranging horizontally the actions arranged vertically for the first application as specified in lines 125-134 of Table 3. Those of skill in the art will identify numerous other differences between the rendered versions of the payloads shown in Tables 3 and 7 springing from differences between the host configuration resources shown in Tables 2 and 6, including, for example, fonts, font sizes, and color values
In some examples, the facility permits the originating application to include in the payload conditional logic. The conditional logic has the effect of either including or excluding content or content relationship elements on the basis of whether condition specified by the conditional logic are satisfied. In some examples, the conditions in the conditional logic are evaluated at display time. In some examples, the conditions in the conditional logic are evaluated at rendering time. Table 8 below shows conditional logic that is added to the content payload shown in Table 1 in a sixth rendering scenario.
In particular, these lines establish an “Approve” action that, when clicked, changes its title to “Approved” and becomes disabled. Whether the action has been clicked is the condition that is evaluated by the conditional logic.
In some examples, the facility allows the originating application to include in a payload information about the expiration of some or all of the content in the payload. In some such examples, this includes an expiration date and time after which the content in the payload is to be considered expired, as well as a reference that can be used to retrieve an updated version of the payload after expiration. Table 9 below shows sample expiration information that's included in the payload shown in Table 1 in a seventh rendering scenario.
Line 1 of Table 9 specifies the expiration time of the payload contents, and line 2 specifies the reference that can be used to retrieve an updated, or “refreshed” version.
In some examples, the facility provides a method in a computing system for injecting content into host applications, comprising: in a content injection mechanism: receiving from an originating program a content payload compliant with a content payload schema, the content payload specifying (1) two or more elements of content, and (2) a relative significance among at least two of the elements of content; receiving from the originating program information identifying a host program in the context of which the content of the received content payload is to be rendered; determining a rendering strategy based at least in part on the identity of the host program; using the determined rendering strategy to generate a rendered version of the content of the received content payload; and causing the generated rendered version of the content of the received content payload to be displayed in the context of the identified host program.
In some examples, the facility provides one or more instances of computer-readable media, collectively having contents configured to cause a computing system to perform a method for registering a distinguished host application with a content injection mechanism, the method comprising: on behalf of the distinguished host application, receiving information identifying a first host configuration resource to be used by a renderer program shared across applications to render content injection payloads for presentation in the context of the distinguished host application; and persistently storing an indication of the identified first host configuration resource in connection with the identity of the distinguished host application for access when a content injection payload is received for the distinguished host application.
In some examples, the facility provides a cross-application content injection system, comprising: a processor; and one or more memories, the memories collectively having contents that, when executed by the processor, cause the performance of a method, the method comprising: receiving from an originating application a content payload, the content payload specifying (1) two or more elements of content, and (2) a relative significance among at least two of the elements of content; determining a first rendering strategy; using the determined first rendering strategy to generate a first rendered version of the content of the received content payload; causing the generated rendered first version of the content of the received content payload to be displayed in the context of a host application; determining a second rendering strategy; using the determined second rendering strategy to generate a second rendered version of the content of the received content payload, the second rendered version of the content of the received content payload being different from the first rendered version of the content of the received content payload; and causing the generated rendered second version of the content of the received content payload to be displayed in the context of a host application.
In some examples, the facility provides one or more memories collectively storing a rendering strategy data structure, the data structure comprising: a plurality of entries, each entry comprising: information identifying a host application program; and information specifying a rendering strategy to be used to render content injection payloads for presentation in the context of the identified host application program,
such that, when a content injection payload is received from an originating program in the context of a specified host application program, the contents of the data structure are usable to determine rendering strategy for the received content injection payload.
It will be appreciated by those skilled in the art that the above-described facility may be straightforwardly adapted or extended in various ways. While the foregoing description makes reference to particular examples, the scope of the invention is defined solely by the claims that follow and the elements recited therein.
This application claims the benefit of U.S. Provisional Patent Application No. 62/482,616, filed Apr. 6, 2017, and U.S. Provisional Patent Application No. 62/503,810, filed May 9, 2017.
Number | Date | Country | |
---|---|---|---|
62503810 | May 2017 | US | |
62482616 | Apr 2017 | US |