Ontwerp en implementatie in SCORM en METS Groep 1 Tem Bertels
Andres Gutierrez
1ste master CW
3de bach Informatica
[email protected]
[email protected]
Tom Mercelis
Annelies Van der Borght
1ste master CW
2de bach Informatica
[email protected]
[email protected]
ABSTRACT The last three weeks were spent working on two different multimedia systems; SCORM and METS. We approached each of them in a different way, and since none of the members of our group had ever heard of, or worked with these systems before, the development of our applications didn't go as smoothly as planned. This paper will elaborate on a description and comparison of the systems and related tools, as well as on the implementation of our applications.
1 SCORM AND METS When working with SCORM, we encountered a couple of problems because we didn't have any previous experience with this kind of system. Also, not much information about SCORM (for example tutorials...) was available on the internet. This also meant it took us some time to get started with the actual implementation of our program.
were necessary and which were optional. A more negative thing about METS was that even less information about it was readily available on the internet, than there was about SCORM. It was also quite complicated to test the application locally on our computer: we had to make an html from the xml, deploy the viewer.war file on a tomcat server, put the html in the server etc. This meant it was not extremely straightforward to develop an application with it. To us, METS appeared to be a development tool created specifically for indexation and sharing of multimedia (text files, images, sound and video...). An application we would make with METS is, for example, efficiently sharing a large amount of multimedia (possibly with a database behind it). Some comparisons we can make between SCORM and METS are:
METS seemed to still be in a development stage, while SCORM didn't give this impression (mostly because of the tools and the fact that there was relatively more information to be found on the internet);
For people with no programming experience, SCORM will probably be more interesting thanks to the tools. METS, on the other hand requires at least some knowledge of java and xml.
For programmers, SCORM will possibly be easier to start working with, but METS will eventually give the satisfaction of being able to adapt the system to your particular needs.
Once we got used to the system, and the tools we were working with (see below), we realized it wasn't that hard to make a “simple” tutorial, as asked. From what we experienced, SCORM seems to be a very good tool to create tutorials, programs in which we expect the user to learn something, tests, self-study modules... Unlike Flex, which seems to be oriented towards entertainment multimedia, SCORM is more teaching oriented. The positive thing about METS was that being mainly java and xml code, writing a METS application was easy to get started with, once we knew which options to change, which
When asked to compare with Flex, we find this difficult
since we have the feeling Flex has a completely different purpose from SCORM and METS. Like noted before, Flex is a system that is used for more entertainment aimed multimedia programs. Flex is also more widely used (as seen from the amount of information/tutorials found on the internet). While SCORM and Flex are both aimed at creating interactive applications, Flex doesn't restrict the programmers in any way. SCORM also expects the programmer to build more strict events.
When using the RELOAD tools, we did experience some oddities:
Sometimes, when running the application, the prerequisites didn't work (we could jump to a page that shouldn't be available yet, and vice-versa).
We got stuck with pages we couldn't see anymore because they were already viewed (“page completed”). This was particularly annoying when this page contained a test we didn't fill in yet and that we possibly needed to get to the next page. We found out this could be fixed by editing the css file.
2 EXE AND RELOAD The positive thing about EXE is that the tool gives us some predefined options to use in our application. This allows the user to get acquainted to the possibilities that SCORM offers them. The tool is pretty intuitive, since it just defines the html code (it doesn't bother about the prerequisites yet). A less interesting aspect about EXE is that there is almost no possibility to extend the basic options to more advanced and personalized ones. This is also because we don't know exactly how the communication between the created html files and RELOAD happens. EXE has an option that allows the user to change the generated html code. When we tried to use it, we discovered that some changes weren't possible (for instance, adding spaces: “ ”). We assume this is a bug in the tool. Once the html files were created in EXE, we imported them in the RELOAD editor to specify details like the prerequisites. Since each of us worked on a part of the application, we first tried to merge the four parts together in RELOAD. This didn't seem possible. We then decided to merge the files in EXE, and import the whole project at once. We used two versions of the RELOAD editor, namely the eclipse based version, and the “simple” version. The advantage of the eclipse based version is the possibility to edit the html files, but because we had a hard time finding where to define the prerequisites, we switched to using the “simple” version. This one ended up being a lot easier to use. We found that while the GUI of RELOAD editor isn't extremely intuitive, the tool is quite easy to use once one had read the documentation (this also applies to people with little/no programming knowledge). In our opinion, the RELOAD player has no particularly positive or negative aspects, it just seemed to do what it was supposed to do.
Since our knowledge about SCORM is limited to the applications we made in this course, we think we would use EXE and RELOAD in the development of tutorials, tests, lessons, self-study courses... In our opinion, EXE and RELOAD are complementary and both handy to create a correct SCORM application. FlexBuilder and EXE have the following things in common:
They both allow the programmer to use predefined options;
They both let the user edit the code created by these predefined options.
Both of these aspects worked very well in FlexBuilder, but still seemed to have bugs in EXE (especially the second aspect, like stated earlier). RELOAD and FlexBuilder didn't seem to have anything in common when it comes to functionality or GUI. We can conclude by mentioning that FlexBuilder has more of a “finished” feel about it (for example, all the functionalities work), while EXE and RELOAD seem to still be in a development phase.
3 RESULT 3.1 Implementation in SCORM We were asked to make a tutorial about Flex in SCORM. First of all, we made a story-board of the content we wanted to put in the tutorial [Image 1 and 2]. Then we drew a graph of the transitions between the different pages of the application [Image 3]. We divided the work in four, and each of us made two pages of the tutorial. When we tried to merge them in RELOAD, we couldn't add the files from one project to another. So we decided to put them together in EXE. Once all the files had been merged, we all worked together on defining the prerequisites and fixing the problems that came up during testing (for a quick overview of these problems and bugs, see 2 EXE AND RELOAD).
We didn't change anything in the actual functionality of the application designed in the story-board, but modified the layout a little:
We put an image on the “introduction” page because it seemed a little empty when it just contained plain text. We didn't follow the initial layout of pages 5 and 6 (this was because images didn't seem to fit).
Although the final result wasn't as “spectacular” as a flex application can be, it was pretty much to our liking. It had a clean look, well adapted to the purpose of the tutorial. The only minor disadvantage was that we couldn't change the images of the predefined options in EXE (for instance the light bulb or eye above the tests). We would have changed them because they didn't seem to necessarily fit well with tutorials for adults.
3.2 Implementation in METS For this assignment, we were to choose between sharing personal pictures and sharing images of a couple of pages from a book. We decided on the second option and started working in group from the beginning, because it didn't seem like the task could be divided between the four of us. Initially we weren't sure whether we should adapt the given java code before parsing it, or change the xml code created by the parsing. We settled on the java code as we are more acquainted with this programming language. Most of the time spent on this project was used to figure out which options we could/should change to achieve the result we wanted (adding a date or an author, changing the multimedia/title...). Once we knew all this, the adaptation itself wasn't extremely difficult. While working we encountered two little problems:
The name of the xml file that was being processed, was hard-coded in the file METSFrameSX.xsl, which meant we initially always translated the wrong file to html.
When our html files were finally finished and being deployed, we kept seeing the wrong content (the content of the pages of Test2.html). It took us some time to figure out why this happened. Eventually we found out this was because Tomcat cached the original example file (Test2.html) and didn't automatically load the file we wanted to run.
From the beginning, we knew the layout and functionality of our application would be similar to that of the given Test2.html, so we weren't very surprised by the result. We didn't spend time figuring out how to change the layout of the application, as we didn't deem this necessary for the
purpose of it. Finally we can remark that it was a shame the example file wasn't more extensive, because we have the feeling that we weren't able to explore the full capabilities of METS.
4 CONCLUSION We are quite happy with the way we handled both projects, and the working in group on these projects (splitting up the work for SCORM, not doing this for METS...). As such, we wouldn't really change anything in the way we approached the development of our SCORM and METS applications. We got off on the wrong foot in the SCORM assignment (because we didn't exactly know what was expected of us), but in the end, we did figure out how to work with two new content sharing systems. We had the distinct feeling that SCORM and METS very much aimed at efficiently sharing data (and corresponding metadata) so we now know that there other kinds of multimedia applications than just “entertainment” kind (like we made in Flex).
are the are the
APPENDIX A Time spending Table 1: Overview of time spend on the projects Name During courses Outside of the Total courses Andres
12 hours
5 hours
17 hours
Annelies
12 hours
5.15 hours
17.15 hours
Tem
12 hours
4.30 hours
16.30 hours
Tom
12 hours
4.30 hours
16.30 hours
See Table 2 (in APPENDIX C) for a more detailed description of the time spent on the projects. The hours noted during the courses are the once we spent listening to the introductions, installing the tools, learning how to work with them and the actual implementation of the applications. The hours spent outside of the courses were spent mostly on writing/correcting the layout of this paper.
B ISMIR paper Samenvatting De paper die we gelezen hebben is “Development of a music organizer for children”. De paper start met de vaststelling dat kinderen van zes tot tien jaar computers ook willen gebruiken zoals grote mensen. Maar kinderen kunnen niet zo goed lezen en spellen als volwassenen en ze hebben ook problemen met het begrijpen van abstracte begrippen. Het doel van het onderzoek was een voor kinderen bruikbare music organizer te maken.
Bij dit onderzoek werden ook testsessies met kinderen gehouden, in eerste instantie om de bestaande producten te onderzoeken. Deze waren Windows Mediaplayer, iTunes en KidsPlayer. Deze laatste is zoals de naam doet vermoeden gemaakt voor kinderen. Uit het vooronderzoek bleek dat kinderen de “volwassen” programma's saai vonden qua uiterlijk en dat de hoeveelheid informatie overweldigend was. Positieve punten waren het sterretjes geven aan de liedjes en de visualisaties van het geluid in Mediaplayer. De KidsPlayer gebruikte wel kleurrijke knoppen, maar vergat om de knoppen duidelijk te omlijnen, waardoor kinderen ze moeilijker konden vinden. Uit voorafgaande studies en dit onderzoek werden volgende conclusies/richtlijnen getrokken voor het ontwerp van Kids Music Box:
de interface moet zeer visueel zijn;
vermijd lange of ingewikkelde tekst;
vraag geen tekstinvoer, maar laat de kinderen liever kiezen uit een lijst;
elke actie moet onmiddellijk een reactie geven;
icoontjes moeten overeenkomen met zaken die kinderen kennen, geen abstracte concepten;
kinderen hebben soms abstracte concepten;
best geen menu's met meerdere niveaus;
geluidjes/animatie/oplichtende knoppen helpen kinderen elementen met functionaliteit te vinden in de GUI.
moeilijkheden
met
Er werd ook vastgesteld dat het muisgebruik bij kinderen anders is dan bij volwassenen: iets over lange afstand slepen bleek moeilijk en de nauwkeurigheid waarmee ze klikten was minder goed. Drag & Drop operaties en kleine knoppen moeten dus zoveel mogelijk vermeden worden. Om de muziek te organiseren kozen de ontwerpers voor een concept waarvan ze verwachtten dat de kinderen het allemaal zouden kennen: dozen. Verschillende liedjes kunnen georganiseerd worden in dozen, net zoals kinderen hun speelgoed in de echte wereld vaak moeten opruimen in dozen. Deze dozen stellen dus de “playlists” voor die we kennen van de volwassen programma's. Een eerste prototype van het programma was een niet functioneel ontwerp van de GUI. Deze versie werd enkel door experts onderzocht en het ontwerp werd naar hun opmerkingen aangepast. Naast de gebruiksinterface voor kinderen, werd er ook één
gemaakt voor de ouders. Zij kunnen de toegang die het kind krijgt tot de bestanden op de computer configureren. Uit het onderzoek met de kinderen bleek dat het gebruik van de interface niet te moeilijk was. De visualisatie werd goed onthaald, maar het doosconcept kwam niet zo goed over. Vooral omdat dit niet zo duidelijk was (geen afbeelding van een doos, geen drag & drop). Een andere bevinding was dat de skins een onderwerp zijn dat door de kinderen zeer uiteenlopend onthaald werd. De jongens vonden sommige skins te meisjesachtig, of de oudere kinderen vonden de skins te kinderachtig. De verschillen tussen de jongste kinderen (6 jaar) en de oudste (10 jaar) was zeer opvallend. Dit bemoeilijkt de creatie van een ontwerp dat voor verschillende leeftijden bruikbaar is. Het programma heeft dus nood aan verschillende skins, die aanpasbaar zijn naar de wensen van de gebruiker. Waarom we deze paper gekozen hebben De eerste selectie is gebeurd op basis van de algemene inhoud van de papers. Op die manier zijn degenen die “te” wiskundig of te technisch gericht waren, gesneuveld. De papers waar een bepaalde kennis (bvb van een muziekinstrument, partituren...) voor verreist is, hebben we ook geëlimineerd. Uiteindelijk bleven er drie papers over, die ons enigszins boeiden:
Development of a music organizer for children (pagina 185);
Rhyme and style features for musical genre classification by song lyrics (pagina 337);
Social playlists and bottleneck measurements [...] maximum flow values (pagina 559).
Het eerste paper trok heel gemakkelijk de aandacht aangezien het origineler en creatiever leek dan de andere twee. Ook hadden we het idee dat als we de inhoud van het paper zouden moeten toepassen in onze applicaties, dit het leukste en interessantste zou zijn. Toepassing van deze paper in onze applicatie Hoewel het concept van het “satanisch citaat in de teruggedraaide plaat” niet echt kindvriendelijk klinkt, kan het ook wel door kinderen gebruikt worden. Het is voor kinderen immers zeer normaal dat ze een eigen interpretatie geven aan liedjesteksten in vreemde talen die ze niet begrijpen. Onze interface is zeer eenvoudig, de enige hindernis die we na het lezen van deze paper kunnen inzien is dat jonge kinderen misschien nog niet kunnen neerschrijven wat ze horen.
C Images and tables
Image 1: Storyboard SCORM, part 1
Image 2: Storyboard SCORM, part 2
Image 3: Graph of the transitions When
During courses
Table 1: Detailed list of hours spend on the projects Outside of the courses Name Worked on
17/10/2008
4 hours
-
Group
Download and installation of SCORM + learn how to work with SCORM
23/10/2008
-
30 minutes
Andres
Completing wiki
24/10/2008
4 hours
-
Group
Making SCORM-application
31/10/2008
4 hours
-
Group
METS introduction + making application
03/11/2008
-
1 hour
Group
Start working on paper
04/11/2008
-
3.30 hours
Group
Completing paper
05/11/2008
-
30 minutes
Annelies
Lay-outing paper
