HK1180791B - Web application transitioning and transient web applications - Google Patents

Description

Web application transformation and transient WEB applications

Background

Recently, the industry has begun to focus on the concept of integrating a web application or website with a user's computer desktop environment or "desktop". However, challenges associated therewith also exist. For example, it is difficult today for web sites to define the boundaries of their sites for desktop integration purposes. Thus, the boundaries are defined by end users through their own developed client-side scripts. This may be problematic because the end user may not know how to construct a particular web site. For example, the end user may not know all of the connections, associations, or other nuances between web properties that the website uses to provide functionality to the user. Accordingly, the end user's script may not be aware of these connections or nuances, thereby possibly resulting in an unintended or broken user experience.

Furthermore, users today also face the so-called double import (boot) problem. In particular, users have to boot their personal computers, open their browsers, and ultimately launch the particular web application that they wish to work with. This problem is exacerbated by the fact that: browsers are capable of providing users with overly distracting things, such as those that appear in the browser's system window control (chrome), and do not allow users to focus only on specific tasks associated with web applications at hand.

Disclosure of Invention

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 to limit the scope of the claimed subject matter.

The various embodiments provide a mechanism that allows an end user to install web applications and websites on a client device, such as a client device desktop. In accordance with one or more embodiments, client-side code may be used to allow developers associated with a website to define boundaries associated with user interaction and have a run-time engine (enforcement) enforce (enforcement) these boundaries. In at least some embodiments, developers can provide various configurations through JavaScript code for creating a start menu shortcut, navigation, and so-called jumplist integration, as well as a number of other features.

Drawings

Throughout the drawings, like features are referenced with like numerals.

FIG. 1 illustrates an operating environment in which various principles described herein can be used in accordance with one or more embodiments.

FIG. 2 illustrates a web application window in accordance with one or more embodiments.

FIG. 3 illustrates a JavaScript API in accordance with one or more embodiments.

FIG. 4 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments.

FIG. 5 is a flow diagram that describes steps in a web application interaction method in accordance with one or more embodiments.

FIG. 6 illustrates a portion of a client desktop in accordance with one or more embodiments.

FIG. 7 illustrates a JavaScript API in accordance with one or more embodiments.

FIG. 8 illustrates dynamic interactions between a website and a custom (custom) jumplist in accordance with one or more embodiments.

FIG. 9 illustrates a portion of a client desktop in accordance with one or more embodiments.

FIG. 10 illustrates a portion of a client desktop in accordance with one or more embodiments.

FIG. 11 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments.

FIG. 12 is a flow diagram that describes steps of a method in accordance with one or more embodiments.

FIG. 13 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 14 illustrates a client desktop in accordance with one or more embodiments.

FIG. 15 diagrammatically illustrates a drag and drop (drop) operation in accordance with one or more embodiments.

FIG. 16 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments.

FIG. 17 illustrates a client desktop in accordance with one or more embodiments.

FIG. 18 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments.

FIG. 19 illustrates a client desktop in accordance with one or more embodiments.

FIG. 20 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 21 illustrates a client desktop in accordance with one or more embodiments.

FIG. 22 illustrates a relationship between a browser displaying a website, a credential store, an associated web application, and a web application credential store in accordance with one or more embodiments.

FIG. 23 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 24 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 25 illustrates an example of multiple web application instances in accordance with one or more embodiments.

FIG. 26 illustrates a client desktop in accordance with one or more embodiments.

FIG. 27 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 28 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 29 illustrates a client desktop in accordance with one or more embodiments.

FIG. 30 illustrates a client desktop in accordance with one or more embodiments.

FIG. 31 illustrates a client desktop in accordance with one or more embodiments.

FIG. 32 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 33 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 34 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 35 illustrates a relationship between a web application and a browser in accordance with one or more embodiments.

FIG. 36 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 37 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 38 illustrates an example of a transient web application in accordance with one or more embodiments.

FIG. 39 illustrates a site mode browser in accordance with one or more embodiments.

FIG. 40 is a flow diagram that describes steps in a method in accordance with one or more embodiments.

FIG. 41 illustrates an example system that can be used to implement one or more embodiments.

Detailed Description

Overview

The different embodiments provide a mechanism that allows end users to install web applications and websites on client devices, such as client device desktops. In accordance with one or more embodiments, client-side code can be used to allow developers associated with a website to define boundaries associated with user interaction and have a runtime engine enforce these boundaries. In at least some embodiments, developers can provide various configurations through JavaScript code for creating a start menu shortcut, navigation, and so-called jumplist integration, among other features.

Boundaries can be viewed as a developer-defined experience related to how functionality is exposed to an end user. Boundaries are associated with website domains, such as top-level domains and sub-domains that may be associated with individual applications, or a subset of websites hosted (host) on a domain. Thus, the boundaries may be defined by a set of domains, sub-domains, folders, substations, protocols, hosts, paths, etc. that are used to work with a particular web application.

In one or more embodiments, the website may select the functionality described above and below. In this case, the developer may provide code that defines the boundaries of the user's experience with their website, where in some instances the code is expressed in JavaScript. Alternatively or additionally, websites that do not select the functionality described above and below may have a default experience provided for them.

In the following discussion, a section entitled "operating Environment" is provided and describes one environment in which one or more embodiments can be used. Thereafter, a section entitled "integration infrastructure" describes an infrastructure that enables web applications to be integrated into client devices in accordance with one or more embodiments. Next, a section entitled "jumplist integration" describes how a so-called jumplist can be integrated in accordance with one or more embodiments. Next, a section entitled "taskbar pinning" (pin) describes how a web application can be pinned to a taskbar in accordance with one or more embodiments. Thereafter, a section entitled "associating credentials and login sessions" describes how credentials and login sessions can be associated in accordance with one or more embodiments. Next, a section entitled "creating and launching a Web application with associated credentials" describes how a Web application can be created and launched in accordance with one or more embodiments. Following this, a section entitled "Web application task sessions" describes the concept of task sessions in accordance with one or more embodiments. Next, a section entitled "transition between Web application and browser" describes how a transition can be made between a Web application and a browser in accordance with one or more embodiments. Thereafter, a section entitled "creating transient web applications from a browser" describes how transient web applications are created from a browser in accordance with one or more embodiments. Next, a section entitled "transforming transient web applications into installed web applications" describes how transient web applications are transformed into installed web applications in accordance with one or more embodiments. Thereafter, a section entitled "Web application HyperHome button" describes a Home button associated with a Web application in accordance with one or more embodiments. Finally, a section entitled "example System" describes an example system that can be used to implement one or more embodiments.

An exemplary operating environment in which one or more embodiments may be implemented will now be considered.

Operating environment

FIG. 1 illustrates an operating environment in accordance with one or more embodiments, generally at 100. The environment 100 includes a computing device 102 having one or more processors 104, one or more computer-readable storage media 106, and one or more applications 108, where the one or more applications 108 reside on the computer-readable storage media and can be executed by the one or more processors. By way of example, and not limitation, computer-readable storage media may comprise all forms of volatile and non-volatile memory and/or storage media that are typically associated with a computing device. Such media may include ROM, RAM, flash memory, a hard disk, removable media, and the like. One specific example of a computing device is shown and described below in FIG. 41.

Further, the computing device 102 includes a software application in the form of a web browser 110. Any suitable web browser may be used, examples of which are available from the assignee of this document, as well as others. Further, the computer-readable storage medium 106 may include a web application mode browser 111 that operates in the manner described above and below. The web application mode browser 111 acts as a runtime engine that receives and generates API calls from and to websites, supervises the web application installation process, enforces boundaries, and enables functionality as described above and below, respectively. In operation, the web application mode browser is a subtractive version of a full browser that shuts down many of the normal browser functions. In some instances, a web application mode browser may be viewed as a "system-less" browser that does not contain many common browser controls. However, some commands may be exposed through the micro control bar. Thus, the web application mode browser removes much of the user's distraction and allows for a managed, web-site defined user experience in which the web site can control how the user interacts with their web application.

In operation, the web application mode browser may be logically viewed as residing between the website and the operating system of the client device. Thus, the web application mode browser receives calls from the website and in response may generate operating system calls, affecting the functionality described herein. Likewise, the web application mode browser may receive calls from the operating system that affect website functions. For example, the operating system exposes an API that enables interaction with the desktop taskbar. The Web application mode browser may receive calls from the Web site and in response, the browser may generate API calls that enable taskbar functionality as will become apparent below.

The Web application mode browser 111 can be implemented as a stand-alone component. Alternatively or additionally, the Web application mode browser 111 can also be implemented as part of the application 108 and/or browser 110.

Further, environment 100 includes a network 112, such as the Internet, and one or more websites 114 from and to which content may be received and transmitted. As described above and below, such content may include content, such as web applications, that is integrated into a client desktop or otherwise available through a client device.

Computing device 102 may be implemented as any suitable computing device, which may be, by way of example and not limitation, a desktop computer, a portable computer, a handheld computer such as a Personal Digital Assistant (PDA), a cell phone, and so forth.

Having described an exemplary operating environment, consider now a discussion of an infrastructure that allows web applications to be integrated into a client device.

Integrated infrastructure

In accordance with one or more embodiments, a website may select domain navigation provided as part of a more general "site mode" experience. Domain navigation enables websites to customize the behavior of their existing websites when a user accesses links that are inside or outside a particular domain. Upon accessing the links within the developer-specified boundaries, the content can be rendered and consumed within a Web application window rendered by the Web application mode browser as part of the associated Web application. Upon accessing the links outside of the developer-specified boundaries, the associated content can be rendered and consumed inside a default browser that is external to the Web application mode browser. This allows the website to define what domains should be treated as website extensions and which should not.

In one or more embodiments, the navigation domain can be defined by a Web developer and the navigation domain identifies a link, wherein the content of the link is displayed by a Web application mode browser as part of an integrated website or in a default browser outside of the Web application mode browser. In addition, default domain parameters for associating sets of web application pages together may also be defined.

As an example, consider the following single line (in-line) domain page definition:

*contoso.crm.dynamics.com\*;*.microsoft.com\*;

this domain page definition will allow the following forms of URIs to be displayed in the same desktop web application window:

sales.contoso.crm.dynamics.com\*

hr.contoso.crm.dynamics\*

*.microsoft.com\crm\

also, even if the link reference is inside a page within the desktop web application window, the domain page definition may force other URIs to be displayed outside the desktop web application window:

www.bing.com

home.live.com

in the above domain page definition, wildcards are used inside the web application installation API. The API is typically called by the website when the user selects a website integration link provided by the website. The API may populate a web application file or ". webapp" file with information and content of a desktop, taskbar, start menu, or any other suitable location that will be used to initiate a web site shortcut. It is to be appreciated and understood that any suitable file extension can be used to indicate a web application file. Navigation fields and other boundary information are saved within the webapp file.

Upon launching the webapp file, the navigation fields within the file will be enforced by the Web application mode browser 111. The user-selected or website-accessed links continue to run inside the web application window as long as they match the wildcard domain. However, upon detecting a website that is outside of the defined navigation domain, the default browser will be instantiated or otherwise used, and the content associated with the website will be displayed outside of the web application window and inside of the default browser.

As an example, consider fig. 2, which illustrates a web application window 200 with a set of navigation domains consisting of a.com (202), b.com (204), and d.com (206), meaning that all pages from these domains are all displayed inside the web application window 200. When pages from c.com (208) or e.com (210) are accessed from within the web application window 200, these pages will be displayed in the default browser window instead of the web application window 200.

FIG. 3 illustrates a JavaScript API in accordance with one or more embodiments at 300. The illustrated JavaScript API enables a website to integrate a web application with a client desktop. The API defines the navigation domains to be enforced by the web application or runtime engine. In this example, the navigation domains are described in a wildcard expression as shown above. The API enables the content and information on the client device to be used to populate or update the webapp application file 302, as well as to store navigation fields and other information in the file. These navigation domains are implemented at the time the web application is launched.

In the illustrated and described embodiment,. webapp application file 302 includes information that a website defines for its site mode configuration. This information includes a start URL, which is the initial page displayed by the web application mode browser, all navigation domains specified by the website, the web application title, and a so-called website icon (favicon). Other information may also be included, as described below.

Now, once the Web application is launched at the client, the Web application mode browser will read the Web application file and will enforce the boundaries defined therein. As noted above, since the web application experience is defined by developers who are able to know a particular website and its nuances, a complete and integrated user experience may be provided.

FIG. 4 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client device.

Step 400 selects a website integration feature. This step may be performed in any suitable manner. Typically, the steps are performed when a user selects a tool or otherwise takes action to initiate the web application installation process. For example, the user may select a link that enables him to integrate the web application. Specific examples of how this can be done are provided below.

Step 402 creates a web application file on the client device, designated herein as a ". webapp" file. This initially created file may constitute an artifact (artifact) or shell (shell) that is subsequently populated with content and information received from or on behalf of the website. Step 404 populates the web application file with the web application content. This step may be performed in any suitable manner. For example, this step may be performed using a JavaScript API examples of which are provided above and below. Alternatively or additionally, this step may be performed by using a mark (markup) such as HTML.

If a web application file is created on the client and the file is populated with content, the web application can now be launched and interacted with.

FIG. 5 is a flow diagram that describes steps in a web application interaction method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client and software running on a server supporting a website. Accordingly, one column of the figure is labeled "client" to indicate that the steps are performed by or on the client, such as by a web application mode browser, and another column is labeled "website" to indicate that the steps are performed by or on behalf of the website.

Step 500 receives a user selection of a site mode. This step may be performed in any suitable manner. For example, a shortcut installed on a client desktop may be used to receive a site mode selection. In response to receiving the site mode selection, step 502 requests a start URL. The start URL may be found in the web application file described above.

Step 504 receives a start URL request. Step 506 returns the relevant web resource containing the content associated with the start URL to the client.

Step 508 receives the associated web resource and step 510 renders the web resource in the web application window. As described above, the Web application window is rendered by the Web application mode browser. Step 512 receives user interactions related to the resources rendered in the web application window. The user interaction may comprise any suitable type of user interaction. For example, the user interaction may include navigation activity originating inside a web application window. Step 514 determines whether the user interaction is within the boundaries defined by the web application file. If the user interaction is within the boundaries defined by the web application file, step 516 renders content associated with the user interaction in the web application window. On the other hand, if the user interaction is not within the boundaries defined by the web application file, step 518 renders content associated with the user interaction in a default web browser.

In this way, the boundaries of a particular website defined by a website developer may be enforced to ensure that the user experience is preserved as intended by the developer. For example, the website defined start URL is the home page, and subsequent access to the home page in the web application mode will navigate to the start URL, rather than the user's initially defined browser home page. This allows quick access to web application specific pages, rather than some unrelated home pages. This process alleviates the end user the following: that is, their own site-specific experiences must be defined, which may or may not work properly. Thus, a complete, integrated and intelligently managed experience may be provided to the end user.

Having described the example installation and interaction experience, the concept of jumplist integration will now be considered.

Jumplist integration

In one or more embodiments, a developer may enable a website to define a series of so-called jumplist tasks during a desktop integration process that may be used to interact with the website. Further, in at least some embodiments, the website can create and update a customized jumplist.

A jumplist can be thought of as a list that constitutes a set of related tasks or content that is presented to a user. Through jumplists, websites can promote essences of relevant and useful information to users. The jumplist is related to the capabilities or functions of a particular web application. For example, a jumplist for an email application may include tasks that give a user the ability to open a contact, create a new email message, and the like. In some cases, the jumplist may include a list of related and most commonly used commands and data.

In one or more embodiments, the jumplist functionality can be implemented to include both static and dynamic elements.

As described above, a developer may define static elements during a web application installation process that populates a web application file. Settings associated with the static elements may be saved within the web application file. In one or more embodiments, the settings may include a list name and associated task. In at least some instances, static elements may constitute elements that represent common functions.

The settings associated with the dynamic elements may be driven by a web site page running inside a web application window. These settings include settings that dynamically expose discernable indicia to the user. For example, one setting may add an item to the custom jumplist, and one setting may display an overlay icon, examples of which are provided below. In at least some embodiments, the dynamic settings can be cleared each time the web application is launched and can be configured by web application script code.

As an example of a customized jumplist in accordance with one embodiment, consider FIG. 6, which illustrates a portion of a client desktop generally at 600. The custom jumplist 602 is exposed in accordance with one or more embodiments. Here, static elements are shown at 604 and dynamic elements are shown at 606. In this example, the static element list name is "task" and the tasks or static elements include "new email message", "new appointment", "new contact", and "new task". The name of the dynamic element list is "today" and in this example, the task or dynamic element includes a reminder generated from the user's calendar. These dynamic elements are dynamically populated by the associated web site. Thus, in this example, the dynamic element or content is associated with the process of providing notifications to the user and is generally independent of user actions.

As noted above, jumplists may be defined during desktop integration. These task and jumplist definitions may be saved within the web application file. As an example, consider FIG. 7, which illustrates a JavaScript API in accordance with one or more embodiments at 700. The illustrated JavaScript API enables a website to integrate with a client desktop and define a jumplist. This JavaScript API may be the same or similar to the API described with reference to FIG. 3, except that there is a "custom task" and a "custom jumplist". Some of the contents of fig. 3 are omitted here for the sake of brevity. In at least some embodiments, the initial creation of the static list of jumplist tasks can be defined with markup, for example using HTML tags (tags) defined inside an HTML file.

For example, consider the following example in which a static list function is described using metatags:

<META name="msapplication-task"

content="name=Task; uri=http://marap/test3.html;icon-

uri=http://marap/icon3.ico"/>

in one or more embodiments, there is one coupling option at the time of performing the task. For example, a URL associated with a task may open inside the same web application/browser window that contains the currently viewed web page. Alternatively or additionally, a new page may be launched. Alternatively or additionally, a new pop-up window may be displayed.

After the system defines and reads these parameters, they can be used when the user installs a website to his desktop, for example by adding it to a start menu or pinning it on a taskbar, as will be described below. Also, in at least some embodiments, there is a set of dynamic values that can be manipulated by the website client code on the jumplist.

The website uses "custom tasks" to define static tasks as described above. In this example, the static task is a static task for a new message. The API creates a webapp application file 702 on the desktop and stores the navigation fields (as in the example of FIG. 3) and other information, such as information associated with jumplists.

In the illustrated and described embodiment,. webapp application file 702 includes information that a website has defined for its site mode configuration. This information includes the start URL, all navigation domains (not specifically shown) that the website has specified, the web application title, and a so-called website icon. Other information includes the customization tasks associated with the new message as described above, as well as a "customization list". In this example, the custom list element is a dynamic element that can be dynamically populated by the website when the web application is running on the client. Here, the "friend" name contains a header associated with the dynamic content. Thus, in this example, if the user's friends are online, the dynamic content is associated with the process of providing notifications to the user. Here, the customization list is a separate API that is not resident in the web application. However, the customization task resides in a web application.

In operation, items associated with static elements may be prefetched and cached while the web application is running. On the other hand, a website may work while the web application is running and provide items associated with dynamic elements. As an implementation example of how to provide items associated with dynamic elements to a web application while working, consider FIG. 8.

FIG. 8 illustrates how a website can dynamically interact with a custom jumplist to allow a user to know that a message has arrived. In this example, JavaScript 800 illustrates how a website can send updates to pages hosted in a Web application mode browser. Client code running in the browser is responsible for receiving updates, updating on-screen content, and sending requests to the jumplist to update its list. In this example, the website can push information to the jumplist to provide a real-time experience. Here, when the website receives New messages, such as New Message 0 (New Message 0) and New Message 1 (New Message 1), a JavaScript call can be generated from the web application to update jumplist 802. In at least some embodiments, a notification can appear in task bar 804 to inform the user that the relevant information was received. The notifications may appear in any suitable location in the taskbar and may include any suitable type of notification. For example, the notification may appear in or around icon 806 associated with the web application. Alternatively or additionally, the notification may flash to attract the attention of the user.

As an example, consider fig. 9. A portion of a client desktop is illustrated generally at 900. The taskbar 901 includes an icon 902 associated with the current web application. Here, it should be noted that overlay icon 904 has been rendered inside of icon 902. In this example, the user has received a new message, and the website has invoked a web application to cause the overlay icon 904 to be rendered within the icon 902, as described above. This provides notification to the user that a new message has arrived. In response to seeing the overlay icon 904, the user may access jumplist 905 to expose an element 908 indicating an appointment that is currently occurring or about to occur. It should also be noted that element 906 would likewise be exposed. JavaScript snippet 910 illustrates one example of code that may be used to update an overlay icon.

The dynamic interaction between the website and the web application may be performed in other different ways. For example, in at least some embodiments, a preview window can be pushed from a website to a jumplist in response to a user action associated with the website. In the illustrated and described embodiment, the preview window is a miniature view provided by the website. The preview window may be provided in response to any suitable type of user action. For example, in at least some embodiments, the preview window can be pushed from the website to the jumplist in response to a mouse-over on a taskbar icon associated with the website. Alternatively or additionally, the preview window may be provided by placing a cursor over a taskbar icon of the web application and by left clicking.

As an example, consider fig. 10. A portion of a client desktop is illustrated generally at 1000. The taskbar 1001 includes an icon 1002 associated with a current web application. It should be noted here that the user has placed their cursor over icon 1002. In response, the preview window 1004 has been rendered. In operation, an event is transmitted to the web page in response to the user's action of placing their cursor over the icon. The web page may then dynamically provide a preview or a preview window that causes a rendering cache to be rendered in response to receiving the event.

In at least some embodiments, the website can also define toolbar buttons and associated behaviors using a preview window. For example, in the illustrated and described embodiment, the web application comprises a media player application, and three toolbar buttons appear in the user interface tool 1006 that overlays the preview window 1004. These buttons include a pause button, a stop button, and a play button. In at least some embodiments, the toolbar button may be implemented in client code, which avoids having to interact with a remote server. For example, individual buttons may be registered for a particular web page. Each button is configured and assigned an ID. One "listener" is registered for all button events. When a button is pressed, an event is generated and passed back to the browser, which then propagates the event to the registered event listener. The event comprises a button being pressed. This enables disambiguation of the buttons.

Implementation examples

In an implementation example, a web developer may use the following JavaScript functionality to update the custom list in the jumplist and update the taskbar overlay icon.

List creation behavior

The behavior defines a list name that is a custom list title. This value will be displayed as a list title. Optionally, an item list containing the name of the item, the URI value of the item, and the image associated with the item may be initially provided to populate the list. The functionality may be supported when the browser is launched in the web application mode.

List update behavior

The list item values are provided to update a particular list item. The list item values include an item name, a URI value for the item, and an image associated with the item. The functionality may be supported when the browser is launched in the web application mode.

Setting overlay icon

A URI value is specified that points to an icon that will be used as an overlay to an existing taskbar icon. This functionality may be supported when the browser is launched in the web application mode.

Setting preview image

A URI is specified that points to an image that should be used as a pictorial representation of a taskbar preview image (or thumbnail preview). The preview is displayed when the user clicks on the taskbar icon using the left mouse button.

Clearing overlay icons

This function will remove the existing overlay icon on the taskbar icon. This functionality may be supported when the browser is launched in the web application mode.

The Web developer can use the following JavaScript functionality to define and modify a set of toolbar buttons displayed in a taskbar preview window of a particular website.

Toolbar button mounting

The list of button IDs is specified with a tool tip and an image URL. When the user selects the toolbar button, the event will be passed to the website for processing. The website may then disambiguate the button events. The call is performed at least once while opening the site mode window to display the button. This functionality is supported when the browser is launched in the web application mode.

Updating an image

This function identifies the state and visibility of the designated button ID. The state may be enabled or disabled. In at least some embodiments, the button is enabled by default. The view may be displayed or hidden. The defined buttons are visible by default. This functionality is supported when the browser is launched in the web application mode.

FIG. 11 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client device.

Step 1100 selects a website integration feature. This step may be performed in any suitable manner. Typically, this step is performed when a user selects a tool or otherwise takes action to initiate the web application installation process. For example, the user may select a link that enables him to integrate the web application. Specific examples of how this process is performed are provided below.

Step 1102 creates a web application file on the client device, designated herein as a ". webapp" file. This file, when initially created, may constitute an artifact (artifact) or shell, which may then be populated with content and information received from or on behalf of the website. Step 1104 populates the web application file with web application content, which in this example includes a jumplist. This step may be performed in any suitable manner. For example, this step may be performed using the JavaScript API examples of which are provided above. Alternatively or additionally, aspects of this step may be performed by using markup such as HTML.

If the web application file is created and populated on the client, the web application can now be launched at any suitable time.

FIG. 12 is a flow diagram that describes steps of a method in accordance with one or more embodiments. These steps may be performed in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, the method can be performed by software running on the client in association with software running on the server.

Step 1200 receives a user action associated with a jumplist. Any suitable user action may be received, examples of which are provided above. For example, in at least some embodiments, the user action can be received with respect to a specifically displayed jumplist or a jumplist that is not displayed. Alternatively or additionally, the user action may be received with respect to a displayed icon associated with the web application. For example, the icon may be displayed in the desktop taskbar or in any other suitable location. Examples of such actions are provided above.

Step 1202 presents content associated with the user action. For example, the presented content may include the jumplist itself. The jumplist may be presented in response to any suitable type of user action, examples of which are provided above. The presented content may also include content other than the jumplist itself. For example, the customized preview window may be presented in response to a user action, such as a left click on a taskbar icon. For example, a user may choose to create or compose a new email message.

FIG. 13 is a flow diagram that describes steps in a method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client and software running on a server supporting a website. Accordingly, a column of the diagram is labeled "client" to indicate that the steps are performed by or on the client, and a column is labeled "website" to indicate that the steps are performed by or on behalf of the website.

Step 1300 receives information associated with a dynamic jumplist item. Any suitable jumplist items may serve as a basis for receiving information, examples of which have been provided above. Step 1302 generates a notification and step 1304 communicates the notification to a client device running a web application.

Step 1306 receives the notification and step 1308 provides a discernible notification to the user. Any suitable type of discernible notification may be provided. For example, in at least some embodiments, the discernible notification can be a visually discernible notification, such as an overlay icon or a flashing web application icon. Alternatively or additionally, the discernible notification may include a notification that is audibly discernible, such as a ring tone or beep.

Having considered various embodiments associated with jumplist integration, consideration will now be given to discussing how a website is "pinned" on a desktop feature such as a taskbar in accordance with one or more embodiments.

Taskbar fixation

There are a number of different ways in which a web application can be integrated with a client desktop or taskbar. In at least some embodiments, the web application can be integrated with the desktop through a drag-and-drop operation. Alternatively or additionally, the web application may be integrated via menu selection by a web browser. Alternatively or additionally, the web application may be integrated through the associated website itself. Each of these embodiments is discussed below under its own heading.

Integration by drag and drop operation

In one or more embodiments, a web application can be integrated with a desktop or taskbar through a drag and drop operation. As an example, consider fig. 14. A client desktop is shown generally at 1400. Web browser window 1402 includes an address bar 1404 within which a website URL is displayed. An icon named "Website icon" 1406 is displayed in association with the URL. In addition, desktop 1400 includes a taskbar 1408.

FIG. 15 diagrammatically illustrates a drag-and-drop operation in accordance with one or more embodiments. In this example, a cursor is placed over the website icon 1406. By left clicking on a website icon and dragging the icon along the taskbar 1408, the associated web application, which in this example is a message board application, may be pinned to the desktop taskbar 1408. The drag and drop operation initiates the integration process of integrating the web application as described above, thereby pinning it on the taskbar.

In one or more implementations, if a web page associated with a web application has a tab (tab) open in the browser, the associated tab may disappear from the browser window after the website icon is dropped onto the taskbar. Alternatively or additionally, the tag may not necessarily be removed, and instead the contents of the tag may be replaced with a "new tag" page. In the instance of opening a single tab in the browser window, the browser window will disappear after the website icon is fixed on the taskbar. At this point, the tab contained in the initial site may be removed before the browser is closed but after the web application is pinned. Additionally, in at least some embodiments, when a drag operation enters the taskbar, a tooltip in the form of "fix to taskbar" may be presented to inform the user of the pinning functionality.

Further, upon first instantiating the web application, the state of the website or web application pinned on the taskbar may migrate to the newly displayed window. This allows the user to not have to re-enter credentials to the site in order to be able to use the application.

After the website or web application is pinned to the taskbar and the installation process as described above is completed, the web application may now be launched from the taskbar by simply clicking on the associated website icon.

FIG. 16 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client.

Step 1600 receives an indication of a drag-and-drop operation associated with a web application installation. This step may be performed in any suitable manner. In the above-described embodiment, this step is performed when a user drags and drops an icon associated with a website, such as a website icon, to indicate to the website that it is desired to integrate the associated web application with its desktop. For example, a user may drag and drop a website icon to a taskbar, to a quick launch area, or to some other location on the desktop, such as a desktop canvas (canvas). In response to the drag and drop operation, step 1602 creates a web application file. In the illustrated and described embodiment, the initially created web application file is an artifact or shell that does not yet contain information from the associated website, such as, for example, a jumplist task, a start URL, a website icon, or other attributes, such as a static jumplist task, an alternate start URL, an alternate website icon, and so forth. These can be added later through new markup and/or JavaScript APIs as described above. It is to be appreciated and understood that techniques other than those using JavaScript APIs may be equally employed without departing from the spirit and scope of the claimed subject matter.

Integration through browser menu selection

In one or more embodiments, web applications can be integrated via menu selection of a web browser. As an example, consider fig. 17. Therein, a client desktop is shown generally at 1700. The web browser window 1702 includes an address bar 1704 that displays a URL. In addition, desktop 1700 includes a task bar 1706. A browser menu item 1708 in the form of a page menu is displayed. By pulling down the page menu to expose the menu selection 1710, a menu item is displayed or "add to start menu" is selected. By selecting this option, the website or web application may be added to the desktop's start menu and the installation process may be initiated as described above. Alternatively or additionally, an "add to taskbar" menu item or selection may be displayed to enable the initiation of the installation process.

FIG. 18 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client.

Step 1800 receives a browser menu selection. This step may be performed in any suitable manner. In the above embodiments, this step is performed when the user navigates to a particular website, pulls down the browser menu to expose menu selections, and then takes action by selecting a menu item associated with launching a web application associated with the website to install.

Step 1802 creates a web application file in response to receiving a browser menu selection. In the illustrated and described embodiment, the initially created web application file is an artifact or shell that does not yet contain information from the associated website, such as a jumplist task, a start URL, a website icon, and the like. As described above, this information may be added later through a new markup and/or JavaScript API. It is to be appreciated and understood that techniques other than those using JavaScript APIs may be equally employed without departing from the spirit and scope of the claimed subject matter.

Integration through associated websites

In one or more embodiments, the integration of the web application with the desktop can occur from a web page. In these embodiments, a particular website may select an integration activity by using code such as JavaScript to integrate a web application into a desktop. This allows the website to control the integrated launch tool.

As an example, consider fig. 19. Therein, a client desktop is shown generally at 1900. The web browser window 1902 includes an address bar 1904 in which a URL is displayed. In addition, desktop 1900 includes a taskbar 1906. Further, the web page displayed within the browser window 1902 includes a link 1908 entitled "add to desktop". By clicking on the link, the user may initiate the web application installation process as described above.

In at least some embodiments, after a link selection has occurred, a modal confirmation dialog may be presented that explains the user action the user is taking and where to access their newly created shortcut. The confirmation dialog may present the user with the source URL of the page being presented. The displayed URL may contain the complete path of the web site. This may allow the user to verify that the website that he wishes to install is served by the correct site. This may alleviate the situation associated with malicious subdirectories.

In a different implementation, the URL of the website to be integrated with the desktop is checked to confirm that the URL is in the same domain as the webpage containing the URL. If not, an error may be displayed and the operation may fail. After the user confirms the operation, the dialog may be removed and the web application window may be displayed using the correct URL.

FIG. 20 is a flow diagram that describes steps in an installation method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client.

Step 2000 displays a web page with an integrated link. This step may be performed in any suitable manner, examples of which are provided above. Step 2002 receives a selection of an integration link. Step 2004 creates a web application file in response to receiving the link selection. In the illustrated and described embodiment, the initially created web application file is an artifact or shell that does not yet contain information from the associated website, such as jumplist tasks, start URLs, website icons, and the like. As described above, this information may be added later through a new markup and/or JavaScript API. It is to be appreciated and understood that techniques other than those using JavaScript APIs may be equally employed without departing from the spirit and scope of the claimed subject matter.

In at least some embodiments, visual representations of multiple windows or tabs associated with a web application can be provided to a user. As an example, consider fig. 21. Among other things, desktop 2100 includes a taskbar 2102 having web application icons fixed thereon. By clicking on the icon, a cursor is used to launch the web application. In this example, assume that the user has navigated to multiple pages using the start page of the web application. The web application may enable a visualization that displays a collection 2104 of web pages navigated to by a user. In particular, in this example, the set 2104 includes a start page 2106 for the web application and subsequent pages 2108 and 2110 to which the user navigates from the start page.

Having considered different web application integration techniques, consider now a discussion of how user credentials may be associated with a login session for a web application.

Association certificate and login session

Various embodiments enable one or more web applications associated with a website that uses login or credential information to be integrated in a manner that maintains the login or credential information across different instances of the web application.

When the browser navigates to a website that uses login or credential information, the login or credential information may be manually entered or retrieved from a credential store. The credential store may contain user login information, which may be, by way of example and not limitation, a username and password or user credentials for a particular URL. The same URL or website may have multiple entries, and each entry is associated with a different user. Also, the credential store may contain user login information or credentials for multiple URLs.

In at least some embodiments, the web applications associated with the websites that the user logs in may be integrated and interact on the desktop in the manner described above. When integrating such web applications, what website the web application is associated with and the user logged into the website is determined through a process. The process searches the certificate store for the associated login information and/or certificates. The process may then create an association between the user, the created web application, and the related credentials.

By way of example, consider FIG. 22, which illustrates a relationship between a website, a certificate store, and a web application in accordance with one or more embodiments. The browser 2200 displays a website using the login information. In addition to displaying the URL, an icon 2210 is displayed, which can be selected to facilitate integration of the web application, as described above. Certificate store 2220 includes entries that include login information for multiple websites. One such entry is shown at 2230. Here, the entry includes a website URL, a user name, and a password. While FIG. 22 shows the login information as including a username and password, it is to be appreciated and understood that other forms of login information or credentials may be used.

In one or more embodiments, as described above and shown as icon 2240, icon 2210 can be selected and dragged and dropped to taskbar 2235. The process initiates integration of a web application associated with the website. After receiving the selection, which user is currently logged into the website is determined by a process, and the process searches credential store 2220 for the associated credentials. It is to be appreciated and understood, however, that associated credentials may be otherwise determined and/or obtained without departing from the spirit of the claimed subject matter.

Once the user credentials and/or login information are obtained, an association between the credentials and the web application is made in web application credentials store 2250. web application certificate store 2250 may include one or more entries containing data related to associations between websites, web applications, and related certificates.

For example, FIG. 22 illustrates a display that includes a userjsmithCom "related to the website" a.com "2260. In addition to the URL, username, and password information, entry 2260 also includes an application ID or "AppID" that may be used to associate the web application with the corresponding certificate. web application certificate store 2250 also includes information for the same website "a.com" but different usersbsmith2270. The mechanism allows individual web applications from the same website to be associated with different users and credentials associated therewith.

Although not shown in FIG. 22, different forms of user login information and/or credentials may be associated with a web application. For example, in one embodiment, an association may contain a pointer or reference back to information in the certificate store 2220. In another embodiment, web application certificate store 2250 may include information copied from the certificate store. In yet another embodiment, a certificate separate from or in addition to the username and password may be associated with the web application. For example, the biometric information may form the basis of an association created in the web application certificate store.

Having described the relationship between websites, certificate stores, and web applications, consideration will now be given to how web applications can be integrated for websites using associated certificates.

Creating and launching web applications with associated credentials

FIG. 23 illustrates a flow diagram that describes steps in a method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client.

Step 2300 receives a selection of a website syndication feature. Examples of how this process can be performed have been provided above. As described above, the website integration feature is associated with the installation of a web application on a client desktop. In response to receiving a selection of the website integration feature, step 2302 initiates an installation process for installing a web application on a client desktop as described above. In particular, as described above, the initiation of the process on the client may include creating a web application file. Step 2304 obtains session information associated with a current web session associated with a website. This step may be performed in any suitable manner. For example, in one embodiment, the session information may be obtained using a shared memory component between the browser rendering of content associated with the website and the installation process. In another embodiment, the website may automatically forward session information after the website integration feature is selected. In yet another embodiment, the session information may be stored by the browser and subsequently queried.

In response to obtaining the session information, step 2306 obtains credentials associated with the session information. In one embodiment, the credentials store may be queried for logins and/or credentials related to the website the user is logged into. For example, the credentials store may be queried for a username and password associated with the website and user of the current session. Step 2308 associates credentials and/or login information associated with the session information with a web application. This step may be performed in any suitable manner. For example, the certificate may be copied to a web application certificate store for later reference. Alternatively or additionally, a pointer or reference to the certificate in the certificate store may be placed in the web application certificate store. The identification number may be generated based at least in part on the session information and/or credentials to create a unique ID for each instance of the web application and associated credentials and/or login information. The information may be added to a web application certificate store entry to associate the acquired certificate and/or login information with the web application. It is to be appreciated and understood, however, that any suitable technique may be used to associate credentials with web applications without departing from the spirit and scope of the claimed subject matter.

As described above, the unique ID of each web application instance allows multiple instances of a web application to be associated with the same URL or website, where each instance is associated with a different user credential.

FIG. 24 is a flow diagram that describes steps in a method in accordance with one or more embodiments. The method may be performed by any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method are performed by software running on a client.

Step 2400 receives a selection of a web application to launch. This step may be performed in any suitable manner. For example, as described above, icon selection may be made from a taskbar to which the icon is affixed. Alternatively or additionally, the selection may be made from a desktop start menu or system toolbar. Upon receiving a selection of a web application to launch, step 2402 retrieves credentials associated with the web application. For example, in one or more embodiments, the AppID can be used to reference a web application credential store to retrieve login information for a currently logged-in user. Step 2404 retrieves the URL and/or FormID (form ID) associated with the web application and the related certificate. Once the information described in steps 2402 and 2404 is obtained, step 2406 autonomously logs into the associated website without user intervention. After logging into the web site, step 2408 navigates to the start URL as previously described.

Having described how to integrate and launch web applications associated with credentials, consider now discussing several instances of web applications with associated credentials.

Multiple instances of a web application with associated credentials

FIG. 25 illustrates an example of multiple web application instances associated with a certificate. The web application credentials store 2500 includes data related to the web application and associated credentials of the web site. Entries 2510 and 2520 are contained in the web application credential store 2500, each for a different user. As shown in fig. 25, entry 2510 relates to web site "a.com" and contains additional information for logging into the associated web site, such as the username jsmith and password bulldogs. Entry 2510 includes an AppID for associating the entry with web application 2530. Com "is also related to website" a.com, "but it contains login information for user bsmith and is associated with web application 2540. While FIG. 25 illustrates an entry containing a URL/FormID, username, password, and AppID, it is to be appreciated and understood that different forms of association and credential information can be used without departing from the spirit of the claimed subject matter. Thus, two or more data entries in the web application credentials store may include data identifying different web applications integrated on the client desktop, and each entry having different user credentials associated with the same website.

In one or more embodiments, one or more web applications associated with the same website are concurrently available or active. For example, the software module may be configured to enable a web application to be launched via a desktop toolbar and to automatically log an associated user into a website using associated credentials when launching the web application. In addition to launching a single web application, when launching a second web application is selected, the software module may be further configured to enable the second web application to be launched using different user credentials for the same website or a different website.

For example, the two web applications 2530, 2540 of FIG. 25 are activated simultaneously. As described above, each application is related to web site "a.com", but has a different certificate associated therewith. Upon selection and launching of the web application 2530, the web application will automatically log into the website "a.com" using the credentials associated with the user jsmith. Likewise, upon selection and launching of the web application 2540, the web application will log into the website "a.com" using the credentials associated with the user bsmith. Thus, multiple instances of a web application associated with the same website may be activated simultaneously and may be associated with different credentials.

Having described the concept of creating and launching a web application with associated credentials, consider now a discussion of web application task sessions.

Web application task sessions

In one or more embodiments, a task session may be created to enable state information associated with a web application to be saved into the system. By way of example and not limitation, state information may include session cookies, JavaScript state, DOM state, form state, tabs and window positions, window size, URLs, history, and the like.

As state information associated with a particular task session is saved, the web application may be closed and may be reopened at a later time, restoring or supplementing the state information of the (re-hydrate) web application. The state information may be saved either automatically or through a manual selection process.

As an example, consider fig. 26. Therein, desktop 2600 includes a web application window 2602 for planning a trip. Desktop 2600 also includes a taskbar 2604 and a jumplist 2606. The web application directory 2608 provides a storage device that can be used to store task session state information. In the illustrated and described embodiment, the web application catalog 2608 is created in the user space of the system. In this example, the user has two already saved task sessions, one associated with the puerto trip and the other associated with the alaska trip.

In operation, when a user interacts with a web application, the user may select to create and save a task session through any suitable tool. In the illustrated example, jumplist 2606 has a menu item "task" that contains two entries. The first entry "New task Session" enables a user to create a new task session. The second entry "save current task" enables the user to save the current task. By saving the current task, state information associated with the task will remain in the web application directory 2608. The menu item entitled "open task sessions" contains entries that enable the user to restore or supplement previous task sessions that were left in the web application directory 2608. Here, there are two previously mentioned and previously saved task sessions — the puerto rico trip and the alaska trip.

It may be noted from the above example that multiple task sessions may be created and saved for individual web applications. At the time the task session is saved, the application ID associated with the web application may be saved with the task session. The application ID may then be used to determine which web application will consume information associated with the saved task session.

Any suitable techniques and methods may be used to enable task sessions to be created and saved. In at least some embodiments, the system can utilize or otherwise use a crash recovery system associated with a web browser of the system. In this case, the crash recovery function may be triggered when the user chooses to save the current task or create a new task session, for example. The crash recovery function may create an "appdata" file that resides in the user's application data directory and may be used to save information associated with the task session. Those skilled in the art understand the specific operation of a crash recovery system. Accordingly, such systems are not described herein for the sake of brevity.

FIG. 27 is a flow diagram that describes steps in a method for preserving task session state information in accordance with one or more embodiments. These steps may be performed in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, the method can be performed by software running on a client in association with software running on a server.

Step 2700 receives input associated with saving task session state information. Any suitable input may be received. For example, the received input may include input received from a user. Alternatively or additionally, the input may comprise some type of automated programming input. In at least some embodiments, the user input can be received via a jumplist. Alternatively or additionally, the user input may also be received via a shortcut. In the illustrated and described embodiment, the user input indicates that the user wishes to save task session state information associated with the web application. Step 2702 creates or otherwise accesses a task session data structure in the web application directory. The task session data structure will be used to save task session state information. Step 2704 saves the task session state information in a data structure. This step may be performed in any suitable manner. For example, this step may be performed when the user chooses to save the task session state information. Alternatively or additionally, this step may be performed periodically during user interaction with the web application. In at least some embodiments, steps 2702 and 2704 can be performed by a crash recovery system using a web browser. It is to be appreciated and understood that other techniques can be used without departing from the spirit and scope of the claimed subject matter.

FIG. 28 is a flow diagram that describes steps in a method to resume a task session for which state information has been saved in accordance with one or more embodiments. These steps may be performed in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, the method can be performed by software running on a client in association with software running on a server.

Step 2800 receives user input associated with resuming a task session, wherein state information for the task session has been previously saved. Step 2802 accesses a task session data structure in the web application directory. As described above, state information for a task session is maintained in a task session data structure. Step 2804 retrieves task session state information from the web application directory. Step 2806 launches the associated web application and resumes the task session using the task session state information retrieved from the web application directory.

Having described the concept of saving and reusing task session state information, consider now how transitions can be performed between a web application and a browser.

Transition between Web application and browser

In one or more embodiments, a Web application can transition to a browser experience to be able to take advantage of browser capabilities that cannot be provided by a Web application mode browser that enables the Web application. Recall that this is because: in some embodiments, a Web application mode browser is a browser that enables developers to provide a subtractive or system-free window control of a more site-specific experience. For example, such other capabilities excluded from the Web application mode browser may include favorites, toolbars, and/or other plug-ins (add-ons).

In at least some embodiments, content and state associated with individual tags can be migrated from a web application to a web browser. Alternatively or additionally, content and state associated with the plurality of tags and/or complete content and state of the web application may be migrated from the web application to the web browser. Alternatively or additionally, sessions associated with individual tags may be migrated from the web application to the browser.

Consider a situation in which a user launches a web application from their desktop, navigates within it, and opens one or more links in a new tab. As an example, consider fig. 29. Desktop 2900 includes, among other things, a web application window 2902 that contains a portion of a web application for planning a trip. Desktop 2900 also includes a taskbar 2904 from which to launch web applications, such as by clicking on an associated icon fixed on the taskbar. The web application window 2902 includes three tabs 2906, 2908, and 2910. In this example, the user has selected tab 2906 and has a link "click here to search for flights" that may be opened by the user.

Now, assume that the user clicks on the associated link to open it, and once the link is opened, it determines that he wishes to create a favorite item for the website displayed in tab 2906. In this example, the user may open the tools menu 2912 or use some other user interface tool and select an option to open the tab content in the associated web browser. As an example, consider fig. 30 using the same numbers as fig. 29.

Where the tools menu 2912 is opened to expose its contents 3000. In this example, two choices are provided for the user- "open a tag in the browser" and "open WebApp content in the browser. The first selection enables the user to open the contents of the selected tab in the web browser. When a selected tab is opened in a web browser, the content and state of the tab is migrated to the web browser. The web browser may be a browser with an open instance, or alternatively a launched browser. The second option enables the user to open the complete content of the web application in the web browser. When this is done, the content and state of the web application will migrate to the web browser.

Any suitable technique may be used to migrate content and state from a web application tab or web application to a web browser. In at least some embodiments, the migration is performed through a crash recovery system using the web browser, such as the crash recovery system described above. In particular, when a user indicates a desire to migrate content and state from a web application to a web browser, the content and state may be written to a disk of the system, such as by writing an appdata file containing the relevant data to be migrated.

Additionally, in at least some instances, the shared memory can be used to migrate information or data that is not typically used by a crash recovery system of a web browser. For example, data such as certificates and session cookies may be saved in a shared memory, and the shared memory may be used to enable a web browser to use such data.

Once the user selects a particular option displayed in tools menu 2912, the information or data may be migrated to the current instance or a new instance of the web browser and the associated tab in web application window 2902 may be closed. In one or more embodiments, if the tag from which information or data is being migrated is the only tag opened in a web application, the web application may be closed after the migration is completed.

The above approach is equally applicable when the web application and the web browser are running in different processes across process boundaries. In other words, migration using crash recovery systems and shared memory is equally well suited to crossing process boundaries. However, in some cases, process boundaries do not necessarily need to be crossed. Instead, the web application and subsequent web browser functionality may be exposed from within the same process. In particular, in this instance, a Web browser user interface may be instantiated and used in conjunction with Web application window 2902, and functions that are not available through a Web application mode browser may be opened and made accessible through the Web browser's user interface. In operation, one implementation proceeds as follows. First, the web application generates some crash recovery files. The new browser will be launched and the crash recovery information from the crash recovery file loaded. This information will then be used to configure the state of the new browser. When the user is working inside the new browser, he or she will be able to access all browser functionality via the browser's standard user interface.

FIG. 31 illustrates an embodiment in which a user has selected to migrate content and state associated with a tab to a new browser instance. The same numbers are used as in the example of fig. 29. Here, it is assumed that the user selects the menu selection "open tab in browser" for tab 2906 (fig. 30). In response, the content and state of the tab is migrated to a new instance of the web browser, whose associated user interface window is displayed 3100. The user interface window 3100 includes an address bar 3102 associated with tabs that have been migrated from the web application, and a tab 3104. It should be noted that in this example, tab 2906 (FIG. 30) has been closed in web application window 2902, however, because multiple tabs are open, the web application is still open.

FIG. 32 is a flow diagram that describes steps in a method in accordance with one or more embodiments. These steps may be performed in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, the method can be performed by software running on a client in association with software running on a server.

Step 3200 receives user input associated with a process to migrate web application content and/or state to a web browser. Any suitable input may be received. For example, in at least some embodiments, the input can be received through a tool menu exposed by the web application. Step 3202 migrates the web application content and/or state to the web browser. And any suitable technique may be used to migrate web application content and/or state. In addition, content and/or state at any suitable level of granularity may be migrated. For example, content and/or state associated with an individual tab or tabs of a web application may be migrated. Alternatively or additionally, the entire content of the web application may be migratable. Still further, in at least some embodiments, the migration can occur across process boundaries. Alternatively or additionally, the migration may be performed within the same process.

FIG. 33 is a flow diagram that describes steps in a method in accordance with one or more embodiments. These steps may be performed in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, the method can be performed by software running on a client in association with software running on a server.

Step 3300 receives user input associated with the process of migrating the web application content and/or state to the web browser. Any suitable input may be received. For example, in at least some embodiments, the input can be received through a tool menu exposed by the web application. Step 3302 instantiates a user interface of the web browser. Step 3304 exposes functionality using a web browser user interface. Exposing functionality includes enabling interaction with web application content through a user interface of a web browser. In at least some embodiments, the exposed functionality includes functionality that is not available through the Web application or Web application mode browser and that is available to interact with Web application content. Examples of such functionality are provided above. The method of FIG. 33 may be useful in situations where the migration of web application content and/or state is performed within the same process.

FIG. 34 is a flow diagram that describes steps in a method in accordance with one or more embodiments. These steps may be performed in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, the method can be performed by software running on a client in association with software running on a server.

Step 3400 receives user input associated with a process to migrate web application content and/or state to a web browser. Any suitable input may be received. For example, in at least some embodiments, the input can be received through a tool menu exposed by the web application. Step 3402 saves data associated with the web application content. This step may be performed in any suitable manner. For example, in at least some embodiments, at least some data may be written to a disk of the system. Any suitable technique may be used to write data to the disks of the system. For example, in at least some embodiments, a crash recovery system for a web browser can be used to write data to a disk of the system. Still further, in at least some embodiments, step 3402 can be performed by using shared memory shared between the web application and the web browser.

Step 3404 determines whether the web browser is open. If the web browser is open, step 3406 renders the web application content in the web browser using the saved data. On the other hand, if the web browser is not open, step 3408 launches the web browser and returns to step 3406 to use the saved data to present the web application content.

Creating transient web applications from a browser

The different embodiments enable the creation of one or more so-called transient web applications. In at least some embodiments, the transient web application can be created without pinning the transient web application on a taskbar or otherwise integrating the transient web application's related files or markup into the client desktop as described above. For example, a transient web application may not have any user interface tools integrated on the client desktop and provide a way to enable it to be launched or restarted, such as shortcuts in a start menu, shortcut icons on the client taskbar, and so on. However, in such instances, the user may launch the transient web application from a website associated with the transient web application and may access the same functionality provided by the web application with the web application installed or integrated as described above. The user may then turn the transient web application off after it is used. In at least some embodiments, once the transient web application is closed, the user will no longer be able to access a particular instance of the web application, thereby making it impossible to restart the transient web application from the taskbar or start menu of the client desktop. One way to do this is to delete the files or processes created for the web application when the user initially launches it from the associated website. In some embodiments, the transient web application may be transformed into an installed web application, whereby future access to the web application may be provided from the client desktop.

As an example, consider FIG. 35, which illustrates the relationship between a transient web application and a browser. Here, browser 3500 enables access to multiple web pages through a tabbed system, where tab 3510 is associated with the website "any search page" and tab 3520 is associated with "second open page". In one or more embodiments, the transient web application may be created from an open page. In FIG. 35, transient web application 3530 is generated or created by a user selecting tab 3510 and dragging and dropping the selection off of browser 3500 on the desktop. When this occurs, a transient web application file may be created at the temporary location.

It is to be appreciated and understood, however, that the transient web application can be generated in other ways without departing from the spirit and scope of the claimed subject matter. For example, browser 3500 may have a drop down menu to facilitate selection of a web page and subsequent generation of an associated transient web application.

In the context of this document, transient web applications are those that are not installed on a client system in the manner described herein above. However, the website may still perform the same functions in the transient web application that may be performed in the installed web application and provide access to the functions. For example, the website may modify the individual jumplist of the transient web application, set and clear overlay icons, and so forth. Alternatively or additionally, the transient web application may support the same behavior as an installed web application, such as providing a separate set of tabs or windows that open from within the transient web application as described above.

FIG. 36 illustrates a flow diagram that describes steps in a method in accordance with one or more embodiments. The method can be implemented in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method can be implemented by a suitably configured web browser and/or software module on a client device, such as those of FIG. 1.

Step 3600 receives a selection of a website from which a web application may be obtained. This step may be accomplished in any suitable manner, such as by selecting a tab in a tabbed web browser, by dropping down a menu, and so forth. Upon receiving a selection of a website, step 3602 receives input to create a web application on a client device as a transient web application. In one or more embodiments, the processing may include receiving a message or call containing a request or other information that may be used to spawn a web application. In other embodiments, the process may include receiving input resulting from a process in which a user drags and drops a certain token associated with a website. Step 3604 creates a transient web application associated with the selected website. In some embodiments, the process of creating the transient web application will result in a web application file and/or process without integrating it or any associated markup on the client desktop or start menu. For example, the associated file may be saved in a temporary file location that is different from the location where the integrated web application file is placed. Further, in at least some embodiments, the creation of the transient web application can include transferring the website state from the browser to the transient web application.

FIG. 37 illustrates a flow diagram that describes steps in a method in accordance with one or more embodiments. The method can be implemented in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, aspects of the method can be implemented by a suitably configured web browser and/or software module, such as those of FIG. 1.

Step 3700 receives an input to close the transient web application. This step may be performed in any suitable manner. For example, in one embodiment, the processing may include receiving an input from a user selecting a close button on an open transient web application. In another embodiment, the processing may include receiving an input based on a user selecting a close option on a drop down menu of the transient web application. Upon receiving input to close the transient web application, step 3702 closes the transient web application. The process of closing the transient web application may include deleting or removing associated files and processes of the transient web application. Thus, once the transient web application is closed, the user will no longer be able to access its functionality without having to again access it in the manner described above or install it as a non-transient web application, as described below.

Having described the creation and deletion of transient web applications, consider now how a transient web application can be transformed into a fixed or installed web application in accordance with one or more embodiments.

Transforming transient web applications into installed web applications

In one or more embodiments, a transient web application may be transformed into an installed or integrated web application to allow permanent access to the web application after it has been closed. Once transformed, the transient on-demand web application may be considered a non-transient web application.

FIG. 38 illustrates a transient web application containing a jumplist. Taskbar 3800 shows a number of programs that are opened and run on the client device. Transient web application 3810 is a web application that originates from program 3840. Jumplists 3820 are associated with transient web applications 3810. As with the installed or integrated web application, jumplist 3820 has all possible functionality associated with the installed web application. In addition, jumplist 3820 includes an item 3830 entitled "fix this program on the taskbar". Selecting this option fixes the web application on the client taskbar, whereby the web application and associated user interface tools may be installed on the client desktop as described above. This enables web applications that are now no longer transient to be restarted from the desktop. However, it is to be appreciated and understood that any suitable technique may be used to transform a transient web application into a non-transient web application without departing from the spirit and scope of the claimed subject matter. For example, in some embodiments, a transient web application may be added to a start menu of a client desktop in order to integrate and install the web application. In another embodiment, the transient web application may have a drop down menu with an option for initiating the installation process. Of course, there are a number of ways in which a transient web application may be transformed into a non-transient web application.

Web application hyper homepage button

When interacting with a web application, a user may navigate to other domains in addition to the domain directly associated with the website associated with the web application. For example, a user may launch an email web application and may follow an external link to another site, such as a news, shopping, or entertainment site.

In one or more embodiments, the web application home button is provided as part of a user interface experience. The web application home button serves several purposes. First, the web application home button indicates that the purpose of a particular web application mode browser (also referred to as a "site mode browser") instance is for an associated web application. The web application home button may use a trademark or other visual tool to convey this information. Second, the web application home button enables the user to simply and quickly begin returning to the beginning of their web application experience by simply clicking on the web application home button in order to access the start URL. Doing so alleviates the following problems: to access the start URL of an associated website, a particular web application must be closed and restarted. In at least some embodiments, the value associated with the start URL is determined by default from a page for the user to drag and drop a website icon on the taskbar. Alternatively, a web developer may define an HTML tag that describes the start URL as part of its page. This allows it to define an alternate start URL that is different from the page they are currently viewing.

As an example, consider fig. 39. Therein, the Web application mode browser 3900 includes an address bar 3902 in which the URL of the website appears. In addition, a web application home button 3904 appears adjacent to the back and forward navigation buttons. When a user navigates to a domain outside of the website associated with the web application, they may simply click on the web application home button 3904 at any time in order to navigate to the start URL of the website as described in the web application file.

Still further, in at least some embodiments, to convey its context to the user inside the web application rather than the default browser, the back and forward buttons for navigation may use or extract the base color of the site trademark via the home button of the web application to present the identity of the website. In addition, HTML tags may be used to enable the website to specify the color of these buttons as part of its HTML page.

FIG. 40 is a flow diagram that describes steps in a method in accordance with one or more embodiments. The method can be implemented in connection with any suitable hardware, software, firmware, or combination thereof. In at least some embodiments, the method can be implemented by a site mode browser, such as those described above.

Step 4000 navigates the site mode browser to a website start URL associated with a web application installed on the client device. This step may be performed in any suitable manner as the examples provided above. Step 4002 navigates to a different web page. The web page may or may not be associated with the web site associated with the start URL. Step 4004 receives a selection of a web application home button. In response to receiving a selection of the web application home button, step 4006 navigates the site mode browser to the website start URL.

Example System

FIG. 41 illustrates an example computing device 4100 that can be used to implement the various embodiments described above. Computing device 4100 may be, for example, computing device 102 of FIG. 1 or any other suitable computing device.

Computing device 4100 includes one or more processors or processing units 4102, one or more memory and/or storage components 4104, one or more input/output (I/O) devices 4106, and a bus 4108 that allows the various components and devices to communicate with one another. Bus 4108 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. Bus 4108 can include wired and/or wireless buses.

Memory/storage component 4104 represents one or more computer storage media. Component 4104 can include volatile media (such as Random Access Memory (RAM)) and/or nonvolatile media (such as Read Only Memory (ROM), flash memory, optical disks, magnetic disks, and so forth). Component 4104 can include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., a flash memory drive, a removable hard drive, an optical disk, and so forth).

One or more input/output devices 4106 allow a user to enter commands and information into computing device 4100, and also allow information to be presented to the user and/or other components or devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, and so forth.

Various techniques may be described herein in the general context of software or program modules. Generally, software includes routines, programs, objects, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. An implementation of these modules and techniques may be stored on or transmitted across some form of computer readable media. Computer readable media can be any available medium or media that can be accessed by a computing device. By way of example, and not limitation, computer-readable media may comprise "computer-readable storage media".

"computer-readable storage media" include 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-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical 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 a computer.

Conclusion

Various embodiments provide a mechanism that allows end users to install web applications and websites on their desktops. In accordance with one or more embodiments, client-side code can be used to allow developers associated with a website to define boundaries associated with user interaction and have a runtime engine enforce these boundaries. In at least some embodiments, developers can provide different configurations through JavaScript code for creating start menu shortcuts, navigation, and so-called jumplist integration, as well as a variety of other functions.

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.

Claims (14)

1. A computer-implemented method, comprising:

receiving, on a client device, user input associated with migrating web application content and/or state on the client device to a web browser on the client device, the web application content and/or state associated with a web application integrated on the client device through a web application mode browser configured with functionality not available in the web application mode browser, the web application mode browser configured to:

enabling navigation to a domain associated with a web application within a web application mode browser; and

instantiating a default browser for navigating to a domain outside of a domain associated with the web application;

saving data associated with the web application, the saving including an ability to save user credentials associated with the web application; and

in response to the saving, migrating the web application content and/or state to the web browser on the client device, wherein the migrating includes migrating the content and/or state associated with the web application tab.

2. The computer-implemented method of claim 1, wherein the receiving comprises receiving user input through a tool menu exposed by the web application.

3. The computer-implemented method of claim 1, wherein the saving further comprises:

saving at least some data associated with the web application using a crash recovery system associated with the web browser; or

A shared memory is used to hold at least some data associated with the web application.

4. The computer-implemented method of claim 1, wherein the migrating further comprises migrating content and/or state associated with a plurality of web application tags.

5. The computer-implemented method of claim 1, wherein the migrating further comprises migrating content and/or state across a process boundary.

6. The computer-implemented method of claim 1, wherein the migrating further comprises migrating content and/or state within the same process.

7. A computer-implemented method, comprising:

receiving user input associated with migrating web application content and/or state to a web browser, the web application content and/or state associated with a web application integrated on a client device through a web application mode browser, the web application mode browser configured to:

enabling navigation to a domain associated with a web application within a web application mode browser; and

instantiating a default browser for navigating to a domain outside of a domain associated with a web application;

in response to receiving the user input, migrating the web application content and/or state to a web browser, the migrating including migrating the content and/or state within the same process by instantiating and exposing web browser functionality that is not available in the web application mode browser.

8. The computer-implemented method of claim 7, wherein the receiving comprises receiving user input through a tool menu exposed by the web application.

9. The computer-implemented method of claim 7, wherein the migrating further comprises migrating content and/or state associated with a plurality of web application tags.

10. The computer-implemented method of claim 7, wherein the method further comprises saving data associated with the web application content and/or state.

11. The computer-implemented method of claim 10, wherein the saving comprises saving at least some of the data using a crash recovery system associated with the web browser.

12. The computer-implemented method of claim 10, wherein the saving comprises saving at least some of the data using a crash recovery system associated with a web browser, wherein the saving further comprises saving data of the data other than the at least some data using a shared memory.

13. The computer-implemented method of claim 10, wherein the saving comprises saving at least some of the data using a shared memory.

14. The computer-implemented method of claim 10, wherein the saving comprises saving at least some of the data using shared memory, wherein the at least some of the data comprises certificates and/or session cookies.