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
- Αρχική
- Περιήγηση
- Όλες οι Κατηγορίες
- Internet και Εφαρμογές Web
- Αποθήκευση
- Ασφάλεια
- Βιοτεχνολογία
- Δίκτυα και Επικοινωνίες
- Διακομιστές
- Διαχείριση
- Διαχείριση Δεδομένων
- Επιχειρησιακές Εφαρμογές
- Ηλεκτρονική - Συσκευές
- Ημιαγωγοί
- Κινητά – Ασύρματες Τεχνολογίες
- Λογισμικό & κατασκευή λογ/κού
- Μηχανική
- Περιβαλλοντική Τεχνολογία
- Πετρελαϊκά και Εξόρυξη
- Πολεοδομικά Έργα
- Τεχνίτη Νοημοσύνη και Ρομποτική
- Τηλεπικοινωνίες
- Ψυχαγωγία
- Κοινότητα
- Μεταφόρτωση
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο