Chapter 5 Design and Implementation 90
5.3 Final User Interface Implementation 108
5.3.1 Teacher’s User Interfaces Implementation 108
Figure 5.20 shows the first window, when a teacher begins to use IWE. If it is the first time to create worked example, IWE will ask to fill in the course name. IWE will manage different courses separately and keep different teachers’ work in individual folders. After creation, the teacher only needs to distribute his own course folder to students. If examples are built for more than one course, the teacher can find requested course through pressing the drop down button beside the course name field. Choose a course from the list, and then click the “Start” button to enter the system.
Figure 5.20 Teacher User’s Login Window
Figure 5.21 shows the main entry of teacher’s user interface. It contains four views which are application view on the left, middle view for displaying worked examples, document type view on the right top side and document view on the right bottom view. The teacher can access all the creation functions from the tool bar on the top of the GUI. If the teacher wants to edit some existing
content, he can right click on a node in one of the side views and then begin to edit or view the content of the selected node.
Figure 5.21 Teacher User’s Main Entry Window
Figure 5.22 shows the graphical document type editor user interface to describe the target node or line type. The left top area is used to define graphical node type and the left bottom area is used to define line type. The right top area is used to preview the created graphical type and the right bottom area is used to list all the created types. The update buttons in the left side are always
disabled, unless an item from the result list in the right side has been selected. This modification is based on a teacher’s suggestion, because he may only want
to change one or two attributes values of his design, after previewing the result. Instead of deleting his previous result, he only needs to modify the attribute value and then click “update” button.
Figure 5.22 Define Graphical Document Type Window
Figure 5.23 shows the textual document type editor user interface to describe the target text styles. The left side is used to setup the attribute values of the text style and the right side used to preview the defining result. It offers a variety of fonts for the teacher user; this allows documents to be formatted so that different components can be distinguished. For example, in a problem description showing examples of inputs and outputs in a different font to the descriptive text. After feedback from teachers, similar to that for the graphical type editor, an “Update” button was added into the window, which allowed modification after previewing the creation instead of deleting the previous work and recreating it.
Figure 5.24 shows the graphical document editor user interface to describe the target graphical document. The left side top area lists all the node types and the left bottom area lists all the line types based on the selected graphical
document type. The right side is the drawing area. Choosing a node type from the list and then clicking a position in the drawing area causes a node of this node type to be drawn at the clicking point. When the mouse pointer is moved inside a graphical node several linking points will be shown automatically. The person_name node in Figure 5.24 shows the linking points for this node. Choosing a line type from the list firstly, then dragging the mouse from one node linking point and dropping the mouse onto another node linking point causes an instance line of the selected line type to be drawn between these two points.
Figure 5.24 Define Graphical Document Window
Figure 5.25 shows the textual document editor user interface to describe the target textual document. The top area is used for inputting the plain text. The teacher can paste text from other resources to this area. These original texts can then be divided into textual fragments by using the “Enter” button from the keyboard. Clicking the “Load All” button causes the system to load each
individual line as a separate textual fragment into the table “Value” column automatically. The “Load All” button was not included in the original design. A test teacher suggested this modification after dividing a large plain text,
because it could speed up dividing the original texts. Alternatively, the user can select part of the text from the input area by using the mouse, and then click the “Add” button to add a single textual fragment. In order to set the textual fragment type, the user can select the “Type” column in the table to change individual textual fragment type into different styles. Due to the limitation of XML technology used to store documents, the special character “;” is used to represent a “new line” symbol for formatting purposes. This means if the value
of a textual fragment ends with “;”, it will be recognized as the end of a line. So, if the user wants to use “;” as the end of textual fragment, he has to either use double “;” to get a new line or add a space after the “;”. The bottom area is used to preview the editing results.
Figure 5.25 Define Textual Document Window
Creating an application is a process of allocating documents into a predefined layout. So a wizard type user interface is implemented. Figure 5.26 shows the user interface to select a predefined layout to be used to present documents. There were 8 layouts at first, however, due to a teacher’s special request to represent a middle stage of solving a problem, another two new layouts, which are the three vertical and horizontal panels, were added in during the final evaluation period. After giving a name for this application (for students it is called scenario) and choosing a layout, the “Next” button will become available. Click on “Next” button to begin allocating documents in the selected layout.
The nature of the worked example determines the most appropriate layout to use. For example, three panels may suit a programming problem where there are documents for the problem description, a plan, and the program itself. The nature of these documents (a large number of relatively short lines, particularly in the case of the plan and program) suggest that the three documents should be in the vertical format, side by side rather than stacked. Users can change the relative sizes of the panels while exploring a worked example. Figure 5.27 shows an example of selecting a layout of two vertical panels. The user can click a panel to choose a document from a pop up box. And then this document will be placed into this panel. After allocating the target documents into panels, click “finish” button to finish the application creating process.
Figure 5.27 Allocate Documents into the Selected Layout for Creating an Application Window
Figure 5.28 shows the result of allocating documents when creating an
application in the teacher’s main entry window. In this example, the left panel is allocated a graphical document, which is an ER diagram and the right side panel is allocated a textual document, which are the SQL commands for representing an ER diagram. The teacher can also set up the correspondence between these two documents as an optional choice. Setting up correspondence can be done in the teacher’s main entry window when viewing the application creation result. For example, in Figure 5.28, a correspondence can be set up through selecting entity “Book” in ER diagram and selecting “Book” in SQL commands, and then clicking the “Connection” button in the tool bar. When student clicks one fragment in either “Book” entity in the ER diagram document or “Book” in the SQL document, the other fragment will be automatically
highlighted. As mentioned before, setting correspondence is an optional operation for a teacher. If the teacher does not want to set up the
correspondence, he can directly go the next stage to design the process. In this case, a process is going to demonstrate the process of transformation from an ER diagram into SQL commands.
Figure 5.28 Application Creation Result Shown in the Teacher’s Main Entry Window
Figure 5.29 shows the user interface to design a process. The left side area is used to show the tree structure of editing results. A Process root node contains step nodes, and a step node contains change nodes and an explanation node. Clicking “New Step” button, a new step node will be added in as the final step. If a step node between other step nodes is selected then clicking “New Step” button will insert a new step node below the selected step node. In order to add a change into a step, a new change can be defined by selecting a document first from the “Documents” combo box, then finding a fragment in the “Fragments” combo box, and then choosing an operation in the “Operations” combo box. To add the change click the “Insert One Change to a Step” button, the new defined change will always be added into the selected step node as a sub node. For instance, in Figure 5.29 the new change will be added into step 12 as a sub node. When a new step node is added in, it contains an explanation sub node. To create an explanation: select this explanation sub node; write explanation text in the text area, which is at the bottom right side; click the “Update Explanation of One Step” button and the explanation text for this step will be added into the step. During the creation of a process, clicking the “Preview” button will show the process player window to the teacher to see current editing results.
Figure 5.29 Process Editing Window
In Figure 5.30, it shows how to create an embedded multi-choice question as a step. The teacher needs to select “Ask Question” operation from the
“Operation” combo box to bring the popup dialog out; and then write question content in the “Question Area” and the options contents in the “Options” Area. It is also possible to create a descriptive question where the student is expected to type in a textual answer; in this case only the question content needs to be entered, there are no options.
Figure 5.30 Process Editing Window
Figure 5.31 shows the feedback summary user interface. It contains a student’s information area on the left side and a tab panel for viewing different summary
results on the right side. To access this window, the user needs to press the “Tool” option in the menu bar of the teacher’s main entry user interface and then select the “Feedback” menu item. Loading an individual student’s feedback file into IWE can be done through the “File” menu in the top of the window. Clicking on this menu, it will guide the user to select a student’s feedback file on the server and then automatically add and sort the contents into the system. In Figure 5.31, all the feedback messages from students for worked examples designed for the CS1CT course are shown in the “All Feedback” tab. In Figure 5.32, all students’ answers to the embedded questions in these worked examples are summarised, using the “All Answers Statistics” tab.
Figure 5.31 Feedback Summary Window
Figure 5.32 Answers Summary within Feedback Window