Patent Application
20180091458
Computing systems are currently in wide use. Some such computing systems run hosted services and allow users to subscribe to those services. For instance, some services can be list management services, social network services, electronic mail services, project management services, or a wide variety of other services.
Some such services allow a user to submit an electronic mail (e-mail) address where the user is to receive various different types of messages from the service. These messages are often generated by the service, and sent to the user's e-mail address at intermittent times. Thus, users can receive generic, undifferentiated e-mails from a variety of different services, that disrupt the user's focus, or that can get lost with other e-mails in the user's electronic mail system.
Similarly, it is common that users have no control over the various messages they receive from a service they subscribe to. Instead, the service, itself, controls what e-mail messages the subscribers receive. This experience can become unmanageable for a user, as services send more messages over time, and as the user subscribes to more services.
In addition, once a user receives an e-mail message from the service, the e-mail message may request that the user perform some action with respect to that service. This commonly means that the user must navigate away from his or her e-mail, such as using a browser, and navigate to the site of the service, and then perform the desired action, using the interface provided by the service.
Further, notifications or other e-mail messages from a service can cause clutter, thus degrading the user experience. This can happen, for instance, when multiple e-mails are sent by the service concerning a particular item. By way of example, an e-mail may be sent when the service developers discover a bug. Another e-mail may be sent indicating that the bug is being addressed and an approximate time when the bug will be fixed. Yet another e-mail may be sent when the bug is fixed. These e-mails may be received by the user's e-mail system in a scattered and relatively ad hoc fashion. This can be exacerbated when the user has subscribed to multiple services, and this can degrade the user experience even further.
The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.
A message is rendered in an email inbox, with a user actuable element. User actuation is detected and an endpoint associated with the user actuable element is interacted with to perform an action in a service from within the email inbox.
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 features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background.
Client systems 118-120 can be similar or different client systems. For purposes of the present discussion, it will be assumed that they are similar, so that only client system 118 will be described in more detail. In one example, client system 118 includes one or more processors or servers 130, a client e-mail component 132, other client system functionality and logic 134, and user interface logic 136. Client e-mail component 132 can be a client component of e-mail service 108 that is, itself, hosted in remote server environment 106. User interface logic 136 can generate user interfaces 122 and detect and process user interaction with those interfaces, as well. Other functionality and logic 134 can take a wide variety of different forms and will depend on the particular client system it is deployed in, the particular way that the user is using the client system, and/or on a wide variety of other things.
E-mail service 108 illustratively includes connector logic 140, actionable message processing logic 142, and it can include a wide variety of other e-mail functionality and logic 144. In one example, user 126 can interact directly with email service 108. In another example, client email component 132 is used. In the latter example, e-mail service 108 illustratively interacts with client e-mail component 132 to allow user 126 to perform a variety of different e-mail operations. Such operations can include configuring the user's e-mail system with various folders, filters, etc. It can also allow the user to author and send electronic mail messages, receive electronic mail messages, attach attachments to messages, and a wide variety of other things. Connector logic 140 illustratively allows the user to integrate his or her e-mail service with other services 102-104, that the user uses. Specifically, it allows the user to identify which particular notifications from which particular services that the user wishes to receive as email messages within the user's inbox. This is described in greater detail below.
Actionable message processing logic 142 can be a part of connector logic 140 or separate from it. It is shown as being separate from it in
Services 102-104 can also have similar or different components. In addition, they can have some components that are similar and some that are different. For the purposes of the present description, services 102-104 will operate in a similar way with respect to connector logic 140 and actionable message processing logic 142. Therefore, for the sake of the present example, only service 102 will be described in more detail.
In the example shown in
Connector support logic 152 illustratively interacts with connector logic 150 in e-mail service 108 in order to integrate service 102 into e-mail service 108. For purposes of the present discussion, connector support logic 152 allows user 126, through connector logic 140, to configure which types of notifications the user wishes to receive from service 102, as messages within the user's inbox. This is done through a configuration user experience (UEX) which is described in greater detail below.
Connector support logic 152 also acts in conjunction with connector logic 140 to allow a user to perform actions on or within service 102, or using service 102, from with the user's inbox in the user's e-mail system. Thus, in order to perform such actions, the user need not navigate away from the e-mail system to a site hosted by the service, and then use the UI elements exposed by the service. Instead, actionable messages can be provided to the user from the service, within the user's inbox. The actionable messages illustratively have actuatable controls that can be actuated by the user in order to perform actions within the service that spawned the actionable message.
Interaction bot logic 156 illustratively receives user inputs that have natural language or conversational inputs, and processes those inputs to identify an action that the user wishes to perform within service 102. The inputs can be received as electronic mail messages (e.g., SMTP messages), as notifications (e.g., HTTP posts), or in other ways. Bot logic 156 illustratively exposes a conversational interface that parses the natural language inputs to identify actions to be taken within service 102, and it performs those actions. It can also return a result or a response to the user, once the actions have been performed. Similarly, it illustratively has disambiguation logic so that, should any part of the requested action be ambiguous, it can conduct a conversation with the user in order to disambiguate the ambiguous portions. Logic 156 is described in more detail below with respect to
Connector support service-facing logic 160 illustrative interacts with service 102 in order to perform actions, based upon user inputs provided through the user's e-mail service 108. Thus, logic 160 will vary based upon the configuration of the service 102, based upon how the service operates, how it is designed, among other things.
Authentication logic 162 illustratively authenticates the user to the service, for instance, if the user is not logged in. By way of example, it may be that the user attempts to configure service 102 to send particular notifications. However, it may also be that the user is not logged into the service, or has not been authenticated to the service. In that case, as is described in greater detail below, authentication logic 162 conducts an authentication UEX to allow the user to authenticate himself or herself to the service so that he or she can perform the configuration or other actions within the service.
Configuration UEX generator logic 166 illustratively generates the particular configuration UEX that the service 102 desires to conduct for the user, to allow the user to configure the service to send certain notifications to the user's inbox. Again, the particular UEX (and thus the generator logic 166) will vary based upon the type of notifications that are generated by service 102, the type of notifications that the service wishes to allow the user to configure, and a variety of other things.
Notification system interaction logic 164 illustratively includes subscription logic 174, URL endpoint communication logic 176, and it can include other items 178. Subscription logic 174 illustratively interacts with the notification system 150 in service 102 to indicate that the user has subscribed to certain notifications. For instance, once the user goes through the configuration process, the user will have identified certain notifications, or types of notifications, that the user wishes to receive from the service through his or her inbox. In that case, subscription logic 174 interacts with notification system 150 to subscribe the user to those particular notifications. In response, the notification system 150 will determine that the user is associated with a particular URL endpoint, and this will be communicated to the connector logic 140 for this user, by URL endpoint communication logic 176. Similarly, when the notification system 150 for service 102 generates a notification that the user has subscribed to, URL endpoint notification logic 176 may include posting logic that posts the notification, using an HTTP post, to the URL endpoint corresponding to the user who has subscribed to the notification.
Mark-up logic 168 illustratively marks up the notification so that it can be rendered in the user's e-mail system, according to a pre-defined schema. In one example, the mark-up logic marks up the notification in a JSON format or as a JSON string, so that no rendering code needs to be provided by the service 102. Instead, the JSON string can be rendered by the e-mail service 108 or the client e-mail component 132, without receiving any specific rendering information, other than the JSON string.
Table 1 shows one example of an actionable message represented in JSON format. In Table 1, a message card represents the actionable message and it has an action card in it, as part of a potential action property. The specific action represented by the action card in Table 1 is a “move” action. The “move” action is a multi-step action that first allows the user to select from a list and then specify the move. The JSON markup identifies a target API to be called for each step.
It may also be that the particular notification that is generated and rendered in the user's inbox may be an actionable notification. In that case, it will have actuatable user input mechanisms (such as a button, a text box, or a variety of other user actuatable items) that the user can interact with in order to preform actions within service 102. Interaction processing logic 170 detects those user interactions and takes steps needed to perform those actions within service 102.
Connector logic 140 illustratively includes configuration UEX surfacing logic 180, notification endpoint logic 182, notification mark-up parsing logic 184, inbox and group integration and threading logic 186, notification rendering logic 188, notification interaction logic 190, and it can include a wide variety of other items 192. Configuration UEX surfacing logic 180 illustratively includes service identifier 181 that identifies services that the user can configure, and service selector 183 that surfaces the identified services for user selection. Logic 180 then surfaces the configuration UEX generated by generator logic 166 (shown in
Notification endpoint logic 182 illustratively receives the notifications as the HTTP posts that are provided by the notification system 150 in service 102, when a notification is generated. Notification endpoint logic 182 can receive the post in the form of the mark-up generated by mark-up logic 168 (shown in
Notification mark-up parsing logic 184 illustratively parses the notification mark-up to identify the various pieces of the notification that are to be rendered. It can, for example, identify items that are simply to be displayed, or action buttons or actuatable mechanisms, that can be actuated by the user to perform the actions, or a wide variety of other items.
Inbox integration and threading logic 186 can identify whether the present notification should be placed in a conversation thread with other notifications that have been received from service 102. For example, if a variety of different notifications have been received, but they all relate to a particular bug or bug fix, they may be identified as notifications that are part of a common thread, and the corresponding email messages may be thus placed in a conversation thread within the user's inbox. In one example, service 102 will illustratively include threading information in the marked up notification to identify whether the notification belongs in a thread or is to be placed in a conversation thread with other notifications. The threading can be performed in other ways as well.
Notification rendering logic 188 then renders the notification, as a message within the user's inbox. Where it is an actionable message, the user actuatable elements will be rendered as well, and they will be active so that the user can take actions within service 102, without ever leaving the user's inbox.
Notification interaction logic 190 can include interaction detector 194, endpoint identifier logic 196, endpoint interaction logic 198, and a wide variety of other things 200. Interaction detector 194 illustratively detects user interaction with a rendered notification. This can include detecting that the user has actuated one of the user actuatable elements (such as by actuating a button, inputting natural language text, etc.) or in other ways. These are only some examples of user interactions that can be detected by interaction detector 194.
Endpoint identifier logic 196 then identifies an endpoint that is to be interacted with, based upon the user interaction. For instance, it may be that service 102 provides an end point that is to be interacted with when the user interacts with a given actuatable element. In that case, once the user interaction is detected, endpoint identifier logic 196 identifies the particular endpoint that is to be interacted with, based upon the detected user interaction. Endpoint interaction logic 198 then interacts with that endpoint, in a desired way. For instance, it may be that, once the user actuates a user actuatable element, the connector logic 140 is to call a particular application programming interface (API). In that case, when the user actuates that element, endpoint interaction logic 198 calls that API, providing it any needed information obtained from the detected user interaction. By letting the service identify an endpoint to call to perform an action, and then allowing the service, at that endpoint, to take the action itself, this can enhance the security of the service. Again, this is only one example of how endpoint interaction logic 198 can interact with a desired endpoint, based upon a detected user interaction.
In one example, the user can actuate a settings user input mechanism and then choose a particular item to manage the user's connectors.
Service identifier logic 181 then identifies the services that apply to the particular user 126 who will be configuring a connector. This is indicated by block 220 in the flow diagram of
Service selector 183 then displays an actuatable element for the identified services so that the user can select a particular service that the user wishes to configure. Displaying an actuable element for the identified services is indicated by block 232, and detecting user actuation of one of those elements, to select a service for configuration, is indicated by block 234.
Thus, once the user has actuated one of the user actuatable elements, configuration UEX surfacing logic 180 connects to the corresponding service through its configuration UEX generator logic 166, in the configuration support logic 152 for that service. This connection is indicated by block 238 in the flow diagram of
It may be that user 126 is already logged into the selected service, and thus has been authenticated to the service. If not, authentication logic 162 in the connector support logic 152 of the selected service surfaces an authentication experience that allows the user 126 to authenticate himself or herself to the selected service, so that the user can configure that service. This is indicated by block 240 in the flow diagram of
Once the user is authenticated to the selected service, configuration UEX generator logic 166 provides configuration UEX information to the configuration UEX surfacing logic 180 in the connector logic 140 in the user's e-mail service 108. Configuration UEX surfacing logic 180 then surfaces the configuration UEX to the user to allow the user to configure a connector for the service. Surfacing the configuration UEX provided by the service is indicated by block 248 in
The user then interacts with the service, through the configuration UEX, to subscribe to selected notifications that are generated from the service, and that the user wishes to have surfaced as e-mail messages in the user's inbox. Interacting with the service to subscribe to notifications is indicated by block 256 in the flow diagram of
It will be appreciated that the granularity may vary widely based on the service. It may be based on hashtag identifiers, subject matter identifiers, keywords or other things.
The configuration UEX for this service then surfaces the various notification types that the user can select from, as indicated by block 262. It can be seen that, in the present example, the user has selected all notification types including “Card Created”, “Card Moved”, “Comment or Attachment Added to Card”, and “Member Added to Card”. In one example, an additional user input mechanism 264 is also surfaced that allows the user to see additional notifications that the user may wish to subscribe to.
Once the user has selected the various notification types that the user wishes to subscribe to, the user can save that configuration by actuating a user actuatable display element, such as the “save” actuator 266 shown in
When that happens, notification endpoint logic 182 in connector logic 140 sends the subscriber's unique URL endpoint to the notification system 150 in the service, through URL endpoint communication logic 176. Thus, whenever the notification system 150 in service 102 generates one of the selected notifications, URL endpoint communication logic 176 generates an HTTP post to the subscriber's unique URL endpoint, indicative of that notification. Logic 176 can be part of notification system 150 or separate from it, and the posting operation is described in greater detail below.
Sending the subscriber's unique URL endpoint to the notification system in the service is indicated by block 270 in the flow diagram of
Mark-up logic 168 then formats the notification according to a mark-up schema that can be parsed by connector logic 140 in e-mail service 108. Formatting the notification according to such a mark-up schema is indicated by block 282 in
Once the notification has been formatted according to the expected schema, URL endpoint communication logic 176 posts it to the subscriber's unique URL endpoint. This is indicated by block 294 in the flow diagram of
Parsing logic 184 then parses the notification mark-up as indicated by block 298. In doing so, it identifies various portions of the notification, based upon the mark-up, and generates an inbox message from the parsed notification. This is indicated by block 300 in the flow diagram of
Inbox integrating and threading logic 186 can integrate the message into the inbox of the user's e-mail service. It can also, based upon the mark-up information, identify whether the particular message should be threaded with any other notification messages in the user's inbox. For instance, the mark-up may include a thread identifier that identifies a thread that the notification belongs to. The corresponding email message can then be threaded with other messages that have the same thread identifier. This is indicated by block 302. It can generate the e-mail message in the user's inbox in other ways as well, and this is indicated by block 304.
Notification rendering logic 188 then renders the e-mail message in the user's inbox. This is indicated by block 306. When the message is selected by the user, it can render the entire content of the e-mail message, as indicated by block 308. If the notification includes action controls that can be actuated by the user to perform actions relative to the notification, from within the user's inbox, those action controls are rendered and active as well. This is indicated by block 310. The message can be rendered in other ways as well, as indicated by block 312.
Interaction detector 194 then detects any user interactions with the notification message. This is indicated by block 314. For instance, it may be that the user actuates one of the user actuatable controls that were identified in the parsed notification message and rendered for user interaction. Actuation of one of those controls is indicated by block 316. User interactions can be detected in other ways as well, as indicated by block 318.
Endpoint identifier logic 196 then identifies any endpoint that is to be interacted with, based upon the detected user interaction, and endpoint interaction logic 198 interacts with the service 102 that generated that notification, through the identified endpoint. Interacting with the service as specified is indicated by block 320 in the flow diagram of
In one example, the service generates a result or a response corresponding to the user interaction. Notification rendering logic 188 can receive that response and render it as well. This is indicated by block 328 in the flow diagram of
It will also be noted that the protocol used by the connector logic 140 and connector support logic 152 to interact with each other can include other items. For instance, the protocol can call for the connector logic 140 to store any original markup it receives, along with any user interactions, service responses or results, etc. This history can be displayed so users can see this history relative to any action, or it can be accessed by other systems. Further, when connector logic 140 calls a service endpoint, it illustratively includes an identifier identifying who is calling, any authorization tokens, for the caller, and the payload information. It can include other information as well.
The message is a notification that a user has added a card in service 102 (which corresponds to “Service 1” in the display). Recall that this is one of the notifications that the user subscribed to as discussed above. It can also be seen that the notification includes a plurality of user actuatable elements 340, that can be actuated by the user in order to perform an action, within Service 1, from within the inbox display 330 of the user's e-mail service. In one example, the user actuatable elements 340 allow the user to add a note, set a due date, or perform “move” or “view” actions.
In the present example, assume that the user has actuated the “set due date” element 342. In that case, this user interaction is detected by interaction detector 194. Endpoint identifier logic 196 identifies the endpoint in the service 102 to call and endpoint interaction logic 198 calls that endpoint. In the present example, it is assumed that the endpoint instructs the connector logic 140 to display a date picker.
It can also be seen in the example illustrated in
In
Interaction logic 408 can be the same as, or different from, notification interaction logic 190. Interaction detector 410 illustratively detects user interaction with any of the actionable elements that are rendered. API interaction logic 412 then calls the identified API, that is associated with, or corresponds to, the user actuatable element that the user has interacted with. In doing so, logic 412 illustratively performs the desired action (corresponding to the user actuatable element that was actuated by the user) within the service that generated the message.
Logic 156 thus includes natural language payload parsing and understanding logic 424, service manipulation logic 426, response/result generator logic 428, and it can include other items 430. It will also be noted that the various items of logic in interaction bot logic 156 can be separate or remote systems that are called from logic 156, or they can be local.
In the present example, natural language payload parsing and understanding logic 424 receives the natural language input from a particular message 420 or 422 and parses that input to generate a semantic or linguistic understanding of that input. This can be done using a rules-based or heuristically-based system, it can be done using a model, it can be done using context-free grammars or other grammars, or the natural language understanding functions can be performed in a wide variety of other ways.
In one example, the meaning of the natural language input is mapped to a particular action that is to be performed within service 102. Service manipulation logic 426 then manipulates the service to perform that action. For instance, one natural language input may simply be to search for a set of free dates within a calendaring service. In another example, the natural language input may indicate an action which assigns a task to a particular individual within a task management service. These are examples only and a wide variety of other actions can be represented by the natural language input as well.
Once service manipulation logic 426 has manipulated the service to perform the desired action, response/result generator logic 428 can generate any desired response or result and provide it back to the particular system that sent the message or notification 420 or 422, respectively. The response or result can thus be surfaced for the user.
Logic 424 then parses the natural language input to obtain an understanding of the natural language input, as indicated by block 448. It can do this by interacting with a remote natural language understanding system, or it can do it locally, as indicated by blocks 450 and 452, respectively. It can do so in other ways 454 as well.
Logic 424 then correlates the understanding to an action to be performed by or on a given service. This is indicated by block 456. Manipulation logic 426 then interacts with, or manipulates, the service to perform the action. This is indicated by block 458.
Response/result generator logic 428 then returns any response or result of the action to the user through the particular system with which the user sent the system. This is indicated by block 460. For example, the result or response can be returned as an e-mail that is to be rendered within the user's inbox. This is indicated by block 462. It can be returned as a post to the URL endpoint corresponding to the user as indicated by block 464. That post can then be rendered as discussed above, as an e-mail message within the user's inbox. The result or response can be sent and processed in other ways as well, and this is indicated by block 466.
In that case, interactive bot logic 156 can receive the natural language input as a notification action 422 and logic 424 can parse the natural language input to identify this as an assignment task within Service 2.
This type of system also turns email usage into a synchronous system. For instance, email is normally asynchronous. A sender can send an email and may never receive a response to it. However, when user interaction with a message results in an interaction with an API that, itself, results in an http post, this is a much faster and synchronous communication than email.
It will be noted that the above discussion has described a variety of different systems, components and/or logic. It will be appreciated that such systems, components and/or logic can be comprised of hardware items (such as processors and associated memory, or other processing components, some of which are described below) that perform the functions associated with those systems, components and/or logic. In addition, the systems, components and/or logic can be comprised of software that is loaded into a memory and is subsequently executed by a processor or server, or other computing component, as described below. The systems, components and/or logic can also be comprised of different combinations of hardware, software, firmware, etc., some examples of which are described below. These are only some examples of different structures that can be used to form the systems, components and/or logic described above. Other structures can be used as well.
The present discussion has mentioned processors and servers. In one embodiment, the processors and servers include computer processors with associated memory and timing circuitry, not separately shown. They are functional parts of the systems or devices to which they belong and are activated by, and facilitate the functionality of the other components or items in those systems.
Also, a number of user interface displays have been discussed. They can take a wide variety of different forms and can have a wide variety of different user actuatable input mechanisms disposed thereon. For instance, the user actuatable input mechanisms can be text boxes, check boxes, icons, links, drop-down menus, search boxes, etc. They can also be actuated in a wide variety of different ways. For instance, they can be actuated using a point and click device (such as a track ball or mouse). They can be actuated using hardware buttons, switches, a joystick or keyboard, thumb switches or thumb pads, etc. They can also be actuated using a virtual keyboard or other virtual actuators. In addition, where the screen on which they are displayed is a touch sensitive screen, they can be actuated using touch gestures. Also, where the device that displays them has speech recognition components, they can be actuated using speech commands.
A number of data stores have also been discussed. It will be noted they can each be broken into multiple data stores. All can be local to the systems accessing them, all can be remote, or some can be local while others are remote. All of these configurations are contemplated herein.
Also, the figures show a number of blocks with functionality ascribed to each block. It will be noted that fewer blocks can be used so the functionality is performed by fewer components. Also, more blocks can be used with the functionality distributed among more components.
The present discussion has also mentioned a cloud computing architecture. Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location or configuration of the system that delivers the services. In various embodiments, cloud computing delivers the services over a wide area network, such as the internet, using appropriate protocols. For instance, cloud computing providers deliver applications over a wide area network and they can be accessed through a web browser or any other computing component. Software or components of architecture 100 as well as the corresponding data, can be stored on servers at a remote location. The computing resources in a cloud computing environment can be consolidated at a remote data center location or they can be dispersed. Cloud computing infrastructures can deliver services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from a conventional server, or they can be installed on client devices directly, or in other ways.
The description is intended to include both public cloud computing and private cloud computing. Cloud computing (both public and private) provides substantially seamless pooling of resources, as well as a reduced need to manage and configure underlying hardware infrastructure.
A public cloud is managed by a vendor and typically supports multiple consumers using the same infrastructure. Also, a public cloud, as opposed to a private cloud, can free up the end users from managing the hardware. A private cloud may be managed by the organization itself and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installations and repairs, etc.
It will be appreciated that, in various examples of a cloud architecture, it is also contemplated that some elements can be disposed in the cloud while others are not. By way of example, data stores can be disposed outside of the cloud, and accessed through cloud. In another example, various logic or subsystems or components can also outside of the cloud. Regardless of where they are located, they can be accessed directly by a user device, through a network (either a wide area network or a local area network), they can be hosted at a remote site by a service, or they can be provided as a service through a cloud or accessed by a connection service that resides in the cloud. All of these architectures are contemplated herein.
It will also be noted that architecture 100, or portions of it, can be disposed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices, such as palm top computers, cell phones, smart phones, multimedia players, personal digital assistants, etc.
In other examples, applications or systems are received on a removable Secure Digital (SD) card that is connected to a SD card interface 15. SD card interface 15 and communication links 13 communicate with a processor 17 along a bus 19 that is also connected to memory 21 and input/output (I/O) components 23, as well as clock 25 and location system 27.
I/O components 23, in one embodiment, are provided to facilitate input and output operations. I/O components 23 for various embodiments of the device 16 can include input components such as buttons, touch sensors, multi-touch sensors, optical or video sensors, voice sensors, touch screens, proximity sensors, microphones, tilt sensors, and gravity switches and output components such as a display device, a speaker, and or a printer port. Other I/O components 23 can be used as well.
Clock 25 illustratively comprises a real time clock component that outputs a time and date. It can also, illustratively, provide timing functions for processor 17.
Location system 27 illustratively includes a component that outputs a current geographical location of device 16. This can include, for instance, a global positioning system (GPS) receiver, a LORAN system, a dead reckoning system, a cellular triangulation system, or other positioning system. It can also include, for example, mapping software or navigation software that generates desired maps, navigation routes and other geographic functions.
Memory 21 stores operating system 29, network settings 31, applications 33, application configuration settings 35, data store 37, communication drivers 39, and communication configuration settings 41. Memory 21 can include all types of tangible volatile and non-volatile computer-readable memory devices. It can also include computer storage media (described below). Memory 21 stores computer readable instructions that, when executed by processor 17, cause the processor to perform computer-implemented steps or functions according to the instructions. Similarly, device 16 can have a client system 24 which can run various business applications or embody parts or all of tenant 104. Processor 17 can be activated by other components to facilitate their functionality as well.
Examples of the network settings 31 include things such as proxy information, Internet connection information, and mappings. Application configuration settings 35 include settings that tailor the application for a specific enterprise or user. Communication configuration settings 41 provide parameters for communicating with other computers and include items such as GPRS parameters, SMS parameters, connection user names and passwords.
Applications 33 can be applications that have previously been stored on the device 16 or applications that are installed during use, although these can be part of operating system 29, or hosted external to device 16, as well.
Note that other forms of the devices 16 are possible.
Computer 810 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 810 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media is different from, and does not include, a modulated data signal or carrier wave. It includes hardware storage media including both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 810. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 830 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 831 and random access memory (RAM) 832. A basic input/output system 833 (BIOS), containing the basic routines that help to transfer information between elements within computer 810, such as during start-up, is typically stored in ROM 831. RAM 832 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 820. By way of example, and not limitation,
The computer 810 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only,
Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.
The drives and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into the computer 810 through input devices such as a keyboard 862, a microphone 863, and a pointing device 861, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 820 through a user input interface 860 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A visual display 891 or other type of display device is also connected to the system bus 821 via an interface, such as a video interface 890. In addition to the monitor, computers may also include other peripheral output devices such as speakers 897 and printer 896, which may be connected through an output peripheral interface 895.
The computer 810 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 880. The remote computer 880 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 810. The logical connections depicted in
When used in a LAN networking environment, the computer 810 is connected to the LAN 871 through a network interface or adapter 870. When used in a WAN networking environment, the computer 810 typically includes a modem 872 or other means for establishing communications over the WAN 873, such as the Internet. The modem 872, which may be internal or external, may be connected to the system bus 821 via the user input interface 860, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 810, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
It should also be noted that the different embodiments described herein can be combined in different ways. That is, parts of one or more embodiments can be combined with parts of one or more other embodiments. All of this is contemplated herein.
Example 1 is a computing system, comprising:
electronic mail (email) logic that surfaces email user interfaces for user interaction, to perform email functions in an email system;
inbox integration logic that generates a notification email message in an inbox of the email system, based on a notification generated by a service, the notification email message including an action user input mechanism that is actuatable by a user;
notification rendering logic that renders the notification email message in the inbox of the email system, with the action user input mechanism; and
notification interaction logic that interacts with the service to perform an action in the service based on user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system.
Example 2 is the computing system of any or all previous examples and further comprising:
notification markup parsing logic that receives a marked up notification from the service, marked up according to a predefined schema, and parses the marked up notification to identify items in the marked up notification to be rendered, the items including the action user input mechanism.
Example 3 is the computing system of any or all previous examples wherein the notification interaction logic comprises:
interaction detector logic configured to detect user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system.
Example 4 is the computing system of any or all previous examples wherein the notification markup parsing logic is configured to parse the marked up notification to identify an endpoint identifier corresponding to the action user input mechanism.
Example 5 is the computing system of any or all previous examples wherein the notification interaction logic comprises:
endpoint identifier logic configured to obtain the endpoint identifier corresponding to the action user input mechanism in response to user actuation of the action user input mechanism.
Example 6 is the computing system of any or all previous examples wherein the notification interaction logic comprises:
endpoint interaction logic configured to interact with an endpoint identified by the obtained endpoint identifier, to perform an action associated with the action user input mechanism, in response to user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system.
Example 7 is the computing system of any or all previous examples wherein the endpoint comprises an application programming interface (API) and wherein the endpoint interaction logic is configured to call the API to perform the action in response to user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system
Example 8 is the computing system of any or all previous examples wherein the notification interaction logic is configured to receive a response to performing the action, generated by the service, and generate a response display in the inbox of the email system, indicative of the response generated by the service.
Example 9 is a computer-implemented method, comprising:
generating a notification email message in an inbox of an email system, based on a notification generated by a service, the notification email message including an action user input mechanism that is actuatable by a user;
rendering the notification email message in the inbox of the email system, with the action user input mechanism; and
interacting with the service to perform an action in the service based on user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system.
Example 10 is the computer-implemented method of any or all previous examples and further comprising:
receiving a marked up notification from the service, marked up according to a predefined schema; and
parsing the marked up notification to identify items in the marked up notification to be rendered, the items including the action user input mechanism.
Example 11 is the computer-implemented method of any or all previous examples wherein interacting with the service comprises:
detecting user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system.
Example 12 is the computer-implemented method of any or all previous examples wherein parsing the marked up notification comprises:
parsing the marked up notification to identify an endpoint identifier corresponding to the action user input mechanism.
Example 13 is the computer-implemented method of any or all previous examples wherein interacting with the service comprises:
obtaining the endpoint identifier corresponding to the action user input mechanism in response to user actuation of the action user input mechanism.
Example 14 is the computer-implemented method of any or all previous examples wherein interacting with the service comprises:
interacting with an endpoint identified by the obtained endpoint identifier, to perform an action associated with the action user input mechanism, in response to user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system.
Example 15 is the computer-implemented method of any or all previous examples wherein the endpoint comprises an application programming interface (API) and wherein interacting with the endpoint comprises:
calling the API to perform the action in response to user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system
Example 16 is the computer-implemented method of any or all previous examples wherein interacting with the endpoint comprises:
receiving a response to performing the action, generated by the service; and
generating a response display in the inbox of the email system, indicative of the response generated by the service.
Example 17 is a computing system, comprising:
electronic mail (email) logic that surfaces email user interfaces for user interaction, to perform email functions in an email system;
notification markup parsing logic that receives a marked up notification from a service, marked up according to a predefined schema, and parses the marked up notification to identify items in the marked up notification to be rendered, the items including an action user input mechanism;
inbox integration logic that generates a notification email message in an inbox of the email system, based on a notification generated by the service, the notification email message including an action user input mechanism that is actuatable by a user;
notification rendering logic that renders the notification email message in the inbox of the email system, with the action user input mechanism; and
notification interaction logic that interacts with the service to perform an action in the service based on user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system.
Example 18 is the computing system of any or all previous examples wherein the notification interaction logic comprises:
interaction detector logic configured to detect user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system;
endpoint identifier logic configured to obtain an endpoint identifier corresponding to the action user input mechanism in response to user actuation of the action user input mechanism; and
endpoint interaction logic configured to interact with an endpoint identified by the obtained endpoint identifier, to perform an action associated with the action user input mechanism, in response to user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system.
Example 19 is the computing system of any or all previous examples and further comprising:
configuration user experience (UEX) surfacing logic configured to surface a configuration UEX from the service, the configuration UEX exposing a user actuatable item that is actuated to identify a notification for which a notification email message is to be generated in the inbox of the email system.
Example 20 is the computing system of any or all previous examples wherein the endpoint comprises an application programming interface (API) and wherein the endpoint interaction logic is configured to call the API to perform the action in response to user actuation of the action user input mechanism on the notification email message rendered in the inbox of the email system, and wherein the notification interaction logic is configured to receive a response to performing the action, generated by the service, and generate a response display in the inbox of the email system, indicative of the response generated by the service.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
