Patent Application
20080256457
The present invention relates to user interfaces in general and more particularly to a browser interface for browsing pages served over a network.
The Internet and other networks interconnect computers and computing devices to allow for easy transport of data over network connections. Commonly computers and computing devices are organized using the client-server model, wherein network connections are established between some computers or computing devices that act as servers and some computers or computing devices that act has clients. Of course, some computers or computing devices can act as servers and clients.
An example of a server is a Web server and an example of a client is a Web client such as a personal computer running a Web browser program. Many different Web clients have been developed and variations of Web clients are being developed regularly. Merely by way of example, a Web client could be embodied in a desktop computer, laptop computer, handheld device, cellular telephone, wireless device, electronic device with embedded Web client functionality, or the like. Generally, all that is required is some user interface and a network interface.
In some instances the user interface is an interface to a programmatic user, but more typically the user interface is an interface usable by a human user. The Web client operates according to the interface to issue requests to Web servers, using well-known protocols or later developed protocols. In response to requests received, Web servers return data responses. In a typical description of Web client-server interaction, the HTTP protocol is assumed to be used, wherein the Web client issues a request directed at a particular Web server address for a page represented by a URL in the request and a server responsive to the particular Web server address responds with data that may be a page to be displayed or other data set. Generally, regardless of the actual data being requested and returned, the data returned is referred to as a web page.
A Web client that is capable of presenting all or part of a web page in a user interface to a user and accepting user input wherein at least some of the user input can cause the Web client to present further web pages can be referred to as a “Web browser” because of its common use by a user to navigate among web pages generally considered to be part of a “Web” of pages that reference other pages.
Web browsers are known and are in common use and often provide functionality in addition to presenting web pages and accepting user input related to presented web pages. For example, web pages might include program elements that are executed by a Web browser upon receipt of a web page including such program elements. One example of such program elements are JAVA™ applets.
Web pages also might include program elements that cause a Web server to take an action. For example, a web server might provide portal services, wherein the Web server collects information from various sources and upon request generates a portal page for a Web client. An example of such a portal page is the main Yahoo! page (www.yahoo.com) and personalized pages provided by My Yahoo! (my.yahoo.com). The latter provides for pages to be delivered to Web clients that are customized based on user preferences stored at the server.
Customized web pages and varied layouts often provide a rich user experience, but if the presentation of information requires moving from web page to web page, the experience is less favorable when network delays occur, as the user waits for pages to arrive and refresh. The experience can also be disorienting if the user has to move from page to page to see desired information. While network delays can occur and are typically beyond the control of the web server operator, users typically associate negative experiences due to network delays with the services provided by the web server operator. Therefore, it would be desirable to mitigate perceived delays that might be caused by network delays.
In a client-server system where a client system presents a browser for user interaction with server data or resources, a browser user interface includes functionality to request pages from servers over a network and to process received pages for presentation to a browser user, the browser user interface comprising a graphical display, a user input device and storage for dynamic interface elements received by the browser in connection with received pages, wherein a dynamic interface element is able to be presented as part of the browser user interface and modified in response to selected user input without requiring further interaction with a server. In addition to, or in place of, dynamic interface elements such as slide sheets, the browser user interface might also include a rotation display area, tool displays that can overlay a page, opaquely or semi-transparently, menu structures, and an ability for the user to modify a page layout without requiring server interaction.
The rotation display area might comprise some or all of a display area used for a page display and the browser further comprising storage for a plurality of rotation display items for storing a summary and a primary presentation for each rotation display item, logic for displaying, by the browser, primary presentations for less all of the plurality of rotation display items in the rotation display area, logic for displaying, by the browser, summaries for items wherein the number of summaries is greater than the number of primary presentations presented at one time, logic for highlighting, among the summaries displayed, the ones of the summaries that correspond to the primary presentations displayed in the rotation display area; and logic for rotating the plurality of rotation display items to display primary presentations for a different subsets of the rotation display items and for updating highlighting of summaries to correspond to the different subsets of rotation display items.
Other features and advantages of the invention will be apparent in view of the following detailed description and preferred embodiments.
The present invention has many applications, as will be apparent after reading this disclosure. In describing an embodiment of a browser interface system according to the present invention, only a few of the possible variations are described. Other applications and variations will be apparent to one of ordinary skill in the art, so the invention should not be construed as narrowly as the examples, but rather in accordance with the appended claims.
Embodiments of the invention will now be described, by way of example, not limitation. It is to be understood that the invention is of broad utility and may be used in many different contexts.
The example of a browser session is a user at a user location operating a user computer to control a browser, which is typically software running on a general purpose user computer, but might be another device, such as a dedicated hardware browser or firmware operated by a portable device. The browser sends requests over a network for pages or portions of pages and displays received pages or portions of pages. The browser might also maintain local data storage for cookies, cached pages, scripts, code and the like. Typically, the browser requests are directed over the network to page servers, such as HTTP (HyperText Transport Protocol) servers (also called “web servers” as the pages served are often considered part of the World Wide Web of hyperlinked documents). The user can be a human or a machine, but is more often a human user.
A “page” might be a conventional HTML page returned in response to a browser request, which can be a pre-existing page or a page generated in response to the request. The page might contain display portions, formatting portions and executable portions. As used herein, the term page might refer to HTML pages, messages, data blocks, packets, or other structured or unstructured data units that are considered logic units in a page request system.
Referring now to the figures, an exemplary browsing system will now be described.
Once the user initiates an instance of the browser (S1), the browser can accept input from the user. In this example, the user has requested the page identified by the URL (Uniform Resource Locator) “http://PLUS.yahoo.com/index.html” and the browsers gets this request from the user (S2). The browser can get the request by the user typing in the URL, selecting from a bookmark list, clicking on a link of a displayed page or other method. The browser then sends an HTTP request to the server identified with the domain portion of the URL of the request (i.e., “PLUS.yahoo.com” in this example).
Once the server receives the request (S3), it retrieves the page (S4) and sends it to the requesting browser (S5). The page might contain HTML data, such as page text, formatting and the like, but would also contain dynamic elements. One standard for such dynamic elements is the DHTML (Dynamic HyperText Markup Language) standard. Once the browser receives the page (S6), the browser processes the page (S7) and displays the selected layers to the user (S8).
With the selected layers of the DHTML pages displayed, the user might then select an element on the display to cause an action. Some selection might be done by positioning a cursor over an element, while other selection might also include indicating a selection such as by pressing a mouse button with the cursor over an element. Of course, to the browser, the happenstance presence of a cursor somewhere on the display can be treated as a positioning selection, so that the action taken by positioning a cursor might be taken even if the user did not change the position of the cursor as would normally be expected for what is understood as “selecting”.
However a selection action or event is noted, the browser detects or interprets user input (S9) and then takes an action for that selection based on the DHTML code for the element selected (S10). Examples of pages and elements are described below. While DHTML has been in use for presenting content and positioning content, examples shown below provide for tools with interface elements (e.g., buttons, forms) on layers and/or uses of layers for interfacing.
With the advanced search slide sheet, the user can perform advanced searches without appearing to move away from a current page being displayed, as the search toolbar could be part of the currently displayed page, with opening the slide sheet only obscuring a part of that displayed page.
The DHTML “advanced search” link can be represented by a text element 302 or a graphical element, possibly providing a consistent visual language to denote such dynamic links. When a user has not selected the advanced search, the slide sheet remains hidden and when selected, appears to slide down from behind the toolbar. The slide sheet can contain various advanced search option elements. A tabular navigation system can be used within the slide sheet if advanced options need to be separated into sections. Depending on the display real estate available for the slide sheet and the number of elements to be presented, the slide sheet might also include scroll elements to allow for scrolling of the elements within the real estate allotted. In some implementations, the slide sheet could be vertically expandable so that the user can control the real estate used, possibly obviating the need for the scroll bar.
Within the slide sheet shown, a “search” button 306 is provided that might initiate an action that works the same way, or in a similar way, as a “search” button 308 provided in the search toolbar and usable even when slide sheet 301 is hidden. The user can close slide sheet 301 by completing a search, clicking on either search button, clicking outside the slide sheet, clicking the “advanced search” element 302 again or by clicking the “x” close window icon on the top right corner of slide sheet 301.
Such a search slide sheet might be used in various areas of a portal site, such as a main page, a music page, a movies page, a games page, a sports page, a local new/information page and/or a news page. A finance page might incorporate a similar tool for functions such as ticker look up. If each of those pages has different search elements, the side sheets can be different for different pages. The selections made by the user on the slide sheet, or other dynamic interface element, can be stored at the client system and conveyed to the server that sent the page (or other designated server) asynchronously or synchronously (blocking). For example, one server might provide a page to a browser that designates a second server as the server to collect user input collected from a dynamic interface element. Preferably, if a delay is possible all, the client system might take an action based on user input on a dynamic interface element even before a server receives the collected user input,
In some cases, a user might request a page having such DHTML elements, but not nave a browser capable of processing DHTML constructs. In such cases, the DHTML page would be configured to substitute other functionality. For example, when a user with a non-enabled browser selects advanced search element 302, they would be directed to an HTML page for advanced search, typically taking the user away from the page containing the element.
In another instance, dynamic content delivery is provided within a page using dynamic interface elements, thus allowing the user to remain with a page and see additional elements. An example of such a dynamic content delivery construct is shown in
Dynamic layer 400 is used for display of an item 402 and summaries 404 for that item and other items. The summary corresponding to the display item, summary 406 in this case, is shown with a visual cue 408, thus allowing the user to quickly identify which headline is being shown in greater detail above. If the displayed item has associated images or video, or other media, it can be displayed in area 410. Depending on the selection and/or cursor position, the browser might (according to instructions in the page provided by a server) transition automatically through each of the items, showing it in turn and stopping when the user selects a specific item, either by clicking on the item, clicking on the summary, moving the cursor to the summary, or taking another indicative action.
This content delivery mechanism might be found on main pages within properties of a portal web site. In a main news page, top and featured stories can be dynamically rotated in order to serve up more information to the user. The user is able to interrupt the rotation by directly selecting a particular top story from a short list featured on the page, or maybe by just moving the cursor into an item display area or holding down a key. To get the full story (more than just the item shown, in most cases), the user can select the item or the headline.
The automatic transitioning between items can be done in a number of ways. For example, the browser could rotate through the items, fading out one and fading in another. One way to do this is to have the current item in one layer, the next item on another layer, with the next item's layer being transparent and on top of the current layer and gradually increase the opacity of the next item's layer. Alternatively, the current layer might be opaque and on top with that layer gradually becoming more transparent. In some cases, where the items contain media that take time to display, the rotation of a current item out and a next item in might be tied to when the current item is done displaying, such as beginning the transition shortly after the current item is done playing. Where controls are provided to control the playing of media, such as rewind, pause and fast forward, the user might control when the rotation occurs. In any case, the browser should delay enough to allow for comfortable reading of the text presented and present a visual and/or audio cue that a transition is to begin.
When the display transitions from one item to another, the visual cues, such as visual cue 408 would change to the now current item. The order of rotation can be random or defined by some set of rules, but an expected order might be from top to bottom, repeating the top item when the bottom item is rotated out. The list of item summaries (and thus the items) might be sorted at the server by importance or interest.
In addition to the rotated in items and their summaries, dynamic layer 400 might also provide links such as “more top stories” and “see related stories” that take the user away from the current page to new pages, as with conventional links.
Other cues might be provided to the user. For example, a cue might be provided when a user rolls a cursor over the highlighted story to indicate that the rotation is paused. To avoid jarring actions, the browser (again controlled by instructions from the page) might delay action on a roll over for a few seconds and then perform a smooth transition.
Since each of the transitions between items and navigation among elements of dynamic layer 400 can be handled by the browser without reference to a server, the user interaction can happen quickly without concern for network activity or bottlenecks. If statistic information on views is needed, the page can collect status messages and send those to the server (useful for determining which items are of interest over a large audience and which are not), but such server interaction does not delay the display experience.
Such a dynamic layer page might be used in various areas of a portal site, such as a main page, a music page, a movies page, a games page, a sports page, a local new/information page and/or a news page. In some cases, a user might request a page having such DHTML elements, but not have a browser capable of processing DHTML constructs. In such cases, the DHTML page would be configured to substitute other functionality. For example, a user with a non-enabled browser might be presented with the items and summaries, but have to select a summary to view the item.
Where the item includes a video object, that object can be presented directly, via a plug-in or the like, in one of the layers. With the video handled directly, opening an external player is not needed, thus making the pages more flexible. For example, the area allocated to the video could be automatically adjusted based on a detected aspect ratio, and the area can be expanded or contracted by the user without requiring a reload of the video stream.
Another example of a use of dynamic pages is shown in
When a tool is selected, by a click or otherwise, the user is presented with a DHTML layer (preferably, through a consistent visual transition) wherein the interactive elements necessary to complete the task are contained. Links contained within this module typically pop up another browser window.
Such tool layers can be used in a number of ways. For example, a main portal page might include a tool button for sending an e-mail. In response, the browser could present a new layer for entry of the e-mail, without the user perceiving any direction away from the main portal page. Furthermore, since the e-mail layer is part of the page already at the browser, the opening of the layer and the restoring of the main page will not be delayed by network or server delays. Other uses might include website services for quickly uploading files, calendar updates, photo uploading, searches, yellow page inquiries, etc.
For a layer such as an e-mail layer, the portion used for entry of the e-mail can be semitransparent, to keep the user oriented with the page from which the e-mail function was selected. This will often result in a less disorienting, cleaner presentation. Fading can be provided as well.
To accommodate browsers without dynamic page or DHTML capability, the server could detect, by “sniffing” or otherwise, whether a browser is enabled and then serve up the dynamic page or fall back to a separate page without the tool capability.
In addition to dynamic pages that include user interface elements, such as buttons and forms, some dynamic pages might operate without such elements. For example,
In some systems, to keep the interaction simple, the selected menu item is highlighted when selected and a limited number of sublevels (such as one sublayer) are used. In the example of
Such layers might be used in various areas of a portal site, such as a main page, a music page, a movies page, a games page, a sports page, a local new/information page and/or a news page. In some cases, a user might request a page having such DHTML elements, but not have a browser capable of processing DHTML constructs. In such cases, the DHTML page would be configured to substitute other functionality, such as showing the submenu items beneath menu items in a flattened, indented menu and, for menu items that do not have subsections, take the user to the page itself when the link is clicked.
Some pages can be complex combinations of constructs described above. For example,
With the personal assistant set of layers, an “assistant” module within certain properties is provided where content, tools, features and promotions are presented up front based on the user's preferences, which can be managed actively or passively. The customization might comprise event alerts (i.e., auctions results, concert tickets going on sale, etc.), information alerts (news, finance), promotions (new product release) or personal information (bills due, etc.). Preferably, the list is limited to some number (such as 10) entries to avoid clutter and has links that lead to the items themselves. For example, an “edit” link allows the user to edit their preferences on a separate page. Tins separate page will contain explicit items and preferences the user chooses, permission for promotional items to be featured, permission for passive personalization to be used, promotion or news of upcoming personalization features, etc. A “more” link might reveal additional personalization items through a vertically expandable DHTML slide sheet if the module cannot initially contain all items.
If the user has not personalized their module, it will contain promotion, instruction, or tour for the Assistant module. When the Assistant is personalized, it will contain a finite list of items actively or passively customized to the user's preferences. The items listed might contain links, which when clicked will allow users to interact further with that specific item. If the module cannot fully contain all the personalization items, a “more” link will be provided, which when clicked, will present a sliding sheet to reveal the rest of the list.
Preferences may contain actively customizing the types of alerts or content the module presents and filters, it may also include color customization, graphical element and other personalization features.
Such layers might be used in various areas of a portal site, such as a main page, a music page, a movies page, a games page, a sports page, a local new/information page and/or a news page. In some cases, a user might request a page having such DHTML elements, but not have a browser capable of processing DHTML constructs. In such cases, the DHTML page would be configured to substitute other functionality, such as sending the user to a separate page listing all the items when they click on “more”.
Yet another dynamic page is illustrated in
The transition might be consistent with other transitions of other dynamic pages, such as an animation, fade in, box in, etc. The rotation can occur even if the user is idle, preferably being unobtrusive and consistent throughout the module. If the user rolls over a particular space, the rotation for that space will be paused, with rotation resuming when the user rolls away from the module or space. Links within the modules will act like regular links. Users with non-DHTML enabled browsers can be provided with such a set of spaces, but the rotation will likely not be present.
One underlying architecture that could be used to present features described above is to have separate tools on layers of a DHTML page and move the layers by changing their position, thus obviating the need for a page refresh. Where some of the changes should be sticky, such as when the user drags one layer to a new position or changes positions of layers relative to each other, the change could be done without refreshing the page from the server, by the changes might be communicated to the server so that the next time the user comes to that page, the layers are in the order the user put them in at the last visit. In effect, this allows the user to drag and drop portions of a portal page layout, for example, and see them move relative to each other at speeds that might not be possible given network and/or server conditions. The communication of the change can be sent to the server without blocking the movement at the user's machine. In addition to communicating changes, references that a user makes, such as navigating a submenu or selecting an item for further detail, can be communicated to the server even though server action is not needed to respond to the user's action.
The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those of skill in the art upon review of this disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.
This application claims priority from co-pending U.S. Provisional Patent Application No. 60/410,510 filed Sep. 13, 2002 entitled “Browser User Interface” which is hereby incorporated by reference, as if set forth in full in this document, for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60410510 | Sep 2002 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10656846 | Sep 2003 | US |
| Child | 12145079 | US |
