USING MOBILE PHONES FOR MOBILE LEARNING: EVALUATION OF HISTOBRICK

Transcription

1 Fachbereich Elektrotechnik und Informationstechnik Datenverarbeitungstechnik Prof. Dr.-Ing. Bernd Krämer USING MOBILE PHONES FOR MOBILE LEARNING: EVALUATION OF HISTOBRICK Technical Working paper Georg Ströhlein October 2005 Abstract The purpose of the work reported on here 1 was to investigate and evaluate students acceptance of mobile learning using mobile phones. Based on results of internal and external evaluation of a preceding project, a client-based, game-like mobile learning object called HistoBrick has now been created. It harnesses the capabilities of Sun s mobile version of the Java programming language, and serves as a platform for self-studies, exercises and communication in combination with the formerly developed courseware. HistoBrick aims to provide a ubiquitous tool for examining and deepening one s knowledge about statistical distributions and their most important characteristic numbers. HistoBrick supports spontaneous short study sessions on the move using mobile phones to deepen or test one s knowledge of particular statistical concepts. The impact of technology on didactical aims is analysed when reporting on why and how it was tried to set up this game-like, constructivist learning scenario. Results of a post test evaluation are presented and discussed. The evaluation of students feedback suggests that mobile phones are only regarded as a value adding supplement to PC-based educational technologies if obvious shortcomings of phones as compared to PCs are eliminated by the design of the learning scenario. The main idea of capturing a student s attention in distracting environments by providing them with a game-like learning object works well. But the much bigger and crucial problem to be solved seems to be how to convince the large majority of students to use small pieces of spare time occurring in their everyday lives to practise mobile learning at all. From a developer s point of view, it turns out that frequent technology changes in this sector, the diversity of devices and their software, a lack of coherence to middleware, few supported base technology standards, and built-in mobile client software often giving preference to stylish over usable interfaces limit the wide-spread usage of applications to a wider range of devices as well as their sustainability. 1 financially supported by the EU under contract number 2003-IRL/03/B/F/PP

2 2 / 41 Table of contents Abstract: Evaluation of HistoBrick Background Framework Didactics Brief remarks on relevant statistical concepts Brief remarks on didactical setting Impact of technology Technology Some general remarks on the J2ME platform Remarks on the J2ME built-in device emulator HistoBrick as displayed in device dependant emulators Networking within J2ME Evaluation method Findings Developing, testing and deploying HistoBrick Tests concerning the Siemens CX65 mobile phone Tests concerning the Sagem MyX-7 mobile phone Deploying HistoBrick Questionnaire on different phones Project home page on different phones Students opinions Discussion of item ratings Discussion of comments Conclusions Epilogue References...40 List of figures Fig. 1: Histogram where the concept of the mean fails (annotations in German)...5 Fig. 2: CLDC 1.0 / MIDP 1.0 vs. CLDC 1.1 / MIDP Fig. 3: Example of message box asking for permission to connect a MIDlet to the Internet...9 Fig. 4: Selected information provided in the JAD file later on...10 Fig. 5: Adjusting the screen size of J2ME s emulator from default (a) to that of a real phone (b)...11 Fig. 6: Screenshots of the J2ME emulator before (a) and after (b) adjusting the screen size...12 Fig. 7: HistoBrick MIDlet as displayed in selected phone emulators...13 Fig. 8: Game screen of HistoBrick as displayed on the Sagem MyX-7 with annotations...14 Fig. 9: MIDP 1.0 vs. MIDP 2.0 with respect to internet connections...15

3 3 / 41 Fig. 10: Scheme of translations performed by WAP gateway...16 Fig. 11: WAP gateway trouble...16 Fig. 12: Successful establishing an HTTP connection through HTTP APN...17 Fig. 13: Configuring Linux for automatic launch of the WTK emulator for JAD files...22 Fig. 14: Playing HistoBrick on a Linux PC...23 Fig. 15: Error when trying to install SMTK 3.0 without drive c:\...24 Fig. 16: Context menus in SMTK to launch external JAD files...25 Fig. 17: Data transfer from PC to CX Fig. 18: Screenshots of CX65 emulator demonstrating the effect of the soft-hyphen HTML tag...26 Fig. 19: Media rejected by Sagem MyX Fig. 20: Media accepted by MyX Fig. 21: Problems with questionnaire on K700i...29 Fig. 22: Radio buttons and check boxes as displayed by some phones built-in browsers...30 Fig. 23: Button rendering on Nokia 6230i and Sagem MyX-7 phone...31 Fig. 24: Rendering of action buttons by the built-in browser of the Siemens CX65 phone...32 Fig. 25: Button rendering by standard PC browser without (a) and with (b,c) usage of CSS Fig. 26: Rendering of the project home page at DVT on different mobile phones...34 Fig. 27: Response patterns of all students...35 Fig. 28: Items ranked according to mean in reduced sample (N=8) Background The majority of students of FernUniversität, the only German language distance teaching university, is studying part-time, is working, and has a family. Thus, students experience a huge workload and tight daily routine. A survey [1] in 97 revealed that roughly 75% of drop-out students argued they could not manage to find their time for work, family and study any more. Many students of FernUniversität work in offices of relatively large companies or institutions. In Germany, these office blocks are often well connected to public transportation, and thus FernUniversität explored how to enable students to use (public) transportation time for mobile learning (or other time gaps that occur out of home or office). 1.1 Framework The term mobile learning here is defined as the provision of study and training courses via handheld wireless devices which can access the internet, i.e. PDAs (Personal Digital Assistants), smartphones and mobile (cellular) phones. Note that this definition explicitly excludes notebooks. The term smartphone is used to describe mobile phones with some extra functionality like an client or a PC like organizer; this class of devices might be regarded as the result of combining a PDA with a mobile phone. Quite often, smartphones are equipped with a touch screen and thus operated using a stylus instead of keys in case of usual mobile phones (see project leader s homepage [2], e.g.).

4 4 / 41 In a preceding mobile learning project [3] a short course entitled Introduction to descriptive statistics had been developed. The evaluation [4] revealed that students most likely wouldn t want to read through long texts on a mobile phone but rather prefer short concise statements summarising or commenting parts of the courseware provided by conventional PC- or paper-based learning environments, like a glossary or questions and answers, for example. Because these findings applied even to the PDA (personal digital assistant) version of the course and the screen of current mobile phones has as resolution considerably smaller than the quasi-standard of 240x320 pixels in width and height of PDA-like devices, it could be assumed that even a glossary isn t suitable in case mobile phones are used as output device. Taking into account the distracting environment usually found when students don t have access to their traditional learning environment, e.g. during (public) transportation, a means had to be found to attract students attention in some smart manner. Having observed many young people in busses, subways or trains who totally forgot about their environment when playing a game on their mobile phone, it was decided to try out a game-like application to provide a learning experience to mobile students. Moreover, it was decided to focus on mobile phones because there is evidence [5] that at the moment the market penetration of PDAs/smartphones in the German people is only 10% of that of mobile phones. A recent survey [6] shows that among FernUniversität s students this proportion may be more favourable for PDAs (roughly one quarter of FernUniversität s students own a PDA or smartphone), but still mobile phones are by far the most wide-spread class of mobile devices. 1.2 Didactics Practitioners in the area of applied statistics are usually concerned with calculating a small set of characteristic numbers from large data samples. Ideally, these characteristic numbers should be used as foundation to base a decision on which more sophisticated methods can be applied for further investigation. The two most basic as well as most important characteristic numbers are the measure of location and measure of spread of a data set [7]. Ideally, the measure of location tells where many of the data are found, and the measure of spread describes how crowded the data are around the measure of location. In order to visualise a data set often a so-called histogram [7] is used; in its graphical variant a bar chart depicts the amount of data values found for some set of data value classes Brief remarks on relevant statistical concepts The concept of using few characteristic numbers instead of the whole large data set works well when dealing with data sets the visualised histogram of which is bell-shaped, i.e. there is a single region of crowded data values somewhere not too close to the limits of the data values. Unfortunately, experience of many educators in the subject of applied statistics shows that students trust the calculations of statistical software way too much, i.e. they don t check e.g., by looking at histograms - whether the numbers meant to be characteristic for a data set really fulfil this requirement. This is especially dangerous if only the mean is calculated as measure of location, but exactly this happens nearly all the time.

5 5 / 41 A political leader who was aware of that danger, Mr. Franz Josef Strauß who was ministerpresident of the German state Bavaria, has put it this way when asked by amazed journalists about his detailed background knowledge of data on a particular subject: Two guys have lunch in a pub. One guy eats two knuckles of pork, the other drinks four litres of beer. Statistics tell us that on average, each guy had one knuckle of pork and two litres of beer. But in reality, one of them has totally gorged himself on pork knuckle and the other is totally drunk. [The present writer tried to preserve the level of speech when translating from German to English.] Apart from revealing amazing facts about a typical lunch of a person acknowledged as man in Bavaria, this story very clearly points out the danger of not checking automatically computed results: there is no rule at all that the mean of a data set is a characteristic number in the sense that many data are close to the calculated number. For a definition of close, the measure of spread is often used. The following figure illustrates this problem by showing a U-shaped histogram of data restricted to the valued from 1 to 8. There are few data around the mean (dark vertical line near value of 3), and the standard deviation (shaded area up to a value close to 5.5) meaninglessly predicts data outside the range of the data. Fig. 1: Histogram where the concept of the mean fails (annotations in German) Therefore, it was decided to provide students with an application giving them a chance to learn in which cases they should not trust automatically calculated measures of location at all. But because always trusting these numbers is much less harmful than touching a hot plate (in fact, it may even be rewarding due to a smaller amount of work and a much greater pool of sophisticated methods to choose from etc.), we explicitly do not claim we are able to change the everyday behaviour of students towards always looking at histograms. Instead, we try to let them develop an understanding of how most of the dangerous samples are likely to be detected when looking solely at the calculated numbers. For that, we use the fact that in good textbooks as well as lectures on descriptive statistics usually examples of dangerous histograms are shown and it is told to be careful in these cases when dealing with the characteristic numbers calculated from them. But we account for the fact that in reality the task of an applied statistician is just the other way around: the characteristic numbers are given and it is to be decided whether to invest some extra work in checking their reliability. For that, in a first step we try to establish a close connection between graphical representations of histograms

6 6 / 41 and the corresponding characteristic numbers in a student s memory by providing them with a tool to depict different kinds of histograms together with their characteristic numbers over and over again. Relying on some kind of Pawlow s reflex, we then can hope that even in situations when the graphical representation is missing nevertheless the be-careful reflex is triggered when a certain constellation of characteristic numbers is encountered Brief remarks on didactical setting When deciding which learning scenario (see overview in [8], e.g.) seemed most promising, the learning context, i.e. that of students on the move, had to be taken into account. Due to the internal and external evaluation [9] of the first project, an interactive, Java-based [10] learning object (a so-called applet) (see Fig. 1) had been created which can be accessed by any Java-enabled PC browser. The didactical aim of this learning object is to let students experience when and why the statistical concepts mentioned in chap fail and to detect which alarm signals might be there to avoid the failure. The applet lets students manipulate a histogram and observe the influence of their manipulation on the instantly calculated mean (in German Mittelwert ) and standard distribution (in German Standardabweichung ) of the data. Fig. 1 shows a situation in which the statistical concept of describing a data set by few characteristic numbers, e.g. mean and standard deviation, instead of dealing with all the data clearly fails as it here implies even data outside the range of the variable (here one to eight). Within the framework of this project it was decided to try to find an adequate mobile representation of this learning object because firstly, learning about proper application of the statistical concepts involved is crucial, secondly, engaged students might wish to have a ubiquitous tool to analyse data they read in a newspaper or hear in the radio when being on the move, and thirdly no extensive usage of other media or devices is required. Recent findings in the area of game-based learning [11a-b] led to the decision to switch from the simple manipulation procedure of the applet to a game-like setting, mainly in order to capture a students attention in the usually distracting environments found in public transportation, e.g. The didactical setting is mainly based on what Baumgartner [8] calls teaching II and teaching III, i.e. students are meant to construct their knowledge about the suitability of a specific statistical concept for a given data set by themselves. A distant tutor can only guide the students using appropriate means of communication in order to let students experience all the dirty effects encountered in everyday statistics, for example. Such a highly interactive application requires some underlying programming language capable of processing events like user actions. In order to limit the developmental effort to an amount that seemed to fit the project outline, the mobile version of Sun s Java platform [12a-d] was chosen Impact of technology Due to the impact of technology (see chap. 1.3), it had to be decided to use integer numbers as data values and the so-called quartiles as measures of location as well as spread. There are 3 quartiles, which ideally divide a data set sorted by values into 4 parts comprising all the same amount of 25%

7 7 / 41 of the data values. The 1 st quartile is equal to the very data value that is larger than 25% and smaller than 75% of all values. The 2 nd quartile is larger than 50% and smaller than 50% of all values, thus it is called the median of the data set and can be used as a measure of location. Last, the 3 rd quartile is larger than 75% and smaller than 25% of all values. The difference between 3 rd and 1 st quartile (we deal with metric data here) can be obviously used as a measure of spread, it is called the inter-quartile range. The median is subject to the same danger than the mean with respect to the question whether it really is characteristic for a specific data set, and thus can be used as a measure of location instead of the mean in this context without a considerable loss of didactical intentions. Using the quartiles as a measure of spread instead of the standard deviation causes more reservations, because the quartiles provide more information on the data set than the standard deviation: if the histogram of a data set is very asymmetric around the median, the quartiles will show this by different distances between the median and the 1 st and 3 rd quartile, respectively, whereas the standard deviation would not. But though technology considerably restricts our didactical intentions at this point nowadays, we observe that this will be overcome soon. Indeed, nearly all phones now (autumn 05) offered in the stores are shipped with software that would allow using mean and standard deviation. Due to the 2-year mobile subscriber contracts, which allow to get a brand new phone at the end of the contract period nearly for free, used by roughly half of the people in Germany [5], it will take at least another 2 years before these students phones can be assumed to support modern technology. A serious concern is caused by the remaining 50% of people (and therefore students) who use a pay-as-you-go mobile subscriber contract. As in this case there is no chance to get a cheap phone, the average time of phone usage is expected to be much longer than 2 years, leading to a much slower spread of new technologies. 1.3 Technology Basically, three different technologies can be used to provide an interactive application on mobile phones: Microsoft.Net, C++ for the OS (operating system) platform of a particular phone, and J2ME (Java 2 Micro Edition) for some class of mobile devices. Because it was observed that there still exist many areas where mobile phones can t connect to a network, e.g. buildings made of concrete, subways of large cities and trains running through rural areas, a solution had to found that reliably works without access to a network. Therefore, a (naturally) predominantly server based.net solution was dismissed. This decision also takes into account a second recommendation of many students in the preceding project, i.e. they didn t want to spend money on the download of the courseware to a phone using a mobile network connection but preferred to download it to their PC and then transfer it to their phone in an appropriate manner. As a recent study initiated by the German Ministry of Economy [13] showed that in Germany the costs of mobile services are relatively high as compared to all other countries in the EU, it is assumed that this attitude would still apply.

8 8 / Some general remarks on the J2ME platform The diversity of OSs on mobile phones turned out to be larger than the diversity of JVMs (Java Virtual Machines, i.e. built-in software needed to run Java applications on a phone). In general, the J2ME platform [12a-d] is composed of two main parts: the Connected Limited Device Configuration (CLDC) that handles all hardware related aspects, and the Mobile Information Device Profile (MIDP) that handles all interfaces to the real world. Both components now co-exist in two versions, CLDC 1.0 and 1.1 as well as MIDP 1.0 and 2.0. When this project started in late 2003, nearly all new phones supported CLDC 1.0 and MIDP 2.0, whereas only very few ones were announced to support CLDC 1.1 and MIDP 2.0. This was a bit annoying, since the most important improvement of CLDC 1.1 with respect to this project was the invention of a data type dealing with fractional numbers. The following screenshots taken from the documentation of the different J2ME versions clearly show the difference: there are two additional classes Double and Float in the java.lang package in version CLDC 1.1 / MIDP 2.0. Fig. 2: CLDC 1.0 / MIDP 1.0 vs. CLDC 1.1 / MIDP 2.0 Thus, technology had a severe impact on the didactical aims of the software to be developed, as only those calculations could be handled easily that did not lead to results outside the integer numbers. For example, the (arithmetic) mean and the standard deviation of a data set usually are fractional numbers even if the data consist only of integer numbers. Concluding, providing students with a means to achieve a more complex didactical aim, i.e. the possibility to compare the mean to the median and the standard deviation to the quartile range, had unfortunately to be dismissed. J2ME applications, called MIDlets, are developed and tested on a PC before they are deployed to real phones by offering them for download on a web server. They can be transferred to a mobile phone from a PC and thus do not necessarily cause extra download costs (e.g., when a PC connected

9 9 / 41 to the Internet using a flatrate is used). MIDlets ready for deployment comprise two files: a Java Application Descriptor (JAD) providing important plain text information on the core application file which is in Java Archive (JAR) format. The JAD file (see Fig. 3) contains information which can be used by a (mobile) device to analyse whether it supports the standards required by the application or not, and some additional information that can be utilised by the user of a mobile client to obtain further information, as well as entries that may allow for at least some control over deployment. It may contain additional information on that parts of the J2ME framework the usage of which is restricted in some way, too. For example, if the MIDlet provides the possibility to access the Internet and this is accounted for in the JAD file, a user will be provided with this information at the time of download and then be asked whether to download the MIDlet or not. If this is not accounted for in the JAD file, a user will be asked whether she wants to allow the MIDlet to access the Internet at runtime (which will cause an infamous deadlock if the connection is established in the main thread [13]). From a usability point of view, it seems more meaningful to leave this decision to a user at runtime than at download, because only at runtime she will know why the message box with the question pops up (see next figure). Fig. 3: Example of message box asking for permission to connect a MIDlet to the Internet The JAD file is usually created automatically by the IDE (integrated development environment) from information entered into some kind of project file, as can be seen in the following figure. It is important to note that MIDlets can be run on PCs as well; the J2ME environment is available for the PC- OSs Microsoft Windows and Linux [12e].

10 10 / 41 Fig. 4: Selected information provided in the JAD file later on Remarks on the J2ME built-in device emulator There is a J2ME built-in device emulator that can be configured to resemble many of the current mobile devices with respect to screen size and colour depth. This is very important to test the core functionality, and, very important too, the usability of a MIDlet before deployment. Unfortunately, all the adjustments have to be done in a very inconvenient manner, i.e. by changing certain lines of the configuration file describing the properties of the kind of output device chosen. The following figures show this procedure (Fig. 4) and its result (Fig. 5) in case of the so-called default color phone.

11 11 / 41 (a) (b) Fig. 5: Adjusting the screen size of J2ME s emulator from default (a) to that of a real phone (b) As can be seen from Fig. 5, the device emulator provides all keys and other manipulators like a minijoystick (the oval select area) that are found on current phones. Please note the small arrow at the bottom of Fig. 5b; like on real phones it is meant to provide users with a feedback on the fact that in this case - the menu contains more items than are displayed on the screen, and that the invisible entries can be viewed by successively pressing the corresponding down arrow key on the phone. On the one hand, J2ME allows extensive testing of MIDlets in the built-in emulator, but on the other hand, there are many device specific features that can hardly (adjusting the fonts, e.g.) or even not (threading, e.g., because there is no multi-tasking on mobile devices) be modelled by the J2ME emulator. Thus, is seems necessary to download particular emulators obtainable from nearly all major vendors of mobile phones and to use them for testing before MIDlet deployment, too.

12 12 / 41 (a) (b) Fig. 6: Screenshots of the J2ME emulator before (a) and after (b) adjusting the screen size HistoBrick as displayed in device dependant emulators The following screenshots show screenshots of the HistoBrick MIDlet in different emulators. Whereas the Siemens software allows testing nearly all of the real phone s functionality (see chap ), the SonyEricsson software can be best described as graphical user interface only for the J2ME part. Both emulators allow accessing the internet. Though this feature may be used to check whether all hard-coded URLs are correctly entered in the Java code, e.g., there is no guarantee at all that a MIDlet working in all emulators will work on a single phone. This is mainly due to the differences between a phone s and PC s OS with respect to multi-tasking. Googleing through game developer for a on the web shows that threading is a main concern on real phones, as it turned out to be in case of HistoBrick [13].

13 13 / 41 Fig. 7: HistoBrick MIDlet as displayed in selected phone emulators The emulators differ slightly in their usability, i.e. some provide graphic feedback on which key is actually being pressed, and some do not. There have been some severe troubles with emulators and the version of the J2SE SDK required by them. A developer may be required to have several J2SE versions installed simultaneously in order to support different emulators. But despite all the troubles reported on, it is very important to keep in mind that (mobile) learning objects created for the J2ME platform need no extra developmental effort at all when they are to be used in standard PC-based elearning. On real phones, HistoBrick will typically look like it is shown in the following figure [16].

14 14 / 41 Fig. 8: Game screen of HistoBrick as displayed on the Sagem MyX-7 with annotations Networking within J2ME In order to support more complex didactical settings like collaborative learning some means of establishing a connection to the Internet had to be designed within the HistoBrick MIDlet. Following the idea of a client-based user action model, it was decided to set up a kind of problem exchange market. Thus, a specific web service has been created that on the one hand allows to download problems (i.e. game settings) which might have turned out to be too complex for other students or which the tutor might wish to be solved for some didactical reason, and on the other hand, to upload problems in order to get feedback by others. Designing such a service within a MIDlet resolves problems caused by the sandbox model for MIDlets, which in general does not allow them to access the contact database, e.g., but it also creates problems due to the somewhat different manner in which J2ME can access the Internet as compared to the built-in browser of a phone. A crucial question to be answered was whether it seemed meaningful to include the web service to be designed in some kind of learning management system (LMS). Usually, the LMSs used at HEIs like FernUniversität require secure connections to the Internet (HTTPS) in order to transmit all information exchanged between (mobile) client and web server in an encrypted data stream. This means all early phones supporting only MIDP 1.0 are definitely excluded from logging into such LMSs, because device independent support for HTTPS connections has not been introduced until MIDP 2.0, as can be seen from the following figure.

15 15 / 41 Fig. 9: MIDP 1.0 vs. MIDP 2.0 with respect to internet connections As it turned out in early tests (see chap. 3) that - at least the moment it does not make much sense to try to connect phones to an LMS using the built-in browsers, and designing all this functionality in the MIDlet would have been far outside the scope of this project, a simple HTTP connection was implemented. In order not to compromise the web server, the upload functionality had to be dismissed. This is the second severe impact of technology on didactical aims. The problems are caused by the different protocol versions used for data transfer in the wirelined and wireless part of the mobile network. In the usual wire-lined part of the Internet, the TCP/IP (transport c protocol / internet protocol) is used, whereas between mobile clients and the base station - where they are logged into the mobile services provider s network - nowadays WSP/GPRS is used. This requires using a translation device and software called WAP gateway. But not only the protocols differ, originally the browsers of mobile devices were meant to display only documents in WML (wireless mark-up language) format whereas web browsers would only accept documents in HTML format. Moreover, in order to minimise the amount of data transmitted, the WML documents were transmitted in compiled format WMLC. The configuration of a WAP gateway is crucial for the success of a connection attempt of a mobile client, but unfortunately, totally unknown to users and content providers. Even for developers it is a black box of which only the input (documents on a web server or connections initiated by a mobile client, e.g., respectively) and the output (data input streams of a MIDlet on a mobile client or variable content posted by the mobile browser, e.g., respectively) is known.

16 16 / 41 Fig. 10: Scheme of translations performed by WAP gateway What may happen if the WAP gateway decides a bit too freely what to do with content is depicted in the following sequence of pictures. Fig. 11: WAP gateway trouble There is not a simple reason for the erroneous behaviour of the WAP gateway which leads to sending compiled WML data (content-type = application.vnd.wap.wmlc) instead of plain text HTML. Traditionally, mobile service providers came up with two different billing models for WML and HTML content. This led to different so-called APNs (access point name, means a computer) that needed to

17 17 / 41 be specified on the phone, i.e. by entering their IP addresses in some configuration menu entries. On older phones like the Nokia 3650 (see Fig. 10) the built-in browser needs to use the WML APN, whereas J2ME MIDlets need to use the HTML APN. But on some phones their OS, through which all connections are really established, interferes and makes the phone use the WML APN instead. In the example shown in Fig. 10, the WAP gateway then translates the plain text to compiled WML and prevents the MIDlet from successfully establishing an HTTP connection. We did not experience this effect on newer phones which natively support HTTP connections. Fig. 12: Successful establishing an HTTP connection through HTTP APN The different APNs as well as other information are retrieved using our test MIDlet, which posts all relevant information to a server side script if it can establish a connection. The following pieces of information were obtained (among others that are not suitable for publication) for the connections established when taking the screenshot for Figs. 10 and 11, respectively: MIDletPOSTtests.php sent: HTTP_POST_VARS Feldname = DISPisCol ; Wert = true. Feldname = DISPnuCol ; Wert = Feldname = SYSconf ; Wert = CLDC-1.0. Feldname = SYSprof ; Wert = MIDP-1.0. Feldname = SYSplat ; Wert = Nokia3650.

18 18 / 41 Feldname = SYSenco ; Wert = ISO8859_1. Feldname = SYSloca ; Wert = de. Feldname = HTTP_get-text-file-rescode ; Wert = 200. Feldname = HTTP_get-text-file-resmessage ; Wert = Wap_Gateway_Response. Feldname = HTTP_get-text-file-protocol ; Wert = http. Feldname = Header(0) ; Wert = key_is_content-type;value_is_text/plain;charset=usascii. Feldname = Header(1) ; Wert = key_is_server;value_is_apache. Remote Infos REMOTE_ADDR: **IP of host making request gethostbyaddr(remote_addr): wap1-gateway-83.t-mobile.de REMOTE_HOST: wap1-gateway-83.t-mobile.de HTTP_USER_AGENT: Profile/MIDP-1.0 Configuration/CLDC-1.0, to be honest: Schorschis J2ME HTTP_MIDlet UP.Link/ HTTP_ACCEPT: */* HTTP_ACCEPT_CHARSET: UTF-8, * HTTP_ACCEPT_ENCODING: HTTP_ACCEPT_LANGUAGE: HTTP_CONNECTION: close REMOTE_IDENT: REMOTE_USER: AUTH_TYPE: Server Infos SERVER_NAME: mlearning.dvt.fernuni-hagen.de SERVER_PORT: 80 REMOTE_PORT: SERVER_PROTOCOL: HTTP/1.1 SERVER_SOFTWARE: Apache REQUEST_METHOD: POST GATEWAY_INTERFACE: CGI/1.1 HTTP_X_FORWARDED_FOR: Netzwerk Infos resolved to: wap1-gateway-83.t-mobile.de inetnum: netname: D1SERVNET01 descr: Deutsche Telekom Mobilfunk GmbH descr: Standort Bonn country: DE admin-c: BM363 tech-c: HDL23-RIPE status: ASSIGNED PA mnt-by: DETECSM-MNT source: RIPE # Filtered Ping Results: PING ( ) 56(84) bytes of data ping statistics packets transmitted, 0 received, 100% packet loss, time 4000ms Traceroute Results: 1 hsrp-5-0 ( ) ms 2 ar-essen1.g-win.dfn.de ( ) ms 3 cr-essen1-ge4-0.g-win.dfn.de ( ) ms 4 cr-leipzig1-po11-0.g-win.dfn.de ( ) ms ( ) ms 6 do-eb1.do.de.net.dtag.de ( ) ms ( ) ms 8 *

19 19 / 41 There are several things we can learn from this information. The first block describes information on the mobile client. The first line the content of which is different from what is to be expected is the HTTP response message Wert = Wap_Gateway_Response, because in case of a HTTP connection there should be simply an OK. Very interesting, too, is the end of the HTTP_USER_AGENT line, because the information UP.Link/ is added by the phone and describes its built-in web browser. Thus, one might guess that on the Nokia 3650 the HTTP output of J2ME is sent through the built-in WAP (!!) browser. This would explain why the phone is erroneously identified as WAP enabled by the gateway software, leading to the error observed. A value of close for the HTTP connection header usually means that a HTTP 1.0 connection has been established. This can have impact on the authentication procedure used in many open source LMSs, as there frequently some kind of re-direction using HTTP headers is used which has not been invented since HTTP 1.1. In case of the successful connection shown in Fig. 11 the following information is obtained: MIDletPOSTtests.php sent: HTTP_POST_VARS Feldname = DISPisCol ; Wert = true. Feldname = DISPnuCol ; Wert = Feldname = SYSconf ; Wert = CLDC-1.1. Feldname = SYSprof ; Wert = MIDP-2.0. Feldname = SYSplat ; Wert = CX65. Feldname = SYSenco ; Wert = ISO8859_1. Feldname = SYSloca ; Wert = de. Feldname = HTTP_get-text-file-rescode ; Wert = 200. Feldname = HTTP_get-text-file-resmessage ; Wert = OK. Feldname = HTTP_get-text-file-protocol ; Wert = http. Feldname = Header(0) ; Wert = key_is_date;value_is_wed,_28_sep_2005_16:08:29_gmt Feldname = Header(1) ; Wert = key_is_server;value_is_apache. Feldname = Header(2) ; Wert = key_is_lastmodified;value_is_tue,_23_aug_2005_13:27:54_gmt. Feldname = Header(3) ; Wert = key_is_etag;value_is_\"58018-bb-430b245a\". Feldname = Header(4) ; Wert = key_is_accept-ranges;value_is_bytes. Feldname = Header(5) ; Wert = key_is_content-length;value_is_187. Feldname = Header(6) ; Wert = key_is_contenttype;value_is_text/plain;_charset=iso Feldname = Header(7) ; Wert = key_is_connection;value_is_keep-alive. Feldname = Header(8) ; Wert = key_is_keep-alive;value_is_max=20,_timeout=5. Remote Infos REMOTE_ADDR: **IP of host making request gethostbyaddr(remote_addr): tmo customers.d1-online.com REMOTE_HOST: tmo customers.d1-online.com HTTP_USER_AGENT: UNTRUSTED/1.0, Profile/MIDP-1.0 Configuration/CLDC-1.0, to be honest: Schorschis J2ME HTTP_MIDlet HTTP_ACCEPT: HTTP_ACCEPT_CHARSET: HTTP_ACCEPT_ENCODING: HTTP_ACCEPT_LANGUAGE: HTTP_CONNECTION: REMOTE_IDENT: REMOTE_USER: AUTH_TYPE:

20 20 / 41 Server Infos SERVER_NAME: mlearning.dvt.fernuni-hagen.de SERVER_PORT: 80 REMOTE_PORT: SERVER_PROTOCOL: HTTP/1.1 SERVER_SOFTWARE: Apache REQUEST_METHOD: POST GATEWAY_INTERFACE: CGI/1.1 HTTP_X_FORWARDED_FOR: Netzwerk Infos resolved to: tmo customers.d1-online.com inetnum: netname: CUSTOMERS-DE descr: T-Mobile Deutschland GmbH country: DE admin-c: TH12429-RIPE tech-c: MS47198-RIPE tech-c: UN16-RIPE status: ASSIGNED PA remarks: Please send any abuse complaints to: [email protected] mnt-by: MNT-TMD source: RIPE # Filtered Ping Results: PING ( ) 56(84) bytes of data ping statistics packets transmitted, 0 received, 100% packet loss, time 4000ms Traceroute Results: 1 hsrp-5-0 ( ) ms 2 ar-essen1.g-win.dfn.de ( ) ms 3 cr-essen1-ge4-0.g-win.dfn.de ( ) ms 4 cr-leipzig1-po11-0.g-win.dfn.de ( ) ms ( ) ms 6 do-ag1.do.net.dtag.de ( ) ms gw.DO.net.DTAG.DE ( ) ms 8 * Again, there is strangely added information in the HTTP user agent variable: UNTRUSTED/1.0,! But now, this information is obviously added by the JVM as it refers to the fact that this MIDlet is untrusted (not signed). The HTTP response message is OK as expected. Now the HTTP connection header takes a value of Keep-Alive indicating that an HTTP 1.1 connection has been established. And as to be expected under these proper conditions, all networking works well. 2 Evaluation method The primary purpose of this evaluation was to understand the modalities in using mobile phones to support mobile learners. The study was based on the assumption that students using the mobile edutainment application have a basic understanding of the concepts illustrated in the application. In a pilot project like this one, it is unlikely to attract a large audience. Even though a questionnaire was prepared for on-line access by a web browser, no statistically meaningful tests can be expected to work here. Therefore, it was decided to drop all the questions (profession, sex etc.) that would be meaningful only for some more elaborate statistical evaluation procedures. By that too, it

21 21 / 41 was intended to increase the chance that students take the burden to fill in the questionnaire directly after their mobile learning experience using a mobile phone instead of using a PC later on. The questionnaire was designed to gather information on students attitude towards aspects of mobile learning they experienced as well as towards some more general aspects of mobile learning. A bi-directional 5 point Rohrmann scale was used to catch students ratings on given statements. The answer classes were usually labelled 2: I strongly agree, 1: I agree, 0: I m uncertain, -1: I disagree, and -2: I strongly disagree, and listed in this order. A positive bias is thus to be expected [18]-[23], but is magnitude is difficult to forecast. In case it could be expected that a question did not apply to students, an answer class not applicable for me was added to the 5-point scale. Finally, the questionnaire comprised the following questions: F01 F02 F03 F04 F05 F06 F07 F08 F09 F10 F11 F12 F13 F14 F15 F16 F17 F18 F19 F20 F21 F22 F23 F24 m-learning subject mobile device ownership study location equipment easy to use m-learning was fun I'd take further m-learning courses I'd recommend m-learning m-learning increases quality of e-learning learning objectives met by m-learning easy course access student to tutor inter-communication easy convenient inter-student communication navigation in m-learning course easy effective m-learning requires graphic material evaluation / questioning in m-learning effective m-learning increases access to education / training m-learning access costs acceptable m-learning communication costs acceptable learning objectives met by m-learning always-online compared with PC environment pure mobile access acceptable additional mobile access increases e-learning flexibility additional mobile access increases overall e-learning quality additional mobile access increases overall quality of learning outcomes At the end, an open question provides the possibility to add short comments.

22 22 / 41 3 Findings At first, the findings obtained by the developer in many pre-tests related to crucial aspects identified in a previous mobile learning project [] are given, after that the students opinions recorded in this project are reported [] and compared the results of the previous project when meaningful. 3.1 Developing, testing and deploying HistoBrick The HistoBrick MIDlet has been developed using two different software tools both provided for free by their manufacturer Sun, i.e. Sun One Studio 4 ME and WTK (wireless toolkit) 2.2 together with the Eclipse IDE and EclipseME plug-in, both on the MS-Windows XP and Linux platform. The next figure shows the MIDlet as displayed on a Linux PC. Starting a MIDlet in the WTK emulator on a Linux PC wasn t quite as comfortable as on a Windows PC, where all the file registration work is done automatically during installation. After some time of searching the appropriate application we finally identified runmidlet as the correct one (see next figure for path names etc.). Fig. 13: Configuring Linux for automatic launch of the WTK emulator for JAD files

23 23 / 41 After having done all the installation work manually on the command line the system administrator successfully played some HistoBrick games on a Linux PC, as can be seen from the next figure. This picture is mainly presented to provide readers with a means to judge the size of the MIDlet when displayed on a typical 17 monitor. Fig. 14: Playing HistoBrick on a Linux PC Meanwhile, all leading mobile phone manufactures provide tools to test their phones on a PC platform. Some only provide front-end like interfaces handling J2ME applications; others deliver nearly complete simulation software packages. Our tests performed with all this software aimed at checking that the HistoBrick MIDlet works on phones and to try whether it is possible to transfer content to a phone for off-line access. These tests revealed which kind of material suitable for off-line usage on a mobile device. The type of phones FernUniversität dealt with usually does not provide a means to access more complex document formats like ebooks. It was thus only tried to transfer HTML files (sometimes containing images in GIF or PNG format) as well as the HistoBrick JAD and JAR file to a phone. The tests concerning the two phones FernUniversität bought for this project are now reported in some detail. It is assumed that the PC chosen for testing purposes is equipped with a version of Sun Java platform J2SE suitable for the software to be installed, e.g. 1.4.x instead of 5.x. On one PC we experienced a total crash after having specified an unsuitable version; when we tried to remove the software using the standard procedure in MS Windows after that, no software was found

24 24 / 41 by the system. But fortunately, a second successful try during which the suitable 1.4.x version of Java was specified corrected even this very alarming effect Tests concerning the Siemens CX65 mobile phone Two different software packages are needed in order to simulate a Siemens phone on a PC, both of which can be downloaded from the Siemens developer website [] after registration. When trying to install them on a PC not showing a C:\ drive under MS-Win XP, the installation process failed. After looking for support on the web, and discovering that the Siemens people hide their developer forum from search engines, the present writer attended the Siemens forum community, put forward the question and received a problem solving answer within a few hours. It finally turned out that during installation there has to be a C:\ drive. This is problematic for many developers as they frequently use a twin-os configuration of Linux and MS-Windows which usually leads to Linux being installed in C:\ but not being accessible from Windows which starts on D:\, e.g. A simple solution to that problem is configuring a device like a USB stick as C:\ from within MS-Windows and put a stick in during the software installation. Afterwards the stick and drive C:\ isn t needed anymore. Hopefully, this bug will be fixed soon. The error message popping up during installation and the solution (German version of MS-Windows) is depicted in the following figures. Fig. 15: Error when trying to install SMTK 3.0 without drive c:\

25 25 / 41 For a developer, it is convenient to have projects files in one and only one folder (tree) on a PC. Fortunately, the Siemens software allows specifying a directory where to look for the Java binary code by selecting the appropriate context menu entries. The screen size might be chosen to be 100% or 200% by the same procedure as well. Fig. 16: Context menus in SMTK to launch external JAD files Due to the infamous problems of the 65 series with automatically turning the audio level to full volume when shutting down during a connection, for example caused by low battery status, FernUniversität decided to buy a data cable suitable not only for data transfer but also for upgrading the phone software. Using that (serial!!) cable, content may be transferred from the PC to the phone using software that can also be downloaded from the Siemens website []. The transfer was tested using the HTML source version of the mobile learning course on programming concepts as well as the Histo- Brick MIDlet and statistics course, all developed by FernUniversität.

26 26 / 41 Fig. 17: Data transfer from PC to CX65 When trying to view the HTML files using the emulator, it turned out that in this case all the files have to be copied to a location within the emulator s folder tree, in contrast to the convenient access of JAD files. Fig. 18: Screenshots of CX65 emulator demonstrating the effect of the soft-hyphen HTML tag From Fig. 11 it can be concluded that when a language like German is used, due to the frequent very long words it is recommended to make extensive use of the so-called soft-hyphen HTML tag, which is fortunately supported by most phones built-in browser. The relevant source code in the left picture is Betreuervorstellung, in the middle one is Betreuer vorstellung. If this soft-hyphenation would have been done by a software on the web server, it would probably have added a soft-hyphen after each syllabus; then the source code would be Be treu er vor stel lung which is more than twice (44 vs. 19 characters) as long as the original source code. But though it is generally a good idea to keep mobile content as small as possible, the gain in usability will most likely outweigh the extra time and costs for transmitting the extra information. But if mobile devices are to be used by the large majority of people to read text in off-line modus, too, there is urgent need for syllabification support in browsers. Otherwise it may happen that a word is longer than a line of text, and as common HTML browsers - even on the PC platform

27 27 / 41 do not support syllabification, the word break is located totally arbitrarily from a reader s point of view. In this case, the usability tends to zero. But even if the words are shorter than a line is long, it is very inconvenient to read text with only one word in a line, as can be seen from the last picture in figure 11. Summarising, all content based on Java and HTML files can be transferred to the CX65 phone using a data cable. But obviously, the HTML files must not contain any server side scripting code like PHP statements, whereas a basic set of JavaScript statements is interpreted by the browser of the phone in off-line modus Tests concerning the Sagem MyX-7 mobile phone No testing software was found for download on Sagem s website. Even registration failed so that no software for data exchange could be downloaded. Nevertheless, an infrared adaptor was used to connect the Sagem phone to a PC. Fig. 19: Media rejected by Sagem MyX-7

28 28 / 41 Fig. 20: Media accepted by MyX-7 The only media that could be transferred to the Sagem phone through the infrared connection turned out to be GIF pictures (we did not try JPEG). Therefore, this phone is unsuitable for off-line transfer of content Deploying HistoBrick After the MIDlet worked correctly in the so called emulator, it has been offered on a publicly accessible Apache web server for installation. In case of a default installation of the Apache V1.3x web server, the file type JAR is obviously unknown which leads to download failure due to an ASCII format based transfer of a binary file. This problem can be fixed by adding an ASCII file called.htaccess in the directory where a JAR file is located or above in the directory tree and which has to contain at least the following line: AddType application/java-archive jar The MIDlet can be downloaded to phones and PCs as well; the only requirement is a working J2ME environment that can be obtained for a variety of operating systems from Sun s website. When a device accesses a JAD file, its operating systems evaluates the content. If the requirements in the JAD file are fulfilled, it offers the corresponding JAD file for download. This procedure minimises costs in case of mobile access by phones (the HistoBrick JAD has about 400 Bytes, the JAR about Bytes) and prevents unsuitable applications from being installed. 3.2 Questionnaire on different phones It is common sense that exercising and questioning play important roles on the way to deeply understand a matter. Questioning is nowadays usually realised by providing on-line questionnaires, like the evaluation form of this project. The latter shall therefore serve as an example for the problems

29 29 / 41 detected. In the following figures different parts of the questionnaire are displayed using the built-in web browser of a NOKIA 6230i, a SAGEM MyX-7, and a SIEMENS CX65 mobile phone. Unfortunately, the built-in browser of the SONY ERICSSON K700i caused problems and did not display the questionnaire at all but only an error message (in German Gewählte Seite kann nicht angezeigt werden, which in English means Selected page cannot be displayed ) providing no useful information for user or developer action to resolve the problem. Fig. 21: Problems with questionnaire on K700i The problems were tried to be identified and fixed in a broader context when it was tried how to integrate older phones (CLDC 1.0, MIDP 1.0) into the questioning part (see sec ). Unfortunately, we did not have full access to that phone as it is owned by a student who had it de-branded during the evaluation period. The built-in browsers of the Nokia 6230i, the Sagem MyX-7, and the Siemens CX65 displayed the questionnaire, but as can be seen from pictures (Fig. 16) on the following page, there are big differences in how different HTML elements are rendered. But the worst rendering problems occurred in case of the action buttons used to submit the answers to FernUniversität or to erase them. The only browser rendering them in a manner that will cause virtually nobody to fail when wanting to submit the answers is that of the Nokia phone. The browser on the Sagem phone violates a common usability rule that people are used to from PCs, i.e. that the high-contrast button is the active one. But even worse is the Siemens browser, the stylish button rendering of which makes it nearly impossible to perceive which button is active and which is not. And in fact, the only student who tried to submit the answers using the Siemens phone failed and then preferred to redo the questioning on a PC.

30 Fig. 22: Radio buttons and check boxes as displayed by some phones built-in browsers 30 / 41

31 Fig. 23: Button rendering on Nokia 6230i and Sagem MyX-7 phone

32 32 / 41 Fig. 24: Rendering of action buttons by the built-in browser of the Siemens CX65 phone (a) send button selected (b) reset button selected (c) none selected

33 33 / 41 For comparison, now the button rendering by a standard PC browser (Netscape 7.1, MS-Win XP) is shown. It turns out that the usability is considerably increased by harnessing the attribute dependent rendering capabilities of CSS2 (cascaded style sheets). Unfortunately, CSS2 is not available on phones yet. (a) send button selected using keyboard, no use of CSS at all (b) send button selected using keyboard; CSS2 used to render buttons (c) reset button selected using mouse; CSS2 used to render buttons Fig. 25: Button rendering by standard PC browser without (a) and with (b,c) usage of CSS2 3.3 Project home page on different phones Having realised the need to display web pages originally designed for PC access on mobile devices as well, the browser manufactures obviously arrived at different solutions how to accomplish that task. From the following four pictures it is obvious that the diversity of layouts is much larger than one is used to from PC browsers: the page title is displayed once in full length on the screen, once it is abbreviated, once it is displayed as a ticker with moving words, and once only its beginning is displayed. Even the order of elements on different HTML hierarchy levels is different. This means one cannot predict how a complex HTML page will be displayed on a phone and thus has to avoid relying on context effects, e.g. It will also be very difficult to display legally valid registration forms, not only due to the button rendering effect mentioned before, but also due to the small screen it might not be possible to place remarks close to a button as required by jurists in order to claim the user has read it, e.g.

34 34 / 41 Fig. 26: Rendering of the project home page at DVT on different mobile phones 3.4 Students opinions While developing and deploying early versions of HistoBrick, findings and opinions of two former mobile learning students and some pupils were integrated into the development and design process. But it is definitely beyond the scope of the work reported here to evaluate the effect of using Histo- Brick on students knowledge of statistics. As the technical pre-tests revealed that current mobile phones cannot be reliably integrated into a modern LMS and moreover, that assessment appears to be a task unsuitable for mobile students, the focus of the post test evaluation was set on to collect attitudes towards some general as well as project specific statements concerned with mobile learning. For that, a self-administered, web-based questionnaire was used, most parts of which had been developed in a preceding project.

35 35 / 41 At the time of writing, only a very small sample of 10 students has completed the questionnaire after having downloaded and extensively tried out HistoBrick onto their own device or having it tested on a device we provided. We cannot judge here whether pure verbal or pure numerical or combined labelling of the scale points leads to a mentally evenly spaced representation of these points which is theoretically required for numerical calculations like taking the mean of some ratings. Thus, in a first step of exploration, the mean and standard deviation as well as the median and other quartiles are used, the latter ones definitely here being valid measures of location and spread, respectively. When all valid ratings are taken into account [24], the only item with a mean significantly different from zero is pure mobile access acceptable, and it is the worst ranked item with a mean of about The confidence interval of nearly all other items is found to be at least half of the range, which is extraordinarily large. When exploring the reason for that, it turned out that among the 10 students having submitted their answers two extreme response patterns are found, which can be easily identified in the next figure. Fig. 27: Response patterns of all students One student is never uncertain and never disagrees; another one is uncertain only once and otherwise never agrees. We cannot decide here whether these two students express preconceived opinions or whether they became polarised due to the contact with HistoBrick. There is evidence that such extreme attitudes towards a new technology are present in many populations [14].

36 36 / Discussion of item ratings But as it is hard to learn from such non-discriminating statements, the next figure depicts all the items sorted by the mean of the agreement ratings obtained from a reduced sample excluding the two most extreme response patterns. As it is not taken to be granted that the mean is a meaningful measure of location here, the depicted mean of the valid item ratings together with its 95% confidence interval is completed by the median together with the first and third quartile. Fig. 28: Items ranked according to mean in reduced sample (N=8) As can be seen in Fig. 10, ordering the items using the median would only change the ranking within the given error level. The item pure mobile access acceptable is still the only one with a significantly negative mean. But in the reduced sample, there are several items with a significantly positive mean (not significantly different from each other): equipment easy to use, additional mobile access increases the flexibility of e-learning, m-learning increases access to education and training,

37 37 / 41 and navigation in m-learning course was easy. This means students appreciate additional mobile features in elearning, in general, and that they are satisfied with the usability of HistoBrick, in particular. Exploring the other items on a tentative level, it can be stated that students obviously believe the costs for mobile communication as well as data transfer are too high and thus rate them negative, which would support the stated reject of the always-online and pure mobile scenario. There is a large group of items for which the mean is very close to zero and about which most students are indeed uncertain. This group contains all items concerned with quality, learning objectives, effectiveness, and outcomes of mobile learning. The most simple explanation is that most participants in this study did not feel to have enough experience to really state an opinion and therefore have chosen scale points close to 0: uncertain Discussion of comments Though the positively rated items might indicate that we ve learned our lesson, exploring the comments does not support this conclusion. Four of ten participants sent a comment concerned with mobile learning: Well - I even don't like reading long texts on a PC. I need paper - it's better to read from, I can mark words, can add some remarks. things are worse with a screen of some millimetres. So to me this complete idea is crazy. I don't think that a mobile phone could improve the learning experience too complicated menu structures, not much benefit of the game itself, boring, no rewarding experiences I personally do mobile learning quite regularly. I quite often listen to audio books to improve my foreign language skills ( 'Hörkurs'). My motivation is to use the time that I spend in my car. I think that mobile learning with help of mobile phones provides interesting opportunities, but only for particular subjects In my opinion, small scale courses suitable for mobile download onto laptops or PDAs are a happy medium Summarizing, the participant who submitted the first comment seems to be reluctant to concept of mobile learning at all (but is not excluded in Fig. 8!), the second one obviously is used to play compelling games, the third one can only use audio because the hands are needed for operating the car, and the last person prefers PDAs or laptops to mobile phones. Unfortunately, it is hard to translate these comments into recommendations for a more general mobile learning scenario. We do not claim that applications like HistoBrick are able to either change a person s general attitude towards or use of a particular technology. We support that it should be closely examined where mobile learning adds value (from a student s point of view) to existing learning scenarios. Otherwise it will continue to happen that the most expensive learning investments fail (see e.g. [15]) to yield a return. When observing participants playing HistoBrick in various environments it always turned out that the idea of capturing students attention by designing a game-like mobile application worked in

38 38 / 41 reality. Sometimes even shouts like damn (in German Mist ) were heard. But it was not our goal to design a compelling game as there will rarely be a HEI like FernUniversität having the resources to accomplish such a task. And perhaps educators should re-think the idea of communicating that learning has to be fun (as we did, e.g., by asking such a question) and instead report how many boring returns Boris Becker had to exercise on before he became an excellent tennis player. The idea of using audio for mobile learning can indeed be pushed by the current trend of many people to carry an MP3 player always and everywhere, sometimes integrated into their mobile phone. There are significant differences between mobile phones on the one hand and smartphones as well as PDAs on the other hand. Mobile phones usually have small screens, can run only one application at a time and are operated in one hand by pressing keys or pushing a (mini-) joystick, whereas smartphones as well as PDAs (and the convergent device class frequently called MDA, which means a PDA with an integrated telephony functionality) have much bigger (touch-)screens, support multitasking, and are operated using both hands, one for holding the device and the other to hold the stylus needed for the touch-screen. As the latter device class is relatively expensive, it is hardly to be found among students equipment. 4 Conclusions It has been demonstrated that the J2ME platform implemented in modern mobile phones can be utilized to provide students with a highly interactive, constructivist mobile learning scenario. Observing students when playing HistoBrick under real-world conditions proved that a game-like didactical approach is suitable to completely attract a student s attention even in very distracting environments like that found in busses, trams or trains. The most severe restriction of mobile phones is that they do not support multi-tasking. This has to be taken into account at early stages of the design of a mobile learning scenario. There is an urgent need for binding usability standards mobile browsers have to comply with. Unless these standards have been passed and implemented, mobile phones are not suitable for any kind of legally valid user action. Roughly 10% of the total man power needed to finish the project was concerned with designing, developing, and implementing the software. The other 90% was needed to explore the reasons for unexpected failures, to adapt to new standards and software environments, and to support users when they experienced problems. This seems to be typical in case of emerging technologies, but at the present level of convenience only early adopters will develop as well as practise mobile learning using mobile phones. The part of this statement related to students point of view is definitely supported by the results of the questioning, which show that the item pure mobile access acceptable is the only significantly negative one. In these days, mobile services providers begin to offer flatrates. This will probably help to overcome students fear of going bankrupt when accessing the internet from their mobile phones. But saving money is likely not the only reason for students being reluctant participants of mobile

39 39 / 41 learning. Many of them stated in informal conversation during the tests that they make extensive use of SMSs. But SMSs are the most expensive mobile application when the costs per transmitted byte of information are used as indicator. Either students do not sum up the costs for all their SMSs or we educators have to admit that mobile learning is far less tempting than the electronic form of whispering. It was the invention of SMS that enabled people to whisper to distant mates. Another very complex problem that needs further investigation is the marginal utility of adding mobile services to a standard elearning scenario. But perhaps, we should change our point of view: if the world is changing towards ubiquitous and pervasive computing, applications should be designed to run conveniently on handheld devices. At least in case of HistoBrick, none of the students having used this MIDlet on a PC recommended any PC-specific changes. 5 Epilogue Mobile phones seem to be in the focus of advertising copywriters in Germany, as can be concluded without any doubt at all from the screenshot shown beside. It was taken during the HTTP tests and the present writer could hardly believe what he saw on a German (!!) web page. Like the German and English language lie about all over the place in this example, there is the danger that all the different emerging new technologies cover the mobile learner in exactly the same way if educators follow the recommendations of technology evangelists as uncritical as the web designer followed the copywriter. After a few years of technology driven development of mobile learning scenarios, now there is an urgent need for a phase of thinking about learning. And this thinking should take into account that one thing seems to develop on a time scale being about fifty thousand times slower than that of inventing new technologies: i.e. the human brain. We can be pretty sure that humans learned from other humans by watching them or listening to them long before script emerged. And because students of universities have previously been subject to traditional learning during the most important period of development in their lives, we should be very careful when trying to change the learning scenario in that late stage at first. Humans, like other living creatures, seem to be designed to try to minimise the overall effort needed to solve a problem. Because the amount of effort is judged on the background of one s own experience, there might well be a solution to a problem that needs much less effort than the known one on an objective scale if there is any, but what is often neglected in this comparison is the effort

40 40 / 41 need to change one s behaviour towards using this new solution. And obviously, there is no objective scale to measure the subjective amount of change effort. If these considerations are taken into account when designing new (mobile) learning scenarios, the need to publish articles [26] entitled like Will Learning Survive Our Good Intentions? or Thwarted Innovation: What Happened to elearning and Why will hopefully decrease. 6 References [1] Kraft-Dittmar A, Fritsch H, Schuemer R (1997) Materialien zur Exmatrikulation 96: Ergebnisse einer Befragung von Exmatrikulierten zum WS 1996/97, Abschlußbericht. ZIFF, FernUniversität in Hagen, Hagen, Germany, 1997 (in German) (in German) [2] Ericsson LMI, [3] Keegan D (2002) The future of Learning: From elearning to mlearning. ZIFF Papiere 120, FernUniversität in Hagen, Hagen, Germany, ISSN: [4] Ströhlein G, Fritsch H (2003) Test and Evaluation of a Course Designed for Mobile Learning. ZIFF Papiere 120, FernUniversität in Hagen, Hagen, Germany, ISSN: [5] Initiative D21, tns infratest (2004) (N)-Onliner Atlas [6] FernUniversität, Stabsstelle für Qualitätssicherung (2005), priv. comm. [7] Kaye DH and Freedman DA (2000) Reference Guide on Statistics. In: Federal Judicial Center s Reference Manual on Scientific Evidence, 2 nd ed, [8] Baumgartner P (2005) Communication and interaction in learning. In: Proceedings of the elearningconference, pp , [9] Stotz L, Hoppe G, Breitner MH (2004) Interaktives Mobile(M)-Learning auf kleinen Endgeräten wie PDAs und Smartphones. IWI Diskussionsbeiträge #12, Universität Hannover, Hannover (in German) [10] key curriculum press (2004) Java sketchpad. [11a] Prensky M (2000) Digital game-based learning. McGraw-Hill, New York [11b] Prensky M (2003) But the Screen Is Too Small! - No It s Not! [12a] SUN (2000) JSR J2ME Connected, Limited Device Configuration. [12b] SUN (2000) Mobile Information Device Profile (JSR-37).

41 41 / 41 [12c] SUN (2002) JSR Mobile Information Device Profile [12d] SUN (2002) JSR Connected Limited Device Configuration [12e] SUN (2005) [13] TNS Infratest (2005) Monitoring Informationswirtschaft, 8. Faktenbericht. München (in German) [14] Blamire R (2005) The school of tomorrow. In: Proceedings of the elearningconference, pp , [15] Grund S (2005) Multimodality in training and its impact on mental models. In: Pro-ceedings of the elearningconference, pp , [16] Ströhlein G (2004) HistoBrick: utilising J2ME to enable students to use mobile phones for game-based learning on descriptive statistics. In: Attewell J and Savill-Smith C (2005) Mobile learning anytime everywhere, Learning and Skills Development Agency, London, ISBN [17] Ströhlein G (2005) Harnessing Cellular Phones for Statistic Education in Distance Learning. Forschungsberichte des Fachbereichs Elektrotechnik, FernUniversität in Hagen (Ed. B. J. Krämer), Nr 1/2005, ISSN [18] Mummendey HD (1987) Die Fragebogenmethode. Hogrefe, Göttingen (in German) [19] Schwarz N and Sudman S, eds. (1997) Answering Questions. Jossey-Bass, San Francisco [20] Hippler H-J, Schwarz N, and Sudman S, eds. (1987) Social Information Processing and Survey Methodology. Springer, New York [21] Sudman S, Bradburn NM, and Schwarz N (1996) Thinking About Answers. Jossey-Bass, San Francisco [22] Tourangeau R (2004) Survey Research and Social Change. Annu. Rev. Psychol. 55, pp [23] Krosnik JA (1999) Survey Research. Annu. Rev. Psychol. 50, pp [24] Krämer BJ and Ströhlein G (2006). Submitted for publication to: 2nd IEEE International Workshop on PervasivE Learning (PerEL 2006 in Pisa, Italy) [25] Ströhlein G (2006) Mobile learning using mobiles: hype or tripe? Submitted for publication to: E(lectronic)-Learning - Technologiebasiertes Lehren und Lernen (ELTK2006, Passau, Germany) [26] Cited in EDUCAUSE Review, vol. 40, no. 3 (May/June 2005): Annu. Rev. Psychol. is available on-line at: Valuable on-line bibliographies on mobile learning can be found at: MLEARN proceedings (available from NESTA bibliography (available from