Graphical user interface for automatically accessing files

Abstract

Systems and/or methods for automatically accessing files are disclosed. In one instance, a graphical user interface is disclosed that enables a user to access files through a control portion that displays a plurality of user-selectable buttons to control automatic accessing of files, a log portion that displays a record of which files have been accessed, and a content display portion that displays the content of each file after it is accessed.

Description

CROSS REFERENCE TO RELATED PATENT APPLICATION

This is a divisional of and priority is claimed to co-pending U.S. patent application Ser. No. 09/631,854 and a filing date of August 3^rd, 2000, for METHOD AND APPARATUS FOR FILE SEARCHING, ACCESSING FILE IDENTIFIERS FROM REFERENCE PAGE (as amended) of Rahman. This co-pending United States Patent Application is commonly assigned herewith and is hereby incorporated herein by reference for all that it discloses.

TECHNICAL FIELD

This invention relates to accessing files.

BACKGROUND OF THE INVENTION

Nowadays, a great many computers can communicate with one another over networks. One such network is the Internet, the use of which has expanded greatly in recent years (and is expected to continue). One significant way in which the Internet is used is the World Wide Web (also referred to as the “web”), which is a collection of documents (referred to as simply “web pages”) that users can view or otherwise render and which typically include links to one or more other pages that the user can access. These web documents are typically stored as one or more files at a remote location, being accessed by a user via his or her computer and the Internet.

Web pages are accessed for a wide variety of different reasons. By way of example, web pages may be accessed to test a web browser (an application program that manages the rendering of web pages to a user). By way of another example, web pages may be accessed by a user to view information he or she is interested in (e.g., an audio and/or video program, information describing products or services that a company offers, etc.).

Unfortunately, the selection and loading of web pages is currently a largely manual process. For example, selection of a set of web pages that are to be used to test a web browser is performed by a user manually typing in the paths and names of each web page in the test set. These web page identifiers are then individually selected by the user to access the identified page (causing the web browser to load the page and thereby test proper operation of the browser). By way of another example, a web search engine may identify multiple web pages that match a set of search criteria, but the user is then required to access each of the resulting web pages manually. Such manual processes, however, can be tedious and time-consuming on the part of the user, as well as error-prone.

The invention described below addresses these disadvantages, providing automatic file searching and accessing.

SUMMARY OF THE INVENTION

Systems and/or methods for automatically accessing files are disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings. The same numbers are used throughout the figures to reference like components and/or features.

FIG. 1 shows a client/server network system and environment in accordance with certain embodiments of the invention.

FIG. 2 is a block diagram illustrating an exemplary data flow for automatic file searching and accessing in accordance with certain embodiments of the invention.

FIG. 3 illustrates an exemplary display of a reference page in accordance with certain embodiments of the invention.

FIG. 4 is a flowchart illustrating an exemplary process for searching for files in accordance with certain embodiments of the invention.

FIG. 5 illustrates an exemplary user interface for searching destinations in accordance with certain embodiments of the invention.

FIG. 6 is a flowchart illustrating an exemplary process for automatically accessing files in accordance with certain embodiments of the invention.

FIG. 7 is a flowchart illustrating a more detailed exemplary process for automatically accessing files in accordance with certain embodiments of the invention.

FIG. 8 illustrates an exemplary user interface displayed by the tool page in conjunction with the process of FIG. 7.

FIG. 9 illustrates an example of a suitable operating environment in which the invention may be implemented.

DETAILED DESCRIPTION

FIG. 1 shows a client/server network system and environment in accordance with certain embodiments of the invention. Generally, the system includes multiple (m) network server computers 102, and multiple (n) network client computers 104. The computers 102 and 104 communicate with each other over a data communications network 106. The communications network 106 can be, for example, a private network, a public network (such as the Internet), and might also include local-area networks and/or private wide-area networks.

Servers 102 store various information, typically as one or more files 108 that are accessible to clients 104 via network 106. Files 108 can be accessed in accordance with any of a variety of protocols, such as the Hypertext Transfer Protocol (HTTP). One way in which the network 106 can be used is to support the World Wide Web (or simply the “web”), and in certain embodiments, files 108 are conventional web pages.

Client 104 allows users (and/or other applications) to search for files that satisfy a set of search criteria locally at the client 104 and/or remotely at a server 1102 (e.g., client-accessible files 108). The client 104 generates a reference page that includes identifiers of those files that satisfy the search criteria. Additionally, client 104 can also automatically access the files corresponding to the identifiers on the reference page (or identifiers obtained elsewhere) to allow viewing of the files, local storing of the files, etc. This automatic file searching and accessing is discussed in more detail below.

FIG. 2 is a block diagram illustrating an exemplary data flow for automatic file searching and accessing in accordance with certain embodiments of the invention. The automatic file searching and accessing illustrated in FIG. 2 is carried out by a search controller 120 and an access controller 122 (e.g., on a client computer 104 of FIG. 1). Controllers 120 and 122 may be implemented in any combination of one or more of software, firmware, hardware, etc. For example, controllers 120 and 122 may be implemented as software (e.g., one or more scripts) executing on a web page, in a programmable logic device (PLD), etc.

Search controller 120 receives as inputs search criteria 124 and destination identifier 126. Search criteria 124 is made up of one or more search parameters that are identified by a user, or alternatively by another application program. Any of a wide variety of search parameters can be used, and can include global variables (e.g., the use of an asterisk to indicate multiple characters, the use of a question mark to indicate a single character, etc.). Particular file names can be searched for (such as files with certain extensions (e.g., “*.asp” or “*.htm”), as well as other file characteristics (e.g., creation date and/or time, last modification date and/or time, file size, etc.).

Destination identifier 126 is an identifier of one or more destinations that are to be searched. These destinations can be local (e.g., at the same client 104 of FIG. 1 that is performing the searching) or remote (e.g., at one of servers 102). The destinations can be identified in any of a wide variety of manners, such as typical directory or folder paths (e.g., “C:\Work\Reference Documents”), Universal Naming Convention (UNC) paths (e.g., \\server1\documents), etc.

Given the search criteria 124 and the destination identifier 126, search controller 120 accesses the identified destination and compares the files to the search criteria 124. File identifiers of any of the files that satisfy the search criteria (e.g., the files have characteristics that match the search parameters) are stored to a reference page 128 (which itself may be a web page). This storage may be automatic, or alternatively in response to a user input (e.g., allowing the user an opportunity to verify that he or she wants to store the pages). Alternatively, no search criteria 124 may be used and file identifiers for all files at the destination added to reference page 128. In the illustrated example, reference page 128 includes the file identifiers of all the files at the destination that satisfy the search criteria.

Search controller 120 also allows the user to make modifications to the file identifiers on reference page 128. In one implementation, these modifications take the form of additional parameters added to the file identifiers. For example, certain web pages, when accessed, can be passed parameters (e.g., search parameters, identifying information regarding the calling computer, etc.). A user can manually add such parameters to a file identifier on reference page 128, allowing such parameters to be included when the web page is subsequently accessed (as discussed in more detail below).

The file identifiers are included on reference page 128 in a manner that allows the corresponding files to be subsequently accessed by selection of the identifier from page 128. In one implementation, the file identifiers are stored as uniform resource locators (URLs) of the files. The URLs are generated by “wrapping” the file names in html syntax (e.g., <a href=“filename.htm”>filetitle</a>for the file identifier filename.htm).

Selection of identifiers on reference page 128 can be performed manually or automatically. Automatic selection of the file identifiers is carried out by access controller 122, discussed in more detail below. Manual selection of the file identifiers is supported by a viewer 130. Viewer 130 can be, for example, a conventional web browser. Reference page 128 can be a conventional markup language document (e.g., HTML (Hypertext Markup Language), XML (extensible Markup Language), etc.) that is readable by viewer 130. The file identifiers are displayed as user-selectable links, and user-selection of one of the links causes viewer 130 to load the corresponding file.

Additionally, reference page 128 can be input to access controller 122 as a source list of file identifiers. Alternatively, file identifiers 132 may be provided to access controller 122 in place of (or in addition to) the identifiers from page 128. File identifiers 132 can be input to controller 122 in any of a variety of manners, such as manual input by a user, another file including a listing of identifiers, a web page generated by another program (e.g., the results of an on-line Internet search engine), etc.

Access controller 122 then accesses the files corresponding to the file identifiers it receives. In one implementation, where the file identifiers are URLs, the URLs are used to identify the proper location (e.g., an Internet address) where the corresponding file can be obtained, as well as the file name. Access controller 122 generates a log 134 to maintain a record of the files that it accesses. Log 134 includes, for example, the file identifier and the time that the file was accessed.

Accessing of the files by access controller 122 may further include additional functions. For example, for web pages (or other displayable files), the file contents can be displayed to the user in a window of a display device at client 104 of FIG. 1. By way of another example, access controller 122 can copy the files and store them locally as local files 136. Such locally stored files 136 can then be subsequently accessed by a user (e.g., when he or she is not in communication with the Internet, or after the remote server has deleted its copy of a file).

FIG. 3 illustrates an exemplary display of a reference page 128 in accordance with certain embodiments of the invention. An identifier portion 140 of the displayed page 128 includes the multiple selectable file identifiers (additional identifiers can be displayed, such as by use of a conventional scroll bar(s)). A user is optionally able to add parameters to the file identifiers by, for example, situating a cursor at the desired location (e.g., using a cursor control device such as a mouse) and typing in the desired parameter(s) via a keyboard. A user is further able to select one of the identifiers in portion 140 (e.g., by maneuvering a pointer or cursor over one of the identifiers and depressing a button of a cursor control device (e.g., clicking on a mouse button)). Selection of one of the identifiers in portion 140 causes access viewer 130 of FIG. 2 to load the corresponding file in viewing portion 142.

In the illustrated example of FIG. 3, reference page 128 is displayed as a “framed” page, in which each of the portions 140 and 142 comprises a separate frame. Alternatively, reference page 128 may also be displayed in a non-framed manner. For example, the file identifiers 140 could be displayed in a browser window and replaced, in response to selection of one of the file identifiers, by the content of the file corresponding to the selected identifier.

FIG. 4 is a flowchart illustrating an exemplary process for searching for files in accordance with certain embodiments of the invention. In the illustrated example, the process is implemented by search controller 120 of FIG. 2, and may be implemented in software. FIG. 4 is discussed with additional reference to FIG. 2.

Initially, search controller 120 receives an identification of one or more search destinations (act 160), and optionally receives an identification of search criteria (act 162). The search destination is then accessed (act 164) and a file from the destination checked to determine whether it satisfies the search criteria (acts 166 and 168). If the file satisfies the search criteria, then an identifier of the file is stored in a reference page (act 170), and another file is checked if there are additional files (act 172). If the file does not satisfy the search criteria, then an identifier of the file is not stored in the reference page and another file (if any) is checked, act 172. If no search criteria are provided, then all files at the destination are included in the reference page.

Once the file identifiers are added to the reference page, the user is allowed to make modifications to the identifiers (act 170). This modification process may occur after all files have been identified (as illustrated) or alternatively during the identification process (e.g., between acts 170 and 172).

FIG. 5 illustrates an exemplary user interface for searching destinations in accordance with certain embodiments of the invention. The user interface of FIG. 5 is generated by search controller 120 of FIG. 2. A first window 200 titled “Enumerator & HTML Generator” and a second “Browse for Folder” window 202 are illustrated. Upon invoking the search function, the enumerator and generator window 200 is displayed to the user. Window 200 includes a “Choose a folder” button 204, selection of which causes browse window 202 to be displayed. Browse window 202 allows a user to browse through a computer (and/or network) to locate a destination to be searched.

Window 200 also allows the user to input search criteria in file filter field 206 and initiate a search by actuating re-enumerate button 208. After a search is initiated, search controller 120 of FIG. 2 displays, in file field 210, the files in the destination that satisfy the search criteria.

A user is further able to identify whether a framed reference page 128 is to be generated by selecting checkbox 212. The reference page 128 can be generated by the user actuating generate file button 214, and the reference page 128 viewed (by invoking viewer 130 of FIG. 2), by selecting view page button 216.

The specific manner in which files are automatically searched and displayed to users can vary (e.g., due to the design environment (e.g., type of machine, type of network, type of operating system, etc.), designer's preferences, etc.). Table I below identifies exemplary functions that can be used to automatically search for files and display results in one implementation.

TABLE I
Function                      Description
SHGetSpecialFolderLocation( ) Retrieves a list of drives available on
                              the user's computer.
SHBrowseForFolder( )          Allows a user to choose any folder or
                              any drive accessible via the computer.
SHGetPathFromIDList( )        Retrieves file names from the location
                              (e.g., folder) selected by the user.
CFileFind::FindFile( )        Together enumerate files from the
CFileFind::FindNextFile( )    retrieved location that satisfy given
                              search criteria.
CListBox::AddString( )        Populates the list box with names of
                              found files satisfying the search criteria.
CreateFile( )                 Used to generate a new file for the
WriteFile( )                  reference page including the found files
                              satisfying the search criteria.

The automatic file searching and generating of a reference page provides numerous benefits. By way of example, the testing of applications that access the web (e.g., web browsers) can be simplified by automatically generating a reference page that includes URLs of (links to) each of the test files. The reference page can be augmented by the user adding parameters to the file identifiers.

FIG. 6 is a flowchart illustrating an exemplary process for automatically accessing files in accordance with certain embodiments of the invention. In the illustrated example, the process is implemented by access controller 122 of FIG. 2, and may be implemented in software. FIG. 6 is discussed with additional reference to FIG. 2.

Initially, the file identifiers corresponding to the files to be accessed are accessed (act 230). As discussed above, these may be received from a reference page 128 and/or elsewhere. The reference page (or other source) is then parsed as necessary to identify the individual file identifiers (e.g., identifying one by one from a reference page), and one of the file identifiers is selected (act 232). The file corresponding to the selected identifier is then accessed (act 234). The selected file can be accessed in different manners. By way of example, the file can be loaded into a web browser and displayed to the user. By way of another example, the contents of the file may be copied to the client computer that includes access controller 122 for local storage.

The file is then optionally stored locally (act 236). Whether the file is to be stored, viewed, or other action(s) taken can be a user-configurable option. By way of example, a drop-down menu or dialog box may be displayed to the user giving him or her the option as to what actions should be taken when automatically accessing the files.

After the file is accessed, access controller 122 optionally waits for an amount of time (act 238). This amount of time may also be user-configurable. By waiting for a period of time, access controller 122 causes a pause between accessed files (e.g., a pause between displaying web pages to allow the user a chance to view each web page).

Access controller 122 then checks whether there are additional files to be accessed (act 240). If there are additional files to be accessed, then the process returns to select another file identifier (act 232); otherwise, the process ends.

The files can be accessed in any of a variety of orders. For example, the file identifiers accessed in act 230 may be chosen from randomly, in accordance with a pre-determined order (e.g., the order in which they exist in reference page 128), or some other order.

FIG. 7 is a flowchart illustrating a more detailed exemplary process for automatically accessing files in accordance with certain embodiments of the invention. In the illustrated example, the process is implemented by a client computer 104 of FIG. 1, and may be implemented in software. FIG. 7 is discussed with additional reference to FIG. 2.

Initially, a tool web page is loaded (act 260). The tool web page includes software instructions (e.g., in the form of a script) that perform the automatic accessing (e.g., the functionality of access controller 122 of FIG. 2). The tool page creates three frames (act 262) to be used during the automatic access processing: a first frame to allow user control, a second frame to display the log of accessed URLS, and a third frame to display the content of the files identified by the URLs.

The tool web page then checks whether the accessing is to begin (act 264), such as in response to user-selection of a “start” button. If not, then the tool page waits until the accessing is to begin (act 266). Once the accessing is to begin, the tool page creates an array object (act 268), such as a linked list or other data structure, and loads the URLs to be accessed (e.g., from reference page 128) into the array (act 270). The tool page then reads a delay value (act 272), such as may be set by the user, and installs a delay timer based on the delay value (act 274).

The tool page then waits for the delay timer to expire (act 276). Once the delay timer expires, the tool page determines the current time and constructs a log string (act 278). The log string identifies the URL being opened, the time the URL is opened, and how many URLs have already been opened. An URL from the array (e.g., the first URL in the array on the first pass through steps 272-280) is then opened (act 280). A check is then made as to whether an error occurred in opening the URL (act 282). If there was an error, then an error handler is invoked (act 284) to perform any of a wide variety of error handling functions (e.g., log the error, notify the user or an administrator, sound an alarm, etc.).

However, if no error occurred, then the log string created in act 278 is written to the log (act 286). The process then returns to act 272 if there are additional URLs (act 288), and ends if there are not additional URLs.

FIG. 8 illustrates an exemplary user interface displayed by the tool page in conjunction with the process of FIG. 7. The interface 300 includes three different portions or frames: control frame 302, log frame 304, and content display frame 306. Control frame 302 includes start and stop buttons 308 and 310 that allow the user to start and stop the automatic accessing process. A default button 312 allows the user to re-instate default values (e.g., for the delay value), and a help/info button 314 allows the user to view help information regarding use of the tool page. A delay field 316 allows the user to input a delay value to be used to indicate how long pages should be displayed before the next page is displayed.

Log frame 304 is a display of the log strings that are written to the log in act 286. Log frame 304 allows the user to follow the automatic accessing process as it occurs.

The tool page displays the content of the opened URLs in content display frame 306. Content display frame 306 allows the user to view the content of the URLs that are opened.

The specific manner in which files are automatically accessed and the user interface displayed to users can vary (e.g., due to designer's preferences, the design environment (e.g., type of machine, type of network, type of operating system, etc.), etc.). In one implementation, the following methods are used. An array object is created using the JavaScript Array( ) method. The interpage delay value input by the user (in field 316) is retrieved using HTML Object model methods (e.g., “<formame>.<inputcontrol-ID>.value”). The current time is obtained using JavaScript Date object's methods and properties (e.g., getHours( ), getMinutes( ), and getSeconds( )). The date is formatted and written (along with the other log information) to log frame 304 using HTML Object model's document.write( ) method. HTML Object model's window.location attribute is set to the appropriate URL element (the URL to be loaded) in the array of URLs. A timer is installed using window.setTimeout( ) method to insure the proper interpage delay. The window.scrollBy( ) method is used to ensure that the latest log string is always in view in log frame 304.

The automatic file accessing provides numerous benefits. By way of example, the testing of applications that access the web (e.g., web browsers) can be simplified by automatically trying to load each web page that is identified on a reference page. Automating the test in such a manner reduces the time required on the part of a tester in manually accessing each page. By way of another example, a user may locally store the contents of each web page that is identified on a reference page. Such a user is then able to access the locally stored web pages at a later time (e.g., when his or her computer is not in communication with the Internet).

FIG. 9 illustrates an example of a suitable operating environment in which the invention may be implemented. The illustrated operating environment is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Other 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, programmable consumer electronics, gaming consoles, cellular telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

FIG. 9 shows a general example of a computer 342 that can be used in accordance with the invention. Computer 342 is shown as an example of a computer that can perform the functions of client computer 304 or server computer 302 of FIG. 1. Computer 342 includes one or more processors or processing units 344, a system memory 346, and a bus 348 that couples various system components including the system memory 346 to processors 344.

The bus 348 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. The system memory 346 includes read only memory (ROM) 350 and random access memory (RAM) 352. A basic input/output system (BIOS) 354, containing the basic routines that help to transfer information between elements within computer 342, such as during start-up, is stored in ROM 350. Computer 342 further includes a hard disk drive 356 for reading from and writing to a hard disk, not shown, connected to bus 348 via a hard disk drive interface 357 (e.g., a SCSI, ATA, or other type of interface); a magnetic disk drive 358 for reading from and writing to a removable magnetic disk 360, connected to bus 348 via a magnetic disk drive interface 361; and an optical disk drive 362 for reading from and/or writing to a removable optical disk 364 such as a CD ROM, DVD, or other optical media, connected to bus 348 via an optical drive interface 365. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for computer 342. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 360 and a removable optical disk 364, it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, random access memories (RAMs), read only memories (ROM), and the like, may also be used in the exemplary operating environment.

A number of program modules may be stored on the hard disk, magnetic disk 360, optical disk 364, ROM 350, or RAM 352, including an operating system 370, one or more application programs 372, other program modules 374, and program data 376. A user may enter commands and information into computer 342 through input devices such as keyboard 378 and pointing device 380. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to the processing unit 344 through an interface 368 that is coupled to the system bus (e.g., a serial port interface, a parallel port interface, a universal serial bus (US) interface, etc.). A monitor 384 or other type of display device is also connected to the system bus 348 via an interface, such as a video adapter 386. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) such as speakers and printers.

Computer 342 operates in a networked environment using logical connections to one or more remote computers, such as a remote computer 388. The remote computer 388 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer 342, although only a memory storage device 390 has been illustrated in FIG. 9. The logical connections depicted in FIG. 9 include a local area network (LAN) 392 and a wide area network (WAN) 394. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. In certain embodiments of the invention, computer 342 executes an Internet Web browser program (which may optionally be integrated into the operating system 370) such as the “Internet Explorer” Web browser manufactured and distributed by Microsoft Corporation of Redmond, Wash.

When used in a LAN networking environment, computer 342 is connected to the local network 392 through a network interface or adapter 396. When used in a WAN networking environment, computer 342 typically includes a modem 398 or other means for establishing communications over the wide area network 394, such as the Internet. The modem 398, which may be internal or external, is connected to the system bus 348 via a serial port interface 368. In a networked environment, program modules depicted relative to the personal computer 342, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Computer 342 typically includes at least some form of computer readable media. Computer readable media can be any available media that can be accessed by computer 342. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes 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 storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media which can be used to store the desired information and which can be accessed by computer 342. 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 wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

The invention has been described in part in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments.

For purposes of illustration, programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer.

CONCLUSION

Although the description above uses language that is specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the invention.

Claims

1. A graphical user interface for automatically accessing files, the interface comprising:

a control portion that displays a plurality of user-selectable buttons to control the automatic accessing of files;

a log portion that displays a record of which files have been accessed during the automatic accessing; and

a content display portion that displays the content of each file after it is accessed.

2. A graphical user interface as recited in claim 1, wherein the user-selectable buttons include a start button and a stop button.

3. A graphical user interface as recited in claim 1, wherein the files comprise web pages.

4. A graphical user interface as recited in claim 1, wherein the log portion further displays the time that each of the accessed files was accessed.

5. A graphical user interface as recited in claim 1, wherein the log portion also displays the number of files that have been accessed.