Embodiments of the present invention relate to sharing information, and more particularly to techniques for coordinating the process of content sharing among applications.
Being able to receive content from a web page is a feature that some applications like Facebook, Pinterest, Evernote, and others successfully exploit. It is very common to find a web page with an embedded functionality to send an image to a board on Pinterest or share an article with friends on Facebook. However, not all web pages contain said sharing functionality, and the ones that do, might contain a limited list of target applications to share with. In order to overcome these limitations, bookmarking services, like AddThis, can be added to a web browser as browser extensions or bookmarklets. Said bookmarking services enable users to share any web page with any of the apps registered to them.
When users share content to an application through a bookmarking service, the application typically receives page level information like the page's URL, title and main image URL. Sometimes the user wants to share more specific information inside a web page, such as: an article, an image other than the main one, or a section of the page that describes an entity like a product. In most cases the bookmarking service lacks a tooling system to easily select and share specific page content with apps. Accordingly, better techniques for coordinating the sharing of web pages' content are desired. Similar limitations exist when the sharing operation involves a source application other than a web browser.
Developing a new application whose core functionality is going to depend on receiving content that its users may send from other applications is a cumbersome task. Consider, for example, receiving said content from web pages. The application may need to make website owners embed a content forwarding functionality to that new application; but, why would they do that for a new application that nobody knows of. This represents a chicken and egg problem that is limiting the arousal of a potential new category of applications that may successfully exploit the capabilities of content sharing. To avoid this chicken and egg problem, some applications have made themselves available through web browser extension which can parse any web page for content or generate content from any web page. However, people do not like web browsers cramped with too many extensions. Wouldn't it be more suitable to have one browser extension, as a sharing coordinator, that does the parsing and content generation for the other web apps?
Besides sharing content, another way applications interact with each other is by using each other services. These services can be grouped into different categories, such as: payment services, storage services, etc. When an application presents available services to perform an action with, it often groups them into those categories; for example, an application may show, to perform payments, options such as: “PayPal”, “Google Wallet”, and “Amazon Payments”. Sometimes the list of third party services for a given category is numerous. Showing too many services or showing a tool where to search for the desired service—because too many are available—is a rough approach usually implemented. Wouldn't it be better if we were able to know which third party services within a category our user uses, so we can show only those ones?
When an application presents a group of third party service as choices to perform an action with, a user is restricted to use one of those services listed by the application to perform said action. For example, a PDF visualizer application might present options to save the PDF file being visualized to the cloud, using the following third party services: Drop Box and Amazon Drive. In some cases the user using the PDF visualizer is not a client of those cloud storage providers, but instead it might be a client of other cloud storage providers such as iCloud or Google Drive, or even a new cloud storage service that was released a couple days ago. In this scenario the user experience in the PDF visualizer application is limited. Accordingly, better techniques that overcome these limitations are desired.
With the popularity of the use of third party services in applications and the proliferation of “The Internet of Things”, task automater services like IFTT and Zapier have become popular. Said services enable end users to integrate the applications they use to create custom tasks involving said applications. The mentioned tasks are typically triggered by one of those applications, and its execution involves performing actions on the others. An example of a task that can be automated comprises a mutual user of an email and cloud storage applications who wants to save the attachments in new emails to the cloud. In order to do so, it would have to be subscribed to a tasker service into which those applications are integrated and, from inside that service, configure the automated task, if the desired email app-cloud storage app integration is supported by the tasker service. Wouldn't it be more natural to configure that automatic task right from inside the email application, right at the moment the idea of such task came into the user's mind, without having to explicitly deal with the tasker service?