As indicated on the Project Background Knowledge page, the main purpose of providing visual support is twofold: to provide (1) support to a user to reduce their cognitive load (the amount of information working memory needs to process at any given time) and (2) an indication of the progress on the task that has been made thus far. Visual support will be provided by means of a webpage. This page aims at explaining how you can develop code for your MARBEL agent to create such a webpage.

Using Prolog to build HTML elements in our agent

It is important to be able to synchronize the conversational interaction and the visuals displayed on the webpage shown while talking. The MARBEL agent manages the dialog, and for that reason also is the logical place to locate the control over the visual elements. This agent uses a renderPage(Html) action in the dialog_generation.mod2g module to render a webpage; when performing this action, the Prolog variable Html therefore should be instantiated with HTML webpage code. All we need to know before we can use this action, is how to create this HTML page in Prolog.

The basic idea is that we will create essentially a single string that consists of the HTML webpage code. We will utilize a combination of Prolog, HTML and Bootstrap to generate the code for dynamic webpages. Prolog rules are used to generate our HTML code. In other words, the HTML code represented as a Prolog atom, essentially a string, is manipulated with Prolog. So what does that look like? We will first take a look at how to construct some very basic HTML code, then explain how we can add more complicated HTML code that is also using Bootstrap components, and, finally, how we can piece together these components into a complete webpage.

Generating basic HTML elements with short tags

An HTML page consists of HTML elements. HTML elements consists of HTML tags that are used to organize content on that page. Tags often come in pairs of a start and end tag. Basic HTML tags, for example, are the tags <p>YOUR PARAGRAPH TEXT HERE</p> that defines an HTML paragraph, the <h1>...</h1> defining a large heading, <b>...</b> defining bold text, etc. There are many of these basic tags which, moreover, are also short which facilitates their frequent and easy use. The idea to generate basic HTML code for these elements in Prolog is very simple: Simply use single quotes '...' to generate such an element. The table next lists a few examples:

There are many simple, short tags where it is easiest to simply put them between single quotes to create a Prolog atom for generating the corresponding HTML code. Another class of short tags are the single tags such as '<br>' for breaking a line and '<hr>' for adding a horizontal line. These are also most easily generated by simply quoting them.

Generating more complex HTML elements with attributes

Most HTML tag pairs can be simply generated by using a start and end tag and by adding some text to create the corresponding HTML. For example, <button>Start</Button> can be used to generate a simple button saying Start. However, to unleash the full power of the HTML language, it is often useful to modify the type or style of an HTML element by adding additional attributes in the form of name="value" to the start tag.

Making a button

For example, the following HTML code creates a large, colored button using the class attribute and several button class values made available by Bootstrap:

<button class="btn btn-secondary btn-lg">Start</button>

Here, Start between the start and end tag is the content of the HTML element, button is used for the start and end tags to create a button element, and the class attribute uses the values btn-secondary to style the button and btn-lg to create a larger button.

Of course, we can still create this HTML code in Prolog by simply quoting it. And for a simple button this may still most often be quite OK. This is because the content we typically want to fit inside of a button element is often just some simple text. But it will be useful to allow for a more generic approach for more advanced HTML elements in which we want to embed other more complex HTML code as content. To illustrate our approach to generating HTML elements with attributes in Prolog we therefore begin with introducing a predicate button/3 for generating HTML code for a button.

In the button example above, we illustrated the overall approach and structure we will use for generating HTML code for elements with attributes but did not include the attribute part yet. We will now also add that to complete the button example. For the button example we will only include one attribute class. We thus end up with a button/3 predicate with three arguments button(Content, Class, Html). Predicates for other HTML tags, such as the div tag, for example, where we would also want to add a style attribute, would have 4 arguments. To conclude our button example, to generate the <button class="btn btn-secondary btn-lg">Start</button> code, we can use the Prolog code

button('Start', 'btn btn-secondary btn-lg', Html)

When evaluating this clause, we would end up with Html having the button HTML code as its value.

Changing and receiving button events in a MARBEL agent

If you would inspect the html.pl file and search for the button predicate, you will find a button/2 predicate too. You will also see that both the button/2 and the button/3 predicates actually are defined in terms of a button/4 predicate button(Content, Class, DataValue, Html). This predicate allows to set the value send as a percept to the agent when the button is clicked. The button/3 definition by default sets this value equal to the Content value displayed on the button. That, however, is not that useful if the content itself consists of HTML tags again. For example, button('<b>Start</b>', 'btn btn-secondary btn-lg', Html) would display a bold text Start but would also send the tags as a percept of the form answer('<b>Start</b>') when the button is clicked. To avoid that, we can use button('<b>Start</b>', 'btn btn-secondary btn-lg', 'start', Html) which would send the more plain and easy to process answer('start') to the MARBEL agent.

Other tag examples: ul, img, div, span

We introduce a few other tags and discuss how HTML code for these tags can be generated using some of the predefined predicates in the html.pl file. These examples should provide you with a general understanding of how you can generate HTML code for a variety of HTML elements.

ul tag

Displaying lists is a practical feature when you want to show a recipe and its associated ingredient list. The most basic way to do this is to use the unordered list ul and list item li tags. Here’s a simple example of what the HTML code would look like:

We have kept the class attribute simple but Bootstrap list groups provides several other values for the class attribute that can be used to change the basic behavior of the ul tag. For example, use list-group-flush for removing the borders and list-group-horizontal for organizing the list items horizontally instead of vertically.

Even though ul is a short tag we still have introduced a corresponding ul/3 predicate ul(Content, Class, Html) because of the embedded content of list items that needs to be supplied and fit in between the start and end tags in this case. Using this predicate we can simply use ul(Content, 'list-group', Html) for generating the unordered list example above. Clearly, a simple quotation approach will not work here as the list of items may easily get very long and unyieldy and upfront we may not even know how many items we need to add to the list (how many ingredients, for example, does a recipe have?). To facilitate the creation of the HTML list item elements, we have provided the predicate itemList(List, Html) that generates the list item elements when provided with a list of the content for each item. For our example, itemList(['1st item', '2nd item', '3rd item'], Html) will generate what we need as content for the ul element.

The final step that remains is to piece the two things together to generate the complete HTML code for our example. For generating HTML code, we will use the fact that Prolog evaluates subqueries in a query in the order they appear. As a general rule of thumb, in this content, we should make sure to generate the HTML elements we need later first. That is, because we need the list item elements as content to complete the unordered list code, we need to create this code first. In other words, we will use the output argument of itemList/2 as the input argument for the content of ul/3. By piecing the separate queries we defined for the list itself and for the list items together and renaming the appropriate argument variables, we get what we need:

This combined query will generate our example HTML code and return it as value in the Html variable.

img tag

Although this project is not about webpage development and is definitely not about promoting fancy interaction (remember to prioritize conversational interaction throughout the project!), by simply adding some images you can bring a webpage to life, making it more appealing to look at while also adding useful functionality. To start with the latter, users would like to see what the result would look like for the recipe they finally choose. To this end, links to the pictures of all of the recipes included in the recipe database have been included for you to make good use of (check out the recipe_database.pl file). But there are many other opportunities, of course, to add pictures if you like to your webpage design. To facilitate this, we have defined the img/4 predicate img(Source, Class, Style, Html) which allows you to create an img HTML element that looks like:

Check out some of the class options here. The style attribute can be used, for example, to display an image inline (e.g., as part of a sentence in a paragraph) with style="display: inline;".

The Source argument for the predicate is a required input argument. You can use links to pictures that are online available here. For your convenience, for all of the recipes included in the database, the picture/2 predicate picture(RecipeNr, UrlLink) provides images for each recipe. As an example, to illustrate the use of the both picture/2 and img/4 predicates in a combined query, picture('1', Source), img(Source, 'img-thumbnail', 'height: 3rem', Html) would generate the following HTML element:

which would show a small thumbnail version of the first recipe picture

Open

for sweet and spicy gochujang fried chicken.

Alternatively, instead of providing an url to an online image as the source input argument, you can also add image Base64 codes to the Prolog html.pl file and use those. Examples for variants of a microphone icon have already been included in this file. E.g., the mic_image_closed_src(Source) query will instantiate the Source variable with the Base64 code for the closed microphone icon

Open

You can add your own images to the html.pl file by encoding them to Base64 format too. You can do so by following these steps:

1. Go to the Base64 Encode and Decode - Online site (don’t change any options on that page)

2. Go to the Encode files to Base64 format section

3. Upload an image (note that file size cannot exceed 192MB!)

4. Press the encode button, and

5. Download the code as a text file.

6. Copy the text in the file.

7. Add a fact with a predicate name for your image of your choosing (to illustrate we used myImageName) by adding the following template to the html.pl file: myImageName('data:image/png;base64,...')

8. Paste and replace the ... in the Prolog fact with the text you copied from the file (a very long encoded string representing your picture)

9. Now you can use myImageName(Source) instead of the picture(RecipeNr, Source) query to include your picture on your webpage

div tag

The div tag is a versatile block element that can be used to organize and style HTML content in various ways. In the html.pl file provided to you we have defined a div/4 predicate div(Content, Class, Style, Html) that facilitates the generation of div elements with class and style attributes that you can set. The code that will be generated looks simply like a basic div element without any content yet:

In this code template, CLASS refers to the value of the Class variable, STYLE to the value of the Style variable, and CONTENT to the value of the Content variable in the div(Content, Class, Style, Html) query. All of these variables need to be fully instantiated to generate HTML code that is returned in the output argument Html.

Many Bootstrap components are classes that can be used by means of the div tag. These include, for example, the container, jumbotron, alert, progress bar, spinner, card, flexbox, media, and grid system row and column classes. Check out all of these components in the W3 School tutorial or Bootstrap’s own overview. We provide one example to illustrate the use of the div predicate. The following code would generate a Jumbotron element:

Of course, this only works if you add another query (or queries) to generate the Content for this Jumbotron. To add couple of lines of formatted text (a large title head and a paragraph), we could use the following code for creating a complete Jumbotron element with some text as a simple example:

The first query, using the built-in predicate atomic_list_concat/2 generates HTML code that consists of the two HTML elements of a h3 heading following by a paragraph. These elements are just simply quoted each (remember to always use single quotes!) and put in that order in a Prolog list [...]. The atomic_list_concat/2 predicate then returns a new atom that is the concatentiation of these two elements in the output argument Content. This (quoted) HTML code then is passed on to the div/4 query in its first input argument (using the same variable name) to embed it in the Jumbotron element.

The resulting HTML code looks like:

span tag

The span tag is an inline element that is commonly used to style HTML content. We have added a span/3 predicate span(Content, Style, Html) that just does that and nothing else. An example of a span tag that can be useful is to style the content and change the font family that is used within some HTML content:

A list of system or web-safe fonts that you can choose from (supported on most devices) can be found here.

The span tag has other uses too. It can be used for adding Bootstrap badges and borders to elements, for example. We have also used it for setting the value of a button in the template we used for defining the button/4 predicate.

Generating an HTML webpage

Above we have illustrated how to generate individual HTML elements but not yet shown how to generate a complete webpage using one or more of those elements. We will show in this section how you can generate such a webpage and make the agent render it.

Another key question that we have not addressed so far is when to display a webpage. To answer the latter question first, we will use a generic approach where we show a specific webpage when a specific subdialog is ongoing. For example, when the conversation with the user is still in its opening stages and a greeting is ongoing, we can show a welcoming page to a user. As greeting and other subdialogs correspond with names of conversational pattetrns, the idea is to show a webpage when the top level ongoing dialog part corresponds with a name of one of the patterns defined in our conversational agent. The agent will retrieve the body of the HTML webpage that we want to display for such a pattern using the query page(+PatternID, +Txt, -Html) where PatternID is the name of the conversational pattern, Txt is the text the agent will say if its their turn, and Html is the output argument with the HTML code for the body of our webpage.

As before, but now for complete webpages, we will use a structural template to create a page. The typical structure of these templates looks like this:

The template consists of four consecutive parts. The first part uses the currentTopLevel(PatternID) query to check whether the currently ongoing top level conversation pattern is PatternID. The variable PatternID should be instantiated with a specific name of a conversation pattern, and a page rule for each pattern that can be a top level conversation pattern should be created to be able to show a webpage during each ongoing part of the conversation. If you want to differentiate which page is shown also based on other conditions, (optionally) multiple page rules should be defined and (optionally) additional Prolog queries can be added to define more complex conditions for showing a webpage. For example, you could (and will be asked to) add a condition that checks how many recipes still match the requests (preferences, constraints) of a user and show a different page if that drops below a certain number. The second part consists of Prolog code for generating the HTML code for some of the components and elements introduced above. See below for a simple example, and at the end of this page a more complex example for a card deck. Typically, to define a complete webpage, multiple elements will be used that would usually be organized in one or more rows of HTML code (think of these literally as rows on the page, in line with the basic structure of a Bootstrap grid). The third part simply concatenates the HTML code for each of the individual rows using the atomic_list_concat/2 predicate that we explained in detail above. And, finally, the fourth part generates the HTML code for the complete body of the webpage using the predefined html/2 predicate in html.pl (or, alternatively, the predicates html_without_header or html_without_header_footer).

Example Prolog Rule for a Page

As indicated above, the idea is to add a rule defining a page(+PatternId, +Txt, -Html) for each conversation pattern that might be ongoing at the top level during the conversation. You will be asked to add a range of different patterns in the patterns.pl file during the project. One of those hinted at above is a greeting pattern with a pattern ID code c10. We will now provide a simple example of rule that generates a page that will be shown when the pattern c10 is active (or ongoing):

Now suppose that the query currentTopLevel(c10) succeeds. In that case the page(c10, _, Html) query will also succeed (why?). Suppose, moreover, that our conversational agent is called Cookpanion (you think of a good name for your own agent!) and the query agentName(Name) succeeds with Name='Cookpanion'. What HTML code will then be generated (and bound to the Html output argument variable)? To answer this question, you need to understand how the applyTemplate query works (more on that you can find at the end of this page: Visual Support Guide | Defining new predicates for generating HTML elements). But for now the comment just above the query will be sufficient to piece things together. We get the HTML code <h1>I am Cookpanion</h1><br></center> that binds to IntroHeading. The atomic_list_concat query add this to the end of the <center><h2>Hello!</h2></br> HTML code, which then is used as the content for the alert class using the div predicate. By inspecting the html/2 predicate (check out the html.pl file) we can then figure out that the resulting HTML code will look like this:

Perhaps the code that is generated is a bit surprising and it is hard to locate the (just!) three lines that the page(c10,_,Html) query generates (somewhere in the middle, as main part of the page). The code illustrates that the html/2 predicate also does quite a bit of the work for generating the complete body of our webpage, including the generation of a header and footer, and a line at the top to make sure the browser will allow for audio interaction.

Adding a chatbox to your page layout for testing purposes

You will soon enough learn that using speech as the main interface for interaction can be challenging, adding delays and misunderstandings, depending on factors such as the context where it is used (a noisy environment makes ASR much more challenging and may lead to failures), perhaps the accent of the speaker, and other related factors. For testing purposes, it therefore may be useful to also be able to test without these factors potentially complicating the interaction. To this end, we have made a chatbox element available too which makes text-based interaction available as an alternative to (just) speech-based interaction. To add this element to your webpage, we suggest you add the following HTML code to the footer of pages:

We have already added the code for doing this in the html.pl file, but it is still commented out.

Using and Understanding the code in html.pl

We illustrate how the predicates introduced above can be used to create more complex HTML code with a card deck example. We also briefly discuss how the Prolog clauses for these predicates have been defined.

A Quick guide to using Bootstrap components not defined in html.pl

We briefly discuss an example to illustrate how to use the code in html.pl yourself with Bootstrap components that you might want to use that have not yet been introduced. To that end, suppose that you would like to create a lay-out with three images side-by-side. The first step you could take is to check which components Bootstrap offers to create such a lay-out. It turns out that a card deck might just be what you were looking for. It is advertised as something you would use when you “Need a set of equal width and height cards that aren’t attached to one another? Use card decks.” Bootstrap also provides the HTML template code as an example of how to use it. This is what that looks like:

How do we break this code down into pieces that we can (already) manage? We first scan the code for the HTML tags that are used in it. We find that the div tag is often used (with the classes "card-deck", "card", and "card-body"). We also find that the img tag is used as well as some variants of the <h5> and <p> tags with specific card-related classes added. We note that for each of these tags we already have the tools to generate them in Prolog. We can use the div/4 and img/4 predicates for the former tags and can use our strategy to quote basic HTML elements for the h5 and p elements (you can also introduce new predicates for these tags in combination with a class attribute if you like but we will keep things simple here).

Now we have established that all the basic ingredients are available, the next step in our recipe is to create the separate parts of the HTML code by - in a sense - looking from the inside out. We first will generate the elements that are most embedded and then use those to build the elements in which they are directly embedded. The most deeply embedded elements are the heading and paragraph elements. As suggested above, we simply quote these. In order to create a single atom we also concatenate these elements using the atomic_list_concat/2 predicate as follows:

We introduced the CardBodyContent variable here to indicate that the HTML code generated by the atomic_list_concat query will be used as content for the card-body class element.

For the card-body class we can use the div/4 predicate, where we use the CardBodyContent variable to replace the default input argument Content variable for this predicate and fill in the class and style arguments. We name the output argument CardBodyElement and then we get as our next piece of code:

For creating the card, we also need an image (again we do not bother to fill in the ... in the example, which we leave up to you; check out the Visual Support Guide | img tag section above on how to do that). We use the img(+Source, +Class, +Style, -Html) predefined predicate and use CardImage as output variable:

Now we have code to generate the two elements that we need to create a card class element, we can piece these two elements together using the div/4 predicate to generate code for that element. Phrases like piece these together by now should have alerted you to the fact that atomic_list_concat might be useful! We write the following Prolog code to generate the card element:

Finally, as a last step, we now can create our card-deck using div/4 again as follows:

We now have all the different Prolog queries that we need, in the right order, to create one big query that will generate the complete HTML code for the card deck. We simply need to add commas in between these queries (used as conjuncts) to obtain our complete Prolog query:

The HTML code and query above, of course, will not work yet as we used three dots ... for the src attribute. You will still need to make sure that the right image URLs (or Base64 codes) are used to replace these dots and modify the accompanying text in the card bodies to match with these images.

Defining new predicates for generating HTML elements

When you inspect the code in the html.pl file, you will see that a returning pattern has been used to define Prolog predicates for corresponding HTML tags. The general pattern for a tag named tagname looks like this:

One of the placeholders always should represent the content of the tagname element (which typically will appear last in the HTML template code, right between the start and end tag). Other placeholders could be used for class or other attributes. The second clause that defines the tagname predicate that generates the HTML code for the element should have N+1 arguments where N is the number of placeholders in the template. To generate the HTML code, we use the predefined applyTemplate(+Template, +ArgumentList, -Html) query for instantiating the placeholders in the HTML template. The typical pattern looks like this:

Above, we suggested that we could also introduce a predicate for a paragraph with a class attribute, e.g. for HTML code that looks like <p class="card-text">SOME TEXT CONTENT</p>. Perhaps this is not that often needed in practice, but for illustrative purposes we will now show as an example how such a predicate can be defined.

The first thing we always need to do is to add a template for the HTML element. We will simply use the p/1 predicate in line with our convention to name the predicate the same as the HTML tag, which is convenient We want to be able to fill in the class attribute and the paragraph content, so we insert two placeholders ~a (one for each of these):

To define a p/3 predicate p(Content, Class, Html) that allows for filling in a class attribute as well as content for the paragraph element, we use the template and the applyTemplate/3 predicate:

Note that by convention we put the Content argument first. This is just a convention but by sticking with it we keep our code consistent and avoid confusion about what the first argument of our predicates should be instantiated with. The elements in the list [Class, Content] fed to the applyTemplate predicate, however, should match the order of the placeholders ~a in the paragraph template we introduced above to make sure that they are substituted in the right order into this template.

As an example, we can now use our p/3 predicate to replace our quoted paragraph element '<p class="card-text">This is the third card.</p>' in our card deck example above as follows:

Note that we need to introduce an output argument variable name to retrieve the HTML code for the paragraph in.