Institute of Information Systems and Computer Media Graz University of Technology Graz, Austria

Providing User-Centered Information in the Personal Learning Environment

Bachelors Thesis

Igor Skoric i.skoric@student.tugraz.at October 2011

Supervision: Assoc. Prof. Dipl.-Ing. Dr.techn. Martin Ebner

Abstract Students using the information system of their school or university often feel the system is not made according to their needs. Programmers are often more concerned about the needs of the university and its sta, which is understandable as those people make the purchase decisions for the institution. In an eort to alleviate student hassle and increase student motivation and productivity the TU Graz has created the Personal Learning Environment (PLE). The PLE is a studentoriented learning environment providing learning tools for students in the form of a freely congurable widget engine. This work is a contribution to these eorts with the creation of a widget allowing the student to search for exams, compare exam schedules of multiple courses, create an exam plan and rate exams afterwards. The exams are rated 1 to 5 points representing the time investment needed in relation to the attained score on the exam. The rating information is then displayed in a color coded system to other students who are looking for the same exam. Keywords: Social Learning, Networked Learning, Exam, Widget, Widget Engine, Rating System, Student-Centered, PLE, Personal Learning Environment, TU Graz

Zusammenfassung Bei der Erstellung von Informationssystemen fr Universitten werden Studierende als Beu a nutzer des Systems oft vernachlssigt. Diese machen in der Regel den grten Benutzerkreis a o des Systems aus, haben jedoch keinen Einuss auf die Kaufentscheidung bei der Anschaffung des Systems und werden daher auch entsprechend wenig von den Programmierern solcher Systeme bercksichtigt. Die Studierenden mssen sich mit der Lage zurechtnden, u u die sie oft als unntig anstrengend und schwierig empndet. o In einem Versuch diese Probleme der Studierenden zu beheben hat die TU Graz die Personal Learning Environment ins Leben gerufen. Die PLE ist eine Plattform fr Stuu dierende, die Werkzeuge und Informationen in der Form von Widgets zur Verfgung u stellt. Diese Arbeit trgt ein Widget dazu bei. Dieses Widget ist fr die Verwaltung und Planung a u von Prfungsterminen aus Studentensicht gedacht. Der Studierende kann nach Terminen u suchen, diese zwischen verschiedenen Lehrveranstaltungen vergleichen und die Planung der Antritte durchfhren. Nach dem Abschluss der Prfung kann in weiterer Folge eine u u Bewertung des Zeitaufwandes zum Erreichen der jeweiligen Note abgegeben werden. Diese Information wird anderen Studierenden in der Form einer Farbcodierung zur Verfgung u gestellt. Schlagworter: Soziales Lernen, Vernetztes Lernen, Prfung, Widget, Widget Engine, u Wertungssystem, Studentenorientiert, PLE, Personal Learning Environment, TU Graz

Pledge I hereby certify that the work presented in this bachelors thesis is my own and that work performed by others is appropriately cited. Ich versichere hiermit, diese Arbeit selbstndig verfat, keine anderen als die angegebea nen Quellen und Hilfsmittel benutzt und mich auch sonst keiner unerlaubten Hilfsmittel bedient zu haben.

Contents
1 Introduction 1.1 Identifying the Problem . . . . . . . . . . 1.1.1 CampusOnline R . . . . . . . . . . 1.1.2 Making an Exam Schedule . . . . . 1.2 Designing a Solution . . . . . . . . . . . . 1.2.1 Searching for a Good Compromise 2 State of the Art 2.1 Personal Learning Environment - PLE 2.2 Widget Development . . . . . . . . . . 2.2.1 Important Files . . . . . . . . . 2.2.2 Widget Templates . . . . . . . 2.2.3 Model-View-Controller . . . . . 2.3 TU Graz API . . . . . . . . . . . . . . 6 6 6 6 7 7 8 8 9 9 9 9 9 12 12 12 13 14 14 15 15 16 16 17 18 18 18 19 19 20 20 21 21 21 22 27

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3 Implementation 3.1 Getting into Shape . . . . . . . . . . . . . . . . . . . 3.1.1 Width of the Widget . . . . . . . . . . . . . . 3.1.2 Height of the Widget . . . . . . . . . . . . . . 3.2 Extracting the Data . . . . . . . . . . . . . . . . . . 3.2.1 The TU Graz CampusOnline API Format . . 3.2.2 The PHP Code for Extracting the Information 3.3 Storing the Data . . . . . . . . . . . . . . . . . . . . 3.3.1 The DBUtils Class . . . . . . . . . . . . . . . 3.4 Processing the Data . . . . . . . . . . . . . . . . . . 3.5 Retrieving the Data . . . . . . . . . . . . . . . . . . . 3.5.1 JavaScript . . . . . . . . . . . . . . . . . . . . 3.5.2 JavaScript Object Notation . . . . . . . . . . 3.5.3 XMLHttpRequest . . . . . . . . . . . . . . . . 3.5.4 Example of a Request . . . . . . . . . . . . . 3.6 Maintenance of the Data . . . . . . . . . . . . . . . . 3.7 Interfacing with the User . . . . . . . . . . . . . . . . 3.7.1 Program Selection . . . . . . . . . . . . . . . 3.7.2 Course Selection . . . . . . . . . . . . . . . . 3.7.3 Planning Exams . . . . . . . . . . . . . . . . . 3.7.4 Rating Exams . . . . . . . . . . . . . . . . . . 4 Discussion 5 Conclusion

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

Chapter 1 Introduction
1.1 Identifying the Problem
1.1.1 CampusOnline R The Information Management System programmed by Graz University of Technology (TU Graz) is used by 35 institutions of higher education. Its use is obligatory on a daily basis for 247.000 students attending those institutions and about 77.000 sta members. About 1.7 million exams are handled by the software[8]. Although CampusOnline performs a huge number of functions, and performs them well, there are still areas not deemed worthy of investing time or money to improve on. Reasons for this are on the one hand lack of sales impact as mentioned and incompatibility of certain features with the overall organisation of the software on the other hand. Features that do not t into the overall concept make it necessary to reorganise moderately big parts of the system, which is inecient. Features which do not integrate well on the other hand prompt the question if they should be part of the software at all. The solution to these problems for CampusOnline was not to integrate them but to oer APIs to restricted groups of programmers to improve existing functionality. 1.1.2 Making an Exam Schedule One problem identied was the lack of functionality enabling students to choose exams for learning, taking them at the most opportune times. There is also no possibility of nding out how hard an exam is going to be and how long one should plan on learning for it. For planning exclusively courses from the current term there is a sorted list of exam dates already oered in CampusOnline. Nevertheless, the way to plan the exam dates for a list of courses which are not in the students current term is a hard challenge. So far the procedures for such circumstances are follows: 1. Select a course from the list 2. Open up the exam dates search page 3. Search for the course 4. Open the exam dates page of the correct course from the results 5. Write down all possible exam dates on a sheet of paper or similar medium

Chapter 1 Introduction

After that the list must be sorted and all exam dates of all dierent courses must be compiled into a single list. After that the time between exams in dierent sequences and the time to plan for learning before an exam hat to be calculated. If the list of exams changes, the rst part has to be redone partly and the second part has to be redone entirely.

1.2 Designing a Solution

Starting from here there seems to be plenty room for improvement. Assuming that there is total access to information and unlimited resources the perfect solution would be one that does everything automatically. Due to privacy and data protection concerns, the TU Graz does not expose all the existing data to the API. Any data involving specic students or student groups is not provided. The API does not enable an application that utilises it to call up any of the data related to the currently logged in user, despite the properly authenticated user credentials. The content available at any given time is limited to the information provided by the user manually. Furthermore, the API does not provide the information about the link between programs and courses. The full information on all courses and all programs can be retrieved, however it is not possible to nd out which courses actually make up a specic program by using the TU Graz API calls. This means that even if a student provides his or her program and the current term, the system can not oer exam date management tting her requirements without additional complications. This limitation within the API architecture seems unnecessary as the requirement for such a possibility lies clearly within the desired system features of the student users. 1.2.1 Searching for a Good Compromise Given the current limitations, certain information prerequisites are needed from the students: Their study program and the courses they are planning on doing in the near future. After they attended those courses a way is required to communicate their experience back to the system so the system can process it and provide the result to other students. This solves one part of the information gap with a reasonable compromise. The other part of information that is needed is the link between courses and programs. This data which is missing from the API can be obtained from the public part of the TU Graz student web interface. This workaround currently works by parsing the HTML of the web page making it an avoidable source of error that could be remedied by extending the TU Graz API.

Chapter 1 Introduction

Chapter 2 State of the Art

2.1 Personal Learning Environment - PLE
The Personal Learning Environment is the target framework for the solution. The Login page can be seen in gure 2.1. It is a custom desktop-like interface with a rich selection of tools for students (see gure 2.2). Figure 2.1: The login page of the PLE.

Figure 2.2: The main view of the PLE.

The PLE is based on AJAX with strong JavaScript library leverage and exible integration of backend technologies for each and every of the widgets. The main portal interface is rendered with the help of jQuery and jQueryUI JavaScript libraries [5].

Chapter 2 State of the Art

2.2 Widget Development

The PLE lead developer Behnam Taraghi provides a PLE widget development framework called WDE (Widget Development Environment) [6] and a guide on widget denition and design [5]. His paper for the MUPPLE10 Conference (Mash-up Personal Learning Environments 2010) outlines the usage of the MVC pattern for this environment [7].

2.2.1 Important Files Cong File This le holds the standardized widget denition. It denes information like width, height, name and others. It also holds the defaults for user preferences. index.html This is the main le of the widget. It shows the widget interface and starts the javascript. cong.xml

Index File

All the other les are optional, but there are practices which one is expected to follow when developing a widget for the PLE. 2.2.2 Widget Templates The WDE framework comes with example widgets that can be used as templates and built upon. Especially MVCSampleWithLocalization can be used eectively as a starting point and template for new widgets because it already has all important functions built in (MVC, jQuery, SPI WebService, localization). For the le structure see gure 2.3.

2.2.3 Model-View-Controller The PLE design uses the Model-View-Controller design pattern implemented in JavaScript which is illustrated in gure 2.4 [7]. The MVC pattern eectively acts as a sandbox and at the same time allows for a certain degree of parallel development to take place.

2.3 TU Graz API

The CampusOnline conguration of TU Graz is set up to oer a big list of services exposed on distinct URLs and requiring an unique API Key. If requests on those URLs are submitted alongide a valid and authorized key the API provides the XML les containing the requested information. If data is requested at the root node of the organisation tree - which is the organisation

Chapter 2 State of the Art

Figure 2.3: Widget Template File Structure

with ID 37 - then the caller will receive all of the entries that said API can provide. Clearly, there is a wealth of services provided. However, only a few of those are useful to us. In fact only three of those services are needed. Those are as follows: exportCoursesByOrganisation: This API provides all the courses. This is needed because exams are attached to courses. exportProgramsByOrganization:This API provides all the programs in the system. This is needed for nding out which programs exist. exportRDMExamsByOrganization: This API provides the exam dates themselves. As mentioned above there is one additional information service which would be needed. That is the information about the link between programs and courses. Unfortunately, there is no API service providing that information according to the TU Graz CampusOnline API development support team advice provided at the time of writing.

Chapter 2 State of the Art

10

Figure 2.4: Model-View-Controller Pattern in JavaScript

Figure 2.5: An excerpt from the list of CampusOnline API methods.

Chapter 2 State of the Art

11

Chapter 3 Implementation
3.1 Getting into Shape
The nature of the framework that is used means that it is necessary to adapt to certain additional restrictions imposed by it. Because the widget is sharing desktop estate with a multitude of other small applications there are restrictions on the possible window size. The widget has to have a reasonable size which allows to display all the information that is necessary but still maintain a rather slim outline. 3.1.1 Width of the Widget The Widget has to be at least wide enough to t the name of the longest course plus the date of the exam into one line. Figure 3.1: Length distribution of course names.

As seen in gure 3.1 there are course names of 80 chars and more, but the majority of names is in the 10 to 60 characters range. To be more specic, there are 4176 courses in the database. If 95% of courses are to be covered the widget has to be able to display 4176 0.95 = 3967.2 3967 course names. If the limit is set at 57 characters, 3965 course names can be displayed. That amounts to 94,94% of total courses, an almost perfect cut. But not all of the possible courses actually have exams. Only 333 out of the 4176 courses

Chapter 3 Implementation

12

in the database actually have exam dates in the database. The distribution of course name lengths for courses with exams looks a little dierent. Figure 3.2: Length distribution of course names /w exams.

To cover 95% of courses in this distribution, it is necessary to allow only up to a length of 49 characters which covers 318 out of 333 courses and amounts to 95.5%. If that is extended up to 54 characters this can cover all length classes having more than one element which would be 326/333 or 97,90%. At the same time this covers 93.44% of total courses with or without exams. 3.1.2 Height of the Widget Looking at the requirement to have multiple pages of content which are separate from each other there are two solutions provided by the jQueryUI library. Accordion: Has a very rich animation but takes a area of full length of the parent container for every additional page. This is not very benecial for an interface with very limited screen estate. Tabs: Has a very plain animation but takes up only as much space as one item in the accordion. Additionally has the advantage of being intuitively understood by a big number of users. Factoring in the default height of the tab buttons (33px) and about 10 lines of exam dates (about 20px each) this results in about 230px of widget height. After including some kind of description and/or controls plus margins the target height should be at about 300px or more. Having dened the height and width requirements, those can be inserted into the widgets cong.xml le. Listing 3.1: Dening Widget Dimensions
1 < widget 2 3 4 5 xmlns = " http: // www . w3 . org / TR / widgets / " xmlns:palette = " http: // palette . ercim . org / ns / " width = " 550 " height = " 300 " id = " examWidget " >

Chapter 3 Implementation

13

3.2 Extracting the Data

3.2.1 The TU Graz CampusOnline API Format The Widget needs to get the relevant data from the TU Graz CampusOnline API and store it in its database. For that to work an URL with the correct tokens needs to be compiled. Here is an example based on the exportProgramsByOrganization API. 1. The URL: https://online.tugraz.at/tug_onlinej/ws/webservice_v1.0/ 2. The Service Identier: e.g.cdm/organization/programs/ 3. The Output Format: e.g.xml 4. The Parameters beginning with ?, separated by & a) The API token: e.g.token=XXxXXxXXXxXXxXXxXXxXXXXxXXxX b) The Target Node in the Organisation Tree e.g.orgUnitID=37 Where 37 is the root node in this case. This results in an URL similar to this one: https://online.tugraz.at/tug_onlinej/ws/ webservice_v1.0/cdm/organization/programs/xml?token=XXxXXxX&orgUnitID=37 After requesting the resource with an URL like this the caller gets an API response in the requested format. The header of the response can be seen in listing 3.2. Listing 3.2: XML Response Header
1 <? xml version = " 1.0 " encoding = " UTF -8 " ? > 2 < CDM xmlns:xsi = " http: // www . w3 . org /2001/ XMLSchema - instance " x s i : no N a m e s p a c e S c h e m a L o c a t i o n = " http: // campusonline . at / xmlschema / cdm / CDMv2 .01. xsd " language = " german " >

After this there is a list of of programs for each organisational unit below the selected one and then further down the relevant information is found. See listing 3.3. Listing 3.3: Programs Node XML
1 2 3 4 5 6 7 8 9 10 11 12 13 14 < program id = " program_571 " language = " german " > < programID > 571 </ programID > < programName > < text > Elektrotechnik ( UG2002 /11 U ) </ text > </ programName > < programCode > 235 </ programCode > < qualification > < credits ECTScredits = " 180 " / > < degree > BSc </ degree > </ qualification > < level userDefined = " BAK " > Bachelorstudium </ level > < programDuration userDefined = " Semester " >6 </ programDuration > < infoBlock > < webLink userDefined = " CAMPUSonlineURL " >

Chapter 3 Implementation

14

15

16 17 18 19 20

< href > https: // online . tugraz . at / tug_online / semesterplaene . uebersicht ? pStpStpNr =571& amp ; csj_nr =1032& amp ; csr_nr =246 </ href > </ webLink > < subBlock userDefined = " programStatus " >N </ subBlock > </ infoBlock > < searchword > Elektrotechnik </ searchword > </ program >

3.2.2 The PHP Code for Extracting the Information From here all the relevant informationcan be exrtacted by reading the well structured XML le returned from the API. This is done by by processing the le in a server side script, programmed in PHP. For the solution at hand, the API responses are cached into XML les and used from there. See listing 3.4. Listing 3.4: Parsing XML and lling the DB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 /* * parsing programs from cache */ echo ( " processing programs ... \ n " ) ; $db = new DBUtils ; $filename = " ../ cache / raw_programs . xml " ; $xml = ;

if ( openFile ( $filename , $xml ) ) { foreach ( $xml - > program as $program ) { $programID = $program - > programID ; $programCode = $program - > programCode ; $programName = $program - > programName - > text ; $programLevelText = $program - > level ; $program_type = " ?? " ; $arr = $program - > level - > attributes () ; $program_type = $arr [ userDefined ]; $db - > dbExec ( " REPLACE INTO programs ( program_id , program_code , program_name , program_type ) VALUES ( " . $programID . " , " . $programCode . " , " . $programName . " , " . $program_type . " ) ; " ) ; 19 } 20 }

By using object oriented PHP, a reference to an object of the type DBUtils is created this is described in further detail in the following section.

3.3 Storing the Data

This widget uses a MySQL database to store the data used by it. The layout of the database is illustrated in gure 3.3.

Chapter 3 Implementation

15

Figure 3.3: Database Layout.

3.3.1 The DBUtils Class This class encapsulates all database operations for the web service of the widget. It is located in the internal directory and is used by every le that needs database access. An example of its usage is given in code listing 3.5. Listing 3.5: DBUtils Usage Example
1 2 3 4 5 6 require_once ( ../ internal / dbutils . php ) ; $db = new DBUtils ; $result = $db - > getNrProgs () ; echo ( " Number of Programs to parse : " . $result . " \ n " ) ;

3.4 Processing the Data

Ratings given by individual students provide the raw information which needs to be processed and interpreted to get meaningful results which can be presented to the students. As there are ve levels of diculty in the rating system that is being used for this software, it makes sense to use ve levels of diculty in the color coded indicator system which is displayed to users. Deciding which indicator to show is not as straightforward as calculating the average and rounding the result. To decide how to part the eld of courses into ve categories a few assumptions were made. One of those assumptions is that course diculty is normally distributed. This is a fairly safe assumption to make as many similar datasets are normally distributed. This

Chapter 3 Implementation

16

will suce as a starting point until a large dataset of course diculty ratings has been gathered. Partitioning a normally distributed eld into ve sets of courses with equal cardinality means calculating the ve quantiles of the distribution that contain 1 of the courses each. 5 For this the statistical computing software R in its standard distribution package [9] was used. Figure 3.4: Normal distribution quintiles

This is pictured in a diagram combined with the normal distribution in gure 3.5. Figure 3.5: The course diculty distribution with quantiles.

As is visible in gure 3.5 the chosen parameters of = 2.5 and = 1 make the distribution spill over the edges of the rating window. This is made intentionally to ignore 5% of fringe cases and get a more tting partitioning. Similar to above this is subject for review as soon as enough data is gathered.

3.5 Retrieving the Data

The retrieval of data is the point at whichit is appropriate to introduce XMLHttpRequest objects, JavaScript and JSON. All the work of formatting the interface and displaying data is done client side by the XHTML and JavaScript part of the widget. The PHP server side part is only supplying data to the client side scripts in JSON format.

Chapter 3 Implementation

17

3.5.1 JavaScript JavaScript R (sometimes shortened to JS) is a lightweight, object-oriented language, most known as the scripting language for web pages, but used in many non-browser environments as well.[3] This is the programming language in which the used framework and widgets are programmed in. It is an implementation of the ECMA Script Standard [4]. The following is a short example of what JS code looks like. Listing 3.6: JavaScript Example
1 function onLoad () { 2 // === Starting it all === 3 MVC . Controller . init ( 4 function ( key ) { 5 return widget . preferenceForKey ( key ) ; 6 }, 7 function (k , v ) { 8 return widget . setPreference (k , v ) ; 9 }) ; 10 }

3.5.2 JavaScript Object Notation JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON denes a small set of formatting rules for the portable representation of structured data. [1] JSON is the format that is used to transport data between this softwares server side API and its client side JavaScript. An example of this format is the localization data used by the widget. Listing 3.7: JSON Example (edited)
1 { 2 " id " : " de " , 3 " Planned " : " Geplant " , 4 " Finished " : " Abgeschlossen " , 5 " My Program " : " Mein Studium " , 6 }

3.5.3 XMLHttpRequest The XMLHttpRequest standardized by the W3C in the W3C Candidate Recommendation from August 2010 [2].

Chapter 3 Implementation

18

The XMLHttpRequest specication denes an API that provides scripted client functionality for transferring data between a client and a server. The XHR is used by JavaScript to request data from the server side API. This is made easier by jQuery function jQuery.Ajax() but in the PLE this is meant to be used by invoking the widget.httpGetJSON() function of the widget framework. This maps 1:1 to jQuery.getJSON() which is a special case of jQuery.Ajax(). The framework function takes the same parameters as the jQuery counterpart. 3.5.4 Example of a Request The program ow is illustrated in broad strokes in the sequence diagram in gure 3.6.

Figure 3.6: Eects of a button click.

3.6 Maintenance of the Data

The data has to be kept up-to-date, every day there are new exam dates being created, old exams are being moved, programs are being modied and new ones are being introduced. It is necessary to maintain data integrity, timeliness and coverage. And it needs to be maintained without the need of manual intervention. For this purpose there is a mechanism in place. There is a scheduled program on the PLE server that updates the data that is stored in the database. This program - also known as a cronjob - retrieves the current data from the TU Graz API and updates the exams,

Chapter 3 Implementation

19

programs and courses so they stay correct and relevant. The data which is updated in this way is immediately available to the user and integrates seamlessly with the old data that was available before. Search queries that have changed show the new values upon the next refresh. Already selected programs also update instantly.

3.7 Interfacing with the User

Now that the data is available, it needs to be presented to the user in the best way possible. The major things that that need to be done when interfacing with the user are letting the user: 1. Select the program he or she is attending for upcoming exam list. 2. Select courses that he or she is attending so the system can display exams for those. 3. Plan exams. 4. Rate exams. 3.7.1 Program Selection As the list of programs is quite large (about 80) and there is a very constricted space, a tting selection mechanic is required. The function jQuery.Autocomplete() ts the requirements perfectly. Figure 3.7: Autocomplete in Action

An auto complete mechanism usually works by letting the user input a few characters and oering a list of matching items for the user to select from. In the example shown in gure 3.7 the word soft was entered and the auto complete mechanism ltered all courses down to only those containing the string soft. The ltering and displaying of items happens asynchronously on-the-y. This oers the possibility for the user to correct and/or change the input. After selecting an item from the list with the mouse or arrow keys the event is automatically red and the bound function is executed with the selected item supplying one of the arguments. In this case the argument supplied is the program id.

Chapter 3 Implementation

20

3.7.2 Course Selection For this the same mechanism is employed as was before for program selection. The dierence is in what is done with the supplied information. Instead of just changing the selected item it is added up to a list which forms the constantly updating search query. In this way the user is provided with a way to search for multiple courses at the same time and remove the need to compare exam dates manually outside this software. The search query can then be manually reset by clicking the reset button. 3.7.3 Planning Exams After either entering their program into the upcoming exams tab or constructing a search query in the search tab a user can add an exam date to his planned exams by clicking a green right pointing arrow displayed at the end of the name of said exam. The right pointing arrow suggests a move command to move the exam from the left to the right. This makes sense because the search tabs are on the left and the planned exams tabs are on the right. 3.7.4 Rating Exams After an exam date has been added to the planned exams and its date passed the exam is moved to the nished exams tab. In this tab the student can mark courses as nished or remove them if he did not participate after all. Clicking the nish button opens up a dialog and gives the student the option to input his experience with the diculty of the course. This rating is afterwards included into the calculations for the diculty indicators which other students can see.

Chapter 3 Implementation

21

Chapter 4 Discussion
Figure 4.1: Lookup tab (empty)

In gure 4.1 the startup view of the Widget can be seen. A user can formulate a comparative search query here by adding multiple exams to the query, which results in a display similar to the one seen in gure 4.2 where a search query with three dierent courses was constructed. The query shows the possible exam dates of all the added courses combined. The user can see the date, diculty (coloured indicator) and name of the exam. The green arrow at the end allows the addition of the exam date to the list of planned exams. The view can be reset by clicking the reset button to the right of the search bar. The second tab is similar to the rst one. The main dierence is that in this tab the user selects a program and the widget automatically shows the next exam dates out of all the courses in that program. This list could be reproduced by adding all the courses in the program to the search query in the rst tab. The second tab is illustrated in gure 4.3 where the empty tab can be seen and gure 4.4 where a program has been selected for display. The third tab (seen empty in gure 4.5) shows the planned exams and represents a quasi agenda. These are the exam dates which the user wants to attend or plans to do so. The only action possible at this stage is removal, which is pictured in gure 4.6.

Chapter 4 Discussion

22

Figure 4.2: Lookup tab (with search query)

The dialog seen in gure 4.6 is shown when the user clicks the remove button on the planned tab or the nished exams tab. An exam removed in this way leaves no permanent record in the database. It is presumed that the exam was not taken or the plan of the user changed. Maybe the exam was added by mistake. Whatever the reason is, this is a clean removal. After an exam date expires the exam is moved to the last tab (seen in gure 4.7). The only signicant dierence for the user is the inclusion of the rating button. The rating button opens the next and last dialog window (see gure 4.8). It allows the user to rate the exam on a ve part scale. The ve options are from no time needed to very long time needed . This represents the students opinion on how much time is needed to get the desired result. It does not represent the students personal opinion of how much the student liked the course.

Chapter 4 Discussion

23

Figure 4.3: Upcoming tab (empty)

Figure 4.4: Upcoming tab (with program set)

Chapter 4 Discussion

24

Figure 4.5: Planned Tab (with exams planned)

Figure 4.6: Delete exam date dialog

Chapter 4 Discussion

25

Figure 4.7: Finished exams tab

Figure 4.8: Rate exam dialog with rating mechanism

Chapter 4 Discussion

26

Chapter 5 Conclusion
The goal of the widget was to reduce student hassle and provide tools that are useful and that are not available in the CampusOnline Software used by many universities. The goal was reached as planned in the beginning. Maximizing automation and minimizing work for the student. Compromises were made where necessary and employed workarounds where the elegant solution is not available yet. The result is uid to use and well received. The user base expanded fast and is continuing to do so. There are two big advantages for students using this software for their exam planning. It saves time for the student and it gives the student information that wasnt available before. Leveraging a social rating system to give the student an idea about the relative diculty of a course can make a big positive dierence on that students assessment of time needed to complete an exam successfully.

Chapter 5 Conclusion

27

List of Figures
2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 The login page of the PLE. . . . . . . . . . . . . . . . . . The main view of the PLE. . . . . . . . . . . . . . . . . Widget Template File Structure . . . . . . . . . . . . . . Model-View-Controller Pattern in JavaScript . . . . . . . An excerpt from the list of CampusOnline API methods. Length distribution of course names. . . . . . . Length distribution of course names /w exams. Database Layout. . . . . . . . . . . . . . . . . . Normal distribution quintiles . . . . . . . . . . . The course diculty distribution with quantiles. Eects of a button click. . . . . . . . . . . . . . Autocomplete in Action . . . . . . . . . . . . . Lookup tab (empty) . . . . . . . . . . . Lookup tab (with search query) . . . . . Upcoming tab (empty) . . . . . . . . . . Upcoming tab (with program set) . . . . Planned Tab (with exams planned) . . . Delete exam date dialog . . . . . . . . . Finished exams tab . . . . . . . . . . . . Rate exam dialog with rating mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 10 11 11 12 13 16 17 17 19 20 22 23 24 24 25 25 26 26

List of Figures

28

Listings
3.1 3.2 3.3 3.4 3.5 3.6 3.7 Dening Widget Dimensions . . XML Response Header . . . . . Programs Node XML . . . . . . Parsing XML and lling the DB DBUtils Usage Example . . . . JavaScript Example . . . . . . . JSON Example (edited) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 14 14 15 16 18 18

Listings

29

Bibliography
[1] Douglas Crockford, ed. RFC 4627: The application/json Media Type for JavaScript Object Notation (JSON). Dec. 6, 2011. url: http://www.ietf.org/rfc/rfc4627. txt?number=4627. [2] Anne van Kesteren, ed. XMLHttpRequest. Dec. 6, 2011. url: http://www.w3.org/ TR/XMLHttpRequest/. [3] Mozilla Foundation, ed. About Javascript. Dec. 6, 2011. url: https://developer. mozilla.org/en/JavaScript/About_JavaScript. [4] Mozilla Foundation, ed. ECMA Standard ECMA-262. Dec. 6, 2011. url: http:// www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf. [5] Behnam Taraghi. Slides Widget Tutorial. Dec. 6, 2011. url: http://ple.tugraz. at/widgets/WDG/resources/widgetTutorial_111017.pdf. [6] Behnam Taraghi. Widget Development Environment. Dec. 6, 2011. url: http://ple. tugraz.at/widgets/WDG/resources/WDE2011.zip. [7] Behnam Taraghi and Martin Ebner. A Simple MVC Framework for Widget Development. Dec. 6, 2011. url: http://ceur-ws.org/Vol-638/taraghi_mupple10.pdf. [8] Technische Universitt Graz, ed. CampusOnline Homepage. Dec. 6, 2011. url: http: a //campusonline.tugraz.at. [9] The R Foundation, ed. The R Project for Statistical Computing. Dec. 6, 2011. url: http://http://www.r-project.org/.

Bibliography

30