Patent Application
20140143644
Many websites today include multiple pages in a normal workflow that the user visits. For example, consider an e-commerce website in which a user may start with a search or product catalog before drilling down to a detail page of a particular product. Another example is a real estate website, in which a user starts with an area search for homes and drills down to a home detail page, and perhaps ever further down to photos or other specific details of an individual home. Thus, given a web site comprised of a master page M and numerous details pages D, D′, D″, and so on, in normal usage, a user views page M, then page D, then presses the browser back button to return to page M, then views page D′, and so forth. An email reader is another common example of such a system in which a user starts at a list of messages, and then opens each message in succession.
As web pages have become more complex and included more dynamic and personalized content, the cost and resources consumed loading each page becomes substantial and has noticeable performance implications for the user. In the examples above, standard web programming practice is to implement pages M, D, D′, and D″ as different pages with different uniform resource locators (URLs). Each time the user views a page, the browser will request the resources from that page from the server, which may involve considerable overhead, forcing the user to wait. In particular, when the user navigates from page M to page D, then back to page M, the browser will request the resources for page M twice—once for the original viewing, and again when the user presses the back button. The user expects the back button to immediately display the content for page M, but in some cases, displaying the correct content for page M may involve considerable delay.
A standard method to address this performance problem is to program pages M and D as, effectively, a single page. When a user navigates from page M to page D, the browser does not make a full page request to a new URL. Instead, client side code in page M (typically JavaScript) redraws the contents of the page such that it looks like page D by dynamically swapping in and out (or making visible and invisible) particular content. It appears to the user that the browser has navigated to page D, but in fact, it has not. When the user presses the back button, logic is invoked which redraws the contents of the page to look like page M. This avoids cost of making a second request for page M to the server. This approach works well, but is difficult for web developers to code. If a developer has already created a system that implements pages M, D, D′, and D″ in the simple but slow manner, converting to the more performant solution generally involves substantial changes to the logic used to generate all pages, at significant expense.
Embodiments of the invention may be operational with numerous general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer and/or by computer-readable media on which such instructions or modules can be stored. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Embodiments of the invention may include or be implemented in a variety of computer readable media. Computer readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media 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 storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
According to one or more embodiments, the combination of software or computer-executable instructions with a computer-readable medium results in the creation of a machine or apparatus. Similarly, the execution of software or computer-executable instructions by a processing device results in the creation of a machine or apparatus, which may be distinguishable from the processing device, itself, according to an embodiment.
Correspondingly, it is to be understood that a computer-readable medium is transformed by storing software or computer-executable instructions thereon. Likewise, a processing device is transformed in the course of executing software or computer-executable instructions. Additionally, it is to be understood that a first set of data input to a processing device during, or otherwise in association with, the execution of software or computer-executable instructions by the processing device is transformed into a second set of data as a consequence of such execution. This second data set may subsequently be stored, displayed, or otherwise communicated. Such transformation, alluded to in each of the above examples, may be a consequence of, or otherwise involve, the physical alteration of portions of a computer-readable medium. Such transformation, alluded to in each of the above examples, may also be a consequence of, or otherwise involve, the physical alteration of, for example, the states of registers and/or counters associated with a processing device during execution of software or computer-executable instructions by the processing device.
As used herein, a process that is performed “automatically” may mean that the process is performed as a result of machine-executed instructions and does not, other than the establishment of user preferences, require manual effort.
A page transition system is described herein that allows for fast switching between a master page and one or more detail pages of a website, without substantial recoding of the website. Instead of substantially recoding pages M and D in the example above to be a single page with intertwining (and complicated) logic, a software library (e.g., implemented in JavaScript) is introduced that handles link-click events in page M, and the back button in page D. When the user clicks a link in M, the content of page M is hidden and the content of page D is displayed in a hypertext markup language (HTML) iframe or similar construct that occupies the entirety of the browser viewport. When the user clicks the back button in page D to return to page M, the iframe is hidden or destroyed, and the content for page M is unhidden (a virtually instantaneous operation). During this process, the content of M may be only loaded once, and is not re-requested from the server when the user returns from D to M. In this way, the system can be dropped into place for existing large websites and web applications, and provides immediate client performance and server scalability benefits without costly recoding. The system also preserves master content contained in hidden document object model (DOM) elements, so page logic continues to work as expected. The system provides for the manipulation of a displayed URL, browser history, and page title to make transitions seamless and appear to the user like the user has navigated from M to D or back even though the user has not done so. Thus, the page transition system provides smooth page transitions that are faster for users and lower in burden on the server.
In some embodiments, the page transition system is implemented by placing all visible content in page M within a single DOM element with a known identifier (ID) (e.g., a single HTML DIV tag). Links in page M that refer to pages D, D′, D″, and so on are handled via an “OnClick” handler or similar device. Upon receiving an indication that a user wants to forward navigate to one of the detail pages, the hander hides the known DOM element in page M, creates an IFRAME that fills the entire browser viewport and displays content from page D, sets the visible URL for the current page to the URL of page D (e.g., using the browser history manipulation application programming interface (API) that was introduced in HTML5), fills the IFRAME with placeholder content while content for D is loading (e.g., the text “Loading . . . ”), and when the content for page D has loaded, copies the title from the IFRAME into the title of the topmost frame (so that the title visible in the browser corresponds to the title for page D). Any other links on page M act as normal. For instance, if a link on page M links to page X, it does not need to change.
When the user wants to backward navigate to a previous page, the system detects the pressing or invocation of the browser back function. The IFRAME displaying content for page D is then hidden or destroyed (if it is expected that the user may return to page D, it may be hidden to allow for a fast re-display of D). The known DOM element for page M is unhidden to display the content for M. The browser title is returned to the title of page M. If page M has any “OnReturn” logic, it is invoked by the system at this point.
On page D, there may be other links to page M, in addition to the “back” button. These links may be overridden or intercepted to perform the same work as the back button. Page D may also contain links to other details pages, such as D′ or D″. These links can also display in the IFRAME, as if the user had clicked to them from page M. The steps to click from page D to D′ are similar to those for clicking from M to D′. The IFRAME has to be updated with content from D′, the browser title and URL are updated, and so forth. Page D may also contain links to pages other than M, and D′. For example, page D may link to page X, which is unrelated to M or D. When the user clicks the link to X, the browser breaks out of the IFRAME that is displaying content for page D. To do this, the browser navigates to page X by setting “window.top.location” or similar depending on the browser (instead of the more typical “window.location”).
The server communication component 110 communicates from a client browser to a web server that provides web pages for a web-based application. The component 110 uses one or more well-known and/or proprietary protocols, such as hypertext transport protocol (HTTP) to transmit requests for web pages and to receive web-based responses, such as HTML, XML, or other data. The server communication component 110 may offer a variety of communication modes, such as synchronous web requests as well as asynchronous web requests. An asynchronous web request can allow the web browser to request additional data from the web server without leaving a currently displayed web page.
The page loading component 120 receives web-based information from the web server and prepares the web-based information for display. The information may include HTML or other formatted information for display to the user, and may be arranged using a document object model (DOM) or other hierarchical or non-hierarchical format that can be accessed, modified, and rendered by client side scripting and the web browser. Typically, a user requests a web page by providing a URL to a web site or page within a website, the browser requests information from the specified domain and virtual directory at the URL, and the web server returns information associated with that URL. The page loading component 120 then renders the returned information for display to the user.
The master management component 130 manages rendering and display to a user of a master web page from which a user can navigate to one or more detail web pages. The master web page is an ordinary web page that in the context of a particular web application may be one that a user navigates to frequently. For example, for a web-based email application the page that displays the user's inbox may be a master web page. For a real estate finding application, the search page or results list may be a master web page. The master management component 130 handles the incorporation of the master web page content received from the server into a client side construct, such as an HTML DIV tag, where the display of the master web page can be managed by the client without modifying the web responses received from the server. The component 130 also includes one or more scripts downloaded and executed at the client, that manage the transition to and from master web pages and handle any links on the master web page.
The page rewriting component 140 performs one or more modifications to the master and other web pages received from the server to manage more efficient transitions between master and detail web pages. For example, the component 140 may identify links on a master page that refer to a detail page, and links on a detail page that refer to the master page, and replace those links with references to scripts that carry out the smooth transitions between pages described herein. The page rewriting component 140 is responsible for modifying and or removing any web content on a page that might interfere with or break the illusion of a smooth transition between pages that is designed to look like normal navigation to another page or normal navigation back from one page to a previously visited page.
The detail management component 150 manages rendering and display to the user of one or more detail web pages referenced by the master web page. A detail web page is typically one that the user visits and then returns to the master web page. An example is a car listing on an auto classifieds web site, in which a user may receive a list of results and successively navigate to detail web pages for each of the cars in the results. The rendering of the master and detail web pages typically involves loading data from the server and is time consuming enough to want to avoid reloading the data when possible. Typical web and browser caching is often ineffective for web pages with moderate to high levels of dynamic and personalized content, such that the content is frequently reloaded, possibly as often as each visit to the web page.
The forward transition component 160 navigates a user from the master web page to one of the detail web pages in a manner that hides rather than discarding the master web page. The component 160 effects a transition to the detail web page not by submitting a typical browser request and navigating fully to the detail web page, but rather by requesting and inserting the detail web page into an IFRAME tag or other similar construct on the client side that may allow display of only the detail web page content and hiding of the master web page content. While the detail web page is being displayed, both the master and detail web page content are available in the browser's memory. One reason for this is so that if the user follows the usual model of exiting the detail web page to return to the master web page, the content of the master web page need not be re-retrieved and re-computed to render it to the user. The forward transition component 160 may also modify various elements of the browser experience to provide an illusion to users that the usual behavior of page navigation has occurred. For example, the component 160 may modify the title bar, displayed URL, and browser history to have the same values as navigating to the detail web page separately.
The backward transition component 170 navigates a user form a detail web page back to the master web page by unhiding an in-memory copy of the master web page rather than re-requesting the master web page from the server. The user may press the back button of the browser, select a link to the master web page from the detail web page, or perform some other action that requests navigation to the master web page. In response, the component 170 hides or discards the detail web page information and unhides the master web page information so that it is once again displayed without having to make any requests to the server or wait for the response. Thus, the transition is both faster and less resource intensive to the server. The system 100 does this with little to no modification of web server content. Rather than modifying each page, a web site owner can turn on the system 100 by simply including a script to be downloaded to the client, and an identification of which pages should be treated as master and detail pages. The client then invokes the script, which handles the transitions transparently to the server.
The backward transition component 170 may keep the detail page in memory in the event that the user selects it again. The system 100 can use a variety of heuristics to determine when to discard detail web pages, such as keeping a fixed number in a most recently used cache, discarding a detail page only after another detail page is selected, and so forth. Keeping more detail web pages in memory uses more memory but also allows fast transitions for a greater variety of potential user requests.
The system cleanup component 180 cleans up resources used by the system 100 upon an exit from the master and detail web pages. For example, if the user navigates to another page entirely, the system may clean up resources, such as in-memory cached versions of pages, used to effect the smooth transitions described herein. The system cleanup component 180 may also destroy or discard from memory detail web pages that have not been requested for a certain amount of time or after other pages are requested that indicate that the detail page is no longer likely to be requested.
Continuing in block 220, the system requests and loads the requested master web page from the server. The server provides the master web page as HTML or other markup language and potentially other types of content, such as dynamically loaded personalized content. The dynamically loaded content may include asynchronous JavaScript and XML (AJAX) or other calls that retrieve information from the server after or during loading of the main page content. The process used to load the master web page from the server is sufficiently complex and time consuming that it is desirable not to repeat the process unnecessarily. Thus, the system described herein promotes reuse of the effort spent to load the master web page by avoiding common scenarios under which the master web page's loaded contents are discarded.
Continuing in block 230, the system displays the loaded master web page to the user in a window of the client web browser. The master web page may include a variety of static and interactive elements for the user to view and interact with. In some cases, the system rewrites portions of the page received from the server before displaying the master web page to the user. Because the system wants to reduce discarding the master web page upon navigation to another page, the system may rewrite links to select other pages on the master web page to cause scripting actions to be invoked rather than navigating away from the master web page.
Continuing in block 240, the system intercepts a request to load a detail page from the master web page. The request may originate from the user clicking on a link within the master web page, or performing some other action to select the detail page. The system intercepts the request by previously rewriting the link to point to client side script controlled by the system, rather than the original link target. For example, the system may provide an OnClick handler that is invoked by the client web browser when the user clicks on the link that previously referenced the detail page.
Continuing in block 250, the system requests and loads the detail page from the server. As the master web page, the detail page may contain a variety of static and dynamic content, delivered synchronously and asynchronously to the client web browser. Rather than navigate away from the master web page and load the detail page, the system causes the client web browser to load the detail web page while the master web page is still in memory and displayable. In some embodiments, the system may display a loading indication to the user, such as an hourglass or temporary web page (e.g., with the text “Loading . . . ”) that indicates to the user that more content is coming soon.
Continuing in block 260, the system stores the loaded master web page in a hidden section of a container page. The container page includes containers for isolating multiple pages that can be switched between or among in a single page. The containers may include common HTML tags, such as DIV and IFRAME that are suitable for isolating web content from other web content on the same page, and that allow turning visibility off and on so that various containers can be switched on and off at any given time and under any given circumstances. The system places the master web page in one such container and invokes the DOM of the container page to indicate that the container may not be visible to the user.
Continuing in block 270, the system places the loaded detail page in a second section of the container page, and makes the second section visible to the user. The second section may be a container that is an IFRAME, where the IFRAME displays as the entire content of the page, from the user's perspective. At this point, both the master web page and the detail web page are loaded in the web browser's memory, and should the user elect to return to the master web page the system can cause that to happen by simply hiding the detail page section of the container page and showing the master page section of the container page. This process is described further with reference to
Continuing in block 280, the system displays the loaded detail page to the user in a window of the client web browser. To the user, the detail page appears as if it is the only page loaded, even though the master web page is still in memory. The system may also rewrite portions of the detail web page to cause the system to be invoked upon certain user actions, such as navigating away from the detail page and back to the master web page. Any links on the detail page to the master web page may be overwritten by the system to invoke a script-based handler function that effects the transition smoothly from the in-memory copy of the master web page. The system may also hook the back button using browser scripting elements that allow modification and/or control of the client.
Continuing in block 290, the system optionally modifies browser info to complete an appearance to the user that the detail page has been loaded. These actions may include modifying the address bar, title bar, browser history, and other elements to make it appear to the user that the detail page has been loaded in the traditional manner, rather than being loaded in conjunction with the master web page within the same container page. After block 290, these steps conclude.
Continuing in block 320, the system hides the detail page by selecting an element of the container page that includes the detail web page and hiding that element. The system may execute client side script that accesses a document object model (DOM) representing the container page and included master web page and detail page. Through the DOM, the system can set a visibility property of various sections of the container page, including the element container the detail web page. In addition to hiding the detail page, the system may also destroy the detail page by removing it from memory.
Continuing in block 330, the system optionally destroys the hidden detail page by removing the page from memory and from the container page. Whether the system keeps a detail page in memory depends largely on the type and purpose of the web application employing the system. In applications where users are likely to request the same detail page again, it may be worth retaining the detail page in memory for some amount of time or under certain conditions. For other applications, the extra memory consumed by keeping one or more detail pages in memory after they are no longer being displayed may be undesirable and thus the detail pages may be discarded upon return to the master web page.
Continuing in block 340, the system locates the master web page in memory by identifying an element of the container page that contains the master web page. The system may locate the master web page by invoking the DOM through client script and identifying a DIV or other tag that contains the master web page within the container page.
Continuing in block 350, the system unhides the master web page by modifying the visibility of the element of the container page that contains the master web page. In this way, the detail page has been hidden and the master web page exposed, so that the user once again may see only the master web page. From the user's perspective, the back action has done what it normally does to load the master web page. However, a substantial amount of typical effort has been saved. Namely, the server has not been burdened with another request for the master web page and any dynamic and personalized content of the master web page has already been received and processed for display. Thus, the system displays the master web page much more rapidly than traditional methods, and does so without asking for significant modification of the web pages associated with a web application.
Continuing in block 360, the system restores any modified browser info to complete an appearance that the client web browser has navigated back to the master web page. For example, the system may modify the address bar, title, history, and other browser elements to make it appear to the user that the user has navigated back to the master web page. If the master web page has any “OnReturn” or similar logic, the system also invokes it so that the master web page can refresh any needed content. After block 360, these steps conclude.
The detail page may also contain links to other details pages. The system may also handle and display these other detail pages in an IFRAME or similar element, as if the user had clicked to them from the master web page. The steps to navigate from the first detail page to the second detail page are similar to those for navigating from the master web page to the second detail page.
From the foregoing, it will be appreciated that specific embodiments of the page transition system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
The present application claims priority from U.S. Provisional Application No. 61/710,606, filed Oct. 5, 2012, which is incorporated by reference as if fully set forth herein.
| Number | Date | Country | |
|---|---|---|---|
| 61710606 | Oct 2012 | US |
