Building Site Advisors with WebLS


Contents

  • A Sample Site Advisor Session
  • Designing A Site Advisor
  • Visitor Characteristics
  • Organizing Site Resources
  • Formulating Good Questions
  • Writing Good Advice
  • Determining the Rules that Match Interests and Resources
  • Running A Site Advisor

  • A Sample Site Advisor Session

    Gathering Information

    Visitors who choose to use the Site Advisor are presented with an initial HTML form, shown in Figure 1, that contains three questions. These gather information about the visitor's interests, type of work they do, and type of organization they work for.

    Figure 1: The initial HTML form

    In this example, the Site Advisor learned from the first three questions that the visitor is interested in implementing intelligent components in Internet applications. This leads to the second HTML form, shown in Figure 2, that poses additional questions at a greater level of detail than the first form.

    Figure 2: Based on the answers to the first form, a second set of questions is dynamically generated

    The answers to the second form lead to one last set of questions, which only appear for visitors that might purchase products. These questions are used to fine tune product recommendations.

    Figure 3: The final set of dynamically generated questions

    Dispensing Advice

    After answering the questions, the visitor is presented with a customized document filled with useful pointers and advice. A part of this document is show in Figure 4. There are two main parts. The first focuses on articles, demos, newsgroups, FAQs, other sites, etc. The second focuses on Amzi!'s commercial, free and shareware tools and products.

    The presentation is a set of dynamically generated paragraphs, each including links to multiple resources. It can incorporate any HTML elements including graphics, sound, video and animation.

    Figure 4: The advice is dynamically generated based on the answers to the questions

    Designing a Site Advisor

    The biggest challenge in building a Site Advisor is figuring out how to organize what you want to say to your visitors. The design involves:

    These elements correspond to the fundamental elements of a WebLS rule base, so once determined, implementing the rule base is a simple matter of phrasing the questions, recommendations and rules in the correct syntax.

    Because rule-bases can be easily built incrementally, it makes sense to start with a subset of visitor characteristics and recommendations. More can be added as you become comfortable with the evolving system.

    Visitor Characteristics

    The first step is to write down the profiles of your visitors. You might find that the free magazine qualification forms provide some insights in determining the categories. Another useful guide is a media kit from a magazine in the same field. These kits often contain reader demographics.

    For our site, we divided visitors into four general categories: technical professionals, researchers, educators and students. These can have subcatagories. For example, technical professionals might be software developers, webmasters, engineers or consultants.

    Visitors also vary in the organizations they are associated with. These can be business, government, education or none and this information also affects the recommendations we make.

    In addition to these general categories, we found it best to also ask about specific application areas of interest, such as scheduling, configuration or expert systems, as we have demos and articles focused on these applications.

    Organizing Site Resources

    There are logical groupings of a site's resource that make sense for different visitor interests. The next step of the design is to identify these. For example, a webmaster, or developer interested in embedded Internet components would be interested in WebLS demos, articles and freeware, as well as our other Internet tools such as our Java Class and Sockets interface.

    The package of related resources for the webmaster is relatively straight forward to determine, as are the packages that are used to respond to application-specific interests.

    Determining resource groupings for the more ill-defined categories takes a bit more thinking. One way to approach this is with a matrix. In our case we made one with job roles down one axis and organizations in another, as shown in figure 5. It's then just a matter of putting resources in the grid spaces that make sense.

    Business

    Government

    Education

    Self

    Software Dev.

    Webmaster

    Engineer

    Researcher

    Consultant

    Teacher

    Grad. Student

    Other Student

    Figure 5: Web site resources based on visitor characteristics

    This analysis leads to a number of groups of related site resources, which will be presented in the final document, based on visitor characteristics.

    Another way to determine how to group resources is to listen to a sales or marketing person speaking to prospects. You can learn what resources, products and features are recommended to which types of potential customers.

    Formulating Good Questions

    Next we write the questions that determine visitor characteristics. This is not as easy as it seems, because you want to be both concise and thorough. One source of inspiration we used for the actual wording was the qualification forms for free magazine subscriptions, which address the same basic problem.

    The questions that are predetermined for the first form should be carefully chosen as they set the foundation from which more detailed questions will be asked.

    WebLS provides a number of options for questions, using standard HTML form elements, such as single-answer multiple choice using either radio buttons or a pull-down list, yes/no questions, questions with multiple answers, and fill-in-the-blank questions.

    Figure 6 shows the WebLS syntax for the radio-button multiple-choice question that determines a visitor's employer.

    question(where,
    [
    firstForm, 
    style = radio, 
    prompt = $Who do you work for?<BR>$, 
    ask = menu(['Business/corporation', 'Government agency', 
                'Educational institution', 'Myself']), 
    itemSeparator = $ $
    ]).

    Figure 6

    WebLS puts little restrictions on the formatting of the questions, so you can include graphics, sounds, videos or other HTML elements as part of the prompt information.

    Since Site Advisors are dynamic, it is important to gather information about visitors whose interests are not reflected in the questions you design. So wherever possible utilize an 'Other' choice on the menus along with a text box to fill in. The rules don't use the entered text, but it is saved for later analysis, and can be used to inspire new or different menu entries.

    Writing Good Advice

    Before writing the rules that link visitors with recommendations, it is valuable to author some of the 'answers'-the paragraphs of advice dispensed by the Site Advisor. Besides needing the answers to execute and test the rules, actually writing them confirms whether or not you have worked out a good organization for your subject groups.

    Figure 7 shows the WebLS code for the answer named 'javaStuff', which is one of the answers shown in Figure 4.

    answer(javaStuff,
    [
    text = [$We've added support for <B>Java</B>. Download the $,
            $<A HREF="/internet.htm">Java class package</A> for the $,
            $Logic Server. It includes a shipping advisor and the classic $,
            $hello samples.$]
    ]).

    Figure 7

    For our Site Advisor, we tried to ensure the advice is concise, uses links to resources liberally and stands on its own without further explanation. Remember the advice document is dynamically generated and includes only a subset of the answers.

    Like questions, WebLS imposes no formatting of answers other than a paragraph mark between them, but lets you control headers and footers so you can present them in list format (as you can see in the bottom of Figure 4). You can also include any kind of graphics or multimedia elements in your answers; including perhaps verbal product explanations, video demonstrations, music, animation and more.

    Determining the Rules that Match Interests and Resources

    Now it is time to write the rules that link the questions and the answers together. If-then rules are an easy way to represent these relationships because they allow you to specify the logical connections without having to worry about how the rules get used.

    This is especially important in maintaining the rule-base, because individual rules can be readily added, deleted and changed without affecting the fundamental structure or integrity of the entire rule set.

    Rules can be simple or multi-part, and serve a couple of purposes. They can relate facts directly to answers, or can be used to derive intermediate facts that are then used to find either further facts or answers.

    Simple One to One Rules

    The simplest rules map a single menu choice in a question to an answer as shown in the first part of Figure 8. 'whys' is the name of the first question in Figure 1. Because 'whys' can have multiple values, we use the 'include' operator to determine if an item was checked. 'what' is the name of the second question in Figure 1.

    If 'Product/service advisors' and 'Consulting' are checked, the execution of these two rules will result in the answers named 'advisorStuff' and 'consultantProgram' being dispensed as advice.

    The values of 'whys' and 'what' selected by the visitor are known as 'facts.' So rules are said to reason over facts.

    Multi-part Rules

    Rules can check the answers from multiple questions as shown in the second part of Figure 8. The '\=' means not equals. WebLS supports the usual collection of comparison operators, which can be used for both arithmetic and textual facts.

    Notice that one of the rules in Figure 8 has 'then tool=' and others have 'then resource='. This is because our Site Advisor is searching for values for both of these goals. The various answers for resource= are site resources, whereas the tool= answers relate to specific product offerings.

    Having multiple goals provides a nice way to organize the advice. You'll notice in Figure 4 that the top half of the advice is resources and the bottom half is tools.

    Intermediate Rules

    If there were just clean one-to-one mappings, a table-driven approach to a Site Advisor would be adequate. However, the real world doesn't often line up that neatly. Rules provide a more flexible tool for mapping, including the possibility of using rules to derive facts that are input to other rules.

    For example, one fact we want to reason over is whether the visitor is doing commercial development. But there are a number of different question answers that imply the visitor is involved in commercial development. This is expressed in the first rule in the bottom section of Figure 8.

    The fact 'commercialDevelopment' is then used in another rule as one of the criteria for deciding whether or not to present the user with information about our ODBC connections.

    So, the then-side of a rule can be an answer or another fact. And facts can either be gathered from questions or distilled from rules.

    One to One Rules
    if whys include 'Product/service advisors'
    then resource = advisorStuff. 
    
    if what = 'Consulting'
    then resource = consultantProgram. 
    Multi-part Rules
    if exploreProlog = yes and
    prologFamiliarity \= 'Very'
    then resource = prologIntroStuff. 
    
    if whys include 'Intelligent components for Internet' or
    what = 'Website construction' or
    what = 'Other'
    then tool = webLS. 
    Intermediate Rules
    if (what = 'Software development' or 
    what = 'Website construction' or
    what = 'Engineering' or what = 'Consulting') and 
    (where = 'Business/corporation' or 
    where = 'Government agency')
    then commercialDevelopment = yes.
    
    if (commercialDevelopment = yes or 
    what = 'Research') and
    connections include 'Existing databases'
    then resource = odbcStuff. 

    Figure 8: Some sample rules

    Running A Site Advisor

    The processing of rules is called inferencing, and different rule engines use different inferencing strategies. The WebLS inference engine is designed to determine the values of specified goals, in this case resources and tools. WebLS is especially optimized for Internet use in that questions are batched on the forms, rather than presented one at a time as needed. This makes for a quicker interaction between user and system.

    Step 1: Just Rules

    Now that you have questions, rules and answers, how are the rules executed to ask the questions and output the answers? First you start with a set of rules as shown above. There are also the definitions of the questions, that is how to format and output the HTML codes to ask for the value of a fact. And, there are the definitions of the answers, that is how to format and output the HTML codes to display the advice paragraph.

    Step 2. Gather the Initial Facts

    In order to get some facts for the rules to reason over, we output the questions that are designated to appear on the first form (see Figure 1). These initial facts are the basis of the entire execution of the rules.

    Step 3: Reach Some Conclusions and Determine Hypotheses

    Having gathered some initial facts as shown on the left side of the figure above, the rules are now executed for the first time. There are two results. First there is a set of conclusions, these are rules that can be proved. A if-then rule is proved if all the facts on the if-side of the rule have a value and if that value meets the constraints given. In addition to conclusions there are hypotheses. These are rules that have neither been proven nor disproven. All the facts on the if-side that have values match, but there are still some facts for which the value is not known.

    Step 4: Gather More Facts to Prove or Disprove Hypotheses

    This leads to the next step which is to gather more facts. For each unknown fact in the hypotheses, we output the corresponding question. After the visitor answers these questions, the rules run again. The result show above has changed as follows:

    Step 5: Repeat 4 Until No More Hypotheses

    The gathering of facts is repeated for each goal. Remember the Amzi! Site Advisor has two goals: resource and tool. It tries to find as many values as it can for each goal. So again, after asking the visitor more questions, we have more facts, more conclusions and less hypotheses as above.

    Step 6: Present the Conclusions

    Finally we have either proven or disproven every rule. The result is shown above. There are no more hypotheses, only conclusions. All the conclusions that are answers (goals) are outputted as separate paragraphs (see Figure 4).

    Copyright ©1996 Amzi! inc. All Rights Reserved.