Method and system for providing interactive electronic catalog for product and constraint information of equality and inequality search6324536Abstract A system for collecting, categorizing and searching metadata about products which may be the subject of user-input inequality searches. Unique methods are provided for: generating image information at the user interface; inputting of the inequality search; conducting an inequality search based on the metadata in response to input at the user interface; and; displaying the search results appropriately. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE I
COLUMN
NAME TYPE PURPOSE
MerchantID INTEGER ID used in multiple merchant
environments
CategoryID INTEGER ID used to identify a category of
products
FeatureID INTEGER ID for single product feature
Name CHARACTER The column name of product in the
table
Usage INTEGER HOW feature used (e.g., data, image,
etc.)
Size INTEGER Size of the data if character-based
Type INTEGER Type of data (e.g., float, double, etc.)
Unit CHARACTER String representing unit of measure
KeySequence INTEGER Indicates this is part of a key field
Nullable INTEGER Flag to determine if null values allowed
Description CHARACTER A textual description to use to label the
data when displaying to the user
Elaboration CHARACTER Long detailed description of feature
Location INTEGER Indicator of where the data originally
came from (used in rebuilding data)
Included INTEGER Flag to determine if the feature should
be included at run-time
Scale INTEGER If data type is numeric, the number of
digits left of the decimal
Precision INTEGER If data type is numeric, the number of
digits right of the decimal
The second level of metadata (Level 2) is concerned with the particular manner of display chosen for the feature. This data might change for a different instance of the data, so that the relationship between the first and second levels of data is one too many. The second level of metadata is composed of display attributes about the data, for example: what manner in which the data should be displayed; how multiple values should be sorted; and whether a unit of measure should be displayed next to the values, how juxtaposed, etc. Table II provides the Level 2 metadata:
TABLE II
COLUMN TYPE PURPOSE
MerchantID INTEGER ID used in multiple merchant environments
CategoryID INTEGER ID used to identify category of products
FeatureID INTEGER ID used to identify a single product
feature in the Level 1 metadata
MetaphorID INTEGER ID used to identify the metaphor for which
the metadata was collected
Displayable INTEGER Flag indicating if the feature should
be displayed
Sort INTEGER Flag to indicate ascending or descending
sort of data values
WidgetType INTEGER Type of display to be used for values
OrderSeq INTEGER Order Sequence-if the feature is part of
a key; its position in the key
UOMDisplay INTEGER Flag to indicate if the unit of measure
string should come before or after the
data, or not be displayed at all
ProductLink INTEGER Flag to indicate that selecting this
feature will link to its product
Given the availability of the foregoing Level 1 and Level 2 metadata, the system can dynamically determine how to deal with the data at run-time. Representative pseudo-code for using the available metadata at run-time follows:
GET CATEGORY FOR SEARCH
GET PREVIOUS CONSTRAINTS
GET LIST OF FEATURES OF PRODUCTS IN CATEGORY
FOR EACH FEATURE
GET METADATA ABOUT THE FEATURE
IF IT SHOULD BE DISPLAYED
GET UNIQUE VALUES, GIVEN CONSTRAINTS, SORTED
BY METADATA SORT
GET USAGE
IF AN IMAGE
GET THE ACTUAL INAGE
END IF
IF IS CURRENCY
FORMAT CURRENCY FOR LOCALE SETTING
END IF
GET THE WIDGET TYPE
DISPLAY THE VALUES
IF THE DATA IS CHARACTER
SHOW QUERYBAR FOR =, .noteq.
ELSE
SHOW QUERYBAR FOR =, .noteq., >, <
END IF
ENDIF
END FOR EACH FEATURE.
In FIG. 4, the "build-time" processing steps are representatively illustrated. At step 401, the product information is indexed, followed by generating product constraint information at step 402. The product constraint information comprises the "immutable" first level metadata. Once the information has been generated, the product information and product constraint information are stored at step 403 for use upon initialization of a user query (discussed below as "run-time" processing). Additional display information may be generated at step 404 and stored, at step 405. The system is further driven by a set of templates at run-time. These templates determine the overall layout of the data. While the data is assumed to be displayed in a table, the template can define how that table should look, (e.g., its orientation, number of rows and columns, background colors, etc.). Any information which is unique to a specific feature is specified in the metadata and any information that controls the overall layout of features is specified in the template. By using these methods, the final determination of what features are shown and how they are sorted, etc., is left to the product expert who enters the data; while the final design and presentation to the customer is left to someone who understands catalog and product layout, such as a graphics artist. The templates are HTML files having special tags that the system recognizes during run-time and processes appropriately. Anything that is not a recognizable tag is passed through the system to be processed by the web server. The custom tags are placed in "comments" so as not to confuse a web browser, which would be unable to "understand" them. The format of the tags is as follows: <!--IC_TAG=tagname option1=value1 option2=value2 etc . . . --> At run-time, the system searches for lines in the template which start with "<!--ICTAG=" and then parses the next word to determine which type of tag is present. The system then passes the remainder of the string over to a class which knows how to process that particular tag. The tag class then renders the tag to the client. All of the known tags are kept in the registry which aids the run-time program in determining what tags are valid and what classes should be used to process the tags. In this way, tags can be added in the future without any modifications of the system, thereby allowing dynamic updating of the display formats without requiring that the catalog be taken "off line" during implementation of updates. Because the system is written in JAVA, new classes can be added while the system is running, simply by refreshing the registry. The pseudo-code for the master run-time loop, including template recognition and implementation, is shown below:
GET CATEGORY
GET CONSTRAINTS
GET TEMPLATE
READ A LINE OF TEMPLATE FILE
WHILE NOT END OF TEMPLATE FILE
IF LINE CONTAINS OUR TAG SIGNATURE
CHECK TAG REGISTRY FOR EXISTENCE OF TAG
IF WE RECOGNIZE TAG
INSTANTIATE CLASS REGISTERED TO TAG
CALL CLASS PASSING IN CATEGORY,
CONSTRAINTS
AND REMAINDER OF TAG TEXT
ENDIF
ELSE
PASS LINE OF TEMPLATE FILE TO WEB SERVER
TO PROCESS
ENDIF
READ A LINE OF TEMPLATE FILE
END WHILE.
The call to the class that handles the tag, shown in the master run-time loop pseudo-code above, invokes similar pseudo-code to that shown previously. Therefore, the main run-time logic simply iterates over the template looking for tags to process, and the actual processing, which is unique to each tag, is handled by a tag's registered class. The valid tags for a representative implementation of the system are seen in Table III. Each tag is registered in a row of a database table which contains the name of the tag and the name of the class which must be used to process the tag.
TABLE III
NAME OPTIONS
IC_TAG=CAT_NAME n/a
IC_TAG=PROD_COUNT n/a
IC_TAG=SA_QUESTION n/a
IC_TAG=SA_ANSWERS n/a
IC_TAG=QA_HISTORY order-LQF FQL
IC_TAG=PC_LINK image=image name
IC_TAG=PE_LINK image=image name
IC_TAG=SA_LINK image=image name
IC_TAG=PC_TABLE orientation=HORIZONTAL VERTICAL
values=COMMON UNIQUE
headbgcolor=#color value
IC_TAG=PE_TABLE orientation=HORIZONTAL VERTICAL
values=COMMON UNIQUE
headbgcolor=#color value.
User Interface Image Once the system is capable of supporting inequality searching, the user interface must provide an input mechanism beyond that which has been previously available. However, the need for multiple buttons to express the various values of equality and inequality may clutter the screen in an environment where screen real estate is very expensive. For example, if a customer is presented with a selection of ten (10) product features, forty (40) screen representations or buttons would be needed to express all of the statements of the query (i.e., one each for "equal to feature x", "unequal to feature x", "greater than or equal to feature x" and "less than or equal to feature x" for each of features one through 10). The forty buttons would not only take up a great deal of screen real estate, but would also overwhelm the user with choices. A first alternative is to provide four screen "buttons" to represent the four query statements for each feature, as schematically illustrated in FIG. 1. The HTML code for the illustrated hard drive representation would be as follows:
<TABLE CELLPADDING=5 CELLSPACING=2 BORDER=0
WIDTH=580 BGCOLOR=#cccff >
<TR>
. . . other cells here . . .
<FORM METHOD=GET ACTION="/cgi-bin/mycgi">
<SELECT NAME=HARDDRIVE>
<OPTION VALUE="540" >540
<OPTION VALUE="720" >720
<OPTION VALUE="810" >810
<OPTION VALUE="1200" >1200
<SELECT><BR>
<INPUT TYPE=submit NAME=equals VALUE="Equal">
<INPUT TYPE=submit NAME=notequals VALUE="Not equal">
<INPUT TYPE=submit NAME=lessthan VALUE="Less than">
<INPUT TYPE=submit NAME=greaterthan VALUE="Greater
than">
</FORM>
</TR>
</TABLE>.
As is illustrated, the browser has "wrapped" the buttons for each feature, due to the fact that the buttons would have been too wide to display next to each other. The text button display is clearly not visually appealing for the user. Moreover, if one were to imagine all query statements for all product features, the display would overwhelm the user and the buttons dominate the look of the page. Furthermore, different web browsers may display the text buttons in different configurations, depending upon the browser's specifications and protocols. Therefore, a consistent look across different browsers accessing the underlying catalog could not be guaranteed. In addition, when a selection is input by the user to one of the text buttons of FIG. 1, the web server would return a query string and utilize logic to test for the existence of each variable. For the "not equal" example, the query string developed by the common gateway interface (CGI) would be: QUERY_STRING=HARDDRIVE=540¬equals=Not+equal. As can be seen, there is no single variable to check, such that each button generates a new variable name. The query would require logic to test for the existence of each variable while anticipating that three of the four would not be generated. Once the program determined which variable was generated, it would then use logic to determine what to do next. Alternatively, one could define all four buttons to have the same name as in the tags below: <INPUT TYPE=submit NAME=operand VALUE="Equal"> <INPUT TYPE=submit NAME=operand VALUE="Not equal"> <INPUT TYPE=submit NAME=operand VALUE="Less than"> <INPUT TYPE=submit NAME=operand VALUE="Greater than">. Using the latter programming, the CGI would return a string representing the button word, and a string compare would be conducted to compare the returned string to the available choices. String comparisons, however, are expensive to execute, making use of such comparisons a less than optimal solution. This user input interpretation process requires several steps; and, therefore extra time. While a useful option for implementing the inequality search, an alternative embodiment has been developed to provide faster, and more visually appealing query statement representations. FIG. 2 illustrates the preferred embodiment of the graphical user interface for the inventive inequality searching. A selection bar, 20, 22 and 24, is provided for each of the product feature values for users of the computer system to easily indicate whether they are interested in retrieval of values equal to, not equal to, greater than or equal to, or less than or equal to, the illustrated value. The selection bar takes up minimal screen space and does not require sophisticated user input in order to implement the desired query. The product feature values, shown as memory in megabytes at 21, hard drive in megabytes at 23, and modem speed at 25, are each accompanied by a selection bar bearing mathematical symbols that express the query. Each selection bar is a single image which takes up minimal screen real estate. Since the selection bar is an image, the web browser will not separate the elements of the image and "wrap" them, as may occur with the text buttons shown in the FIG. 1 embodiment. It is to be noted that the selection bar illustrated for each of the first two features, memory and hard drive, provides for selection of four queries based upon the displayed value. Therefore, the user can retrieve product information about all available computers having, for example, more than 4 Mb of memory but less than 540 Mb on the hard drive; or exactly 4 Mb of memory with a hard drive having more than 540 Mb; etc. Since the search conducted in response to selection of one of the four queries for either the memory or hard drive feature value is a numerical comparison, inequality searching is possible. For the illustrated value for the CD ROM, however, which is 2X (meaning two times the normal speed of 150 rpms), greater than and less than comparisons cannot be conducted on the character string "2X". Therefore, the query choices provided for the CD ROM feature includes only equal to or unequal to the value 2X. As will be apparent to one having skill in the art, it may be possible to express the feature value differently in order to allow for inequality searching for that feature. For example, one could express the CD ROM feature in rpms (e.g., 300) and then conduct any of the four queries on the numerical representation, which does not then involve searching on character strings. Characterization of the product features in the electronic catalog is, however, ideally expressed in the terms of the art which have already been developed through standard marketing channels. Therefore, each type of representation and search can be supported by the present invention, as is appropriate to the product, the market, and the user needs. By providing a single image of the selection bar, one avoids the possibility of the web browser altering the display, as noted above. In addition, the input interpretation is facilitated by providing the queries as illustrated in FIG. 2. The CGI program that interprets the user input would use the X,Y coordinates returned from the call in the environment variable QUERY_STRING to determine where the user pressed on the button image. In actuality, for the illustrated selection bar/button as shown in FIG. 3, only the X coordinate is required for interpretation of the user's input. If the user pressed, or clicked on, the "not equal to" section of the image, the following query string would be returned to the CGI program: QUERY_STRING=HARDDRIVE=540&X=35&Y=6. Because the symbols on the selection bar are of identical size (e.g., 22 pixels in width), a simple offset calculation along the X axis can be used to determine how far over the user pressed, and thus what symbol was selected. In the example above, 35 is between 22 and 44, which places the input on the second symbol. Such input interpretation is much faster than the variable or character string comparisons required by the FIG. 1 embodiment. For data that is character-based, such as the CD ROM feature values discussed above, the less than and greater than queries may not be appropriate. The inappropriate query representations can be removed from the selection bar without affecting the programming logic, since the X values will simply not be generated in that range for the particular product feature displayed. The pseudo-code below shows the logic: if (X<22) // the user pressed equal else if (X<44) // the user pressed not equal else if (X<66) // the user pressed less than or equal to else if (X<88) // the user pressed greater than or equal to endif. The first "if()" that gets satisfied indicates the symbol selected by the user. The selection bar can be implemented for a WWW application by using an HTML form which contains an <INPUT>tag that creates an image button. The button would use the bar as its image. The HTML code for using the selection bar would be as follows:
<TABLE CELLPADDING=5 CELLSPACING=2 BORDER=0
WIDTH=580
BGCOLOR=#CCCCFF>
<TR>
. . . other cells here . . .
<FORM METHOD=GET ACTION="/cgi-bin/mycgi">
<SELECT NAME=HARDDRIVE>
<OPTION VALUE="540" >540
<OPTION VALUE="720" >720
<OPTION VALUE="810" >810
<OPTION VALUE="1200" >1200
<SELECT><BR>
<INPUT TYPE=image SRC="/icons/equalbar.gif" border=0
VALUE=SUBMIT >
</FORM>
</TR>
</TABLE>.
The resulting display is an image that contains mathematical characters that would not otherwise be represented on an HTML page. Furthermore, because it is an image, the web browser will not wrap it in the cell. Programs that use the illustrated selection bar of FIG. 2 evaluate where on the bar the user has pressed or clicked to determine what action to take. The bar itself is generated from the single line of HTML code with the tag: <INPUT TYPE=image SRC="/icons/equalbar.gif" border=0 VALUE=SUBMIT> While the illustrated selection bar image is symmetrical, it may be generated as an asymmetrical image as well; however, input interpretation is not as straightforward for the asymmetrical image instance. Operation In operation upon initialization a user will be presented with a query display based on the information generated and stored in accordance with the processing steps of FIG. 4. As shown in FIG. 5, the system will dynamically generate an image file, at step 501, and display the file, at 502, including the product features and graphical representations of the operators (i.e., the equality and inequality operators). The system receives user input, at step 503, as a user of the system selects a feature that they desire in a product (e.g., hard drive), a value or values desired for that feature (e.g., 1 GB), and an operation on that feature/value pair (e.g., "greater than or equal to"). They do this by selecting the value or values they want from a list that is generated for each feature. The system searches at 504 and displays the search results with further search parameters at 505. If further user input is receive, at 506, the system repeats the search and display steps until the user query is satisfied. The user input selection (again, by clicking on a portion of the image) is interpreted as a query similar to the following: SELECT DISTINCT(HARDDRIVE) FROM FEATURETABLE WHERE <where_clause>. The query shown above will return only the unique values for the feature HARDDRIVE that are in the system. At first, the <where_clause> is empty. As features, values and operations are selected, the where clause will contain the selections (or constraints) so far. If the user selected 1000 and clicked on the "greater than or equal to" symbol on the selection bar for hard drive, the next time that the query is run, the system would add HARDDRIVE>1000 to the where clause. The foregoing has the effect of subsetting all of the other feature values as only those which are also found in a product with a hard drive which is 1 GB or larger. On successive queries, the values are ANDed together so that only products which contain all of the selected features will be considered. Alternatively, the features could be ORed together to show the user products which have ANY (i.e., one or more) of the selected features. In the above example, where the initial values list for MEMORY could have contained 8, 16 and 32, after the HARDDRIVE selection, the system may return only 16 and 32 because there are no available products with 8 MB of memory and a 1 GB hard drive. In this way, feasible products are always kept in the product space and the user will never enter a query selection which yields no products (i.e., no search results). Providing the user with search results is extremely important for keeping a user shopping at your web site, as there is nothing more frustrating than taking the time to formulate a query, only to get back no results. It is important to note that if the user selects multiple values on a single input entry, these values must be ORed with each other before being ANDed with previous or subsequent constraints. For example, if the user selects 1000 and 2000 for HARDDRIVE, then the query should be "HARDDRIVE=1000 OR HARDDRIVE=2000". If on the next invocation, the user selects "MEMORY=16", then the query should be "HARDDRIVE=1000 OR HARDDRIVE=2000 AND MEMORY=16". In this way, like features from each iteration are ORed together and dissimilar features are ANDed together to produce the desired result. It should be noted that "like" features from successive iterations are not ORed together, but rather ANDed together, which allows further refinement of a previous feature constraint. In order for the foregoing to work in a web-based CGI environment, the system must maintain its own state, because CGI programs inherently have no notion of state. CGI programs service a transaction and then exit, "forgetting" everything previously done. It is for this reason that the constraint list of feature, operation, and values must be converted into a format which can be appended to the URL and later transformed back into constraints for a <WHERE_CLAUSE> on subsequent invocations. The server program sends its state, including the previous constraints, to the client and the client sends the constraints back in the next <WHERE_CLAUSE>. In this way, previous constraints from previous query string(s) from the HTML query will be incorporated into each successive call. The invention has been described with reference to several specific embodiments. One having skill in the relevant art will recognize that modifications may be made without departing from the spirit and scope of the invention as set forth in the appended claims.
|
Same subclass Same class Consider this |
||||||||||