Providing User-Centered Information in the Personal Learning Environment

8/2/2019 Providing User-Centered Information in the Personal Learning Environment

1/30

Institute of Information Systemsand Computer Media

Graz University of TechnologyGraz, Austria

Providing User-Centered Information

in the Personal Learning EnvironmentBachelors Thesis

Igor Skoric

[email protected]

October 2011

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


2/30

Abstract

Students using the information system of their school or university often feel the systemis not made according to their needs. Programmers are often more concerned about theneeds of the university and its staff, which is understandable as those people make thepurchase decisions for the institution.

In an effort to alleviate student hassle and increase student motivation and productivitythe TU Graz has created the Personal Learning Environment (PLE). The PLE is a student-oriented learning environment providing learning tools for students in the form of a freelyconfigurable widget engine.

This work is a contribution to these efforts with the creation of a widget allowing thestudent to search for exams, compare exam schedules of multiple courses, create an examplan and rate exams afterwards. The exams are rated 1 to 5 points representing the timeinvestment needed in relation to the attained score on the exam. The rating informationis 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, RatingSystem, Student-Centered, PLE, Personal Learning Environment, TU Graz


3/30

Zusammenfassung

Bei der Erstellung von Informationssystemen fur Universitaten werden Studierende als Be-nutzer des Systems oft vernachlassigt. Diese machen in der Regel den groten Benutzerkreisdes Systems aus, haben jedoch keinen Einfluss auf die Kaufentscheidung bei der Anschaf-fung des Systems und werden daher auch entsprechend wenig von den Programmierernsolcher Systeme berucksichtigt. Die Studierenden mussen sich mit der Lage zurechtfinden,die sie oft als unnotig anstrengend und schwierig empfindet.

In einem Versuch diese Probleme der Studierenden zu beheben hat die TU Graz diePersonal Learning Environment ins Leben gerufen. Die PLE ist eine Plattform fur Stu-dierende, die Werkzeuge und Informationen in der Form von Widgets zur Verfugungstellt.

Diese Arbeit tragt ein Widget dazu bei. Dieses Widget ist fur die Verwaltung und Planungvon Prufungsterminen aus Studentensicht gedacht. Der Studierende kann nach Terminensuchen, diese zwischen verschiedenen Lehrveranstaltungen vergleichen und die Planungder Antritte durchfuhren. Nach dem Abschluss der Prufung kann in weiterer Folge eine

Bewertung des Zeitaufwandes zum Erreichen der jeweiligen Note abgegeben werden. DieseInformation wird anderen Studierenden in der Form einer Farbcodierung zur Verfugunggestellt.

Schlagworter: Soziales Lernen, Vernetztes Lernen, Prufung, Widget, Widget Engine,Wertungssystem, Studentenorientiert, PLE, Personal Learning Environment, TU Graz


4/30

Pledge

I hereby certify that the work presented in this bachelors thesis is my own and that workperformed by others is appropriately cited.

Ich versichere hiermit, diese Arbeit selbstandig verfat, keine anderen als die angegebe-nen Quellen und Hilfsmittel benutzt und mich auch sonst keiner unerlaubten Hilfsmittel

bedient zu haben.

4


5/30

Contents

1 Introduction 6

1.1 Identifying the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.1 CampusOnline R . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.2 Making an Exam Schedule . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Designing a Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.1 Searching for a Good Compromise . . . . . . . . . . . . . . . . . . 7

2 State of the Art 8

2.1 Personal Learning Environment - PLE . . . . . . . . . . . . . . . . . . . . 82.2 Widget Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Important Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Widget Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 TU Graz API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Implementation 12

3.1 Getting into Shape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.1 Width of the Widget . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Height of the Widget . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Extracting the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.1 The TU Graz CampusOnline API Format . . . . . . . . . . . . . . 14

3.2.2 The PHP Code for Extracting the Information . . . . . . . . . . . . 153.3 Storing the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.1 The DBUtils Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Processing the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5 Retrieving the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.5.1 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.2 JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . 183.5.3 XMLHttpRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.4 Example of a Request . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6 Maintenance of the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.7 Interfacing with the User . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.7.1 Program Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.7.2 Course Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7.3 Planning Exams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7.4 Rating Exams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Discussion 22

5 Conclusion 27

5


6/30

Chapter 1

Introduction

1.1 Identifying the Problem

1.1.1 CampusOnline R

The Information Management System programmed by Graz University of Technology (TUGraz) is used by 35 institutions of higher education. Its use is obligatory on a daily basisfor 247.000 students attending those institutions and about 77.000 staff members. About1.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. Reasonsfor this are on the one hand lack of sales impact as mentioned and incompatibility of certainfeatures with the overall organisation of the software on the other hand. Features that donot fit into the overall concept make it necessary to reorganise moderately big parts of thesystem, which is inefficient. Features which do not integrate well on the other hand promptthe 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 offer

APIs to restricted groups of programmers to improve existing functionality.

1.1.2 Making an Exam Schedule

One problem identified was the lack of functionality enabling students to choose examsfor learning, taking them at the most opportune times. There is also no possibility offinding out how hard an exam is going to be and how long one should plan on learning forit.

For planning exclusively courses from the current term there is a sorted list of exam datesalready offered in CampusOnline. Nevertheless, the way to plan the exam dates for a list ofcourses 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 6


7/30

After that the list must be sorted and all exam dates of all different courses must becompiled into a single list. After that the time between exams in different sequences andthe time to plan for learning before an exam hat to be calculated. If the list of examschanges, the first part has to be redone partly and the second part has to be redoneentirely.

1.2 Designing a Solution

Starting from here there seems to be plenty room for improvement. Assuming that thereis total access to information and unlimited resources the perfect solution would be onethat does everything automatically.

Due to privacy and data protection concerns, the TU Graz does not expose all the existingdata to the API. Any data involving specific students or student groups is not provided.The API does not enable an application that utilises it to call up any of the data relatedto the currently logged in user, despite the properly authenticated user credentials. Thecontent available at any given time is limited to the information provided by the usermanually.

Furthermore, the API does not provide the information about the link between programsand courses. The full information on all courses and all programs can be retrieved, howeverit is not possible to find out which courses actually make up a specific program by usingthe TU Graz API calls. This means that even if a student provides his or her program andthe current term, the system can not offer exam date management fitting her requirementswithout additional complications. This limitation within the API architecture seems un-necessary 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 thestudents: Their study program and the courses they are planning on doing in the nearfuture. After they attended those courses a way is required to communicate their ex-perience back to the system so the system can process it and provide the result toother students. This solves one part of the information gap with a reasonable compro-mise.

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 TUGraz student web interface. This workaround currently works by parsing the HTML of theweb page making it an avoidable source of error that could be remedied by extending theTU Graz API.

Chapter 1 Introduction 7


8/30

Chapter 2

State of the Art

2.1 Personal Learning Environment - PLE

The Personal Learning Environment is the target framework for the solution. The Loginpage can be seen in figure 2.1. It is a custom desktop-like interface with a rich selection oftools for students (see figure 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 flexible integrationof backend technologies for each and every of the widgets. The main portal interface is ren-dered with the help of jQuery and jQueryUI JavaScript libraries [5].

Chapter 2 State of the Art 8


9/30

2.2 Widget Development

The PLE lead developer Behnam Taraghi provides a PLE widget development frameworkcalled WDE (Widget Development Environment) [6] and a guide on widget definition anddesign [5]. His paper for the MUPPLE10 Conference (Mash-up Personal Learning Envi-

ronments 2010) outlines the usage of the MVC pattern for this environment [7].

2.2.1 Important Files

Config File config.xml This file holds the standardized widget definition. It de-fines information like width, height, name and others. Italso holds the defaults for user preferences.

Index File index.html This is the main file of the widget. It shows the widgetinterface and starts the javascript.

All the other files are optional, but there are practices which one is expected to followwhen developing a widget for the PLE.

2.2.2 Widget Templates

The WDE framework comes with example widgets that can be used as templates andbuilt upon. Especially MVCSampleWithLocalization can be used effectively as a start-ing point and template for new widgets because it already has all important functionsbuilt in (MVC, jQuery, SPI WebService, localization). For the file structure see figure 2.3.

2.2.3 Model-View-Controller

The PLE design uses the Model-View-Controller design pattern implemented in JavaScriptwhich is illustrated in figure 2.4 [7].

The MVC pattern effectively acts as a sandbox and at the same time allows for a certaindegree of parallel development to take place.

2.3 TU Graz API

The CampusOnline configuration of TU Graz is set up to offer a big list of services ex-posed on distinct URLs and requiring an unique API Key. If requests on those URLs aresubmitted alongide a valid and authorized key the API provides the XML files containingthe requested information.

If data is requested at the root node of the organisation tree - which is the organisation



10/30

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 factonly three of those services are needed. Those are as follows:

exportCoursesByOrganisation: This API provides all the courses. This is neededbecause exams are attached to courses.

exportProgramsByOrganization:This API provides all the programs in the sys-tem. This is needed for finding out which programs exist.

exportRDMExamsByOrganization: This API provides the exam dates them-selves.

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, thereis no API service providing that information according to the TU Graz CampusOnline APIdevelopment support team advice provided at the time of writing.



11/30

Figure 2.4: Model-View-Controller Pattern in JavaScript

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



12/30

Chapter 3

Implementation

3.1 Getting into Shape

The nature of the framework that is used means that it is necessary to adapt to certainadditional restrictions imposed by it. Because the widget is sharing desktop estate witha 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 fit the name of the longest course plus thedate of the exam into one line.

Figure 3.1: Length distribution of course names.

As seen in figure 3.1 there are course names of 80 chars and more, but the majority ofnames is in the 10 to 60 characters range. To be more specific, there are 4176 courses inthe database. If 95% of courses are to be covered the widget has to be able to display4176 0.95 = 3967.2 3967 course names. If the limit is set at 57 characters, 3965 coursenames can be displayed. That amounts to 94,94% of total courses, an almost perfectcut.

But not all of the possible courses actually have exams. Only 333 out of the 4176 courses

Chapter 3 Implementation 12


13/30

in the database actually have exam dates in the database. The distribution of course namelengths for courses with exams looks a little different.

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 of49 characters which covers 318 out of 333 courses and amounts to 95.5%. If that is extendedup to 54 characters this can cover all length classes having more than one element whichwould be 326/333 or 97,90%. At the same time this covers 93.44% of total courses with orwithout exams.

3.1.2 Height of the Widget

Looking at the requirement to have multiple pages of content which are separate from eachother there are two solutions provided by the jQueryUI library.

Accordion: Has a very rich animation but takes a area of full length of the parentcontainer for every additional page. This is not very beneficial for an interface withvery limited screen estate.

Tabs: Has a very plain animation but takes up only as much space as one item inthe accordion. Additionally has the advantage of being intuitively understood by abig 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 kindof description and/or controls plus margins the target height should be at about 300px ormore. Having defined the height and width requirements, those can be inserted into thewidgets config.xml file.

Listing 3.1: Defining Widget Dimensions

1 < w i d ge t x m l ns = " h t t p : / / w w w . w 3 . o r g / T R / w i d g e t s / "

2 xmlns:palette= "http://palette.ercim.org/ns/"

3 width= " 5 5 0 "

4 height= " 3 0 0 "

5 id =" e x a m W i d g e t ">



14/30

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 storeit 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 Identifier: 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=37Where 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 therequested format. The header of the response can be seen in listing 3.2.

Listing 3.2: XML Response Header

1


15/30

15 https://online.tugraz.at/tug_online/semesterplaene

.uebersicht?pStpStpNr=571&csj_nr=1032&csr_nr

=246

16 < / w e b L i n k >

17 < s u b B lo c k u s e r De f i n e d =" p r o g r a m S t a t u s "> N < / s u b B l o c k >

18 < / i n f o B l o c k >

19 < s e a r c hw o r d > E l e k t r o te c h n i k < / s e a r ch w o r d >

20 < / p r o g r a m >

3.2.2 The PHP Code for Extracting the Information

From here all the relevant informationcan be exrtacted by reading the well structuredXML file returned from the API. This is done by by processing the file in a server sidescript, programmed in PHP. For the solution at hand, the API responses are cached intoXML files and used from there. See listing 3.4.

Listing 3.4: Parsing XML and filling the DB1 /*

2 * p a rs i ng p r og r am s f ro m c ac h e

3 */

4 echo (" p r o c e s si n g p r o g ra m s . . . \ n " );

5 $ db = n ew D BU ti ls ;

6 $ f i l en a m e = " . . / c a c h e / r a w _ p r o g r a m s . x m l ";

7 $ xm l = ;

8

9 if ( o p e n F il e ( $ f i l en a me , $ x ml ) ) {

10 foreach ( $ xm l - > p r og r am a s $ p ro g ra m ) {

11 $ p r o gr a m I D = $ p ro g ra m - > p r o g r a mI D ;

12 $ p r o gr a m C o de = $ p ro g ra m - > p r o g r a m Co d e ;13 $programName = $program ->programName ->text;

14 $ p r o g r am L e v e lT e x t = $ p ro g ra m - > l e v el ;

15 $ p r o g ra m _ t yp e = "??" ;

16 $ a rr = $ p ro g ra m - > l e ve l - > a t t r ib u t e s ( ) ;

17 $ p ro g ra m _t y pe = $ ar r [ u s e r D e f i n e d ];

18 $db->dbExec( " R E P L A CE I N TO p r o gr a m s ( p r o g ra m _ id , p r o gr a m _c o d e ,

p r o gr a m _n a m e , p r o g r am _ t y p e ) V A L UE S ( " . $ pr og ra mI D . " , "

. $ p ro g ra m Co d e . " , " . $ p ro g ra m Na m e . " , " .

$ p r o g ra m _ t yp e . " ) ; ") ;

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 databaseis illustrated in figure 3.3.



16/30

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 islocated in the internal directory and is used by every file that needs database access. Anexample of its usage is given in code listing 3.5.

Listing 3.5: DBUtils Usage Example

1 r e q u ir e _ o n ce ( . . / i n t e r n a l / d b u t i l s . p h p ) ;

2

3 $ db = n ew D BU ti ls ;

4 $ r e su l t = $ db - > g e t N rP r o g s ( ) ;

5

6 echo (" N u mb er o f P r og r am s t o p a rs e : ". $ r e s u l t ."\n" );

3.4 Processing the Data

Ratings given by individual students provide the raw information which needs to be pro-cessed and interpreted to get meaningful results which can be presented to the students.As there are five levels of difficulty in the rating system that is being used for this soft-ware, it makes sense to use five levels of difficulty in the color coded indicator systemwhich is displayed to users. Deciding which indicator to show is not as straightforward ascalculating the average and rounding the result.

To decide how to part the field of courses into five categories a few assumptions weremade. One of those assumptions is that course difficulty is normally distributed. This isa fairly safe assumption to make as many similar datasets are normally distributed. This



17/30

will suffice as a starting point until a large dataset of course difficulty ratings has beengathered.

Partitioning a normally distributed field into five sets of courses with equal cardinalitymeans calculating the five quantiles of the distribution that contain 1

5of the courses each.

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 figure 3.5.

Figure 3.5: The course difficulty distribution with quantiles.

As is visible in figure 3.5 the chosen parameters of = 2.5 and = 1 make the distributionspill over the edges of the rating window. This is made intentionally to ignore 5% of fringecases and get a more fitting 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 XMLHttpRe-quest objects, JavaScript and JSON. All the work of formatting the interface anddisplaying 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 for-mat.



18/30

3.5.1 JavaScript

JavaScriptR(sometimes shortened to JS) is a lightweight, object-oriented lan-guage, most known as the scripting language for web pages, but used in manynon-browser environments as well.[3]

This is the programming language in which the used framework and widgets are pro-grammed in. It is an implementation of the ECMA Script Standard [4]. The following is ashort example of what JS code looks like.

Listing 3.6: JavaScript Example

1 function o n Lo a d () {

2 / / = == S ta rt in g i t a ll = ==

3 MVC.Controller.init(

4 function ( k ey ) {

5 return widget.preferenceForKey(key);

6 },

7 function ( k , v ) {

8 return w i d ge t . s e t P r e f e r en c e ( k , v ) ;

9 }) ;

10 }

3.5.2 JavaScript Object Notation

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independentdata interchange format. It was derived from the ECMAScript ProgrammingLanguage Standard. JSON defines a small set of formatting rules for the portablerepresentation of structured data. [1]

JSON is the format that is used to transport data between this softwares server side APIand its client side JavaScript. An example of this format is the localization data used bythe widget.

Listing 3.7: JSON Example (edited)

1 {

2 "id" : " d e ",

3 " P l a n n e d " : " G e p l a n t ",

4 "Finished" : " A b g e s c h l o s s e n ",5 " M y P r og r am " : " M e i n S t u di u m " ,

6 }

3.5.3 XMLHttpRequest

The XMLHttpRequest standardized by the W3C in the W3C Candidate Recommendationfrom August 2010 [2].



19/30

The XMLHttpRequest specification defines an API that provides scripted clientfunctionality 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 madeeasier 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:1tojQuery.getJSON() which is a special case ofjQuery.Ajax(). The framework functiontakes the same parameters as the jQuery counterpart.

3.5.4 Example of a Request

The program flow is illustrated in broad strokes in the sequence diagram in figure 3.6.

Figure 3.6: Effects 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, oldexams are being moved, programs are being modified and new ones are being introduced.It is necessary to maintain data integrity, timeliness and coverage. And it needs to bemaintained without the need of manual intervention.

For this purpose there is a mechanism in place. There is a scheduled program on the PLEserver that updates the data that is stored in the database. This program - also knownas a cronjob - retrieves the current data from the TU Graz API and updates the exams,



20/30

programs and courses so they stay correct and relevant. The data which is updated in thisway is immediately available to the user and integrates seamlessly with the old data thatwas available before.

Search queries that have changed show the new values upon the next refresh. Alreadyselected 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 theuser:

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 fitting selection mechanic is required. The function jQuery.Autocomplete() fits therequirements perfectly.

Figure 3.7: Autocomplete in Action

An auto complete mechanism usually works by letting the user input a few charactersand offering a list of matching items for the user to select from. In the example shownin figure 3.7 the word soft was entered and the auto complete mechanism filtered allcourses down to only those containing the string soft. The filtering and displaying ofitems happens asynchronously on-the-fly. This offers the possibility for the user to correctand/or change the input. After selecting an item from the list with the mouse or arrowkeys the event is automatically fired and the bound function is executed with the selecteditem supplying one of the arguments. In this case the argument supplied is the programid.



21/30

3.7.2 Course Selection

For this the same mechanism is employed as was before for program selection. The differ-ence is in what is done with the supplied information. Instead of just changing the selecteditem it is added up to a list which forms the constantly updating search query. In this waythe user is provided with a way to search for multiple courses at the same time and removethe need to compare exam dates manually outside this software. The search query can thenbe 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 searchquery in the search tab a user can add an exam date to his planned exams by clickinga green right pointing arrow displayed at the end of the name of said exam. The rightpointing 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 areon the right.

3.7.4 Rating Exams

After an exam date has been added to the planned exams and its date passed the examis moved to the finished exams tab. In this tab the student can mark courses as finishedor remove them if he did not participate after all. Clicking the finish button opens up adialog and gives the student the option to input his experience with the difficulty of thecourse. This rating is afterwards included into the calculations for the difficulty indicators

which other students can see.



22/30

Chapter 4

Discussion

Figure 4.1: Lookup tab (empty)

In figure 4.1 the startup view of the Widget can be seen. A user can formulate a compar-ative search query here by adding multiple exams to the query, which results in a displaysimilar to the one seen in figure 4.2 where a search query with three different courses wasconstructed. The query shows the possible exam dates of all the added courses combined.The user can see the date, difficulty (coloured indicator) and name of the exam. The greenarrow at the end allows the addition of the exam date to the list of planned exams. Theview can be reset by clicking the reset button to the right of the search bar.

The second tab is similar to the first one. The main difference is that in this tab the userselects 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 theprogram to the search query in the first tab. The second tab is illustrated in figure 4.3where the empty tab can be seen and figure 4.4 where a program has been selected fordisplay.

The third tab (seen empty in figure 4.5) shows the planned exams and represents a quasiagenda. These are the exam dates which the user wants to attend or plans to do so. Theonly action possible at this stage is removal, which is pictured in figure 4.6.

Chapter 4 Discussion 22


23/30

Figure 4.2: Lookup tab (with search query)

The dialog seen in figure 4.6 is shown when the user clicks the remove button on theplanned tab or the finished exams tab. An exam removed in this way leaves no permanentrecord in the database. It is presumed that the exam was not taken or the plan of the userchanged. Maybe the exam was added by mistake. Whatever the reason is, this is a cleanremoval.

After an exam date expires the exam is moved to the last tab (seen in figure 4.7). The onlysignificant difference for the user is the inclusion of the rating button. The rating button

opens the next and last dialog window (see figure 4.8). It allows the user to rate the examon a five part scale. The five 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 thecourse.



24/30

Figure 4.3: Upcoming tab (empty)

Figure 4.4: Upcoming tab (with program set)



25/30

Figure 4.5: Planned Tab (with exams planned)

Figure 4.6: Delete exam date dialog



26/30

Figure 4.7: Finished exams tab

Figure 4.8: Rate exam dialog with rating mechanism



27/30

Chapter 5

Conclusion

The goal of the widget was to reduce student hassle and provide tools that are useful andthat are not available in the CampusOnline Software used by many universities. The goalwas reached as planned in the beginning. Maximizing automation and minimizing work forthe student. Compromises were made where necessary and employed workarounds wherethe elegant solution is not available yet. The result is fluid to use and well received. Theuser base expanded fast and is continuing to do so.

There are two big advantages for students using this software for their exam planning. Itsaves 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 difficultyof a course can make a big positive difference on that students assessment of time neededto complete an exam successfully.

Chapter 5 Conclusion 27


28/30

List of Figures

2.1 The login page of the PLE. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 The main view of the PLE. . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Widget Template File Structure . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Model-View-Controller Pattern in JavaScript . . . . . . . . . . . . . . . . . 112.5 An excerpt from the list of CampusOnline API methods. . . . . . . . . . . 11

3.1 Length distribution of course names. . . . . . . . . . . . . . . . . . . . . . 123.2 Length distribution of course names /w exams. . . . . . . . . . . . . . . . 133.3 Database Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Normal distribution quintiles . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 The course difficulty distribution with quantiles. . . . . . . . . . . . . . . . 173.6 Effects of a button click. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.7 Autocomplete in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Lookup tab (empty) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Lookup tab (with search query) . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Upcoming tab (empty) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4 Upcoming tab (with program set) . . . . . . . . . . . . . . . . . . . . . . . 244.5 Planned Tab (with exams planned) . . . . . . . . . . . . . . . . . . . . . . 254.6 Delete exam date dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7 Finished exams tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.8 Rate exam dialog with rating mechanism . . . . . . . . . . . . . . . . . . . 26

List of Figures 28


29/30

Listings

3.1 Defining Widget Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 XML Response Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Programs Node XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 Parsing XML and filling the DB . . . . . . . . . . . . . . . . . . . . . . . . 153.5 DBUtils Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.6 JavaScript Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.7 JSON Example (edited) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Listings 29


30/30

Bibliography

[1] Douglas Crockford, ed. RFC 4627: The application/json Media Type for JavaScriptObject 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 Develop-ment. Dec. 6, 2011. url: http://ceur-ws.org/Vol-638/taraghi_mupple10.pdf.

[8] Technische Universitat Graz, ed. CampusOnline Homepage. Dec. 6, 2011. url: http://campusonline.tugraz.at.

[9] The R Foundation, ed. The R Project for Statistical Computing. Dec. 6, 2011. url:http://http://www.r-project.org/.

Bibli h 30
http://www.ietf.org/rfc/rfc4627.txt?number=4627http://www.ietf.org/rfc/rfc4627.txt?number=4627http://www.w3.org/TR/XMLHttpRequest/http://www.w3.org/TR/XMLHttpRequest/http://www.w3.org/TR/XMLHttpRequest/https://developer.mozilla.org/en/JavaScript/About_JavaScripthttps://developer.mozilla.org/en/JavaScript/About_JavaScripthttp://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdfhttp://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdfhttp://ple.tugraz.at/widgets/WDG/resources/widgetTutorial_111017.pdfhttp://ple.tugraz.at/widgets/WDG/resources/widgetTutorial_111017.pdfhttp://ple.tugraz.at/widgets/WDG/resources/WDE2011.ziphttp://ple.tugraz.at/widgets/WDG/resources/WDE2011.ziphttp://ceur-ws.org/Vol-638/taraghi_mupple10.pdfhttp://campusonline.tugraz.at/http://campusonline.tugraz.at/http://http//www.r-project.org/http://http//www.r-project.org/http://campusonline.tugraz.at/http://campusonline.tugraz.at/http://ceur-ws.org/Vol-638/taraghi_mupple10.pdfhttp://ple.tugraz.at/widgets/WDG/resources/WDE2011.ziphttp://ple.tugraz.at/widgets/WDG/resources/WDE2011.ziphttp://ple.tugraz.at/widgets/WDG/resources/widgetTutorial_111017.pdfhttp://ple.tugraz.at/widgets/WDG/resources/widgetTutorial_111017.pdfhttp://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdfhttp://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdfhttps://developer.mozilla.org/en/JavaScript/About_JavaScripthttps://developer.mozilla.org/en/JavaScript/About_JavaScripthttp://www.w3.org/TR/XMLHttpRequest/http://www.w3.org/TR/XMLHttpRequest/http://www.ietf.org/rfc/rfc4627.txt?number=4627http://www.ietf.org/rfc/rfc4627.txt?number=4627

Providing User-Centered Information in the Personal Learning Environment

Documents

Transcript of Providing User-Centered Information in the Personal Learning Environment