evaluation of histobrick

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 here1 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-153111
2 / 41
Table of contents
Abstract: Evaluation of HistoBrick.........................................................................................................1
1
Background.....................................................................................................................................3
1.1
Framework..............................................................................................................................3
1.2
Didactics .................................................................................................................................4
1.2.1
Brief remarks on relevant statistical concepts ................................................................4
1.2.2
Brief remarks on didactical setting .................................................................................6
1.2.3
Impact of technology ......................................................................................................6
1.3
Technology .............................................................................................................................7
1.3.1
Some general remarks on the J2ME platform ................................................................8
1.3.2
Remarks on the J2ME built-in device emulator ...........................................................10
1.3.3
HistoBrick as displayed in device dependant emulators ..............................................12
1.3.4
Networking within J2ME .............................................................................................14
2
Evaluation method ........................................................................................................................20
3
Findings ........................................................................................................................................22
3.1
Developing, testing and deploying HistoBrick.....................................................................22
3.1.1
Tests concerning the Siemens CX65 mobile phone .....................................................24
3.1.2
Tests concerning the Sagem MyX-7 mobile phone......................................................27
3.1.3
Deploying HistoBrick...................................................................................................28
3.2
Questionnaire on different phones........................................................................................28
3.3
Project home page on different phones ................................................................................33
3.4
Students’ opinions ................................................................................................................34
3.4.1
Discussion of item ratings ............................................................................................36
3.4.2
Discussion of comments ...............................................................................................37
4
Conclusions ..................................................................................................................................38
5
Epilogue........................................................................................................................................39
6
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 2.0.......................................................................8
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 / 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 CX65...............................................................................................26
Fig. 18: Screenshots of CX65 emulator demonstrating the effect of the soft-hyphen HTML tag .......26
Fig. 19: Media rejected by Sagem MyX-7 ...........................................................................................27
Fig. 20: Media accepted by MyX-7......................................................................................................28
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 CSS2............33
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).....................................................36
1 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 email 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 / 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.
1.2.1 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 / 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 / 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.
1.2.2 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. 1.2.1 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.
1.2.3 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 / 41
of the data values. The 1st quartile is equal to the very data value that is larger than 25% and smaller
than 75% of all values. The 2nd 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 3rd quartile is
larger than 75% and smaller than 25% of all values. The difference between 3rd and 1st 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 1st and 3rd 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 / 41
1.3.1 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 / 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 PCOSs Microsoft Windows and Linux [12e].
10 / 41
Fig. 4: Selected information provided in the JAD file later on
1.3.2 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 / 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 / 41
(a)
(b)
Fig. 6: Screenshots of the J2ME emulator before (a) and after (b) adjusting the screen size
1.3.3 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.
3.1.1), 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 / 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 / 41
Fig. 8: Game screen of HistoBrick as displayed on the Sagem MyX-7 with annotations
1.3.4 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 / 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 / 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 / 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
Feldname = DISPnuCol ; Wert
Feldname = SYSconf ; Wert =
Feldname = SYSprof ; Wert =
Feldname = SYSplat ; Wert =
= true .
= 4096 .
CLDC-1.0 .
MIDP-1.0 .
Nokia3650 .
18 / 41
Feldname = SYSenco ; Wert = ISO8859_1 .
Feldname = SYSloca ; Wert = de .
Feldname
Feldname
Feldname
Feldname
ascii .
Feldname
=
=
=
=
HTTP_get-text-file-rescode ; Wert = 200 .
HTTP_get-text-file-resmessage ; Wert = Wap_Gateway_Response .
HTTP_get-text-file-protocol ; Wert = http .
Header(0) ; Wert = key_is_content-type;value_is_text/plain;Charset=us-
= Header(1) ; Wert = key_is_server;value_is_Apache .
Remote Infos
193.254.160.83
REMOTE_ADDR: 193.254.160.83 **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/5.1.2.10
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: 42719
SERVER_PROTOCOL: HTTP/1.1
SERVER_SOFTWARE: Apache
REQUEST_METHOD: POST
GATEWAY_INTERFACE: CGI/1.1
HTTP_X_FORWARDED_FOR: 172.24.55.223
Netzwerk Infos
193.254.160.83 resolved to: wap1-gateway-83.t-mobile.de
inetnum: 193.254.160.0 - 193.254.163.255
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 193.254.160.83 (193.254.160.83) 56(84) bytes of data.
--- 193.254.160.83 ping statistics --5 packets transmitted, 0 received, 100% packet loss, time 4000ms
Traceroute Results: 1 hsrp-5-0 (132.176.5.230) 1.243 ms
2 ar-essen1.g-win.dfn.de (188.1.44.1) 2.268 ms
3 cr-essen1-ge4-0.g-win.dfn.de (188.1.86.1) 4.038 ms
4 cr-leipzig1-po11-0.g-win.dfn.de (188.1.18.106) 12.678 ms
5 188.1.50.2 (188.1.50.2) 13.635 ms
6 do-eb1.DO.DE.net.DTAG.DE (62.154.61.106) 17.125 ms
7 62.159.61.218 (62.159.61.218) 18.356 ms
8 *
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/5.1.2.10” 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
Feldname = DISPnuCol ; Wert
Feldname = SYSconf ; Wert =
Feldname = SYSprof ; Wert =
Feldname = SYSplat ; Wert =
Feldname = SYSenco ; Wert =
Feldname = SYSloca ; Wert =
= true .
= 65536 .
CLDC-1.1 .
MIDP-2.0 .
CX65 .
ISO8859_1 .
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-8859-1 .
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
80.187.49.19
REMOTE_ADDR: 80.187.49.19 **IP of host making request
gethostbyaddr(REMOTE_ADDR): tmo-049-19.customers.d1-online.com
REMOTE_HOST: tmo-049-19.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 / 41
Server Infos
SERVER_NAME: mlearning.dvt.fernuni-hagen.de
SERVER_PORT: 80
REMOTE_PORT: 64069
SERVER_PROTOCOL: HTTP/1.1
SERVER_SOFTWARE: Apache
REQUEST_METHOD: POST
GATEWAY_INTERFACE: CGI/1.1
HTTP_X_FORWARDED_FOR: 80.187.49.19
Netzwerk Infos
80.187.49.19 resolved to: tmo-049-19.customers.d1-online.com
inetnum: 80.187.0.0 - 80.187.111.255
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 80.187.49.19 (80.187.49.19) 56(84) bytes of data.
--- 80.187.49.19 ping statistics --5 packets transmitted, 0 received, 100% packet loss, time 4000ms
Traceroute Results: 1 hsrp-5-0 (132.176.5.230) 0.529 ms
2 ar-essen1.g-win.dfn.de (188.1.44.1) 2.447 ms
3 cr-essen1-ge4-0.g-win.dfn.de (188.1.86.1) 2.997 ms
4 cr-leipzig1-po11-0.g-win.dfn.de (188.1.18.106) 12.541 ms
5 188.1.50.2 (188.1.50.2) 13.388 ms
6 do-ag1.DO.net.DTAG.DE (62.154.61.114) 17.621 ms
7 017096-1-1-gw.DO.net.DTAG.DE (62.225.84.178) 18.985 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 / 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 / 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 / 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 / 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.
3.1.1 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 / 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 HistoBrick MIDlet and statistics course, all developed by FernUniversität.
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 / 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.
3.1.2 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 / 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.
3.1.3 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 22
000 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 / 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. 1.3.2). 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 / 41
Fig. 22: Radio buttons and check boxes as displayed by some phones’ built-in browsers
Fig. 23: Button rendering on Nokia 6230i and Sagem MyX-7 phone
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 / 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 / 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 HistoBrick 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 / 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 -1.2. 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 / 41
3.4.1 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 / 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”.
3.4.2 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 / 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 / 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 / 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) http://www.fernuni-hagen.de/ZIFF/exmatr.pdf (in German)
[2] Ericsson LMI, http://learning.ericsson.net/mlearning2/
[3] Keegan D (2002) The future of Learning: From eLearning to mLearning. ZIFF Papiere 120, FernUniversität in Hagen, Hagen, Germany, ISSN: 1435 - 9340
http://www.fernuni-hagen.de/ZIFF/ZP_119.pdf
[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: 1435 - 9340
http://www.fernuni-hagen.de/ZIFF/ZP_120.pdf
[5] Initiative D21, tns infratest (2004) (N)-Onliner Atlas 2004.
http://www.nonliner-atlas.de/pdf/NONLINER-Atlas2004_TNS_Emnid_InitiativeD21.pdf
[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, 2nd ed,
http://www.fjc.gov/public/pdf.nsf/lookup/sciman02.pdf/$file/sciman02.pdf
[8] Baumgartner P (2005) Communication and interaction in learning. In: Proceedings of the elearningconference, pp. 120-130,
http://www.elearningconference.org/images/Proceedings/11%20Developments%20PS2.pdf
[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.
http://www.keypress.com/sketchpad/javasketchpad/about.php
[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!
http://www.marcprensky.com/writing/Prensky%20-%20But%20the%20screen%20is%20too%20small.pdf
[12a] SUN (2000) JSR-000030 J2ME Connected, Limited Device Configuration.
http://jcp.org/aboutJava/communityprocess/final/jsr030/index.html
[12b] SUN (2000) Mobile Information Device Profile (JSR-37).
http://jcp.org/aboutJava/communityprocess/final/jsr037/index.html
41 / 41
[12c] SUN (2002) JSR-000118 Mobile Information Device Profile 2.0.
http://jcp.org/aboutJava/communityprocess/final/jsr118/index.html
[12d] SUN (2002) JSR-000139 Connected Limited Device Configuration
http://jcp.org/aboutJava/communityprocess/review/jsr139/index.html
[12e] SUN (2005) http://java.sun.com/products/sjwtoolkit/download-2_2.html
[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. 25-31,
http://www.elearningconference.org/images/Proceedings/05%20Stocktaking%20PS1.pdf
[15] Grund S (2005) Multimodality in training and its impact on mental models. In: Pro-ceedings of the
elearningconference, pp. 137-141,
http://www.elearningconference.org/images/Proceedings/11%20Developments%20PS2.pdf
[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 1–84572–344–9
[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 0945-0130
[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. 775-801
[23] Krosnik JA (1999) Survey Research. Annu. Rev. Psychol. 50, pp. 537-567
[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): 40–53
Annu. Rev. Psychol. is available on-line at: http://psych.annualreviews.org
Valuable on-line bibliographies on mobile learning can be found at:
MLEARN proceedings 2003 + 2004 (available from http://www.lsda.org.uk)
NESTA bibliography (available from http://www.nestafuturelab.org)