Layout Sections

In order for the layout to be dynamically adapted to the user’s needs, layout sections need to be explicitly accessible via the language. A simple solution would have been to access different sections of the layout via their LAG language equivalents – e.g., PM.Menu, which is currently on the left side; PM.ToDo, which is currently on the right side, etc. However, this would confine the author to use the

121 menus only in their current position, and make it impossible to move the menu to the right side of the screen (this being one of the potential areas of change needed to take into account cultural backgrounds [34] [92]). For this reason, we opted for another well-known paradigm, which most programmers should be familiar with, as explained in the following.

FIGURE 25 - LAYOUT SECTIONS

First, the viewable portion of the interface is divided into North, West, East, South and Centre sections as shown in Figure 25. This layout is similar to that of the jQuery UI.Layout plugin [93] and the Java BorderLayout [94]. Moreover, for authors who may consider this initial division too simple or too restrictive, these sections can be now sub-divided further, using the same layout (a few variations are shown in Figure 26).

122

FIGURE 26 - SUB-DIVIDED LAYOUT SECTIONS

Each layout section is allocated a section type, to denote the type of content that should be displayed within the section. The types identified are listed here:

● Header

This is the course header information, traditionally just displaying the course title.

● Footer

This type displays the footer information for a course, as well as links, such as logout and course menu. This is also where the “Next Recommended Link” is shown in AHA! or ADE. The first concept of the list of concepts where PM.NEXT.GM.Concept.show == true and UM.GM.Concept.accessed == 0 is displayed as the next recommended link by default.

123 The main area displays the actual content requested by the user. This is where the ‘Content adaptation’ takes place, and hence is where most previous research into adaptation has focused.

● Menu

This displays a navigational tree for the course, composed of those concepts where PM.MENU.GM.Concept.show == true. Traditionally, this would appear on the left side of the screen, in the West section in the figure above. The current implementation allows for the author to decide where this goes, similarly to all other section types.

● Todo

This displays a default to-do list for the course. In ADE and AHA! this would be where PM.TODO.GM.Concept.show == true and

UM.GM.Concept.accessed == 0.

● List

This layout section can display links to the concepts in a given list of concepts. The Todo layout section is a specific list section as defined above, but the new syntax allows defining other lists, so this section type is a vehicle through which these new lists can be displayed in the various parts of the screen.

124 This can be used to display the contents of variables (or constants), interpreted as HTML. This has been created to support informing the user about the status of various user model variables, for instance, about their progress in a course, about their knowledge about a certain concept or course, etc. Via this construct, an author that is not knowledgeable of the internal workings of the delivery system, can still specify via the adaptation language exactly which variables are appropriate to show to the student, as per demands of the pedagogical strategy.

● Image

This displays a picture, and the content should be set to the URL of the picture. This is a shortcut, so instead of using a Text section with <img

src=”picture.jpg”/>, authors can just set the layout section to Image

and enter picture.jpg. It is also semantically more informative, as the strategy expects then images in that layout section, as opposed to generic HTML/text.

● Progress

This section type displays a progress bar. The content for this should be a number between 0 and 100, which is interpreted as a percentage to display in the progress bar.

The content for the header, footer, main, menu and todo types are automatically generated by the delivery system. Although they could be generated

125 manually in an adaptation strategy, these layout areas are common to most recent AH systems [28] [24] and can normally be automatically generated, to avoid complicating a strategy with unnecessary detail.

Whereas the type attribute of the layout section determines how these should be formatted, the content attribute determines what should be displayed. The syntax for setting the type and content of a layout section is shown in the following example, which adds a progress bar to the top of the right hand part of a page. The progress bar is set to a user model variable, which would be updated elsewhere in the strategy.

Layout[E][N].type = "Progress"

Layout[E][N].title = "Course Progress" Layout[E][N].content = UM.GM.progress The syntax is similar for the other layout section types.

The layout for the course is stored on a per user basis for each course, so the layout can be individually adapted, as each user progresses through the course. This is a novel extension for LAG and ADE, and currently there are, to the best of our knowledge, no other adaptation languages that allow such detailed layout adaptation that can be set by an author, without knowing the internal workings of the delivery system and directly programming it.

126