Full service research bureau and test center method and apparatus

[0002] This application claims the benefit of Provisional application Ser. No. 60/106,737, filed Nov. 2, 1998.

[0003] 1. Technical Field

[0004] The invention relates to a full-service research bureau and test center. More particularly, the invention relates to a World Wide Web based full-service research bureau and test center.

[0005] 2. Description of the Prior Art

[0006] In the traditional shrinkwrap software world, product usability testing was a business process that was considered nice to have. The software sales cycle relied heavily on product reviews, word-of-mouth, and controlled, static demonstrations (demos). Actual use of a product did not happen until after a user had purchased the product. Costs for customers to switch from a first product to a second product were high, so customer usability was given a low priority.

[0007] Today, in the online world, the product is the World Wide Web (Web) site and the Web site is the sales cycle. The usability of a Web site therefore has a direct and critical effect on how much revenue the site can generate. However, usability testing methods have not yet caught up to the requirements of Web site development processes.

[0008] Traditional user interface (UI) tests are labor intensive, cost-prohibitive, take ages to run, and yield subjective, non-analytical results at best. Online product competition is now in hyper-drive, and despite multi-million dollar budgets for a typical product launch, Web product managers still do not have an objective, rigorous way of measuring the customer satisfaction and usability of features on their own Web sites. The situation for competitive intelligence is even worse.

[0009] The frustration due to the lack of information is summed up by the product manager of a Top 5 Portal Site:

[0010] No one in this space knows what they're doing. The most successful people are also the most superstitious about their methods, since with no hard data, they feel their success—however great—has only been based on luck and gut feel so far. Everyone has an opinion, but no one can tell me why any one product is really winning or losing.

[0011] Poor understanding of a Web usability and feature quality measurement system is due to a number of factors:

[0012] 1. The pace of technological advance. In the arms race of new technology, companies' implementation timetables are driven by the competition, not their Information Technology (IT) staff.

[0013] 2. The multiplicity of functions. Functions for a corporate information Web site are inappropriate for a pre-teen chat room. Designers have to figure out how each function (email, chat, games, shopping, etc.) works best, taking into account the unique audience and objectives of the particular Web site.

[0014] 3. A flood of raw data but a lack of information. Web logging efforts provide a multitude of traces of user activity. Yet determining what the Web logging data means is impossible because a most important piece, the user's objective, is missing. The most advanced Web site-level tracking methods available focus on whether a marketer's objective, i.e. purchase, registration, ad clicks, etc., was met. The user's objective is ignored. The implication is that a look-to-book ratio twice as good as the industry average might not be cause to celebrate. Perhaps hundreds of willing buyers didn't purchase an item or service because they didn't understand the return policy.

[0015] 4. Little in-depth testing. Traditional user testing methods, such as for example usability laboratories with one-way mirrors, are expensive, labor intensive, and require long turnaround times. In addition, they provide highly subjective results across an insignificant sample size.

[0016] O. Davis and V. Jain, Method and Apparatus for Tracking Client Interaction with a Network Resource and Creating Client Profiles and Resource Database, U.S. Pat. No. 5,796,952 (18 Aug. 1998) discloses a method for monitoring client interaction with a resource downloaded from a server in a computer network. The method comprises the steps of using a client to specify an address of a resource located on a first server and downloading a file corresponding to the resource from the first server in response to specification of the address. The method further comprises the steps of using the client to specify an address of a first executable program located on a second server, the address of the first executable program being embedded in the file downloaded from the first server. The first executable program includes a software timer for monitoring the amount of time the client spends interacting with and displaying the file downloaded from the first server. The method further comprises the step of downloading the first executable program from the second server to run on the client so as to determine the amount of time the client interacts with the file downloaded from the first server. The method further comprises the step of using a server to acquire client identifying indicia from the client, and uploading the amount of time determined by the first executable program to a third server. The first executable program may also monitor time, keyboard events, mouse events, and the like, in order to track choices and selections made by a user in the file. It may execute upon the occurrence of a predetermined event, as well as monitor or determine the amount of information downloaded by the client. The monitored information and client identifying indicia is stored on a database in a server for use in analysis and for automatically serving out files assembled according to user interests and preferences.

[0017] While an objective of the Davis teachings is to provide means for -creating a database of user profiles containing details of individual user interaction with and use of network resources and of the amount of time spent by users interacting with and/or using particular resources, as well as details of choices created by individual users within a particular resource, Davis does not disclose nor suggests a usability test or pre-qualified testers. Davis does not disclose nor suggest that a customer take part in the design phase of a usability test to accomplish a set of customer objectives, which take into account a user's objectives.

[0018] S. R. Coffey, D. B. Pinsley, and K. A. Poloniewicz, Computer Use Meter and Analyzer, U.S. Pat. No. 5,675,510 (07 Oct. 1997) discloses a system that measures and reports the use of a personal computer by a user through a log file. The log file includes entries corresponding to predetermined events and can report on the applications used and communication functions engaged in by the user. The log files from one or more computers may be assembled and analyzed in order to ascertain computer use habits for computer software, computer hardware and computer communications. The system may also be used to predict computer use trends and to represent computer use history.

[0019] The monitoring system of Coffey, et al., provides traces of what users choose, but the disclosure does not teach nor suggest why a users navigate down particular paths. Coffey, et al., discloses that their system collects child Window information for commercial online service providers and user applications. Window titles of these applications' child Windows generally hold useful descriptions of the activity at that moment. For example, if a subscriber is using a mail system for a service, then the Window title so indicates. The system records those titles in a log file.

[0020] Coffey, et al., further discloses that online marketers try to understand the characteristics of Web traffic and how much time users spend at different sites. Traffic statistics become fundamental inputs for media planning, in a fashion analogous to using TV ratings as a basis for buying or pricing commercial time. However, Coffey, et al. does not disclose nor suggest that users' objectives be considered in any process of the system.

[0021] A. N. Goldhaber and G. Fitts, Attention Brokerage, U.S. Pat. No. 5,794,210 (11 Aug. 1998) discloses a system that provides for the immediate payment to computer and other users for paying attention to an advertisement or other negatively priced information distributed over a computer network such as the Internet. It is the business of brokering the buying and selling of the attention of users. A further disclosure allows advertisers to detach their messages from program content and explicitly target their audience. A special icon or other symbol displayed on a computer screen may represent compensation and allow users to choose whether they view an ad or other negatively priced information and receive associated compensation. Targeting users may be provided by reference to a database of digitally stored demographic profiles of potential users. Information is routed to users based on demographics, and software agents can be used to actively seek out users on a digital network. Private profiles are maintained for different users and user information is released to advertisers and other marketers only based on user permission. Users may be compensated for allowing their information to be released. Competing advertisers may bid for the attention of users using automatic electronic systems, e.g. an auction protocol and these concepts can be generalized to provide an electronic trading house where buyers and sellers can actively find each other and negotiate transactions.

[0022] While Goldhaber et al. discloses its four basic principles are attention, interest, sponsorship, and privacy, it gains knowledge about the behavior of users through estimates of past behavior. That is, Goldhaber et al. discloses a mechanism by which advertisers actively compete by bidding for a viewer's attention, wherein the bids are based, in part, on estimates of the viewer's interest and likelihood to buy. The estimates are derived from access to the viewer's electronic profiles detailing preferences and past consuming behavior. Goldhaber et al. does not disclose nor suggest a mechanism for learning from a viewer why a viewer chooses particular actions.

[0023] Goldhaber et al. discloses demographic profiles constructed through interest questionnaires that a customer completes when subscribing to the disclosed service and also through electronic tracking of the customer's usage of the service (and other habits). The profiles are dynamic and evolve with the customer's transaction history. A customer can choose to exclude any transaction (e.g. viewing of certain material or purchasing of certain products) from his profile. The profile is also interactive in that a customer edits the profile at any time to add or delete interest features and to delete any transaction records. Goldhaber et al. does not disclose nor suggest a testing mechanism to measure a customer's success in achieving the customer's objectives. Nor does Goldhaber et al. disclose or suggest prompting for context-specific feedback ranging from the aesthetics of the design to the reason a page request is terminated. Furthermore, Goldhaber et al. does not disclose nor suggest aggregating statistics across a testing population and presenting the testing results with recommended actions backed up by analysis.

[0024] It would be advantageous to provide a method and apparatus that provides Web product managers with quick and detailed feedback on customer satisfaction of their own and competitive products across a large sample size using efficient techniques.

[0025] It would be advantageous to provide a method and apparatus that provides a usability test for typical tasks faced by a customer to a Web product manager's site. The test measures a customer's success in achieving the customer's objectives and also prompts for context-specific feedback ranging from the aesthetics of the Web page design to the reason a page request is terminated.

[0026] It would be advantageous to provide a method and apparatus that aggregates statistics across a testing population and presents data with recommended actions backed up by analysis.

[0027] The invention herein is a method and apparatus that provides, in a preferred embodiment, Web product managers with quick and detailed feedback on a visitor's satisfaction of the Web product managers' own and competitive products. The invention herein in a preferred embodiment provides an end-to-end, automated solution for testing the Usability and Feature Quality™ of any Web site. Unlike other usability and product testing solutions, the invention herein quickly generates highly specific, quantitative results across a large sample size using labor and time efficient techniques.

[0028] Specifically, the invention herein aids a customer, which in a preferred embodiment is a Web product manager, in designing a usability test for typical tasks faced by a visitor to the customer's site. The invention uses proprietary software, which in one embodiment comprises enhancements to a tester's Web browser, to administer the usability test to a pre-qualified pool of testers meeting desired demographic constraints. The usability tests measure a visitor's success in achieving the visitor's objectives and also prompt for context-specific feedback ranging from the aesthetics of the design of the customer's site to a reason why a page request was terminated. Statistics are aggregated across the testing population and are presented as data with recommended actions backed up by analysis.

[0029] FIG. 1 is a schematic diagram showing the relationship of objects according to the invention;

[0030] FIG. 2 is a flow diagram showing the steps of designing a usability test according to the invention;

[0031] FIG. 3 is a flow diagram showing the steps of using a usability test according to the invention;

[0032] FIG. 4 is a schematic diagram showing a tester registration stage according to the invention;

[0033] FIG. 5 is a schematic diagram showing a test creation stage according to the invention;

[0034] FIG. 6 is a schematic diagram showing a test matching stage according to the invention;

[0035] FIG. 7 is a schematic diagram showing a test processing stage according to the invention;

[0036] FIG. 8 is a schematic diagram showing a test analysis stage according to the invention;

[0037] FIG. 9 is a screen shot of a tester client browser according to the invention;

[0038] FIG. 10 is a screen shot of a tester client browser according to the invention;

[0039] FIG. 11 is a screen shot of a tester client browser according to the invention;

[0040] FIG. 12 is a screen shot of a tester client browser according to the invention;

[0041] FIG. 13 is a block schematic diagram of an exemplary system architecture according to the invention;

[0042] FIG. 14 is a block schematic diagram of a specific implementation of the browser according to the invention; and

[0043] FIG. 15 is a block schematic diagram showing frame history lists according to the invention.

[0044] The invention herein is a method and apparatus that provides, in a preferred embodiment, Web product managers with quick and detailed feedback on a visitor's satisfaction of the Web product managers' own and competitive products. The invention herein, in a preferred embodiment, provides an end-to-end, automated solution for testing the Usability and Feature Quality™ of any Web site. Unlike other usability and product testing solutions, the invention herein quickly generates highly specific, quantitative results across a large sample size using labor and time efficient techniques.

[0045] Benefits of the invention comprise, but are not limited to speed, competitive benchmarking, better information, better statistical validity, and lower cost.

[0046] The speed in increased because customers get insights from hundreds of user testing sessions in less time than it takes to schedule a handful of test subjects for local testing sessions.

[0047] According to an embodiment of the invention, a Web product manager competitively benchmarks a product against its primary competitors. An advantage of the invention is a Web product manager can competitively benchmark as part of an iterative design process, thereby effectively guaranteeing the success of the product.

[0048] Better information is provided because a Web product manager learns why an action occurred rather than only what action occurred. For example with a traditional usability test, a Web product manager learns that two testers found a site too slow. According to the invention, the Web product manager learns in addition that 14% of page requests were stopped during transmission and 75% of those were stopped because they took too long to load.

[0049] Better statistical validity is provided because the invention is adapted to allow for a large sample size of testers. The customer therefore gains more confidence in the test results and conclusions.

[0050] Retaining a tester according to the invention is one-fifth the cost of retaining a tester in a traditional environment. In one example, retaining a tester according to the invention is $250 whereas retaining a tester in a traditional environment is $1250. According to a preferred embodiment of the invention additional reduction in cost is set forth therein because of soft costs, such as, for example, faster turnaround time, lower downtime for the development team, less hassle and higher quality results.

[0051] A Usability and Feature Quality™ testing solution is provided to customers using a centralized, Web-based service bureau model. Advantages to customers using the centralized Web-based service, alternatively to selling a software system to each customer to run on the customer's own tester network, comprise but are not limited to ease of adoption, maintenance, tester recruiting, and billing.

[0052] Ease of adoption is provided because no server software is required for customers to install, learn or maintain.

[0053] Ease of maintenance is provided because the server software need not run on a myriad of platforms.

[0054] A preferred embodiment of the invention is adapted to improve tester recruiting. The invention is adapted to accommodate a large tester population from which to build precisely designed test panels for each test. In addition, the invention is adapted to provide a central location for all participating testers to access tests. The invention is adapted to sponsor tests anonymously, rendering a mechanism useful for competitive benchmarking.

[0055] A central billing and payment center for customers and testers to clear transactions is provided.

[0056] Further advantages to a preferred embodiment of the invention comprise, but are not limited to, sales cycle, support cost, installed base, return on investments (ROI), and customer satisfaction. These further advantages of the invention comprise, for example:

[0057] Central billing and evaluation cycles and sales cycles are shorter than in a traditional development and testing environment.

[0058] Support costs are lower because only one installation, as opposed to several different installations of software needs to be maintained.

[0059] An installed base is provided. Specifically, central control and registry of tester population, tester data and test history is provided.

[0060] An improved rate of return (ROI) is provided because a single investment in the central platform is amortized across industry report revenues and network test revenues.

[0061] A preferred embodiment of the invention is adapted to monitor more easily customer usage of products and services, which are provided by the invention. For example, the invention is adapted to make linking sales compensation to actual customer usage easier, in contrast to linking sales compensation to license revenue, which often ignores post-sale customer satisfaction.

[0062] FIG. 1 is a schematic diagram showing the relationship of objects according to a preferred embodiment of the invention. FIG. 1 shows three core components of preferred embodiment of a Web-based platform of a full-service research bureau and test center. The three core components are a first proprietary software, a second proprietary software, and a storing and retrieval means. In the preferred embodiment, the first proprietary software is a Tester Client Browser 10, the second proprietary software is a Test Manager server 20, and the storing and retrieval means is a Data Warehouse 30. FIG. 1 shows a TCP/IP communication path 40 between the Tester Client Browser. 10 and the Test Manager 20. Typically, test questions and responses, browser events, comments and any other relevant information are transmitted through the TCP/IP communication 40.

[0063] Typically, the Tester Client Browser 10 is a modified browser, downloaded and installed on testers' personal machines. In addition to standard navigation and HTML display functions, the browser 10 is adapted to collect browser events 40, such as, for example, submission or fulfillment of a page request; usage of back, forward, or stop buttons; page scrolling and mouse-overs. The browser events 40 are transmitted in a log form to the Test Manager 20. The browser 10 is modified also to pose questions 40 depending upon browser events or messages from the Test Manager 20. Responses 40 to the questions are sent to the Test Manager 20. Additional buttons are provided on the browser 10 that use easily to comment upon a page. Comments 40 are also transmitted to the Test Manager 20.

[0064] FIG. 1 shows the Tester Client Browser 10 linked to a Customer Web site 50 through an HTTP Communication path, whereby a customer Web page is loaded directly from a hosting server, with no additional HTML added to the page. Therefore, the Web page is displayed with the identical appearance and latency as viewed from an unmodified browser.

[0065] Typically, the Test Manager 20 is a server application simultaneously supporting a multiple of test sessions with a multiple of clients or testers. Herein, the terms ‘clients’ and ‘testers’ are interchangeable and refer to the same entity. Each test session presents the customer's objectives to a tester as a series of questions. Additional questions may be triggered as the result of specific answers to earlier questions. The data from a completed test are transmitted to a Data Warehouse 30 through Structured Query Language (SQL) communication 50. Data from the completed test typically comprises, but is not limited to, test questions and responses, browser events and comments. The data 50 is thus stored in the Data Warehouse 30.

[0066] Typically, the Data Warehouse 30 stores each logged event from the test session for future analysis. The entries transmitted in an SQL call 50, such as question responses, comments, and significant browser events, are tagged with a test sequence identifier, and a tester identifier (ID). Online analytical processing (OLAP) queries against fact tables in the Data Warehouse 30 permit complex queries. An example of a complex query is a query that represents behavior of a test group on particular questions or combinations of questions, broken down according to demographic or test-specific properties.

[0067] FIG. 1 shows a preferred embodiment of a full-service bureau and test center Web site 70. The Web site 70 is linked to the Test Manager server 20 through Common Gateway Interface (CGI) interaction 80. The Web site is a central presence for interaction among the Test Manager 20, customers, and testers. Primary purposes of the Web site 70, include, but are not limited to:

[0068] educating customers about benefits of usability testing;

[0069] educating testers about benefits of testing and current opportunities;

[0070] enrolling testers including, for example, gathering contact information and demographic information;

[0071] providing access to customers for pre-generated reports, ad hoc reports, and a test builder application;

[0072] providing information relevant to stakeholders and potential employees;

[0073] creating communities among testers and customers; and

[0074] handling electronic commerce (e-commerce) transactions to sell tests and pay testers.

[0075] FIG. 1 also shows an HTTP communication path 90 between the Web site 70 and a Customer Browser 100. Through the HTTP communication path 90 and the CGI communication path 80, the customer has access to a Web application on the Web site 70, referred to as Test Builder, with which to create and initiate a usability test automatically. Test Builder allows the specification of number of testers, desired demographics, objectives and other questions.

[0076] In another embodiment of the invention, through the HTTP communication 90 the customer has access on the Web site 70 to a Web application, referred to as Ad Hoc Reporter. With Ad Hoc Reporter, the customer, from the Customer Browser 100, poses queries and by an SQL Call 110 about test results against the Data Warehouse 30. In another embodiment, a tool is provided which permits interactive interpretive activities, such as, for example, generating graphs and statistical processing.

[0077] In another embodiment of the invention, a support tool, referred to as Report Builder, is provided. Report Builder runs locally on either the Web site 70 or the Test Manager 20 by specialists to facilitate extracting meaningful insights from the test data. An early version of the tool performs a suite of statistical processing and graph generation. A later version of Report Builder assists in highlighting the most relevant quotes and statistics, moving towards increasingly automated generation of personalized reports.

[0078] In another embodiment of the invention, a utility, referred to as Test Auditor, is provided as an add-on utility to Test Manager 20. Test Auditor assures data quality. It uses heuristic evaluations to ensure that testers are making good faith efforts to meet objectives and are devoting adequate attention to tasks. In another embodiment, Test Auditor offers bonuses, such as a better rate of payment for completing tests, to testers who provide high quality feedback.

[0079] FIG. 1 shows an HTTP communication path 120 between the Tester Client Browser 10 and a Competitor Web site 130 used in competitive benchmarking. Also shown in FIG. 1 is an HTTP communication path 140 between the Tester Client Browser 10 and the Web site 70 used in a tester registration stage and finding available or open tests on the Web site 70.

[0080] FIG. 2 is a flow diagram showing the steps in designing a usability test according to the invention. In a preferred embodiment, a customer logs onto the full-service bureau and test center (200) and:

[0081] designs a test script for a customer Web site, wherein the test script includes, for example, tasks to perform, questions to answer, and items to measure, and wherein the test script is customized from a set of available templates (210);

[0082] defines a composition of a desired test panel for each test using factors such as, for example age, location, gender, experience level and personal interests (220);

[0083] defines requirements for a test completion date (230);

[0084] authorizes a test run after reviewing time and cost estimates (240);

[0085] retrieves raw test result data for analysis (250);

[0086] analyzes test result data online using a proprietary tool, such as an OLAP-style data mining tool, designed specifically for Usability and Feature Quality™ test results analysis and data mining (260);

[0087] optionally competitively benchmarks test results for the customer Web site using an aggregate, anonymous database of other Web site test results that are compiled and maintained by the full-service bureau and test center (270);

[0088] optionally retrieves a sufficiently timely or latest Industry Report, for which the customer has purchased a subscription, on comparative Usability and Feature Quality™ test runs across an entire industry segment, such as for example, computer shopping, business travel, outsourced Human Resources (HR) and groupware applications (280); and

[0089] builds presentation quality reports for delivery to clients or other stakeholders in the tested Web site (290).

[0090] FIG. 3 is a flow diagram showing the steps of using a usability test according to the invention. In a preferred embodiment, a tester, recruited through a customer Web site and through the efforts of the full-service bureau and test center, logs onto the full-service bureau and test center (300) and:

[0091] registers as a paid Usability and Feature Quality™ tester for a testing network (310);

[0092] downloads a latest version of the Tester Client Browser, which enables the tester to participate in testing sessions (320);

[0093] checks for new test sessions in which to participate (330); and

[0094] optionally checks a personal account for payment status and to manage a personal profile (340).

[0095] FIG. 4 is a schematic diagram showing a tester registration stage, according to the invention. In a preferred embodiment, any person or tester connects to the Internet through a tester Web browser 400 and thereby connects to a centralized service, such as a central processing system and Web site 410. The tester submits demographic information, creates a user profile, and downloads data collection software to the tester's Web browser 400. The collection of these registration data creates a tester data base 420.

[0096] FIG. 5 is a schematic diagram showing a test creation stage, according to the invention. In a preferred embodiment, test creation is performed as a collaborative effort between a domain expert, typically a customer who commissions the test through a customer Web browser 500, and consultants 510 that are familiar with test script internals. A tool, such as a test template database 520, is provided for both the tester and consultants to automate the process either partially or completely. A test script, which is available for download by qualified testers, results. A test database 530 stores relevant test data. Communication between any of the customer's Web browser 500, consultant input 510, the test template data base 520, and the test data base 530 is enabled through a central processing system and Web site 540.

[0097] FIG. 6 is a schematic diagram showing a test matching stage, according to the invention. In a preferred embodiment, registered testers who from a tester's Web browser 600 wish to participate in another test visit a centralized depository for tests, a test data base 610, commissioned by many customers. By logging into the depository 610, which in one embodiment is part of a World Wide Web site, the tester's stored demographics 620 are matched by a central processing system and Web site 630, against a desired composition of testing panels that still have openings. If openings are available, they are presented to the participating tester. In one embodiment, the selection of openings triggers a distribution of a complete test. In another embodiment, the selection of openings triggers a distribution of the beginning piece of it a test to the tester's machine 600.

[0098] FIG. 7 is a schematic diagram showing a test processing stage, according to the invention. In a preferred embodiment, the tester invokes a test script within a tester's Web browser 700. The tester visits a Web site 710 that is the subject of the test. The tester's Web browser 700 gathers navigation behavior, answers to questions, and other feedback either explicit feedback, such as comments or verbal commentary, or implicit feedback, such as from a video camera trained on tester, an eye tracking system, or a biofeedback response. Actions may trigger additional questions. Responses are transmitted to the central processing system and Web site 720 for storage in a log database 730, either as they occur, or in batches.

[0099] FIG. 8 is a schematic diagram showing a test analysis stage, according to the invention. In a preferred embodiment, upon completion of a test by a testing panel, test results stored in a log database 800 are combined by a central processing system and Web site 810 to provide a report to a customer. A report template database is provided. In one embodiment, an analysis process includes a review by a consultant 830. In another embodiment, the consultant's efforts are leveraged by automated statistical processing tools or other analysis tools. The resulting conclusions and supporting data are distributed to a customer's Web browser 840 electronically or are distributed in paper form. In another embodiment, a customer is granted access to underlying data in the log database 800, enabling the customer to perform analysis of the data. In a preferred embodiment, the customer Web browser provides an interface to the log data base 800 and is adapted to provide the construction of queries in an intuitive format.

[0100] FIG. 9 is a screen shot of a tester client browser according to the invention. A tester is asked to complete a first customer objective.

[0101] FIG. 10 is a screen shot of a tester client browser according to the invention. The tester is in the process of completing a customer objective.

[0102] FIG. 11 is a screen shot of a tester client browser according to the invention. The tester is in the process of submitting a free-form comment, according to an embodiment of the invention.

[0103] FIG. 12 is a screen shot of a tester client browser according to the invention. The user is answering the question asked in the first customer objective.

[0104] Table A below shows a preferred embodiment of an architectural design of a modified browser comprising a usability test, according to the invention.

[0105] File Formats

[0106] The current implementation of the Test Browser uses persistent (disk) storage in place of a real time connection between a test manager server and the tester client. There are three separate file formats: the Test File, which directs the Test Browser what objectives to give to the client and what additional questions to ask; the Log File which is the result of the tester's performance on the test script; and the Saved Test, which essentially pickles the state of the test in progress so that a tester can resume a test at his convenience. In order to make things as easy as possible for the tester, the saved state is appended directly to the log file, obviating the need to deal with another set of files. The state is overwritten when the test is resumed.

[0107] Test File

[0108] The Test File is made up of 3 segments:

[0109] 1) a header;

[0110] 2) “standard” questions; and

[0111] 3) triggered questions.

[0112] Each of these sections are covered below.

[0113] Header

[0114] Keyword “FACILITAS” all caps.

[0115] Test Battery ID: Integer (the key value in the database for this customer test)

[0116] Test File name: String (space terminated) (Filename stem used for logfile on tester's machine. A hyphen, followed by the tester login is added to form the complete filename.)

[0117] Minimum Build #: Integer. Used for version control between script and browser. Each major build of the browser increments this number. If a script is run on a browser with a build number of less than the script's number, it might not work (because it may require features added to the browser after the tester's version) so it just reports an error and suggests they download a new version.

[0118] Number of “Standard” Questions: Integer

[0119] Number of “Objectives”: Integer

[0120] “Standard Questions”

[0121] Question Text: New-line terminated sequence of characters (including spaces)

[0122] Start URL: String. If <3 characters, then “don't change”

[0123] Number of Response: Integer

[0124] Number of Repetitions: Integer

[0125] Response Type: Integer

[0126] Bits 0-4: Response Type:

[0127] 1: Radio Button

[0128] 2: Check Boxes

[0129] 3: Single Integer Entry Box

[0130] 4. Text box display (no entry)

[0131] 5. Text blurb entry (for paragraphs)

[0132] 0, 6-31: Reserved for future use

[0133] Bit 5: 1=“Objective”, 0=“Normal Question” (+32 if yes, +0 if no)

[0134] Bit 6: 1=“Use last response as the title of dialog box”; 0=“Use all responses as normal responses” (+64 if yes, +0 if no. Generally should use for all except objectives.)

[0135] Bit 7: 1=Add an “Other Answer” option” 0=don't. (+128 if yes, +0 if no)

[0136] Bit 8: 1=Add “Info not here vs. Can't find it” question on giveup (+256 if yes, +0 if no)

[0137] Bit 9: 1=Advance objective with a success (generally used for triggers +512 if yes, +0 if no)

[0138] Bit 10: 1=Advance objective with a failure (generally used for triggers +1024 if yes, +0 if no)

[0139] Example: A free text box, not an objective, that asks specifies a title:

[0140] What is the most confusing thing about this task?

[0141] a

[0142] 1 1 69

[0143] Survey on Objective #3

[0144] Description:

[0145] Text of question on first line.

[0146] Second line “a” indicates do not go to any URL.

[0147] Third line: First “1”=one response (the dialog box title) Second “1”=show this question at most once. 69=text blurb entry (5)+use last response as title (+64).

[0148] Next Line is text of first response (but in this case, also the last response, therefore the dialog box title).

[0149] Responses: New-line terminated sequence of characters (including spaces)

[0150] “Trigger Questions”

[0151] All elements of a “Standard Question”, plus:

[0152] Trigger: New-line terminated sequence of chars (See section on triggers for syntax/format)

[0153] Log File

[0154] Essentially a trace of the tester's interaction with the browser, the log file is line based. Each line is a separate event. Lines have a largely common structure (which might be further rationalized for ease of loading into database).

[0155] Event Code: Integer

[0156] 1: Back

[0157] 2: Forward

[0158] 3: Search

[0159] 4: Stop

[0160] 5: Refresh

[0161] 6: Go to “Start”

[0162] 7: Go to Typed URL

[0163] 8: Go to URL from drop down box

[0164] 9: Comment

[0165] 10: Answer question

[0166] 11: Page load complete

[0167] 12: Behavior Triggered question

[0168] 13: Followed link

[0169] 14: Item selected from back history

[0170] 15: Item selected from forward history

[0171] 16: Give up

[0172] 17: Go to start URL of objective

[0173] 18: Find in Page

[0174] 19: Stop test

[0175] 20: Restart test

[0176] 21: Pause

[0177] 22: Give up on whole test

[0178] 23: Add bookmark

[0179] Date: Date

[0180] Time: Time

[0181] Elapsed Time: Integer (in number of seconds)

[0182] Question Number: Integer

[0183] Objective Number: Integer

[0184] Frame ID (as a 7 digit ID)

[0185] Other info:

[0186] Event Code: 1-8, 13, 14, 15, 17: Source URL, Page Title, Destination URL, POSTed data

[0187] Event Code: 9: Comment Text (new-line terminated sequence of characters)

[0188] Event Code: 10, 12: Binary encoding of answer(s) selected. First answer=1, Second =2, Third =4, etc. If “other” is selected, a text string follows with contents of text box

[0189] Event Code 11: Number of Links: Integer; Words per Link: Float; Number of Images: Integer

[0190] Event Code 16: Comment Text (new-line terminated sequence of characters)

[0191] Event Code 18, 19, 20, 22: None.

[0192] Event Code 21: Length (in seconds) of paused time

[0193] Event Code 23: URL added to bookmarks

[0194] Saved Tests in Progress

[0195] Test URL: String delimited by &'s, since it may contain spaces

[0196] Current Question: Integer

[0197] Current Objective: Integer

[0198] MaxReps[ ] & Response[ ]: pairs of Integers, 1 per TEST_SIZE

[0199] Number of Open Browser Windows:

[0200] For Each Open Window:

[0201] Number of Entries in History List: Integer

[0202] Current Index into History List: Integer

[0203] Entries in History List: Strings, pointers to Frame History, [0] first, up to [SIZE]//Currently, FrameHistory is forced to NULL, i.e., frame status is not saved/re-loaded

[0204] Pause Time: Integer, clock entry at time of save

[0205] Time Offset: Integer, difference between clock time & elapsed time

[0206] Event Window Index: Integer

[0207] Event. Code[ ] & Event Time[ ]: Pairs of integers, 1 per WINDOW_SIZE (event time is elapsed time)

[0208] Triggers & Parser

[0209] Behavior-based questions are asked when the trigger condition is met. The trigger is a Boolean expression with traditional compositional semantics. The syntax is described in the context-free grammar below (Trigger is the start symbol). The primitives are described after that. Note that the language has been designed so that one token lookahead is always sufficient to correctly determine the next parsing step.

[0210] Trigger→Condition|AND (Condition, Trigger)|OR (Condition , Trigger)|NOT (Trigger)

[0211] Condition→EV=(EventType, EventType)|!=(IntType, IntType)|>(IntType, IntType)|<(IntType, IntType)|=(IntType, IntType)

[0212] MATCH (TextType)|XITMATCH (TextType)|RANDOM (IntType, IntType)|LOADCOMPLETE (TextType)

[0213] IntType→integer|CURRENTQUESTION|RESPONSE (IntType)|TIMESINCE (EventType)|NUMBERINWINDOW (EventType)|LOADSTATUS

[0214] EventType→TYPE (IntType)|IntType

[0215] TextType→character string delimited by white space

[0216] AND, OR, NOT: Typical Boolean interpretation

[0217] ==, <, >, !=: Typical integer comparators

[0218] EV=: Event Equality. Tests whether one Event Code is equal to another or to a constant. Separate event and integer equality for semantic hygiene. An alternative way to do it is to have a function to cast from event types to int's.

[0219] CURRENTQUESTION: A special symbol bound to the current question number that the tester is working on. Questions are numbered consecutively in the order of the test file, starting with 0.

[0220] RESPONSE (X): The tester's response to question #X, always an integer.

[0221] TIMESINCE (Y): The number of seconds which have elapsed since the last event of type Y. If none occurs in the event history the value is 99999.

[0222] NUMBERINWINDOW (Y): The number of events with Event Code=Y in the event history

[0223] TYPE (X): Uses X (probably a small negative number) as an offset into the event history, and gets the event code of that event. For example TYPE (0) is the event code of the current event, TYPE (−1) the previous event, and so on. An Integer used as Event Type corresponds to the EventCode, as defined in the Log File format.

[0224] MATCH (URL): True iff the current URL of the page the tester is going to matches (currently strcmp) the argument

[0225] XITMATCH (URL): As above, but the URL of the page the tester is leaving

[0226] LOADCOMPLETE (URL : As above, but the URL of the page after the page load is complete

[0227] RANDOM (X, Y): True if and only if a random number between 1 and X is less than a second random number between 1 and Y. (i.e. RANDOM (40, 100) is true 40% of the time. Used to prevent a question from becoming repeated too frequently, among other things.

[0228] LOADSTATUS: Variable that contains the “reason” why test triggers was called: 1=About to leave page; 2=Page load complete; 3=About to Enter Page; 4=Timer expired

[0229] Extensions for Trigger Language

[0230] URL matching: Rather than strict equality, strip off query string, and remove any digits before first dot in URL. E.g. www3.sportsline.com matches www.sportsline.com. Other match functions may permit partial matches (any .com domain, or any sportsline.com domain e.g.)

[0231] COUNT (X): Used to fire the trigger every X-th time. Each trigger has an associated counter with it, and if the other conditions are met, the counter is incremented. If the counter then matches IntType X, the trigger fires, and the counter is re-set to 0. If the counter is less than X, the trigger does not fire.

[0232] TEXTMATCH (X , Y): True if and only if X appears in Y. To be added when responses may contain free text.

[0233] NUMBERINWINDOW (X , Y): The number of events with Event Code=Y in the last X events of the history

[0234] Clock

[0235] While it is interesting and useful to know the absolute time that certain events occurred (e.g. did people testing at noon find the site slower than those testing at 3AM?) it's also useful to know the duration of certain tasks, but it isn't fair to penalize people for spending a long time writing comments, reading the question, or taking a break. Therefore, it's also important to track the relative time (elapsed time in seconds) since the start of the test, pausing the count for any events that should be “off the clock”.

[0236] This is accomplished by maintaining a “Time Offset” value that indicates the difference between the current system clock and the start of the test. Time Offset is initially set to the system clock at the start of the test. 1 second later, the elapsed time is system clock—Time Offset, yielding 1. Suppose we want to pause the clock for 30 seconds while the tester enters a comment. At the start of the “Clock Off” time, we store the current system clock in a temporary variable, Pause Time. At “Clock On” time, we add the difference between the current system clock and the Pause Time (which is the amount of time the clock should have been paused) on to the Time Offset.

[0237] However, due to the asynchronous nature of some of the procedure calls as well as events going in multiple windows, it's not clear that the pause/restart events will always occur in consecutive pairs. That is, there might be two calls to pause before a single call to restart. Therefore, using a single variable is insufficient. Instead, a stack is effectively required. But the times of intermediate pauses (any but the first) are not relevant, since the clock is already stopped. Therefore, the representation used is a single PauseTime variable that is set if the clock was currently running. The PauseCounter is set to 1. Additional “pause” calls increase the counter, but do not change the clock. Restart calls decrease the counter. When the counter hits zero (all pauses have been restarted) the difference between the current system clock and the pause time variable is added to the Time Offset. If a time is logged while the counter is paused (due to an event in another window, for example), the difference between the current system time and the PauseTime is effectively added to the TimeOffset to determine the elapsed time for the current log entry.

[0238] Internet Explorer Specific Details

[0239] Extended Web Browser, Internet Explorer version (see FIG. 14)

[0240] The Test Browser is a MFC application of the “Multiple Document Interface” variety. The relationship among these files is shown in the figure.

[0241] The main files are:

[0242] MainFrame

[0243] The MainFrame 51 manages each of the ChildFrames 52, 54, keeping track of which one is active. The MainFrame also catches messages that apply at the level of the application, such as quitting.

[0244] ChildFrame

[0245] This class controls the windows for each of the browser frames. It adds the “chrome” (the button bar, the URL address box, and the Objective ReBar when a test is in session). It supports updates to the Objective ReBar.

[0246] FacilitasIEDoc

[0247] The Document class 53, 57 is a shell. When a new document is created, it calls the ChildFrame to add the Chrome.

[0248] FacilitasIEView

[0249] This class 55, 59 catches most of the messages from the navigation tool bar (anything that is specific to one browser frame, like Forward, Back, Home), as well as those that are window specific (such as font size). It also catches return messages from the webbrowser control that indicate when a document has loaded.

[0250] Access to HTML

[0251] Each FacilitasIEView is also a HTMLDocument2, so when called with the appropriate interface, it's possible to access the structure of the HTML document, getting full HTML text, or collections of the images, or tags.

[0252] History Lists

[0253] The HistoryList is a class defined to abstract the operation of history lists and the related frame history list. It is implemented as an array for each ChildFrame, an array of CStrings that stores the URL, and an array of pointers (to FrameHistoryLists). A third column stores the page titles. The HistoryList class also has an integer data member which acts as an index into the array. The first page displayed in the window is at slot 0, the second page is at [1].

[0254] HistoryList.GetURL(HistoryList.GetIndex) is the URL of the current page. Going back or forward involves decrementing or incrementing the counter. Deeper jumps (via the file “go” menu or drop downs) are just bigger offsets to the index. Allowing back jumping means that the history kept by the Webbrowser control is no longer accurate. Therefore, all navigation, including forward and backward one step, which would be part of the webbrowser control must go through the separate history list instead.

[0255] A related problem is when to add a page to the history list. Doing so immediately upon requesting the page is problematic, because if the page takes too long to load and the tester hits stop, that page shouldn't make it on to the history. On the other hand, waiting until the page is completely loaded is too long—if the tester follows a link before all the images from one page load, that page should still be in the history list. The current choice is to add a page to the history list at NavigateComplete, which happens before all the graphics are downloaded. However, the current implementation does not provide enough information for all of the event codes to work this way. In particular, jumps in the history via the “go” menu or drop downs are recorded instantly, even if the navigation is cancelled quickly.

[0256] Frame History Lists

[0257] Frames are used primarily in two ways by web sites:

[0258] 1) Positioning certain types of content (such as ads);

[0259] 2) Providing an outer “host frame” that may include a navigation bar, while the inner frame contains the changing content.

[0260] The desired behavior of the Facilitas Test Browser is different in these cases. In the first, the frame should be treated essentially as an embedded graphic, and not generate a log entry when the frame loads to completion. In the second case, however, we need to recognize that the completion of a frame load is a significant event. Nested frames have different IDISPATCH interfaces (stored in pDisp) that indicate when a navigation completion is that of a top level page (if pDisp=GetApplication( ) or a real navigation within the frame (case 2 from above) in which case the frame pDisp is the first in a stack of open navigate calls; or (case 1 from above) it is not at the top of the stack, and is in fact a constituent frame, requiring no action.

[0261] If a top level page, then the page history should get updated. If Case 2, the move should be recorded in the history, but in a special way: once you move out of the hosting frame, it should disappear (so people can't navigate to a sub-frame without going through the hosting frame). In addition to storing the URL in the history, it is also necessary to store the frame name, so the page can be appropriately re-generated if it is selected from the history. The resulting data structure is essentially a separate stack (showing the frame history) for each page in the stack of page history. The frame stacks have two strings (a URL and a frame name) and a pointer to another stack history which can be used to handle recursive display of frames correctly. The URL for the hosting frame (the one designated_top) is stored in the page history. Any subsequent navigations within that frame set are stored in the frame history stack. When history lists are generated (in the “go” menu or drop downs) the frame history list for the current page only are included as the nearest neighbors of the current frame, followed by the adjacent entries in the page history stack. If you navigate away from a frame history stack, it seems to “collapse” in the history lists (“go” menu). But if you navigate back to that URL (of the hosting frame), the frame history stack re-appears, with all the local frame navigation events once again listed in the “Go” menu. It's confusing, but it's how IE works . . . Moving forward and backward through the frame set is a bit complicated. Once you move backwards from Frame[0] in the Frame history stack, you go back to the hosting frame in the page stack. When you go back from that, you go to the previous page in the Page History Stack. See FIG. 15. The data structure to store a Frame History Stack is a subclass of the Page History Stack, with an extra field (and access methods) to store the frame name.

[0262] In this example, there have been 9 navigation events, the URL's were visited in order from URL 0 to URL 8. URL1 is the host frame, in which URL's 2 and 3 were sub-frame navigations. URL 5 was the host frame for URL's 6 through 8. Suppose the tester is at URL3: the go menu displays URL's (0,1,2,3,4,5). If the tester is at URL 4, only (0145) are displayed. At URL 6, (0145678) is displayed. In general, the back button subtracts 1 from the URL number in this example.

[0263] Exceptions are:

[0264] Going back from 0 is not permitted, back from 4 goes to 1.

[0265] Table B below shows a sample test script of a usability test according to a preferred embodiment of the invention.

[0266] Table C below shows a preferred embodiment of a network test report, according to the invention.

[0267] The following is a discussion various alternative embodiments of the invention.

[0268] Browser Navigation/Behavior Data

[0269] Capture Locally at the Tester

[0270] Capture browser events through new technology in browser (EventSpy

[0271] Communicator's “Quality Feedback Agent”, etc).

[0272] Capture browser events locally through modified browser application

[0273] Capture browser events through browser as modified on the fly (via applets, plug-ins, and helper apps)

[0274] Use history log of browser

[0275] Capture information at the OS, firing of events, access of resources, bare communication channel . . .

[0276] Capture Remotely at Server

[0277] Modify Web sites to be analyzed (use of frames, JavaScript, cgi scripts, cookies, etc)

[0278] Use server logs

[0279] Use info coming in at the raw communication channel

[0280] Capture at Third Party

[0281] Capture communications at a Web proxy

[0282] Applet/Link from a third party server

[0283] Remote server which captures the site to be tested within a frame

[0284] Survey Data/Explicit Commentary

[0285] Capture Locally at the Tester

[0286] Capture browser events locally through modified browser application

[0287] Capture browser events through browser as modified on the fly (via applets, plug-ins, helper apps)

[0288] Related applications for audio capture

[0289] Capture Remotely at Server

[0290] Modify Web sites to be analyzed (use of frames, JavaScript, cgi scripts, cookies, etc)

[0291] Communication channel from a remote test manager (human or automated)

[0292] Capture at Third Party

[0293] Applet/Link from a third party server

[0294] Remote server which captures the site to be tested within a frame

[0295] Implicit/Subconscious Data

[0296] Capture Locally at the Tester

[0297] Video capture

[0298] Bio-response

[0299] Capture Remotely at Server

[0300] Communication Channel from a remote test manager (human or automated)

[0301] Data collected at the client is typically combined with data from other clients in the analysis. Usually this involves transmission of the data from the client to the server. The data sent may either be in raw form, or summary statistics after processing has been performed at the client. The amount of data may be either very small (on-line transferals of each log entry or response made, e.g.) or much larger scope (the log for an entire test script, or extended period of browser usage). Either the client or server may initiate such transfer. Trigger events may be explicit user actions, time-based, log sized based, in response to a remote message (sent via RPC, e-mail, etc), visiting a particular page of the WWW. A (denigrated) alternative is to manage the data as a distributed database, with each tester client maintaining his or her own information and contributing to the processing of any query that may involve said data. Encryption and compression may be advantageously employed to enhance the security and efficiency of the data transmission step.

[0302] Download application via the Web

[0303] Download applet via the Web

[0304] Download plug-in or helper app via the Web

[0305] Distribute magnetic or optical media via mail

[0306] E-mail an application, applet, plug-in or helper app

[0307] Pre-load/bundle with computer purchase

[0308] Pre-load/bundle with delivery of other software (browser, OS . . . )

[0309] The test script is a way to guide the tester to exercise certain parts of the Web site or application. It also specifies what questions are to be asked, under what conditions. There are two essential tradeoffs to be made: whether processing takes place at the client or the server, and whether the test is pre-computed or constructed dynamically. Both of these tradeoffs exhibit a spectrum of possible solutions. Some of the sample options within this space are: 1) A powerful, expressive general programming language that is interpreted at the client. Under this formulation, the test script device is a program that is “executed” within the testing device at the client. 2) A “Universal Plan” (in the style of Schoppers AI planning work): For each possible test state, a next question has been pre-calculated. The whole plan comprises the test script device, and may be represented as a table, a tree, or other data structure. 3) A limited programming language. In this style, the test script device is also an executable program, but its capabilities are limited to the common operations of the domain. The architectural design document (Table A) describes one such limited programming language based on triggers in more detail. 4) A simple “question/response” pairing. Under this formulation, the entire test is generated dynamically. The client sees only one question at a time, and sends a response to that question. All calculation about which question to ask next is carried out at the server (perhaps based on one of the techniques described earlier). 5) Hybrid approaches combine some simple question/response pairs with a more powerful dynamic generation technique, along with guidelines about when to use each technique.

[0310] The test script construction generally requires knowledge:

[0311] 1) Of the site being tested (what objectives to set, what questions to ask, what possible answers to offer, what types of testers should be recruited); and

[0312] 2) Of the testing techniques (format of the question, useful questions that enhance analysis, size of test population, length of test, etc).

[0313] The test script construction process may be a collaboration between two or more people that together have the necessary expertise. It is also possible, however, to provide the expertise detailed above in “intelligent” tools that help construct the test scripts. One such tool is a simple editor that provides forms to fill in basic data and translates those forms into a full test script, perhaps adding common recurring questions from a standard template. Other tools may assist in the script construction by surfing the site to be tested and automatically collecting relevant domain questions. Server logs and the like may be used as an additional input to the tool to help construct the test.

[0314] The mechanisms to provide the collaboration between people (possibly assisted by tools) are diverse: a stand-alone application, a Web-based application or applet, macros in a word processor, a “group ware” application, voice-based systems such as IVR, along with the full range of technologies to allow the collaborators to communicate with each other.

[0315] Test scripts need to be available to the tester client. They may be distributed by:

[0316] Download test script via the Web (either as a separate resource or embedded within a larger resource)

[0317] Distribute magnetic or optical media via mail

[0318] Physical tokens that contain the information (bar code, magnetic token, etc)

[0319] The collected data are useful in a variety of ways, so it is advantageous to store the raw data for subsequent analysis. Any type of database (relational, object, multi-dimensional, for example) can be employed for storing the raw data. Access to the raw data may be granted over a computer network, or the data file may be distributed in ways similar to those described for data collection device distribution. As noted above, it is also possible to permit each tester to maintain control over his own data, treating the population as a distributed data base.

[0320] In order to extract the most value from the collected data, it is typically necessary to perform additional analysis. This analysis may include simple aggregation (sums and averages, for example), selection (production of a subsample) of “typical” data, finding outliers and either excluding them or focusing on them, measuring correlations between data factors, measuring the confidence in a hypothesis. Results from such queries may be presented in tabular or graphical format. Subsamples of the data can also be textual, audio, or video.

[0321] The tools to perform this analysis can either be custom crafted to specialize in this domain, or they can be general purpose database and statistical analysis tools, perhaps enhanced with “stored procedures” crafted for the domain.

[0322] Analyzed data may be distributed in the same ways as raw data, but additional alternatives are now advantageous. Hardcopy reports (delivered via mail or fax) are practical when the length is short. Publication of results on a web site, in a periodical, or other press release is appropriate for certain types of analyzed data. In other cases, interactivity is a key aspect of the data usage, so posting to a web site, or distribution of data files in machine readable form (via e-mail, ftp, http, or mailed magnetic or optical media) is more appropriate.

[0323] The selection of testers to participate in a test can greatly affect its outcome. Often, the owner of the site to be tested, or the company that has commissioned the test composes the makeup of the desired test panel. The description of the test, as well as the places in which it is publicized determines respondents. Some options are: publication of the test at a well known depository for multiple tests (e.g. the Facilitas Web site), e-mail distribution, a link or ad on the site to be tested, a link or ad on a separate site that targets the demographics of the desired tester sample, direct mail, inserts into certain physical products. In all of these cases, additional qualifying questions may be asked before the test begins to ascertain that the tester meets the desired characteristics. In some cases, the ability to meet these characteristics may be proven through digital certificates, references, or physical documentation such as a driver's license or passport.

[0324] Additional tools may assist with the selection of an appropriate sample size, as well as providing an estimate as to how long it may take to recruit a test panel exhibiting the desired characteristics.

[0325] Given the “remote” nature of the testing, in most cases, there is not any direct observation of the tester during the test. Therefore, additional techniques may be employed to ensure that the tester is taking the test with his “best effort”. Some may be statistical techniques to see that adequate progress is being made (in terms of the number of pages visited, e.g.) some may be “pop questions” that ask trivial questions (3+5=?) but require an answer within 5-10 seconds. Other techniques may encourage testers to leave more comments when they have not done so for some time. A post hoc analysis of the test (which may be automated) may result in a test being excluded from consideration in the results.

[0326] The following shows a preferred embodiment of two core products of the full-service bureau and test center, according to the invention.

[0327] Network Tests: These are tests specified by customers and managed through the Facilitas Test Center. Results are made available in raw data or via a Web-based OLAP-style data mining tool, specifically designed for reporting on and analyzing usability and Feature Quality™ testing data. This is useful for the reasons outlined in the business plan.

[0328] Industry Reports: These are based on sponsored tests against the top players in a specific industry segment. Industry Reports analyze the relative Usability and Feature Quality™ of each player against a standard set of user tasks relevant to that industry segment. Industry Reports are published and distributed to customers on a subscription basis.

[0329] A sampling of the industry segments to be covered follows:

[0330] Search Engines (several categories)

[0331] Shopping (several categories)

[0332] Publications (several categories)

[0333] Travel

[0334] Regional

[0335] Yellow Pages/Directory

[0336] Chat/Community

[0337] Brokerage

[0338] Online Banking

[0339] Finance and Investing

[0340] Calendaring/Scheduling

[0341] Gaming

[0342] Groupware

[0343] Human Resources/Accounting

[0344] Auction

[0345] Adult

[0346] Kids

[0347] Personal

[0348] Classifieds

[0349] Sports

[0350] Email

[0351] Customer Service

[0352] The following is a discussion of multiple of embodiments of additional full-service bureau and test center products, according to the invention.

[0353] 1) Expanding the test product suite to support the entire product development cycle. The full product development cycle typically requires different types of user input for each phase:

[0354] a) Planning: Requirements gathering is the main activity here. Facilitas Industry Report is most effective at revealing the strengths and weaknesses of the customer's product against competitors, and helps in generating an initial list of next-generation product requirements.

[0355] b) Design: Research to fully understand the user's mental model in a given domain is useful here. Products to support “card sort” tests and other such exercises can be built into the Facilitas testing suite

[0356] c) Development: Testing of whole features is most prevalent here, as developers build subsystems of the full product, and need to test them part-way through to make sure they are going in the right direction. Products to support testing of specific features and semi-functional prototypes can be built into the Facilitas testing suite.

[0357] d) QA/External Beta: Testing of how the product helps or hinders users who are trying to solve whole problems is critical here (i.e. Feature Quality™). Facilitas Network Test is targeted at this phase

[0358] e) Post-launch: Facilitas Industry Report can be performed again here, to measure the relative improvement of the product as measured against the same set of competitors tested in the Planning Phase.

[0359] 2) Richer data collection on the tester side via enhancements to the test browser:

[0360] a) Audio/Video recording of individual user test sessions

[0361] b) Voice-to-text conversion of user comments.

[0362] c) Full test replay module, so the test analyst can pick certain test sessions and replay exactly what happened at certain points.

[0363] d) Natural-language processing module to filter tester comments and pick out “representative” comments.

[0364] e) Bio-electrical impulse/brainwave data capture and recording for monitoring of non-verbal, non-visual reactions to content being tested

[0365] 3) Aggregated test results database of all Facilitas-sponsored tests, so that customers have a reference data set to benchmark their sites' performance against various categories, of Web sites, not necessarily those of their competitors.

[0366] 4) Real-time reporting of test results, as they happen. This is accomplished by retrieving data from tester browsers on a more frequent, “click-by-click” basis, and processing and reporting on this information immediately.

[0367] 5) Integration with personalization tools, Web authoring tools, and other such “Web creation and control” systems, which allow developers to make specific design or personalization response decisions, and track how each automated response and design decision leads to changes in Usability and Feature Quality™ of the site. This combination therefore becomes a fine-grained, efficient tuning system for any type of advanced personalization or dynamic content management system. For instance, if a new algorithm leads to a 5% increase in the purchase rate from Website visitors, then a Facilitas test is able to discern if the rise was due to more relevant products being displayed to the user, better navigational cues, a better feeling of security and credibility of the site in the eyes of the user, clearer statement of warranty terms, or lower price.

[0368] 6) Expanded testing capabilities to cover non-browser clients like email, media players, personal digital assistants, palmtop computers, cellular phones, automobile personal computers and distributed enterprise applications.

[0369] 7) Longer-timeframe usability testing to enable “customer relationship quality” testing of a Web site's services and support capabilities, via a Facilitas testing browser installed and used on the tester's computer for an extended period of time, with or without following a predetermined test script.

[0370] 8) A proprietary composite index for measuring the overall quality of any Website tested using the Facilitas testing solution, and using the data generated thereof. The composite index is composed of test performance metrics such as, but not limited to, percent of testers who completed a task successfully, length of visit (in time and pages viewed) taken to complete the task successfully, percent of testers who gave up on a task, percent of testers who completed a task unsuccessfully (i.e. gave the wrong answer or did not fully perform the action requested), and satisfaction ratings given by testers on the Web site's quality, speed, security, comprehensiveness, product selection, product price, visual appeal, accessibility, as well as the testers' own inclination to return to the site on their own and use it for their own objectives and information needs.

[0371] 9) A proprietary composite index for measuring the overall quality of the portfolio work of any Web design and development firm, via a composite index composed using the composite index in #8 above, calculated across the Websites of all or part of a Web design and development firm's current or past Web development client base.

[0372] Although the invention is described herein with reference to variety of preferred embodiments, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the invention should only be limited by the claims included below.