Patent Publication Number: US-8117555-B2

Title: Cooperating widgets

Description:
RELATED APPLICATION 
     This U.S. Patent Application claims the benefit of priority of U.S. Provisional Application 60/873,869 filed Dec. 7, 2006. 
    
    
     FIELD 
     Embodiments of the invention relate to end-user applications, and more particularly to interactions of end-user applications within an operating environment. 
     BACKGROUND 
     Computing systems enable a user to perform various operations supported by the computing system. Applications are developed to provide functionality and enable a user to perform one or more functions associated with the application. There is a focus in modern work environments with providing access to data and work functionality that a user needs to perform his or her job. Current end-user applications for performing work are generally full-featured applications, which have limitations on the interfaces provided to enable work to be performed. Traditional end-user applications are currently limited to functionality bounded by the environment provided by the application itself. Some applications allow the use of extensions to provide an additional function to an application, or tie in to another full-featured application. However, the use of extensions generally provides more features to an application that may already suffer from “feature-creep,” and the application still has the same limitations on user interfacing. 
     Another class of applications exists in addition to the feature-rich or full-featured applications referenced above. Such applications are generally referred to as “widgets” or “gadgets,” and they are designed to be narrowly defined in scope of functionality and have a dedicated purpose. Traditionally, widgets are considered to be more portable from one platform to another. The functionality of widgets is traditionally limited to games (e.g., tic-tac-toe, sudoku) or novelty features (e.g., cursor followers), and more recently to functional features available over an unsecured Internet connection (e.g., weather indicator, mortgage rate indicator, etc.). Traditionally, widgets suffer many defects that make them unsuitable for use in a work environment. Such defects may include security issues surrounding the use of portable applications, and the limited functionality limits their standalone usefulness in a work environment. There is a general lack in end-user applications, whether full-featured, or widgets, of interactive ability. 
     SUMMARY 
     Methods and apparatuses enable interaction with an end-user application to perform functional operations with a selected item of the end-user application or a selected item of an operating environment of the end-user application. The end-user application has an associated runtime that obtains information relating to a selection of an item, a selection of a target, and a relationship between the item and the target. When the runtime receives an indication of the selection of the item of the end-user application, and a command to have the selected item interact with a target, the runtime can initiate an operation that is based on functionality associated with the selected item and the target type. The end-user application may be a widget, which may include being an enterprise widget. The target type may be, for example, a widget, a folder, the desktop, etc. The interaction may result in, for example, creation of a standalone widget, execution of the functionality, creation of a relationship, etc. 
     In one embodiment, an item from the desktop may be selected and caused to interact with the end-user application to provide additional functionality in the end-user application. The functionality generated in the end-user application is dependent on the type of the item caused to interact with the end-user application. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The following description includes discussion of figures having illustrations given by way of example of implementations of embodiments of the invention. The drawings should be understood by way of example, and not by way of limitation. As used herein, references to one or more “embodiments” are to be understood as describing a particular feature, structure, or characteristic included in at least one implementation of the invention. Thus, phrases such as “in one embodiment” or “in an alternate embodiment” appearing herein describe various embodiments and implementations of the invention, and do not necessarily all refer to the same embodiment. However, they are also not necessarily mutually exclusive. 
         FIG. 1  is a block diagram of an embodiment of an operating environment where an item from a widget interacts with another element in the operating environment. 
         FIG. 2  is a block diagram of an embodiment of an operating environment where an item from the operating environment interacts with a widget in the operating environment. 
         FIG. 3  is a block diagram of an embodiment of an operating environment with a widget runtime engine. 
         FIG. 4  is a flow diagram of an embodiment of a process for having an item from a widget interact with another element in the operating environment. 
         FIG. 5  is a flow diagram of an embodiment of a process for having an item from the operating environment interact with a widget in the operating environment. 
     
    
    
     Descriptions of certain details and implementations follow, including a description of the figures, which may depict some or all of the embodiments described below, as well as discussing other potential embodiments or implementations of the inventive concepts presented herein. An overview of embodiments of the invention is provided below, followed by a more detailed description with reference to the drawings. 
     DETAILED DESCRIPTION 
     Functional interactions with end-user applications are provided. An item of an end-user application can be caused to interact with a target (e.g., a widget, a folder, the desktop, etc.). Based on the target type and a functionality associated with the selected item, one or more actions can be initiated (e.g., create a standalone widget, create a relationship, execute the functionality associated with the item, etc.). A runtime of the operating environment may include relationship data that indicates what operations to perform when a particular interaction is initiated, or may have a default interaction. An item could also be selected from somewhere on the operating environment (e.g., another end-user application, an object, a folder, etc.) and caused to interact with an end-user application. The results of the interaction can generally cause an additional functionality to be incorporated into the end-user application. As used herein, the interaction can be the result of a drag-and-drop operation, a copy and paste, a menu selection, etc. 
     Functional interactions as described herein can be applied to any type of end-user application, and may find particular use in cooperation among widgets. As used herein, a widget refers to a class of applications characterized by focused functionality and features, minimized form factor (relative to feature-rich applications), and reduced resource consumption (relative to feature-rich applications). In one embodiment, the widget is an enterprise widget or a business widget, which is a widget further characterized by the ability to connect to a backend enterprise system. Thus, in one embodiment, a widget represents a modularization of functional components of a service oriented architecture (SOA). That is, an SOA provides functionality in the form of enterprise services, which may be associated with business widgets that each provide a single service. 
     The functional interactions are enabled via a framework for collaboration or cooperation between end-user applications. User collaboration can be provided by combining functionality from different end-user applications or combining widgets. Widgets can also cooperate via associations or relationships that the widgets have with other widgets in the same operating environment. As examples of different possible methods for relationships, there may be methods to create a child widget (children widgets) through either spawn-off or tear-off of content, freeze a specific search as a dynamic query, create a functionality shortcut, tear off a selected item from an end-user application, which can initiate an operation on a desktop, and create a widget from a link, for example, by enabling a drag and drop of the link to the desktop to create a widget. An end-user application can also be “filled,” where additional content is provided in the end-user application via, for example, dropping a link or a business object onto the end-user application. A widget can also be dropped into a container, such as a widget briefcase, as discussed in co-pending U.S. patent application Ser. No. 11/867,648, entitled, “WIDGET LAUNCHER AND BRIEFCASE,” and filed concurrently herewith. Other containers or logical structures or object associations could also be used. In one embodiment, dropping an enterprise widget onto another object, of either the same or different type, creates an action. In one embodiment, dropping an enterprise widget onto a function causes an action, such as the creation of a new purchase order. 
     Although the principles of end-user application interaction as discussed herein are applicable to any type of end-user application, particular descriptions are made in reference to widgets and enterprise widgets. Thus, a short discussion of widgets follows by way of example, and not limitation. The functionality of a widget is provided via one or more runtime components within an operating environment in which the widget is instantiated. The principle functionality and/or features of the enterprise widget are provided via a backend service. In one embodiment, an enterprise widget can be understood as being an interactive desktop tool, where a user would generally associate the user interface with the functionality of the enterprise widget. An enterprise widget may also be referred to as an enterprise gadget, a business widget, or a portable logic module (PLM). 
     Widget as used herein should be distinguished from the use of the term “widget” to refer to GUI components such as sliders, buttons, checkboxes, and dropdowns. The World Wide Consortium (“W3C”) define widgets as “usually small client-side applications for displaying and updating remote data, packaged in a way to allow a single download and installation on a client machine . . . . ” Refer to W3C, Widgets 1.0 (W3C Working Draft 9, November 2006). The W3C definition identifies a class of applications referred to herein as widgets. An enterprise widget more specifically includes functionality that enables communication with backend servers within an enterprise environment. Enterprise widget is to be understood broadly to incorporate any diminutive application having backend access. In one embodiment, the enterprise widget contains all business logic necessary to interface with the user and send a request to the enterprise. Alternatively, business logic can be contained within a runtime environment on which the enterprise widget executes. Enterprise widgets permit users to more easily and rapidly access and view data from enterprise/backend systems and to commit data to enterprise/backend systems. 
     In one embodiment, an enterprise widget targets one backend system and one task type. For example, one widget can allow a user to look up a sales order or create a sales order, while another widget permits a user to quickly load files to a collaboration environment by simply dragging and dropping files onto a collaboration widget. The user does not need to interact with a user interface (UI) associated with the collaboration environment (e.g., SAPMats as available from SAP AG of Walldorf Germany). Instead of a user interacting with the UI, the widget can perform the interactions. The invocation of the UI interaction is provided by the interaction with the widget, which is able to interpret the interaction to the desired interface, and is enabled with necessary application programming interfaces (APIs) and/or code to provide the interaction. An enterprise widget can be a proxy for an object instance, can represent a collection of instances, can enable a specific action (e.g., send, look up, enter data, check status), can display a specific aspect of an object (e.g., KPI monitor, conversation tracker, progress tracker, status updater, item capturer), and/or can represent a container for widgets. 
     In one embodiment, the interaction functionality includes the ability to generate an “i-View” widget or an equivalent. SAP i-Views enable a user to relate or drop data within an operating environment of a portal. In one embodiment, a widget runtime enables dragging an item out of a portal and generating a standalone widget from the item obtained from the portal. For example, an i-View widget can result from a right-click on an i-View, which could instantiate a widget right on the desktop of that i-View. 
     In one embodiment, the interactions described herein work in conjunction with other user application solutions. For example, SAP provides a DYNAMIC WORK CENTER, as described in co-pending U.S. patent application Ser. No. 11/413,258, filed Apr. 28, 2006. The Dynamic Work Center provides a dynamic presentation and selection of functions/actions related to a user&#39;s context. Dynamic interfaces from a Dynamic Work Center can provide the ability to click an icon or other item to provide end-user application functionality. The Dynamic Work Center can be a source of an item that interacts with an end-user application as described herein. 
     Additionally, in one embodiment, interoperability of end-user applications can provide extensions of functionality with other existing applications. For example, MICROSOFT OUTLOOK available from MICROSOFT CORPORATION of Redmond, Wash., is a commonly-used workplace application. Note that all trademarks used herein are the property of their respective owners, and are used herein solely for purposes of identification. In one embodiment, an extension to Outlook can enable, for example, a right-click on a person&#39;s contact information to “add to my collaboration widget,” or some other end-user application. 
       FIG. 1  is a block diagram of an embodiment of an operating environment where an item from a widget interacts with another element in the operating environment. Operating environment  100  represents any type of computing system operating environment, which may be understood to include both software and hardware features. Software features may include an operating system or a control interface, user interfaces (such as graphical user interfaces (GUIs)), etc. Hardware components may include the hardware resources such as memory, processor(s), storage, network interfaces, etc. Specific hardware elements illustrated are memory  102  and processor  104 . Memory represents any type of operating memory, which is generally volatile and stores data and/or code to be executed by processor  104 . Processor  104  represents one or more processing resources of operating environment  100 , which may include central processing unit(s) (CPUs), microcontrollers, multi-core devices, etc. Processor  104  generally executes instructions that implement software components of operating environment  100 , including widget  110  or similar applications. 
     In one embodiment, operating environment  100  includes widget  110 . Note that widget  110  could be any type of application, as discussed above. However, reference to the general principles of component interactions can be understood by reference to a widget. The description with reference to a widget should be understood only as representative, and is not limiting on the type of application to which the principles could be applied. 
     Widget  110  may execute in conjunction with widget runtime engine  120 . Widget runtime engine  120  represents one or more logical components that provide functional and control features for widget  110 . Runtime engine  120  also provides such logical components for other widgets running on operating environment  100 . Thus, all widgets designed for runtime engine  120  can be supported by runtime engine  120  on operating environment  100 . A runtime engine can be understood generally as having control features, translation or interpretation blocks, etc. The runtime engine is generally the underlying rendering engine for the widgets of operating environment  100 . Widget  110  may be standalone in reference to the logic or functionality it provides, or the functionality may be provided via runtime engine  120 . In an implementation where widget  110  is replaced with some other application, runtime engine  120  may be logic or code included within the application itself. 
     Widget  110  includes item  112  and item  114 . Items  112  and  114  have a functionality associated with them that widget  110  provides. For example, an item could be a picture or graphic representing a company or a person. An associated function may be to display contact information, or to launch a contact mechanism (e.g., open an email addressed to the contact, generate a chat session, etc.). Another example may be a block of text or data that is associated with a work group collaboration room that can be initiated by interfacing with the text. Another example may be an icon that represents the ability to generate a table, or a report, or a drawing, etc. The examples of what the items may represent are innumerable, and the skilled practitioner will understand that items can be associated with particular functionality. Each widget  110  or other application can be implementation-specific with regards to functionality and items associated with the functionality. 
     The association of items  112  and  114  to particular functionality is illustrated with reference to the dashed lines to, respectively, service  128  of runtime engine  120  and service  116  of widget  110 . As mentioned above, widget  110  may include self-contained logic to provide functionality to widget  110 , as with service  116 . Other functionality may be provided via runtime engine  120 , as with service  128 . In one embodiment, widget  110  is a business widget that connects to a backend enterprise server for its functionality. Such functionality may be accessed via runtime engine  120 . 
     Interactions with items  112  and  114  with other components of operating environment  100  can enable functionality previously unavailable. Illustrative examples are described below which is to be understood as a non-exhaustive discussion of possible implementations. Other interactions are possible with the technology described herein. As described herein, interactions can occur in any of a number of ways, including drag-and-drop, copy/cut-and-paste, menu selection, etc. For purposes of simplicity in description, the following examples are discussed in relation to drag-and-drop, although it will be understood that the drag-and-drop interactions are merely described as representative of any interaction (e.g., selection and command to cause an interaction). 
     In one embodiment, item  112  of widget  110  is dragged and dropped onto operating environment  110 , or a desktop of operating environment  100 . The desktop can be generally understood as a GUI provided by most operating systems that acts as a consistent starting point of operation on a computing device. In one embodiment, dropping item  112  onto the desktop generates new widget  132 . Such an interaction may be described in reference to widget  110  as the “parent widget” and widget  132  as the “child widget.” Note that although described as “parent” and “child,” it is important to understand that child widget  132  exists independently of widget  110 . That is, changes to widget  110  will not affect child widget  132 , opening or closing widget  110  will not affect the state (open or closed) of child widget  132 , etc. Child widget  132  has a life of its own independent of widget  110 . The creation of child widget  132  generates a new widget having item  112 , with the associated functionality (service  128 ). Thus, widget  132  can now provide the functionality of service  128 . In an implementation where item  114  were spawned off of widget  110 , the same logic could be created within widget  132  to have service  116  associated with item  114  in the new widget. In one embodiment, dragging item  112  out of widget  110  onto the desktop removes item  112 , which then exists within widget  132 , but not within widget  110 . Such an interaction can be referred to as “tearing off” functionality. Tear-off functionality could result the creation of an object-centric widget or a function-centric widget, depending on what is torn off. Alternatively, the functionality can be duplicated, and would exist in both widgets  110  and  132 . 
     In one embodiment, item  114  is dragged from widget  110  and dropped on widget  134  (the target). In one embodiment, item  114  may represent widget  110  itself, which could be dropped onto widget  134 . Dropping widget  110  onto widget  134  provides a docking station for widgets. Such a docking station may be a widget briefcase or widget launcher, as described in co-pending U.S. patent application Ser. No. 11/867,648, referenced above. Such an interaction may be considered similar to creating a playlist. The target widget (widget  134  in  FIG. 1 ) can be or become a container that logically associates all the contents of the container. Such functionality is useful for creating groups of widgets commonly used together to provide a “suite” of functionality for a given task. The functionality of the suite consists of associated portable logic blocks that can be added, removed, etc. Dropping item  114  onto widget  114  could also create other relationships between the widgets. For example, dropping item  114  onto widget  134  can create a functional relationship that causes widget  134  to be launched every time item  114  is executed from widget  110 . 
     Runtime engine  120  includes relationship metadata  140 . Relationship metadata  140  can be understood as any information, in any form, which provides a description of a relationship between a widget item and a function, an interaction result or action to perform when items of particular types are dropped on targets of particular types. The relationship metadata can be very specific, and indicate a particular action when a particular functionality is “dropped” onto a target of a particular type. Thus, causing the interaction may include causing runtime engine  120  or a similar component to determine what action to perform. The runtime engine could then initiate the action that is based on the target type and the functionality associated with the item. 
     In one embodiment, item  114  is dropped onto target  136 . Note that although described in reference to item  114  having self-contained functionality, both the interaction with widget  134  and folder  136  could also be applied with item  112  having derived functionality. In one embodiment, folder  136  represents a collection, or a collaboration mechanism (e.g., a collaboration room icon, etc.). If the widget itself were dropped onto folder  136 , in one embodiment, widget  110  would be added to a collection represented by folder  136 . Alternatively, dropping widget  110  onto folder  136  may activate the widget for the collection. If item  114  is dropped onto folder  136 , an object (e.g., a business object) may be added to folder  136 , which could add the object to a collection, or as a resource to collaboration, or as a resource to a project, etc. In one embodiment, a scripting mechanism is defined across widgets to provide a default action, which could be initiated by dropping item  114  onto folder  136 . In one embodiment, a widget may be cloned into the folder. Thus, a user could create multiple instances of the same widget. 
     In one embodiment, drag and drop interactions from widget  110  could include, for example, dropping a person object (which may be represented as item  112 ) onto widget  134 , which may be a search widget. The search widget could be the ARGO enterprise search available from SAP. More details on Argo are available in co-pending U.S. patent application Ser. No. 11/333,961, filed Jan. 17, 2006. Thus, dropping a person item onto the search could result in performing an enterprise search on the person represented by the item. 
     In one embodiment, the interaction can be indicated by the rendering of the interaction. For example, dragging content or objects could create a ghosted image of the item being moved attached to a mouse pointer (e.g., dragging a results list from Argo could show a ghosted list of items to indicate what is being grabbed from Argo). In another example, hovering an item over a drop target could modify the ghosted drag image with an action modifier badge (e.g., the action modifier could be a plus badge when the action is adding the item to the target, or an envelope when the target has an email function). In another example, hovering over a drop target that has multiple drop actions can generate a spring-loaded ghosted menu of several action icons to allow a user to select the desired option without releasing the mouse button (e.g., dragging content on to a ‘person’ drop target could spring open a ghosted menu with options such as send via email (envelope), send via IM (chat bubble), send via SAPMats (SAPMats icon), etc.). 
     In one embodiment, widgets or other applications can be aware of the state of the computing device on which they are executing. For example, a widget can be aware that the computing device is online and connected to a backend, but is outside a firewall. Such device awareness can be linked, for example, to a location manager setting on a MACINTOSH computer available from APPLE COMPUTER, INC., of Cupertino, Calif., or a network connection profile on a WINDOWS machine (Windows is Available from Microsoft). 
     In one embodiment, the items selected from widget  110  to drag and drop to other components of operating environment  100  are objects. The object items can be dropped onto other objects, as described above (e.g., dropping a person object onto a project object, dropping a person object onto an “opportunity” object to assign a project or trigger a message or generate a document). In one embodiment, targets are functions, rather than other objects. For example, dropping a customer object onto an “order” function could initiate a new order being created for the customer. Such an interaction may also cause the customer&#39;s order history to be displayed. The function can be represented in another widget on the desktop. 
     The interaction mechanisms as described herein also provide a new collaboration model. For example, a search for a particular subject, a particular project, or a particular area of expertise within an enterprise may provide a result of a list of individuals. Each individual is identified by a business object. The results could be dragged off the search results (e.g., of a search widget) and dropped onto a collaboration target. The individuals could then all be sent an alert, sent a file, provided with a worklist or an action item, etc. 
       FIG. 2  is a block diagram of an embodiment of an operating environment where an item from the operating environment interacts with a widget in the operating environment. Operating environment  200  provides an example of operating environment  100  of  FIG. 1 . Operating environment  200  includes widget  210 , which can be a widget as described herein, or any other type of end-user application. As used herein, an end-user application is one that has user interface components and mechanisms, as contrasted to applications that are limited to execution by a system and have no interfacing with a user. Operating environment  200  includes memory  202  and processor  204 , which can be understood as hardware resources on which operating environment  200  exists, and on which the applications and components of  FIG. 2  execute. 
     Widget  210  includes various items,  212 - 218 , which are described in more detail below. Item  212  can be considered to be an item associated with a functionality of widget  210  as the widget originally exists. For example, perhaps widget  210  is a standard widget available as part of a software package, and the default configuration of the widget provides for functionality associated with item  212  (the specific functionality is not shown). The functionality could be self-contained within widget  210 , or could be derived from widget runtime engine  220 . 
     Runtime engine  220  represents one or more logical components that provide functional and/or control features for widgets  210  and  230 . In one embodiment, runtime engine  220  includes services  222 - 228 , which represent service interfaces to a backend server or to functionality within operating environment  200  from which functionality of a widget may be derived. Thus, a widget can provide the backend service as its functionality. Runtime engine  220  includes relationship metadata  260 . Relationship metadata  260  can be understood as any information, in any form, which provides a description of a relationship between a widget item and a function, an interaction result or action to perform when items of particular types are dropped on targets of particular types. Thus, runtime engine  220  is enabled to initiate various actions based on interactions between components of operating environment  200 . 
       FIG. 2  represents a static representation of one or more possible implementations where one or more items are incorporated into widget  210  from the surrounding operating environment  200 . Many of the interactions discussed below have already been suggested in the discussion with regards to  FIG. 1 , except that now the interactions will be looked at from the view of widget  210  being the target of an interaction, rather than its source. 
     The interactions may cause various actions within the operating environment. In one embodiment, it can be understood that certain interactions dynamically modify or change end-user applications within operating environment  200 . The dynamic modification is a runtime event, rather than a development or a design-time operation. Thus, an executing end-user application, such as a widget, can have content added to it, or removed or copied from it to create new or modified end-user applications. The end-user applications thus can be considered to be dynamic in terms of the functionality provided, which may be changed in runtime. The flexibility provided by such an approach allows a very customizable work experience, where a user can dynamically establish the functionality necessary to perform the user&#39;s work. 
     In one embodiment, widget  210  can be dynamically modified through interactions with other items in operating environment  200 . For example, widget  230  represents a widget or another application executing on operating environment  200 . Widget  230  includes functional item  232 . Item  232  is functional because there is an associated functionality provided in widget  230  via activation of item  232 . For example, item  232  could be any of the items mentioned above, including an object, a graphic, a text field, as well as a “button” or other interface component with an associated functionality. In one embodiment, dragging and dropping item  232  onto widget  210  generates item  214 , which represents the “same” item in widget  210  as in widget  230 , with the same functionality now existing in widget  210 . Importantly, the functionality exists in widget  210  independent of widget  230 . Thus, widget  210  is capable of producing the functionality independently of the state of widget  230 . In one embodiment, the functionality is removed from widget  230 ; whereas in an alternate embodiment, the functionality is duplicated. 
     Object  242  may also be dragged and dropped onto widget  210 . Object  242  may be present in another application, or may be retrieved from a database or object repository. In one embodiment, dropping object  242  onto widget  210  generates item  216  with an associated functionality. For example, the functionality may be associated with service  222  of runtime engine  220 . Item  216  may be object  242  as incorporated into widget  210 . Thus, business objects can be incorporated into a widget or other application to provide functionality there. Note that incorporation of object  242  refers to generating an instance of the object within the widget. Multiple end-user applications can have instances of the same object. 
     Icon  244  represents a function that exists on a desktop. In one embodiment, dragging and dropping icon  244  initiates the function with respect to widget  210 . In one embodiment, dropping the function onto widget  210  generates the function in widget  210 . Item  216  may be a graphical representation similar to icon  244 , and the functionality may be derived from operating environment  200 , or from a backend. For example, item  216  may be associated with service  222  of runtime engine  220 . 
     Application  250  represents an end-user application that is either a full-featured application or a widget that provides links to objects or services. Link  252  represents a link to an object or feature that exists external to application  250 . In one embodiment, dragging and dropping the link creates item  218  associated with service  219 , which provides a functionality for widget  210 . Dragging and dropping link  252  may further include accessing an object or a service from a backend or a source in operating environment  200  and incorporating the functionality into widget  210 , as illustrated by service  219 . Thus, dropping a link on widget  210  can incorporate a functionality associated with the link target. If link  252  is a link to an object, the data may be displayed in widget  210 . In one embodiment, link  252  is part of an entire results set, which may be dragged and dropped as an entire set onto widget  210 . 
     As an example, an Argo search may result in a list of results, with links to the results. A search in a browser may similarly produce a list of results of services available. In one embodiment, the dragging and dropping creates a metadata layer, which could be generated in relationship metadata  260 , and an object descriptor that identifies what happens. For example, when a user performs a drag operation from Argo, the resulting functionality may depend on knowing what the operation looks like, and what are the methods associated with the operation. Dragging a result into the receiving widget, runtime engine  220  detects the object type and determines how to handle the operation. Based on the determination, functionality may be created, one or more components may be accessed, etc. 
     In one embodiment, the widgets of operating environment  200  have “collaboration intelligence.” That is, for example, widget  210  may have logic to enable it to act as a collaboration mechanism based on certain interactions with items from the desktop. For example, widget  210  may be able to detect that another user desktop has a widget of the same type executing on it. Based on the other widget being online on the other desktop, objects or files dropped onto widget  210  may be immediately sent to the corresponding widget on the other desktop and available to the other user. If the user is online but outside a firewall, widget  210  may email the file to the other user instead of sending it via internal file transfer. Other similar types of interaction and collaboration are also possible. 
       FIG. 3  is a block diagram of an embodiment of an operating environment with a widget runtime engine. Environment  300  represents an example of operating environment  100  of  FIG. 1  or  200  of  FIG. 2 . As represented in environment  300 , widget  310  includes item  312  that is associated with a functionality of widget  310 . Item  302  of environment  300  has an arrow linking it with item  312 , which represents any of the different types of interactions described herein. That is, item  302  and item  312  may be the same item, they may be duplicates of each other, and they represent both interactions of items from widget  310  with environment  300  as well as interactions of items from environment  300  with widget  310 . 
     Environment  300  includes widget runtime engine  320 , which provides an example of a runtime engine or a runtime interaction module according to any embodiment described herein. Runtime engine  320  is illustrated with a number of components; however, implementations of runtime engine  320  could be more or less complex than what is illustrated. In one embodiment, runtime engine  320  includes selection identifier  322 , functionality identifier  324 , context determiner  326 , relationship determiner  328 , and one or more services  330 . Each component is described in more detail below. 
     Selection identifier  322  enables runtime engine  320  to identify an item and a target that are selected on environment  300 . Such capability may be provided by APIs with the operating platform. For example, a GUI may provide an indication of selected items, of copy and paste actions, of drag and drop actions, etc. Selection identifier  322  obtains or receives such information to identify the source and target to determine what interaction can result from the selections. 
     Functionality identifier  324  enables runtime engine  320  identify a functionality associated with a selected item. The functionality may be provided via the end-user application itself (e.g., widget  310 ), or with a supporting module (e.g., runtime engine  320 ), or functionality associated with a backend. In one embodiment, functionality identifier  324  identifies and accesses functionality associated with a link that is dropped into widget  310 . The functionality may be associated with an item via a function call or relationship table within the end-user application. 
     Context determiner  326  enables runtime engine  320  determine a context in which the interaction is taking place. In one embodiment, an end-user application is context-aware, which may include having information to indicate what type of device is executing the application, whether or not the device is online (network connected), whether the device is inside a firewall, whether another corresponding application is executing on another machine, etc. Knowledge of what type of device is executing the application may affect a determination on what action to initiate responsive to the interaction of items and components. That is, different actions may be defined for different contexts. A default action could be applied in most cases, and a specific action be performed if certain conditions exist. For example, a widget could default to emailing a file to another user, unless a corresponding widget is executing on the user&#39;s machine, in which case the file may be directly passed to the other application. 
     Relationship determiner  328  enables runtime engine  320  determine what relationship exists between interacting entities, or what relationship to create for the interacting entities in the case where a relationship does not yet exist and is being created. Particular classes of applications may have particular relationships defined, or relationships may be defined individually for each possible application type. Similarly, relationships may be defined for classes of items or each individual item. In one embodiment, relationship determiner  328  has or has access to relationship metadata, as previously discussed. In one embodiment, relationship metadata is provided by lookup table (LUT)  350 , which may include entry  352 . Entry  352  can include information such as a source, a target, a context, and an action. Thus, the same source could have multiple different actions, depending on the context and target. As mentioned above, the same source-target pair could have different actions based on context. The source refers to the selected item (whether in an application or in the operating environment) and the target refers to the entity with which the selected item will interact (which could be a drop target in the case of dragging and dropping). Note that LUT  350  is shown with only entry  352 , but could include many entries defining multiple scenarios. 
     Services  330  enables runtime engine  320  to access services available either from within environment  300  (e.g., via service source  340 ) or from a backend (via service mediator  360 ). The services can be understood as providing functionality to widget  310 . Some services may be available from the operating platform itself, while others may be backend enterprise services. Backend services are accessed through service mediator  360 , which is an example of a service mediator as described in co-pending U.S. patent application Ser. No. 11/867,650, filed concurrently herewith. As described therein, in one embodiment, the service mediator can be understood as a mash-up of service plugins. A plugin refers to a software program that operates on top of, or dependently with, another program. Plugins may also be referred to as addons. Plugins utilize APIs or similar mechanisms for control and interfacing, may have a specific associated protocol, and may register with the host program and/or with an operating system on which the host program operates. The plugins may be control modules that are executed on service mediator  360 , where service mediator  360  provides user interface and graphical components, and the plugins provide functionality. The plugins enable access to backend  370 , and services available from backend  370 . 
     Various components described herein in  FIGS. 1 ,  2 , and  3  may be a means for performing the functions described. Each component described herein includes software, hardware, or a combination of these. The components can be implemented as software modules, hardware modules, special-purpose hardware (e.g., application specific hardware, application specific integrated circuits (ASICs), digital signal processors (DSPs), etc.), embedded controllers, hardwired circuitry, etc. Software content (e.g., data, instructions, configuration) may be provided via an article of manufacture including a machine readable medium, which provides content that represents instructions that can be executed. The content may result in a machine performing various functions/operations described herein. A machine readable medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., computing device, electronic system, etc.), such as recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). The content may be directly executable (“object” or “executable” form), source code, or difference code (“delta” or “patch” code). A machine readable medium may also include a storage or database from which content can be downloaded. A machine readable medium may also include a device or product having content stored thereon at a time of sale or delivery. Thus, delivering a device with stored content, or offering content for download over a communication medium may be understood as providing an article of manufacture with such content described herein. 
       FIG. 4  is a flow diagram of an embodiment of a process for having an item from a widget interact with another element in the operating environment. Flow diagrams as illustrated herein provide examples of sequences of various process actions. Although shown in a particular sequence or order, unless otherwise specified, the order of the actions can be modified. Thus, the illustrated implementations should be understood only as examples, and the illustrated processes can be performed in a different order, and some actions may be performed in parallel. Additionally, one or more actions can be omitted in various embodiments of the invention; thus, not all actions are required in every implementation. Other process flows are possible. 
     A functional item of an end-user application is selected,  402 . A target in the operating environment of the application is selected,  404 . A user action causes an interaction between the selected item and the target,  406 . The user action is identified and a command generated by the system in response to the user action. The user action, as described above, can be a drag and drop, copy and paste, menu selection, etc. The command initiates the interaction, which a runtime interaction module (such as the widget runtime engine of previous figures) determines what action to initiate responsive to the interaction command,  408 . 
     If the selected target is the desktop, the interaction between the item and the desktop can result in the runtime interaction module creating a child widget on the desktop,  410 . The item that caused the interaction is incorporated into the child widget,  412 , and the item is associated within the child widget with functionality to be provided by the child widget,  414 . The child widget is now a standalone entity executing on the environment of the desktop, and capable of being opened and closed, incorporated into aggregations of widgets, etc. 
     If the selected target is a widget, the interaction can result in a relationship between the end-user application and the widget,  420 . The relationship can be, for example, associating the selected item with a collection or a group of widgets. The relationship can be to place the item in a logical container with other objects. The relationship can be to cause the widget to launch each time the end-user application is opened or the selected item on the end-user application is activated. The runtime interaction module can then store the association in a runtime engine, for example, in a metadata layer. Such information will be available to control subsequent operations of the related entities. 
     If the selected target is a folder or logical container, the interaction can result in the runtime interaction module generating an icon to represent the item,  430 , which is included in the project folder or logical container,  432 . Whatever functions are associated with the folder can be applied also to the newly added item. The icon is related with project data,  434 , thus making the icon and its functionality associated with the project. When the project is viewed, the item will be available with its functionality. 
     If the selected target is some other target not mentioned, the runtime interaction module performs some other defined action based on the item and the target,  440 . 
       FIG. 5  is a flow diagram of an embodiment of a process for having an item from the operating environment interact with a widget in the operating environment. In one embodiment, an item is selected from the operating environment,  502 . The item can be selected from the desktop itself, from a widget or application executing on the application, from a folder, from a data repository, from a link, etc. An end-user application in the operating environment is also selected as a target,  504 . A user operation causes an interaction between the selected item and the target application,  506 . The user operation is converted into commands by the system, which can then be sent to the selected items themselves. In response to receiving the commands indicating the particular interaction caused, a runtime interaction module (such as the widget runtime engine of previous figures) performs various actions. 
     In one embodiment, the runtime interaction module incorporates the item into the target application to create a new component in the application,  508 . The incorporation may include the generation of a text or graphical representation of the component in the application. A graphical representation may be incorporated from the source of the selected item, or a default or generic graphic may be used. In one embodiment, the runtime interaction module determines the type of the item,  510 , including identifying a functionality to associate with the item. The item may have an inherent functionality associated with it, or may be assigned a functionality based on its type (e.g., via a relationship lookup as described above). 
     New functionality is then generated in the end-user application based on the incorporated item,  512 . The functionality incorporated into the end-user application is associated with the incorporated item,  514 . Thus, selection of the incorporated item will generate the functionality in the end-user application. Note that the functionality and the incorporated item are persisted in the end-user application once incorporated. That is, closing the end-user application and opening it again, or resetting the end-user application will not remove the item or the functionality. They become part of the end-user application itself. A revert operation may be available in some implementations. 
     Besides what is described herein, various modifications may be made to the disclosed embodiments and implementations of the invention without departing from their scope. Therefore, the illustrations and examples herein should be construed in an illustrative, and not a restrictive sense. The scope of the invention should be measured solely by reference to the claims that follow.