Image Gallery Application for M-learning Systems

ubiquitousstrumpetΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

159 εμφανίσεις

Honours Project Report

 
 
Image G
allery A
pplication for
M
-
learning Systems

 
George Ng'ethe

Supervised by Professor Sonia Berman

Marks breakdown

Category

Min

Max

Chosen

1

Requirements Analysis and Design

0

20

20

2

Theoretical Analysis

0

25

0

3

Experiment

Design and Execution

0

20

5

4

System Development and Implementation

0

15

15

5

Results, Findings and Conclusion

10

20

10

6

Aim Formulation and Background Work

10

15

10

7

Quality of Report Writing and Presentation

10

10

8

Adherence to Project Proposal
and Quality of Deliverables

10

10

9

Overall General Project Evaluation

0

10

0

Total Marks

80

80


Department of Computer Science

University of Cape Town


2012

 
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

ii
 
Abstract
 
Mobile technology
has advanced

rapidly

to support desktop like p
erformance on mobile devices such
as
smartphones.
In addition, the technology has provided rich user experiences with mobile
multimedia such as pictures
.
At the same

time, learning requirements have

moved from more
conventional means to a more ubiquitous a
pproach facilitated by mobile phones
called mobile learning
(m
-
learning).
M
-
learning can make use of mobile phone capabilities such as the camera to capture
learning material.
This introduces a problem how to manage
image content

for m
-
learning
application
s.

An

iterative U
ser
-
Centred design approach

was

used

to develop an image gallery for m
-
learning application
s
.
User requirements were first determined then

followed by iterations of

a de
sign,
implementation and e
valuation of

prototype
s
.

The final system te
sted the functionality of the whole
system

and it was evaluated by end
-
users who completed a set of tasks. The results obtained suggested
that the investigation’s goal had been met. Suggestions for future work concluded the report.


Keywords

M
-
learning, us
er
-
centred design,
image gallery

 
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

iii
 
Acknowledgements
 
Firstly I would like to thank my project supervisor, Professor Sonia Berman for all her feedback, help
and support

during the course of this project.

Thank you for puttin
g up with the late meetings and th
e
abrupt walk
-
ins to your office.

Next, I would like to thank Samsung South Africa for providing the test phones that were used in the
project. I hope I can get more test phones for future projects.

I would

also

like to thank my group members, Tatenda
Shumba, Donovan Thompson

and Sascha
Watermeyer. Without the constant arguments and pushing each other, we would have not got to this
point. I wish
them

the best with
their

future endeavours.

Additionally I would like to thank my housemates

for keeping the
noise down in the house during this
long period of
this project
.

I would also like to thank my parents for the constant support through this long and tiresome ye
ar.
Their words of advice gave me home even when swamped with a lot of work.

Finally I would l
ike God for without him,
getting through this project would have been a difficult task.

 
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

iv
 
Table of Contents

 
ABSTRACT
 
................................
................................
................................
................................
......................
 
II
 
ACKNOWLEDGEMENTS
 
................................
................................
................................
.........................
 
III
 
TABLE OF CONTENTS
 
................................
................................
................................
..............................
 
IV
 
TABLE OF FIGURES
 
................................
................................
................................
................................
...
 
VI
 
1.
 
INTRODUCT
ION
 
................................
................................
................................
................................
..
 
1
 
1.1.
 
P
ROBLEM
O
UTLINE
 
................................
................................
................................
................................
..........
 
1
 
1.2.
 
P
ROPOSED
S
OLUTION AND
D
IVISION OF
W
ORK
 
................................
................................
.....................
 
1
 
1.3.
 
E
THICAL
C
ONSIDERATION
 
................................
................................
................................
.............................
 
2
 
1.
4.
 
R
EPORT
O
UTLINE
 
................................
................................
................................
................................
.............
 
2
 
2.
 
BACKGROUND  AND  MOTIV
ATION
 
................................
................................
................................
..
 
3
 
2.1.
 
I
NTRODUCTION
 
................................
................................
................................
................................
....................
 
3
 
2.2.
 
C
URRENT
 
M
OBILE  
T
ECHNOLOGY  
L
ANDSCAPE
 
................................
................................
..............................
 
3
 
2.2.1.
 
Development  alternatives
 
................................
................................
................................
....................
 
5
 
2.3.
 
C
ROSS
-­‐
PLATFORM  MOBILE  DEVE
LOPMENT
 
................................
................................
................................
....
 
6
 
2.3.1.
 
Phonegap
 
................................
................................
................................
................................
.....................
 
7
 
2.4.
 
C
HOICE  FOR  
M
-­‐
LEARNING  DEVELOPMENT
 
................................
................................
................................
.....
 
7
 
2.5.
 
I
MAGE  MANAGEMENT
 
................................
................................
................................
................................
.........
 
8
 
2.6.
 
S
UMMARY
 
................................
................................
................................
................................
.............................
 
8
 
3.
 
REQUIREMENTS  
ANALYSIS  CHAPTER
 
................................
................................
...........................
 
9
 
3.1.
 
I
NTRODUCTION
 
................................
................................
................................
................................
....................
 
9
 
3.2.
 
U
NDERSTANDING  THE  
U
SERS  AND  THEIR  
N
EEDS
 
................................
................................
.........................
 
9
 
3.2.1.
 
Student  Interviews
 
................................
................................
................................
................................
...
 
9
 
3.2.2.
 
Use  Cases
 
................................
................................
................................
................................
....................
 
10
 
3.3.
 
P
ROTOTYPES
 
................................
................................
................................
................................
.....................
 
12
 
3.4.
 
E
VALUAT
IONS
 
................................
................................
................................
................................
...................
 
12
 
3.5.
 
S
UMMARY
 
................................
................................
................................
................................
..........................
 
13
 
4.
 
DESIGN  CHAPTER
 
................................
................................
................................
...............................
 
14
 
4.1.
 
I
NTRO
DUCTION
 
................................
................................
................................
................................
.................
 
14
 
4.2.
 
L
OW  
F
IDELITY  
P
APER  
P
ROTOTYPE
 
................................
................................
................................
..............
 
14
 
4.2.1.
 
Structure  and  Design  of  Evaluation
 
................................
................................
...............................
 
15
 
4.2.2.
 
Task  Outcomes
 
................................
................................
................................
................................
........
 
16
 
4.2.3.
 
F
indings
 
................................
................................
................................
................................
......................
 
19
 
4.2.4.
 
Summary
 
................................
................................
................................
................................
....................
 
19
 
4.3.
 
H
IGH  
F
IDELITY  
P
ROTOTYPE
 
................................
................................
................................
...........................
 
19
 
4.3.1.
 
First  Iteration:  Vertical  Prototype  (feasibility  demonstrat
ion)
 
................................
.........
 
19
 
4.3.2.
 
Second  Iteration:  Horizontal  Prototype
 
................................
................................
.......................
 
21
 
4.3.3.
 
Summary
 
................................
................................
................................
................................
....................
 
25
 
5.
 
IMPLEMENTATION  CHAPT
ER
 
................................
................................
................................
........
 
27
 
5.
1.
 
I
NTRODUCTION
 
................................
................................
................................
................................
.................
 
27
 
5.2.
 
P
LATFORM
,
 
D
EVELOPMENT  
L
ANGUAGE  
&
 
API
 
................................
................................
..........................
 
27
 
5.2.1.
 
HTML5
 
................................
................................
................................
................................
........................
 
27
 
5.2.2.
 
JQuery  Mo
bile
 
................................
................................
................................
................................
...........
 
27
 
5.2.3.
 
Sencha  Touch  2
 
................................
................................
................................
................................
.......
 
27
 
5.2.4.
 
Platform  &  IDE
 
................................
................................
................................
................................
........
 
28
 
5.3.
 
T
HE  
S
YSTEM  
M
ODEL
-­‐
V
IEW
-­‐
C
ONTROLLER  
A
RCHITECTURE
 
................................
................................
....
 
28
 
5.3.1.
 
Models
 
................................
................................
................................
................................
.........................
 
29
 
5.3.2.
 
Stores
 
................................
................................
................................
................................
...........................
 
29
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

v
 
5.3.3.
 
Views
 
................................
................................
................................
................................
............................
 
30
 
5.3.4.
 
Controllers
 
................................
................................
................................
................................
.................
 
30
 
5.4.
 
D
ATA  
F
LOW  AND  
C
ONTROL  
S
IGNALS
 
................................
................................
................................
...........
 
30
 
5.5.
 
D
ATA  
F
ORMAT
 
................................
................................
................................
................................
..................
 
32
 
5.6.
 
D
EVELOP
MENT  AND  
C
HANGES
 
................................
................................
................................
......................
 
32
 
5.6.1.
 
Connection  Timeouts  utilized
 
................................
................................
................................
...........
 
32
 
5.6.2.
 
Ordering  of  image  thumbnails
 
................................
................................
................................
.........
 
32
 
5.6.3.
 
Image  slideshow
 
................................
................................
................................
................................
.....
 
32
 
6.
 
EVA
LUATION  AND  EXPECTED
 
OUTCOMES
 
................................
................................
.................
 
33
 
6.1.
 
I
NTRODUCTION
 
................................
................................
................................
................................
.................
 
33
 
6.2.
 
E
VALUATION  METHOD
 
................................
................................
................................
................................
....
 
33
 
6.2.1.
 
User  Selection
 
................................
................................
................................
................................
..........
 
33
 
6.2.2.
 
Structure  and  Design  of  Evaluation
 
................................
................................
...............................
 
34
 
6.2.3.
 
Tasks
 
................................
................................
................................
................................
............................
 
34
 
6.3.
 
F
INDINGS  AND  
R
ESULTS
 
................................
................................
................................
................................
.
 
35
 
6.
3.1.
 
Task  outcomes
 
................................
................................
................................
................................
.........
 
35
 
6.3.2.
 
User  feedback
 
................................
................................
................................
................................
...........
 
36
 
6.3.3.
 
P
roblems  identified  with  the  application
 
................................
................................
....................
 
37
 
6.3.4.
 
Problems  that  are  beyond  the  system
 
................................
................................
...........................
 
37
 
6.3.5.
 
Questionnaire  feedback
 
................................
................................
................................
.......................
 
37
 
6.4.
 
S
UMMARY
 
................................
................................
................................
................................
..........................
 
38
 
7.
 
CONCLUSIONS  A
ND  FUTURE  WORK
 
................................
................................
.............................
 
39
 
8.
 
REFERENCES
 
................................
................................
................................
................................
.....
 
41
 
APPENDIX  A:  STUDENT  
INTERVIEW  QUESTIONS
 
................................
................................
.............
 
44
 
APPENDIX  B:  LOW  FIDE
LITY  PAPER  PROTOTYPE
 
SCREEN  SKETCH
ES
 
................................
......
 
45
 
APPENDIX  C:  DESCRIPT
ION  OF  LOW  FIDELITY  
PAPER
-­‐
BASED  PROTOTYPE  EVAL
UATION
 
47
 
APPENDIX  D:  FINAL  EV
ALUATION  TASK  LIST  A
ND  INTERVIEW  QUESTIO
NS
 
..........................
 
48
 
APPENDIX  E:  USABILIT
Y  USE  QUESTIONNAIRE  
RESULTS
 
................................
..............................
 
51
 
APPENDIX  F:  USABILIT
Y  USE  QUESTIONNAIRE
 
................................
................................
.................
 
52
 
 
 
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

vi
 
Figures
 
 
F
IGURE  
1:
   
A
 
SAMPLE  OF  THE  MOBILE
 
PLATFORMS  AND  THEIR  
VARIOUS  PROGRAMMING  
LANGUAGES  AND  DEVICE
S
.
 
.................
 
4
 
F
IGURE  
2:
 
T
HE  SPECTRUM  OF  MOBIL
E  APPLICATIONS
 
................................
................................
................................
...........................
 
5
 
F
IGURE  
3:
 
A
 
SUMMARY  OF  THE  SUPPO
RTED  PLATFORMS  AND  T
HE  SUPPORTED  FEATURE
S  USING  
P
HONEGAP
.
 
T
AKEN  FROM  
P
HONEGAP  WEBSITE
.
 
(V
ERSION  REVIEWED  
2.1.0)
 
................................
................................
................................
....................
 
7
 
F
IGURE  
4:
 
U
SE  
C
ASE  
D
IAGRAM  SHOWING  THE  I
DENTIFIED  USE  CASE  O
F  THE  PROPOSED  SYSTE
M
.
 
................................
..............
 
11
 
F
IGURE  
5:
 
S
KETCHES  OF  THE  LOW  F
IDELITY  PAPER  PROTOT
YPE
 
................................
................................
................................
.......
 
14
 
F
IGURE  
6:
 
T
HUMBNAIL  BROWSING  ON
 
A  
HTC
 
S
ENSATION  SMARTPHONE
 
................................
................................
........................
 
15
 
F
IGURE  
7:
 
P
APER  
P
ROTOTYPE  
G
ALLERY  
I
NTERFACE
 
................................
................................
................................
...........................
 
16
 
F
IGURE  
8:
 
P
APER  
P
ROTOTYPE  
C
AMERA  AND  
U
PLOADING  
I
NTERFACES
 
................................
................................
...........................
 
17
 
F
IGURE  
9:
 
P
APER  
P
ROTOTYPE  
U
PDATE  
G
ALLERY  
I
NTERFACE
 
................................
................................
................................
...........
 
18
 
F
IGURE  
10:
 
P
APER  
P
ROTOTYPE  
F
ULL  
S
IZE  
I
MAGE  
I
NTERFACE
 
................................
................................
................................
..........
 
18
 
F
IGURE  
11:
 
S
CREEN  SHOTS  OF  THE  V
ERTICAL  PROTOTYPE  IN
TERFACE
S
 
................................
................................
..........................
 
21
 
F
IGURE  
12:
 
S
CREENSHOTS  OF  THE  HI
GH  FIDELITY  HORIZONT
AL  PROTOTYPE  WITH  TH
E  IMPLEMENTED  DESIGN
 
CHANGES
 
....
 
23
 
F
IGURE  
13:
 
S
CREENSHOT  OF  APPLICA
TION  SHOWING  SYSTEM  
VISIBILITY
 
................................
................................
.......................
 
24
 
F
IGURE  
14:
 
S
CREENSHOT  OF  APPLICA
TION  SHOWING  USER  CO
NTR
OL  AND  FREEDOM
.
 
T
HE  CANCEL  BUTTON  ALL
OWS  THE  
USER  TO  CANCEL  THE  A
CTION
.
 
................................
................................
................................
................................
......................
 
24
 
F
IGURE  
15:
 
S
YSTEM  
A
RCHITECTURE  FOR  THE  
IMAGE  GALLERY
 
................................
................................
................................
.........
 
29
 
F
IGURE  
16:
 
D
ATA  AND  
C
ONTROL  SIGNAL  FLOW
 
................................
................................
................................
................................
...
 
31
 
F
IGURE  
17:
 
A
 
GRAPH  SHOWING  THE  CO
MPLETION  RATE  FOR  EA
CH
 
TASK  
(8
 
TASKS  ATTEMPTED  BY  
8
 
USERS
)
 
.........................
 
35
 
F
IGURE  
18:
 
P
ICTURES  OF  LOW  FIDEL
ITY  PROTOTYPE  SKETCH
ES    USED  IN  THE  EVAL
UATION
 
................................
.......................
 
46
 
 
 
Tables
 
 
T
ABLE  
1:
 
U
SABILITY  QUESTIONNAI
RE  RESULTS
 
................................
................................
................................
................................
....
 
51
 
T
ABLE  
2:
 
USE
 
QUESTIONNAIRE  USED  F
OR  THE  FINAL  EVALUAT
ION
 
................................
................................
................................
..
 
52
 
 
 
1
 
 
1.

Introduction
 
 
Mobile hardware
technology has advanced rapidly. The technology has put in the pockets of users
computing power and memory that is far greater than the computers that were made in the ten years
ago. This project aims to create a
n image
gallery

for

m
-
learning applications.

Using

the University of
Cape Town’s learning management system, Vula,

as a case study a mobile application

will be
developed
,

optimised for mobile phones running on Google’s Android operating system. In addition
the project aims to exploit features

such a
s the camera

available on mobile devices that will aid

students in their use of Vula.

Vula is accessible through on the Internet from any location using an
Internet browser but most access to Vula is done in computer laboratories on university campuses.
Vu
la services are available to registered students and staff.

1.1.

Problem  Outline
 
UCT’s Learning Management System, known as Vula, is an implementation of SAKAI
[13]
.
Learning
Management Systems (LMS) have become central to education at universities
. They provide a means
for effective distribution of academic materials, feedback and administrative informati
on.
Mobile
technology has advanced, introducing new ways to interact with and display content

facilitating
M
-
learning and

rendering SAKAI’s mobile interface out of date.

According to a survey conducted at
UCT

by the Centre for Educational Technology (CET)
,

98% of students own a cell phone, of which
85% are smartphones

[29]
.
This survey provides an opportunity to explore the use of smartphone
features
to enhance m
-
learning.


This project forms part of an investigation into

the redesign
and extension
of the mobile interface of
Vula,
with
improved feedback facilities and a
n

image gallery to manage
user
-
generated

content.
The
application aims to improve ac
cess to Vula, providing students
with their information needs,

provide
comprehensive academic feedback

and encourage
M
-
learning
.


1.2.

Proposed  Solution  and  Division  of  Work
 
The project team proposes to develop a mobile application that will assist students or
staff

to
access
Vula.
This is approached by User Centred design process to ensure potential users are involve
d

in the
research, design and testing process of the application.

The application is geared to improve access to
information on Vula as well as ele
vating the user experience of Vula on mobile. The workload is
divided into four components:



Redesign of the current Vula mobile interface



Backend support for web services provided by SAKAI



Incorporation of a

mobile

image gallery
tool
.



The redesign of feedb
ack functionalities within Vula

This report is concerned with the incorpora
tion of a mobile multimedia

management

system

in the
form of an image gallery,

to establish if potential use
rs can use it to manage mobile media, in this
case, pictures,

that are related to their studies.

The system should allow the user to take pictures

using
the phone camera or retrieve an image from the phone gallery and upload the picture to a server for
storage. The motivation for this system

is to

organize and archi
ve
pictures of academic material in one
location and provide access to the pictures for mobile viewing as well as

viewing

on a desktop
browser. Having this system integrate with Vula provides a means to enhan
ce m
-
learning on mob
ile
devices
.

Department  of  Computer  Science
 
 
VulaMobi
 
 

2
 
1.3.

Ethical  Conside
ration
 
User testing

had to be

conducted in this investigation
. Ethical Clearance was obtained from the
Science Faculty Research Ethics at the University of Cape Town to carry out user experiments.

With regard to confidentiality and legal issues in the pro
ject, all participants were required to complete
consent forms before participating in the experiment. Confidentiality and privacy was maintained by
collecting experiment data in a manner that does not reveal the identity of the experiment participant.
All

participants of the experiment
were informed that their data
would

not be used or shared without
their consent.

1.4.

Report  Outline
 

The next chapter
, c
hapter 2,

it

outline
s

the background
and motivation

that was completed in relation
to the research of this p
roject, motivating the need for the proposed system.

Chapter 3
, Requirements
analysis,

looks at the user requirements, how they were obtained
and the possible use cas
es for the
proposed system
. C
hapter 4
, Design chapter,

explains in detail the

design

s
teps and procedures taken
in
designing the prototype iterations
, the
design motivations

and their evaluations
. Chapter 5

presents
the implementation of the

final system

and

c
hapter 6

examines the evaluations and findings of the
final system. Chapter 7

conc
ludes with the exploration of opportunities of the application being
adopted

for use in the university, concluding remarks and future work.

Chapter 8 is the references and
the appendices are found at the end of the document
.

 
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

3
 
2.

Background  and  Motivation
 
2.1.

Int
roduction
 
In recent years, mobile technology drivers have changed significantly. Feature phones used to direct
the evolution of mobile devices. Now high
-
performance mobile devices such as smart phones
drive
technology, due to their almost desktop
-
like proc
essing capability and multimedia rich content
.

The
multimedia rich content produced, stored and viewed on smart phones has led to the proliferation of
numerous uses of the multimedia content dubbed mobile multimedia. The latter point is stressed in the
con
text of mobile devices in mobile learning (M
-
learning).

Multimedia content is described a
s items such as images, video and

audio

[35]
.

The mobile aspect of
the multimedia is the content created on or for the mobile de
v
ice by users to provide access to the
content anywhere and at any time.

With the increasing number of mobile devices,
device users are
cr
eating more mobile multimedia content

and management of this content is key due to the limited
amount of memory on the devices

[10]
.

M
-
learning stated as mobile learning is described as learning independent of time, place and facilitate
by mobile devices
[17]
.

Most m
-
learning end
-
user involves a mobile phone (smart or feature phone), a
tablet PC, a personal digital assistant (P
DA) or a portable media player such as (Apple iPod). The
applications are supported by latest wireless communication infrastructure

such as 3G and Wi
-
Fi
communication as well as some of the devices has Location Based Services (LBS)


using Geographic
Infor
mation System (GIS)
[36]
.

M
-
learning has been identified to have the following characteristics
[17]



Ubiquitous: Ability to access the content irrespective of the time and place.



Bite
-
sized: The content must be short in duration as it is used in environment where the user
might be easily distracted.



On
demand: Ability to provide the content to the learner at the point of need.



Can be collaborative: M
-
learning should take advantage of mobile communication (e.g.
mobile phones, Wi
-
Fi enabled tablet PCs and PDAs) to promote collaborative learning. The
collab
oration can be achieved through the use of
SMS, email or chat.

In order to facilitate
M
-
learning,
M
-
learning providers want apps to deliver consistent user experience
and behave

similarly across different devices and platforms
[19]
. This sounds simple in theory but it is
highly complex due to a range of factors. In the forefront of these facto
rs is the highly fragmented
mobile technology landscape. This is closely followed by rapidly evolving standards, limitations
imposed by the mobile device itself (screen size, input methods, display capabilities, etc.) and also
constraints of the mobile net
work such as high latency and low bandwidth

[19]
.

The following sections will look at li
terature on the current mobile technology landscape,
cross
-
platform

application development for M
-
learning and lastly study requirements for content
management fo
r m
-
learning applications focus
ing particularly on mobile photoware
.



2.2.

Current  Mobile  Technolo
gy  L
andscape
 
With the recent boom of smartphone market growth, mobile application development is quickly
becoming an area that can no longer be ignored
[8]
.

According to the International Data Corporation,
smartphones outsold PCs for the first time in the fourth quarter of 2010
[27]
.

Bases on

their
calculations, the
ir

prediction is that the expansion rate will continue for
the next few years
[38]
.

Both
developers and their target users have many choices in cellular devices and mobile operat
ing systems
(OS
s), which means a mobile strategy must reflect multiple perspectives
[8]
.

Department  of  Computer  Science
 
 
VulaMobi
 
 

4
 
While a
ttempting to provide a rich and satisfying user experience and broadening the reach to many
u
sers has encountered obstacles along the

way. Figure 1 below shows why
mobile application
development can be intimidating. The mo
bile market has numerous available

devices that have split
the market among several mobile platforms with the majority belonging to Android,
Apple iOS, RIM
(Blackberry) and Windows 7
[8]
.


Figure  
1
:    A  sample  of  the  mobile  platforms  and  their  various  programming  langua
ges  and  devices
.
 
From Figure 1 above
, it is clearly seen that the numerous devices (only a
sample) and the
programming languages of each platform. Because each platform is different, developing a native
application generally means having to learn a new development language for each platform. The
programming language and software development kit
are specific to a particular platform
[8]
.

For example,
applications developed for
Android

use

Java

development language and in

the Eclipse
development environment.

To develop the same application for Apple’s iOS, platform for iPad,
iPhone and iPod requires the developer to switch to Xcode, a specific integrated development
environment (IDE)

and program the application in Objective
-
C.
The same applies to the other mobile
platforms.

Having to learn multiple languages
, software development kits, IDEs and managing several
code bases translates to increase in development time

and costs
[8]
. Managing several code bases
might increase the chances of errors and the post
-
production releases of
updates are delayed to
accommodate all the platforms.

Fortunately
, new technologies are changing this picture.

Despite native application
s

still having
a
larger dominance, recent innovations in web technologies are offering alternative means for
developing

applications across platforms using a single code base
[8]
.

Although web
-
based
applications off
er uniformity
a
cross the different mobile platforms, it lies at the opposite end of the
spectrum leaving a gap

in the middle.

To bridge the gap, a hybrid approach that seeks used to narrow
the gap between native and web
-
based applications
[8]
.

Department  of  Computer  Science
 
 
VulaMobi
 
 

5
 


Figure  
2
:  The  spectrum  of  mobile  applications
 
Figure 2 shows the
gap

between native app
lications and web
-
based applications. In the middle of them
sits the hybrid applications.

Hybrid approaches make it much easier to break into the mobile
application universe which was to begin with difficult
[8]
. In the next section development alternatives
for mobile application wil
l be discusses focussing on web
-
based and cross
platform alternatives.

2.2.1.

Development  alternatives
 
Alternative development technologies are web
-
based, use proprietary middleware a
nd clients, or are a
hybrid of W
ebkit and native applications
[8]
. Usually, a project

s requirements determine which
alternative is best suited
. A hybrid approach has the benefits of both web
-
based and native
applicat
ions pa
rticularly the retail options of native applications.

Web
-
based

These applications are written usi
ng web technologies

Hypertext Markup Language, Version 5
(HTML

5)

[18]
, Casca
ding Style Sheets (CSS)

[7]

and JavaScript

[20]

to create mobile websites that
have the look and feel
of native applications
[8]
.

This was made p
ossible by smartphones and the
W
ebkit browsers that t
hey contain make such applications possible.

A web
-
based application uses

a JavaScript framework

like JQTouch
[1]
, JQuery Mobile

[11]

or
Sencha

Touch

[3]

for the mobile user interface
.

These frameworks are solely for mobile development
and accommodate touch
-
based devices and use a website to deliver a m
obile user experience complete
with animations
[8]
. In addition, offline capabilities and limite
d access to device features

are available
in some cases.

Web
-
based applications are essentially multiplatform since viewing only requires a browser
emphasizing convenience being advantageous. However, on the down side its product limitations

make it
not a
candidate for other retail avenues such as an app store.


Proprietary middleware and clients

In this alternative, application development is based on prebuilt services, which lets developers create
mobile applications through a web interface by selecting p
rebuilt modules. Technically, there is no
code written. Modules categories are varied examples, audio, video, RSS feeds and photo galleries.
Each module has a different layout and functionality is built into the module. Using a web
-
based form,
a user selec
ts modules, customises them and once the application is complete, and the service builds a
native application that the developer can submit to an application store
[8]
.

native  
web-­‐based  
Department  of  Computer  Science
 
 
VulaMobi
 
 

6
 
The advantage of this approach is the ease of creating native applications that look good and have a
decent performance. The disadvantage is that functionality and design are limited
to

what’s offered in
the modules
and the prebuilt services come at a cost

[8]
.

Hybrid Webkit and

native

Hybrid soluti
ons are applications that use web technologies in place of programming languages such
as Java
[8]
. Hybrid applications are web
-
based applications built into native applications. Hence they
possess the best of both worlds (native and web
-
based).

Most hybrid solutions use Platforms such as
Phonegap or Titanium to wrap HTML, CSS and

JavaScript code to make device features such as
camera, contacts and storage

are made

available to the application through JavaScript application
programming interface (API).

Using this approach gives the developer much more flexibility and control of the

application. A single
code base is used to develop a mult
iplatform application
while still offering performance and
availability
that

rival
s

native application
s
.

With a brief explanation into development alternatives for mobile application the next
section focuses
on cross
-
platform or multiplatform mobile development particularly on hybrid solutions

for M
-
learning
.

2.3.

Cross
-­‐
platform  mobile  development
 
With the proliferation and evolution of tools and frameworks in recent years, cross
-
platform
applicatio
ns

are within reach of being achieved without compromise on quality and user experience
[19]
.

The popular approach to cross
-
platform mobile applications is to build the app
lication

as a mobile web
application that will run on the mobile browser. This involves using standard web technologies

that
were

mentioned in the previous section

and make
it look like a native application. This is made
possible due to the capabilities of HTML 5 and CSS 3.

However this approach is not suited for highly
interactive, visually rich applications.

In this cross
-
platform application, a web app runs in a browser
-
vi
ew embedded into a native
application (hybrid view)
[19]
. The hybrid model runs inside a
thin native

wrapper

app, which

provides a bridge to the device’s operating system and sensors. The web application is cached locally

on the device on installation, eliminating the need for an active data connection.

Access to advanced
device capabilities l
ike contacts, stora
ge and sensor is made available to the hybrid application through
a JavaScript
wrapper
API.

The mobile user experience is replicated using
JavaScript libraries such as JQTouch, JQuery Mobile
and Sencha Touch.
These libraries deliver a mo
bile user interface that has the look and feel of a native
application while not compromising on performance.

The hybrid solutions are made possible using frameworks such as Phonegap. A framework
is a set of
libraries, software components

and architecture
guidelines that provides the developer with a
comprehensive toolkit to build a complete mobile application, from top to bottom
[19]
.

In the report ‘Cross platform mobile development’
Hartmann
,

[19]

reviews frameworks

and platforms
used to develop cross
-
platform mobile applications. The
criterion used to narrow down the selection
was

as follows:



Are relevant to m
-
learning



Provide a complete toolbox for developing end
-
to
-
end
cross
-
platform mobile apps.



They have a mature code base and a large community

behind it

Department  of  Computer  Science
 
 
VulaMobi
 
 

7
 


Provide decent documentation and support



Are free and open source.

In the subsection
s

below
, the

framework is explained in more detail and later it is explained in the

context of m
-
learning concentrating on content management.

2.3.1.

Phonegap
 
Phonegap is an open source framework
that gives web applications written in HTML5, CSS and
JavaScript access to native functionality of a mobile device such as access to the camera, phone
book
and

local storage to mention a few
.

In addition
,

Phonegap
builds a native

application by applying a
native wrapper to the web application.

At the time of this writing, Phonegap
just came out of beta
phase.


The popularity of Phonegap can be attributed

to its flexibility, straightforward architecture and ease of
use. The libraries just need to be dropped in the right place and with a little programming a functional
app can be quickly created

[19]
.
Phonegap makes converting/porting existing web applications to a
mobile environment.

Furthermore, Phonegap imposes little structure or guidelines

on how best to develop applications with
it. This allows users to freely a
rchitect their solutions in whichever way suits them best. Unfortunately,
Phonegap fall short when it comes to user interface.
Using user interface libraries like JQuery Mobile
and
Sencha Touch counteracts this shortcoming
.

The figure below shows the supported list of features
and platforms
.


Figure  
3
:  A  summary  of  the  supported  platforms  and  the  supported  features  using  Phonegap
.  
Taken
 
from  
Phonegap  website
1
.  (
Version  reviewed  2.1.0
)
 

2.4.

Choice
 
for  M
-­‐
learning
 
development
 
The mobile industry is evolving making new affordable frameworks available for mobile
development. The

proliferation of all the libraries and platforms makes the decision process of
choosing on
e much more difficult. The wrong choice for
an

m
-
learning project may have dire
                                                                               
                             
 
1
 
www.phonegap.com/about/feature
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

8
 
consequences. Therefore,

a technical approach is used to choose the libraries and platforms that will
support the m
-
learning activities
[19]
.

Pr
evious work on the MoLE project

[30]
, list terminology related to m
-
learning

for example

as

mobile
learning virtual environment

(
mVLE
)

learning and Experience
-
based learning.

Mobile learning virtual
environment

(
mLVE
)

learning is

an

extension to a virtual learning environment and experience
-
based
learning makes use of device functionality such as the camera.

The m
-
learning approaches above
require high interactivity in the case of the mobile learning virtual environment (mLVE) and in

experience
-
based learning; access to device features is needed to make the learning meaningful.
Therefore, the
hybrid solution is best for these kinds of m
-
learning.

Furthermore, managing multimedia content for these learning

methods is paramount. Due to
the
limited memory on mobile devices, an efficient management scheme for mobile multimedia,
particularly images. The next section analyses requirements for managing images for m
-
learning.

2.5.

Image  management
 
 
Personal photography is one of the most successful

mobile technologies of the last century
[4]
.
The
ubiquitous camera

phone

brings new opportunities to media capture, as the devices ar
e always at hand.
Rapid improvements in image quality substantially increase camera

phones’ potential. Currently,
image quality on most high
-
end camera phones rival image quality of some digital cameras

[4]
.

Now
the need to manage photographic content is rising since mobile phones have limited memory.
The term ‘photoware’ from Frohlich et at.
[15]
,

i
s used by the author
s

to refer to groupware for
collaboration around photos. In t
he paper, ‘Requirements for mobile photoware’, they borrow the term
‘photoware’ and use in a mobile context to refer to technology that suits all phases of a photograph’s
life. The phases include taking, uploading, organising and annotating, sharing viewin
g and archiving
[4]
.


Adapting the use of mobile photoware to m
-
learning, it will require

manageme
nt of
photos
for m
-
learning applications.
The mobile photoware should allow the learner to have access to their photos
from any location and at any time and promote the use of experience
-
based learning, utilizing the
camera

phone’s potential.

2.6.

Summary
 
 
The mobile
technology landscape is diverse. There is a trend to move from native applications towards
web
-
based application
s for greater coverage. However, the greater reach web
-
based applications have
compromises on performance, access to native application features

and potentially the user mobile
experience. Hybrid or cross
-
platform solutions bridge the gap by providing the best of both native and
web
-
based applications.

M
-
learning applications development approaches were consid
ered based on the requirements of the
learning. The considerations involved the interactivity and the

use of device functionalities such as the
camera to enhance
m
-
learning. The best solution, to still have a wider coverage was a cross
-
platform
hybrid application.

The lifecycle of a photograph

gave insight to the requirements needed to manage image content for a
cross
-
platform m
-
learning application.
The limitation that mobile devices have in terms of memory

space and processing power makes managing photos for m
-
learning even more necessary to
deliver a
better learning experience on mobile devices.

 
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

9
 
3.

Requirements  Analysis
 
Chapter
 
3.1.

Introduction
 
This chapter dis
cusses the desi
gn of the system and provide

the detailed

procedures
that
are

implemented to design the photo gallery for VulaMobi

as well a
s the steps taken to identify user
requirements
.

Initially, the user needs or requirements are not understood, and the goal of the project is
to follow a User
-
Centred Design
(UCD)
process to develo
p this system.

Using this approach ensures
that users are i
nvolved at every stage of the project, from requirements gathering to the evaluation of
the prototypes. The UCD design process allows for user
-
friendliness of the mobile application
, such
that it will encourage the use of the application.
The

subsections
below outline the interviews and
meeting that were

conducted with potential users.

3.2.

Understanding  the  Users  and  their  
Needs
 
The focus of this pr
oject is on User Centred Design. I
t is essential to understand the potent
ial users,
identify the
ir needs and unde
rstand them. The understanding of
the user needs,
had to answer the
following question
.

What do you need the application for?

Why would you need the application?

How do you want to use the application?

To understand students’ needs thoroughly,
the
project
team needed to first know what features of Vula
students mostly use.

This serves as a basis for knowing what features of the desktop version of Vula
that could be ported to a mobile platform. Vula is run and maintained by the Centre for Educational
Technol
ogy (CET), a department at University of Cape Town (UCT).
The project team conducted
meeting with the head of (CET) in order to provide further insight into Vula.

A survey conducted by CET
, under the mobile project
[29]

on
students

to determine what type of
mobile phone
students at UCT use
, revealed that 98% or the respondents of the survey had a
smartphone

[29]
.

Us
ing the data received from this survey was the basis
for the project team to narrow
down the scope to smartphone users. Various methods were utilized to reach students for the
project
such a
s individual

interviews with students and focus groups.

The interviews
aimed to cover students
from different faculties

at the University of Cape Town
.

3.2.1.

Student  Interview
s
 
In the early phases of the project, interviews were held with students
in different departments and
faculties. To have a diverse group of students to interview
, students in different

academic levels, in
both undergraduate and postgraduate levels,

were interviewed
. The

author

conducted
student
interviews

on and off University
of Cape Town premises
.

The
aim
s of the interviews were

to seek
insight into the use of the
camera phone
, (smart phone or feature phone
)

and whether the pictures the
students took were

directly

or indirectly
relevant
to their studies
.


Before the interviews

were conducted,

a list of questions was set.

This list of questions intended to
cover the themes listed below.



General use of the camera phone and frequency of taking pictures



Context
in which the
pictures were taken



The context in which they use the pict
ures



Organisation and archiving of pictures

To see the full list of questions asked in the interviews see Appendix A.

Department  of  Computer  Science
 
 
VulaMobi
 
 

10
 
Appointments were first made to set up a time to interview the students
. The appointments set the time
and location for the interviews and

clarified any auxiliary information such as items needed for the
interviews. Once this was done, the interviews could then be conducted.

The procedure for the interviews started with explaining the purpose of the

research and the structure
of

interview
. A
fter that, the students were asked the questions listed in Appendix A while the author
took down notes on paper. At the end of the interview, the students were given an opportunity to ask
questions about the study.

After all

interviews

were done, the notes

that were taken down were analysed and the results obtained
were used to create possible use cases of the system that are discussed in th
e next S
ection

3.2.2
.

The interviews were conducted with

six

student
s

in the faculties of Commerce, Science, Eng
ineeri
ng
and Built Environment and

Humanities
.
The initial participants were students chosen to represent a
variety of user types, including undergraduates (first year, second year and third year students) and
postgraduates (H
onours and Masters
).
In the
course o
f the interviews
,
questions asked were from a list
of set questions

but some questions were open
-
ended.

Every
participant had owned or currently owns
a camera phone, of which all were smartphones. The brands of the smartphones ranged from
Blackberry, Samsu
ng, LG
, Apple

and Nokia
.

The interview participants revealed that their photo taking needs were quite varied.

Most participants
took photos with their camera phone approximately twice a week up to a maximum estimate of 5
times a week and a minimum of 0 tim
es in a week. In addition, 4 out of the 6 participants indicated
that they used their camera phones in university. Two participants revealed that they used their camera
phones while participating in group projects while one participant in
dicated that the p
ictures he took
served as reminders
.

Many of the participants revealed that they took pictures
were

ta
ken either in a
social, educational or both, however one participant said t
hat they use their camera phone

primarily on
a

social basis
.
One participant
particularly used the camera phone to take pictures of designs during
their design course. Subsequent need

to use the camera phone

reduced when the course was
completed.
Another major use

identified

was
the

use of

the camera phones

was to take pictures of
announcements. T
he participants mentioned that they were “lazy”

to take down

on paper the
announcements and found taking a picture far much easier.

Furthermore,

the
use extends to taking
pictures of graphs on
black and white
boards

as well

as pictures of e
ssay questions and list of readings
that the participants didn’t want to jot down
.
One participant revealed that the pictures they took were
of

electrical components such as

circuit boards that were necessary for their project documentation.

A participant,

used their camera phones to take
pictures of Microsoft PowerPoint
slides
. The reason
behind it was the presentation slides

file

did not open on their mobile phone.

Two of the participants
said they took pictures of the Jammie timetable
s

(Jammie Shuttle Se
rvice is a transport service offered
to staff and students at University of Cape Town)

[34]
, regularly reviewing the pictures to che
ck the
times for the next bus.



All participants agreed

that they wanted to be able to access their pictures on a desktop computer

hence a need to archive the imag
es
. They saw this as a key feature that
they would want to be able to
view their pictures on a
desktop computer or

on a laptop
.

3.2.2.

Use  Cases
 
Using the information gathered from the student interviews in the section above, possible use cases for
the system can be drawn up.

The figure (
Figure 4
)

belo
w sho
ws the identified use cases

of the
potential application.

Department  of  Computer  Science
 
 
VulaMobi
 
 

11
 

Figure  
4
:  Use  Case  Diagram  
showing  the  identified  use  case  of  the  
proposed
 
system
.
 
The figure above, Figure 4, shows the identified use cases of the potential system.

The main use cases
are located on the left of the diagram and the additional uses cases that are linked to th
e main use case
with “uses” and “extends” links. “Uses” links describe uses
cases that are mandatory for the main use
cases

while “extends”

links
describe use cases that

are optional
and

extend the functionality of the
main use case. On the right of the figure, the server is linked t
o

use case
s

and provides functionality
for those use cases. The box around the use cases is the system boundary that d
efines the scope of the
system.

The use case ‘Take Picture’ requires the phone to detect if it supports the capability indicated by
‘identify device capability’. It ensures that if the device does not have a camera, the application will
default to retrieve

pictures from the phone gallery, indicated by the
‘load picture from phone gallery’
use case.

‘Upload picture’ use case requires the ‘detect network connection’ use case to upload the
picture to the server. ‘Share picture’ use case requires the ‘select pi
cture


use case

in order share a
picture but optionally can use ‘search for users’ use case where a search for user from a list of users
can be done. The ‘view gallery’ use case describes the browsing of the gallery and different ways of
viewing the pictur
es. It requires ‘load pictures’ use case, where functionality of the use case (load
pictures) is provided by the server.

Having identified the possible use case of the proposed
system, the project could now move forward to
design phase. The design phase
would involve prototyping. The prototypes used are discussed below
in section 3.3
.

Department  of  Computer  Science
 
 
VulaMobi
 
 

12
 
3.3.

Prototypes
 
Interviews could only progress the user requirements to a point. To further understand the user
require
ments
and give the users a
look and
feel for

the

real appli
cation
, constructing prototypes will
assist to a great extent.

Prototypes not only give the potential users a feel of how the application will
work but also allow the users to be assessed whilst performing which cannot be achieved by just
interviewing cand
idates. The prototypes allow developers

to assess the users’ reaction to specific tasks
or features of the application

and understand better the users behaviour towards the application and its
features
[21]
.

It allows ironing out poor interface designs that are detected at an early stage of the
project as well as redefining some user requirements. Prototypes exist in different kinds, each with its
strengths and
weaknesses. The prototypes used in this project are as follows:



Low Fidelity Paper
-
Based Prototype



Two
High Fidelity Vertical Prototype
s



Final Mobile application (Final Prototype)

Paper
-
based prototypes are popular due to its greatest strength of being che
ap, eas
y to implement and
modify
[21]
.

It follows a user centric design approach to the give the users the opportunity to
contribute towards the application.

T
he potential user is interviewed separately so as to have their
decision making process not influenced by other
seeing other
users

testing the prototype
. Ensuring that
the decision the user makes is solely his/hers, the
tests are conducted individually in
a dedicated time
slot.

The testing involves a user seated at a table, a sheet of paper with a sketch of the interface of the
application

is placed in front of the user and the user is given a set of task to perform
. The user
chooses an option on the paper
interface and

a new sheet of paper is placed on the table showing the
next set of options.

This approach allows for users to recommend any design changes

before the next
stage of testing. The main limitation of paper
-
based prototyping is the restricted int
eraction between
the user and the prototype.

High fidelity prototype provides interface functionality of the final application and overcomes the
limited interaction of the paper
-
based prototype. It gives the user the first feel and
looks

of the real
application

and includes any interface
modifications suggested by the user.

In addit
ion, the prototype
introduces the user to interaction that will be utilized in the final application. Implem
enting the high
fidelity prototype on mobile,
allows the user to see how the final system would be actually designed.

However, the implementing it would require the developer understand the development platform, in
this case, JQuery Mobile

library was used

for the first high fidelity

vertical

prototyp
e iteration

and
Sencha Touch 2 for the second iteration
, designing a horizontal prototype
.

T
he hardware and system
requirements of the mobile

device used for testing

should be known in advance
, in this case a
Samsung Galaxy Ace

[31]

running on Google’s Android 2.3

[16]

mobile operating system
.

During the
prototype testing, extra hardware and software requirements

and capabilities

that be needed by the
application can be assessed.

The final prototype is fully implemented on mobile with
full functionality and connectivity to the
backend using HTTP requests.

The mobile application will primarily be programmed using Sencha
Touch 2,

a mobile application framework that uses HTML5 (Hypertext Markup Language, fifth
revision), ExtJS (Extended Ja
vaScript) and CSS (Cascading Style Sheet)
. The major pitfall of the final
prototype is that making changes that users suggest during testing may not be easy to implement.

However,
the aim will be to identify many of the user requirements during student int
erviews and the
testing of the low and high fidelity prototypes to reduce the risk of major changes to the final
prototype.
Implementing an interactive design process discussed in section 3.1 above should avert this
risk
.

3.4.

Evaluation
s
 
Jones
et.al

2006

[21]

in their book
, “Mobile Interaction Design”, provide a variety of evalu
ation
methods such as interview
s, constructive interaction method

and

direct observ
ations
.

Department  of  Computer  Science
 
 
VulaMobi
 
 

13
 
The evaluation method, direct observation is utilized during prototype testing where the researcher
(evaluator) observes the users interacting with the system

[
21]
.

The user is asked to perform a series of
tasks while an evaluator observes and takes down notes. This method is great to identify any design or
interface problems
.

The drawback of this method is the validity of the observation highly depends on
how

controlled the situation is

[21]
.

To make this method more effective, a “think aloud” approach is
used where the users air their thoughts as they perform the
given tasks
[21]
. Jones
et.al

[21]

, mention
that this approac
h gives the evaluator insight
to what the participant’s trail of thought is and how they
interpret the prototype. Talking while concentrating may prove difficult for some users as well as

being

awkwardly uncomfortable for the participant. The evaluator gen
erally has to make the
participant feel comfortable and

inform the participant that the evaluation is not to test their ability but
to test the system

in order to make them feel as comfortable as possible
.

Due to the fact that people
react negatively to be
ing observed, the researcher/observer should make it abundantly clear the what
the participant what will happen, what is expected and the duration of the observation
[21]
.

During
the testing of each prototype, data is gathered using various methods.

The method adopted by
the evaluator is note writing

on paper

while observing the user interact with the prototype. In addition,
the evaluator does interrupt or

give any suggestions to the user so the choices made by the user are not
manipulated and the evaluator is able to

understand the user
-
friendliness of the system
[21]
.

After
completion of all tasks and note writing, a short interview with the user, usually
with
open
-
ended
questions,

to get insight to what the user’s experience with the design is and a possibility of
recommendations or suggestions to improve the
design
. Users are encouraged to criticize the
prototype, thus giving the evaluator constructive criticism that will be used in redesign of the system if
necessary in the next iteration.

The interviews that follow the prototype testing are unstructured and
generally the questions are based on incidents observed during testing.

Interviews and direct observation provide qualitative results. To obtain quantitative results
,
questionnaires can be used on the final prototype. The
questionnaires collect both qualit
ative and
quantitative results
. By designing the questionnaire to contain questions of a scalar form using the
Likert scale, the evaluator can be provided with a more quantitative way of assessing the users
opinions and attitudes that open
-
ended questions
cannot achi
e
ve

[21]
.

3.5.

Summary
 
In Section 3.2 it was established that

from the interaction wi
th students, there was a desire for
a picture
management application

to organize pictures

of

academic related or not.

The
methodology

and
tools

that are used to develop the gallery have been introduced. In the next chapter discuss the design
iterations of the prototype and their evaluations.

 
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

14
 
4.

Design  Chapter
 
4.1.

Introduction
 
The next iteration of the project involved implementing a low fidelity paper prototype. The prototype
was cheap, quick and easy to make and useful in giving the potential user the general look and feel of
the system

[21]
. This was the first prototype; there were chances that modifications would have to be
done once the testing was complete. The paper
prototype would allow the author to make quick
modifications t
o the design. The next iteration

involved developing and testing a high fidelity
prototype that was tested on a mobile phone.

The low fidelity
design prototype was a horizontal prototype that focused solely on the design of the
user interface providing the

maximum number of features the system while limiting functionality.

This
allows the user to familiarize with the system features and capabilities. The high fidelity prototype is a
vertical prototype.
Vertical prototypes offer the user a slice of the core
functionality of the system.
This provides the user with an idea of how the complete system w
ill function and provide the author
an indication if the user requirements have been correctly identified or they need more elaboration.


This chapter examines in
detail the designs, testing and evaluation of the low and high fidelity
prototypes
. The finding
s obtained from an evaluation
with an interface heuristic expert with regards to
the interface design heuristics are also discusses in this chapter.

4.2.

Low  Fidelity
 
Paper  Prototype
 
The paper prototype was made of paper and pencil. A
mock
-
up

of a phone was printed on paper and
the user interface was drawn using pencil. This allows the paper
-
based prototype to be cheap, quick
and easy to produce and modify. However, in
teraction between the user and

the system is very limited.

On the upside, low fidelity paper prototypes are the best way to begin interface design of a system,

to

identify the user requirements. The figure below (Figure 4) shows sample

redrawn

s
ketches

of
the low
fidelity prototype
. The actual
sketches used

in
the prototype evaluation are located in Appendix B
.




Figure  
5
:  
Sketches
 
of  the  low  fidelity  paper  prototype
 
Figure 5 above shows sample

of three

sketches of the low fidelity prototype that were shown to users

who participated in the evaluation of the low fidelity prototype.
The first screenshot on the left shows
the gallery view with a grid containing six thumbnails.

The second sketch contains a

d
ialog showing
upload progress

and the third shows the

full size image with a button on the top, to go back to the
Department  of  Computer  Science
 
 
VulaMobi
 
 

15
 
gallery.

According to Lumsden 2008
[22]
,

using thumbnails allows easy browsing that leverages the
efficient human visual system. Thumbnail browsing is popular in desktop photo management systems
and although mobile devices have smaller screen sizes, it is a useful tec
hnique and widely used in
mobile interfaces for photo browsing
[22]
. The figure below illustrates thumbnail browsing on a HTC
Sensation.



Figure  
6
:  Thumbnail  browsing  on  a  HTC  Sensation
 
smartphone
 
Using the concept of thumbnail browsing, it served as the basis to design the image gallery sketch.
The
prototype evaluation is found in

section

4.2.1

and the findings discussed in section 4.2.2.

4.2.1.

Structure  and  Design  of  Evaluation
 
To evaluate
the low fidelity prototype, three use

cases shown in Figure 4

were selected.

The selected
use cases formed the core of the proposed system.

The use cases were



Take

picture



Load picture from phone gallery and



View Image Gallery


The evaluation required ethics clearance from Science Faculty Research Ethics at the University of
Cape in order to conduct user testing. Once this was obtained, the evaluation could proceed.

A list of
set tasks that implemented the selected use cases was prepared
and

presented to test participants

(See
Appendix C)
.

The participants chosen to participate were all volunteers.

Six volunteers were chosen

to
participate in this

evaluation.

The vol
unteers chosen were in the faculties

of Engineering and Built Environment, Science and
Commerce. Three participants were in third year,
two in honours and one in masters.


The evaluation was conducted in a lab environment setting. The overview of the study

was first
explained to the participants followed by the purpose of the evaluation.

It was emphasized to the
participants the design of the user interface of the proposed system was being tested not the subjects’
ability.

In addition the participants were
told that their feedback would be treated confidentially.
Lastly they were asked if they had any questions before the evaluation began.

Department  of  Computer  Science
 
 
VulaMobi
 
 

16
 
The aim of the evaluation is to assess the
design of the user interface. The tasks cover scenario of
adding pictures to
the gallery from

two

different

sources
. Eight tasks were given to the
participants
,
always in
the same order.

The task list was printed on paper and given to the user to follow while the
author watched the user’s expressions and body language. When the use
r clicked on an option on the
interface, a new paper was placed on the table showing the next set of options, similar to a use case
scenario walkthrough.

During the
task implementation
, the author did not give any suggestions or hints in how to go about
pe
r
forming the tasks. When the participant

encountered a problem or was confused, the author
suggested that they go with their instincts or guess, if necessary. This was done to ensure that the
participant

was not influenced and the choices made by the parti
cipant where theirs and not of the
authors
.

Following the tasks, each
participant

was interviewed. The interviews were conducted to assess
information about the subjects’ experiences during the task section. This took approximately
5
-
8

minutes and

it depen
ded on the responses of the participant
. The interview questions chosen would
reveal the
participant
s’ user experiences and recommendations that they would have.


Participants were encouraged to criticize and give honest opinions on the prototype, to give
the author
useful feedback that was used to design the high fidelity prototype in the next iteration and
subsequently in the final design of the image gallery for the mobile application. The

section below
discusses the task outcomes of the evaluation

4.2.2.

Task  
Outcomes
 
The paper prot
otype testing involved getting participants

to perform tasks li
sted in Appendix C
.
Below
are the task outcomes.

Task 1

and Task 2
:

The first ta
s
k was aimed at allowing the participant

to familiarize
with

and understand

the user
inter
face.

All participants

found it easy to identify with the controls on the interface
.
They all found it
straightforward

Furthermore, except for one participant
, the all counted the right number of
thumbnails that they could see on the paper prototype.


Fig
ure  
7
:  Paper  Prototype  Gallery  Interface
 
Department  of  Computer  Science
 
 
VulaMobi
 
 

17
 
Task 3:

All the participants were comfortable selecting this option. However, there was some confusion with
where to
proceed after making the choice, particularly when selecting a picture fr
om the phone library
because the phone library was looked like the gallery in th
e previous screen
.

All the
participants

did
not have any difficulty selecting the camera option.





Figure  
8
:  Paper  Prototype  Camera  and  Uploading  
Interfaces
 
Task 4

and Task 5
:

All

participants were easily able to locate

and select

the thumbnail of the image

that had been added to
the gallery.

Department  of  Computer  Science
 
 
VulaMobi
 
 

18
 

Figure  
9
:  Paper  Prototype  Update  Gallery  Interface
 
Task 6:

When the
participants

were asked to select the thumbnail of the picture that the added to the gallery,

they were able to view the full size image

and verify it was the image they added to the gallery.


Figure  
10
:  Paper  Prototype  Full  Size  Image  
Interface
 
Task 7

and Task 8
:

All participants

found it easily to navigate back to the gallery
. It was also easy for the
participants

to
do a manual refresh of the gallery.

The button
was easily seen by the participants
.

Department  of  Computer  Science
 
 
VulaMobi
 
 

19
 

4.2.3.

Findings
 
Interestingly, only one of

the
participants

that tested the prototype had ever tested a pro
totype on
paper. The other participants

had

never been exposed to paper prototypes therefore it took them some
time to settle in and get comfortable with the concept. The
participants

preferr
ed to test the prototype
on the mobile phone.

In the interviews, participants revealed that they

did not want to remove any of the prov
ided features.
However, one participant

suggested an image magnification feature to facilitate zooming in and out of
t
he
full size image. Another participant

suggested having folders to manage pictures based on projects
that they were undertaking.

All the
participants

were interested in using the gallery

and wanted to test a later version of the gallery
when it was ready. On
e reason was b
ecause the gallery kept pictures related to academics together
and
the pictures could be accessed on a desktop computer

or laptop

for future reference
.

4.2.4.

Summary
 
The low fidelity paper prototype was only utilized to iron out design results
obtained from the

requirements gathering mentioned in
Section 3.2
.
Three use cases identified in section 3.2.2 were
selected for this evaluation and the rest were left out.
The focus was more towards students who use
their mobile phones to take pictures

of

academic related material. I
t was not s
urprising to see that the
participants

were not familiar with paper prototypes

and some finding it awkward with the idea
.

The
paper prototype was used to ensure that user requirements had been met.

4.3.

High  Fidelity  Prot
otype