marketing via mobile application zong yuan he msc ...€¦ · marketing via mobile application zong...
TRANSCRIPT
The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be considered as plagiarism.
(Signature of student)________________________________
Marketing via Mobile ApplicationZong Yuan He
MSc Computing and Management
Session 2009/2010
Summary
This report documents the development of an Android mobile application for University of Leeds
that designed to add extra values to the marketing strategy. Existing systems are incapability to
deliver high quality information services to small screened devices, which in turn will bring negative
effect to the marketing of the university as a non-profit service provider. Therefore the purpose of
this application is to generate and maximise the positive effect to the marketing strategy by
enhancing user experience on mobile devices. The process goes from identifying the marketing
values analysis of a mobile application, through application design and implementation, and finally
to its evolution by comparison with existing system and usability tests.
i
Acknowledgements
I would like to thank the following people for their help with this project:
• My project supervisor Andy Bulpitt for his tremendous support through the project and the
course.
• Paul Townend of School of Computing for his help in analysis the message of library service.
• James Padgett of the library system team for his help to understand the library catalogue and
its AirPAC interface.
• My friends for participating in user requirement survey and the usability tests.
• Many kind-hearted people in mailing list and social network for providing advice on
technical difficulties.
ii
Table of ContentsChapter 1: Introduction............................................................................................................................................1
1.1 Overview.........................................................................................................................................................11.2 Problem Statement........................................................................................................................................11.3 Project Aims...................................................................................................................................................11.4 Deliverables....................................................................................................................................................11.5 Summary.........................................................................................................................................................2
Chapter 2: Progress Management..........................................................................................................................32.1 Overview.........................................................................................................................................................32.2 Methodology...................................................................................................................................................32.3 Progress Plan..................................................................................................................................................3
Chapter 3: Background Reading.............................................................................................................................53.1 Mobile Marketing..........................................................................................................................................53.2 Education Outside the Classroom..............................................................................................................7
3.2.1 General....................................................................................................................................................73.2.2 Case study: UC San Diego Mobile.....................................................................................................8
3.3 Summary.......................................................................................................................................................10Chapter 4: User-Requirement Analysis..............................................................................................................11
4.1 Previous Experience....................................................................................................................................114.2 Survey............................................................................................................................................................12
4.2.1 Questionnaire.......................................................................................................................................124.2.2 Distribution and Subjects..................................................................................................................124.2.3 Results....................................................................................................................................................12
4.3 Conclusions...................................................................................................................................................13Chapter 5: Software Design...................................................................................................................................15
5.1 Design Principles for Mobile Devices......................................................................................................155.1.1 Balance between Performance and Battery...................................................................................155.1.2 UI design on Small Touch Screen....................................................................................................15
5.2 Android Design Guides..............................................................................................................................165.2.1 Java + XML + Web.............................................................................................................................165.2.2 Activities, Intents and Others...........................................................................................................17
5.3 Project Specific Design...............................................................................................................................185.3.1 Open and Controllable.......................................................................................................................185.3.2 Consistent but Lighter........................................................................................................................195.3.3 Device compatibility...........................................................................................................................205.3.4 Rich documentation............................................................................................................................205.3.5 Internationalize....................................................................................................................................21
5.4 Summary.......................................................................................................................................................21Chapter 6: Implementation....................................................................................................................................22
6.1 Overview.......................................................................................................................................................226.2 Tools...............................................................................................................................................................236.3 Modules.........................................................................................................................................................24
6.3.1 Portal......................................................................................................................................................246.3.2 Library...................................................................................................................................................266.3.3 Email......................................................................................................................................................296.3.4 RSS..........................................................................................................................................................316.3.5 Map........................................................................................................................................................32
6.4 Documentations...........................................................................................................................................336.5 Testing............................................................................................................................................................34
iii
6.6 Variations to the Plan.................................................................................................................................34Chapter 7: Evaluation.............................................................................................................................................35
7.1 Overview.......................................................................................................................................................357.2 Mobile Marketing Value Created.............................................................................................................357.3 Comparison to the Existing Systems.......................................................................................................367.4 Usability Test................................................................................................................................................39
7.4.1 Method and Task List.........................................................................................................................397.4.2 Subject and Practise............................................................................................................................397.4.3 Result.....................................................................................................................................................40
7.5 Related University Departments: Library and ISS................................................................................417.6 Comments and Issues from Online..........................................................................................................417.7 Summary.......................................................................................................................................................42
Chapter 8: Conclusion............................................................................................................................................438.1 Limitations....................................................................................................................................................438.2 Future Improvements..................................................................................................................................438.3 Summary.......................................................................................................................................................44
Bibliography.............................................................................................................................................................45Appendix A: Personal Reflection.........................................................................................................................47Appendix B: Gantt Chart.......................................................................................................................................48Appendix C: Interview to UC San Diego...........................................................................................................51Appendix D: Links to online resources...............................................................................................................52Appendix E: HTC Tattoo.......................................................................................................................................53Appendix F: Screenshots on Android x86 devices............................................................................................54Appendix G: Poster.................................................................................................................................................56Appendix H: Usability Test...................................................................................................................................57
iv
Chapter 1: Introduction
1.1 Overview
This section sets out the problem statement and the deliverables of the project to solve the problem.
1.2 Problem Statement
For a non-profit educational service provider, user experience plays an important part in the
marketing strategy in University of Leeds[17]. A lot of effort has been put into ensure the students,
staff and visitors to the university experience high quality online services on desktop PCs and
laptops provided by the Information Systems Service (ISS) and various departments. However, due to
some unique constrains of mobile devices, many of these efforts become invalid when people start
using their Smartphones, PDAs and tablet PCs. The unoptimized web pages are barely readable on
small screens while some resources can only be reached through several navigating menus. No doubt
it would harm the user experiences, which in turn has negative effect from a marketing aspect.
Not only the profit-making corporation but also universities around the world start to see mobile
devices as a valuable field to market their services. At the time of writing, the keyword 'university'
returns over 800 results in Apple App Store and 562 results in Android Market. Despite the number,
there is little literature to guide the direction on marketing in this area. Without sufficient reference,
the university has to develop a suitable mobile strategy for its own needs.
1.3 Project Aims
The aim of this project is to review the field of mobile marketing and develop a solution to suit the
specific needs of university by following the marketing principles.
1.4 Deliverables
The minimum requirements of this project are:
• An analysis of mobile marketing.
• A mobile application which satisfies the specified needs identified from the analysis.
The further extensions of this project are:
• A project which could be used as the foundation of mobile strategy for the university in a
1
long term.
1.5 Summary
The goal of the project has been set up so that the plan to implement the project can be formed.
2
Chapter 2: Progress Management
2.1 OverviewThis chapter describes the methodology used in the project and the plan to carry the development.
2.2 MethodologyThis project employs the basic framework of marketing plan to analysis and the agile approach to
develop the software.
As suggested by Kotler[17], a marketing analysis should contain the understanding of the
marketing characteristics, the study of the competitors, the target population, a survey about the
customer needs, product development and feedback after distribution. By following these steps, a
reliable approach to explore an uncertain marketing area can be formed.
As a part of the whole project, an agile software development approach is used in the application
development phase. The following principles[6] make the agile approach particularly suitable to this
project: First, fast delivery allows quick responses to the changes of the market and the feedbacks
from customers. Second, quick built-in tests can be helpful to isolate and solve the problem if the
applications contains several features, which is very likely. Third, the evolutionary commitment
would leave the options for alternative approaches if the planned one does not work as expected.
This approach is considered to be the most suitable one when the user requirement is not thoroughly
clear or dynamically evolving.
2.3 Progress PlanThe project was planned to have four milestones in the process of development. The more detailed
time-plan can be found in the Gantt chart in Appendix B: Gantt Chart.
1. Milestone 1 17/Jun/2010
Literature research and survey should be completed.
Several books on mobile application development should be carefully read.
The interim reports should be written and handed in.
2. Milestone 2 10/Aug/2010
Application should be well-designed and completely according to the needs specified from
previous phase.
3
Application should enter feature-frozen phase and ready to be tested.
3. Milestone 3 27/Aug/2010
Various feedback and evolution should be done.
Report should be finished.
4
Chapter 3: Background Reading
3.1 Mobile Marketing
The mobile market is rapidly growing in Europe. Research suggests that by 2009 nearly 80% of the
Europe citizens were mobile subscribers[16]. In the review of Bill and David[3], the values which
can be created from this prosperous mobile market are seen in Figure 1:
For a mobile application, the five service-dependent needs are the determined elements to its
marketing value. Entertainment needs on mobiles are different from the ones on game consoles.
They are satisfied by filling the time gap between business rather than highly engaging into virtual
world. They have close relation with spontaneous needs, which are the actions which are not
planned or necessary but still need to be satisfied. Efficiency ambitions are the working efficiency
which are unlikely to be achieved through other non-mobile technologies such as mobile office.
Time-critical arrangements are the desirable actions triggered by external events, for instance,
calender alerts and email push(notifying newly coming email). The satisfaction of these needs are
normally the value-adding part of the whole. Mobility-related needs are the services which is related
to the location, time or other dynamically changing factors such as GPS(Global Positioning System)
navigation.
Since the three service-independent elements are the generic characters across all mobile
application, they can be safely ignored when assessing the marketing value for a particular
5
Figure 1: Value creation in mobile marketing
application.
Two points are worth emphasizing for a marketing strategy of educational organizations. First,
though argued to be the core of value creation, mobility-related needs such as location based services
might have difficulty in adoption due to the technique limitations. The nature of the GPS system
limits its accuracy in the geographically small campus field[15]. Second, time-critical arrangements
and efficiency ambitions could be the suitable elements in a marketing strategy of university.
Providing the services in a quick-responsive and efficiency manner could generate benefits to the
service provider.
Moreover, Bill and David[3] mentioned the personalization of the service, though not uniquely to
the wireless service providers, can be a value-adding feature in mobile marketing.
Mobile marketing began with distributing business information through SMS (Short Message
Service) and MMS (Multimedia Message Service). Then it eventually evolved to distributed mobile
applications. The development of mobile banking in Europe reflects this process. First the banks
introduced the SMS-based service to attract the consumers who prefers to receive account
information by text rather than by calling. With the mobile technology progressed, Java-based
mobile applications allow the customers to authorise transactions or make payments directly from
their phones. This accessible and convenient service generates great advantages to banks. By
delivering the finical services to the pocket of clients, mobile banking not only significantly reduces
the expenditure on other automatic or manual services, but also improves the customer relationship
and brand loyalty. Thus the mobile application became an essential part in marketing strategy across
European banks[23].
The exploratory factor analysis in a large group of undergraduate and graduates in an American
university suggested that mobile applications can be grouped into five ranks according to the
perception of customers. The mobile application which could be used to find and retrieve
information is ranked to be the top usefulness. The second is the transaction supporting application.
The personalized services such as receiving discount tickets are considered to be the third, followed
by emergency and entertainment purpose applications[18].
6
3.2 Education Outside the Classroom
3.2.1 General
As stated in 1.2 Problem Statement, the University of Leeds has already employed plenty of
resources to provide learning opportunities off campus. The School of Computing even provides its
own learning resource on its internal network[25]. On one hand, the University Portal (See Figure 3,
22% of actual view size), a unified entrance to library, email et al, performs quite well on a
functional-rich level across all major desktop browsers. On the other hand, the complex layout made
it hard to use on small screen devices such as mobile (See Figure 2, 50% of actual view size).
Being aware of the difficulty to fit the desktop resource to mobile devices, some universities have
begun to construct a more appropriate way to deliver university services to mobile phones.
A survey on health students in Northumbria University suggested the high internal demand to
deploy educational services on mobile devices[28]. Library service and learning utilities are the
highest demanding features according to the survey. In 2004, the University of Birmingham
systematically evaluated the usefulness of a mobile learning organizer for undergraduates[9].
Besides revealing the needs to access course content and timetabling, the evaluation indicated the
importance of institutional support. Furthermore, the compatibility problem across various platforms
was addressed during the implementation phase.
7
Figure 3: University of Leeds Portal
Figure 2: University of Leeds Portal Mobile
3.2.2 Case study: UC San Diego Mobile
During the literature research, many researches pointed to the mobile strategy employed by
University of California San Diego(UC San Diego). Unfortunately, the survey sent to UC San Diego
Internet service department has not been replied to at the time of writing(See Appendix C: Interview
to UC San Diego). So the analysis had to be carried on externally. The five mobile values in Figure 1
will be used to assess UC San Diego Mobile.
UC San Diego Mobile strategy are composed by iPhone client, BlackBerry client and mobile
website. According to their website[27], it was powered by Blackboard Mobile Platform. Since the
author has no access to any BlackBerry devices, only the iPhone client (Figure 4) and mobile website
(Figure 5) were examined.
According to the screenshots, UC San Diego provides four features in the mobile website edition
and two additional feature videos and images in the iPhone edition. Directory provides a yellow
page of university staff(See Figure 6). Athletics seems to provide the scores and schedule for various
stadiums but all the entries are empty at the moment(See Figure 7). Courses along with Shuttles
provides the location and time schedule of certain courses and shuttles(See Figure 8).
8
Figure 4: UC San Diego Mobile iPhone Main
Figure 5: UC San Diego Mobile Mobile website Main
News is just a link to the news website of university, which had not been optimized for
mobile(See Figure 11). Videos and Images will directly connect to data-consuming multimedia
websites without a bandwidth warning(Figure 9). Map on iPhone simply overlays GPS location over
a static image map with no navigation or routing functions(See Figure 10) whereas the mobile web
site directs the user to Google Map Mobile.
The evaluation can be seen in Table 1 in the next page. 'S' in the column indicates the need was
satisfied by the feature, which was also the marketing value created from that feature.
9
Figure 6: Directory of UC San Diego Mobile
Figure 7: Athletics of UC San Diego Mobile
Figure 8: Course of UC San Diego Mobile
Figure 11: News of UC San Diego Mobile
Figure 9: Images of UC San Diego Mobile
Figure 10: Map of UC San Diego Mobile
FeaturesEntertainment
needsSpontaneous
needsEfficiency ambitions
Time-critical arrangements
Mobility-related needs
Directory S
Athletics
Courses S S
Maps S
Videos S
News S
Images S
Shuttles S
Table 1: Marketing values created from US San Diego Mobile
3.3 Summary
The literature on mobile marketing and off-campus education were reviewed and a case study was
presented. With these informations, the survey for user requirements was ready to be carried on.
10
Chapter 4: User-Requirement Analysis
4.1 Previous Experience
From the literature review and analysis of the current remote education several assumptions can be
drawed regarding to the user requirement. First, the library related service should be attractive for
students in university. Second, the time-critical information service such as news and course content
is generally popular on mobile devices. Third, a university application may not be an ideal place to
provide entertainment related services. Nevertheless, these assumptions must be confirmed by actual
result of a public survey.
Another issue is the choice of platforms. Current major mobile platforms are listed in Table 2
with required Software Development Kit (SDK) and distribution channel.
Platforms Required Techniques Development Environment
Distribution Channel
Apple iOS Object-C Apple X-code App Store
BlackBerry Java BlackBerry SDK App World
Google Android Java, XML Eclipse Android Market
Generic JavaME JavaME NetBeans Unclear
Linux MeeGo C Any Unclear
Palm WebOS JavaScript WebOS SDK App Catalog
Symbian S60 C++ Symbian SDK Unclear
Windows Mobile 6 C#, .Net WM SDK Unclear
Table 2: Major smartphone platforms[4] [5] [30] [14] [13] [12] [26] [19]
Besides the smartphone platforms listed above, many feature mobiles(fixed features without
extendibility) require the development tool chain which is not accessible to individual developer. For
those feature mobiles, mobile web site developed by HTML(Hyper Text Markup Language),
CSS(Cascade Style Sheets) and JavaScript is probably the only choice. The choice of targeting
platform became even more difficult to make, thanks to the recently announced Windows Mobile 7,
which is not compatible with its predecessor[31]. In all, the area of mobile development is extremely
segmented by their techniques and SDK. Giving the limited resource, it is impossible to target three
platforms like UC San Diego Mobile. Hence the development platform should be another question
hopefully the survey could answer.
11
4.2 Survey
4.2.1 Questionnaire
The interactive questionnaire contains six pages(See Figure 12). It is hosted on Google Docs (See
Appendix D: Links to online resources to full questionnaire). The questionnaire covers six
categories(figure in the bracket indicates the number of questions in that category): basic
demographic information(3), current mobile model(1), future purchasing tendency(1), common
mobile usage(5), opinion towards the features(7) and survey feedback(1). Most of them are multiple
choice questions with only a few optional short answer entries.
4.2.2 Distribution and Subjects
Initially, the questionnaire was supposed to be broadcast through the university and the School of
Computing mailing list. Unfortunately, the permission was not granted from the marketing
department until the end of survey. Thus the questionnaire was sent privately to social network web
site and the author's colleges in the form of email.
4.2.3 Results
In the end, 10 responses(3 females) were collected from the survey(See Figure 13 below). Most of
12
Figure 12: Online Interactive Questionnaire Page 2
them are taught postgraduate students aged from 23 to 28. Symbian S60 mobiles are the most
popular modules whereas WebOS and none of the participant uses Windows Mobile. Two
participants with featured mobile had no plan to purchase a smartphone in the coming year.
Querying information service and using utilities features such as dictionary and calculator are the
most common usage of mobile. 70 percent of them showed interests in accessing library and email
on their mobiles.
4.3 Conclusions
Combining the previous experience and the result of survey, the conclusions about the required
features and target platform were addressed.
Library, email, news and map features were nominated to be the implemented features. Library
and email related features are scheduled to be implemented due to the high interests showed in the
survey. Though not popular in the survey, news, as one of time-critical service, is considered due to
the suggestions from literature. Maps have a reason to be not attractive at all to the participants in
the survey: most of the participants have been in campus for almost a year. Considering the bias
caused by the attribute of participants in the survey and the suggestion by the supervisor, the map
should be a feature worth to implement.
Giving the limitation of distribution, the project will focus on the students. Features for staff
could be added if further information becomes available.
The Android system was chosen to be the target platform of this mobile application project after
assessing the following three factors: First, the author could fully utilise the learnt knowledge and
techniques in Android development whereas in others has to go through another learning curve.
Second, the entry for Android development is lower than others. The Android SDK and testing
device are freely available whereas most of the others require to purchase expensive additional
13
Figure 13: Responses Summary
software and equipments. Last but not the least, Android Market, as a distribution channel, allows
the author to perform agile development. Most of the others either lacks a centre distribution point
or requires a long time review.
In conclusion, the features of the application and the target platform have been confirmed. The
software design of the application can be launched.
14
Chapter 5: Software Design
5.1 Design Principles for Mobile Devices
5.1.1 Balance between Performance and Battery
Unlike desktop applications, performance of mobile application are not only constrained by
hardware, but also the particular usage environment. Though the CPU on almost every computer
has a clock frequency higher than 1GHz, only a few of mobile devices have embraced 1GHz speed.
The memory is normally below 512MB. Even with such squeezed computing power, the application
cannot push them to limits because the mobile devices always have many services running
background to answer the phone call or receive SMS. The application consumed all the computing
power may prevent the device from responding to other critical operations, which is unlikely to be
welcomed by any users. Moreover, the mobile application should be launched instantly without long
loading time. It is highly suggested because in many situations such as on public transport or in
time-critical task users would be annoyed if the application took too much time to load[24].
A mobile application is also restricted to the battery supply of the devices. Though proved to be
very useful, many features such as GPS and WLAN(Wireless Local Area Network) found on recently
mobiles are quite battery consuming. For the developer, it means that the application should make
wise use of the battery hungry services. For instance, the Internet connection should be grouped into
bunches to reduce the time to establish connection. Some local cache or pre-processing should be
helpful, too. These resources should be released quickly once the remote operations are finished.
Maintaining an obsolete service may not seem to be wasteful for a short time. It could be quite a
significant waste when the mobile runs 24 hours a day, 7 days a week[24].
5.1.2 UI design on Small Touch Screen
UI(User Interface) on mobiles is quite different from the desktop application, especially for the
devices with touch screens. First, screens are always small and the pointing mechanics are normally
inaccurate[20]. Both stylus and finger are still far behind the accuracy provided by the mouse on a
desktop. Hence, for instance, the buttons on a toolbar should be placed loosely with enough space in
the middle. Second, single hand usage is common whereas the availability of two hands are always
assumed on a desktop. Hence, for instance, it would be wrong if many actions require two-hand
15
operations to complete. Third, some of the using environments such as noisy spaces could be full of
disturbances so that the users have a higher chance to make mistake. Hence, for instance, an 'Undo'
mechanical should be included in case user did something wrong accidentally.
No matter what the target platform is, these design principles should apply to the development of
any mobile application.
5.2 Android Design Guides
5.2.1 Java + XML + Web
For the development of Android applications, three techniques are normally employed to solve
the particular problem in their scope: Java, XML and Web technology (HTML/CSS/JavaScript)[30].
Java is the programming language for Android platform application development. It comes with a
subset of standard Java libraries with some other commonly used third-party libraries(e.g.
org.apache.http) and Android platform specific libraries. Unlike traditional Java application, after
invoking 'javac', bytecode file will be converted to 'dex' file in compiled time. Then it will be
executed in Dalvik VM. Both 'dex' files and Dalvik VM were implemented by Google for more
efficient mobile computing[7]. The structure of 'dex' can be seen in Figure 14 on page 17. By sharing
constant pool in 'dex' files, the memory is saved via 'minimal repetition, per-type pools typing and
implicit labelling'. Also, the size of 'dex' file is 5~10% smaller than the 'jar' file. Dalvik VM, named
after a small town in Iceland, is a virtual machine designed to 'run a slow CPU with relatively little
RAM and no swap space'. Register machine is used in this case to avoid instruction dispatch and
memory access. Statistic shows that it generates nearly 35% fewer instructions and code units than
traditional virtual machine. For high level application developers, Java is the language to describe
the logic of the programme and establish connection with either local or remote services and
applications.
16
XML, on the other hand, is used to describe the UI structure and store configurable resources[20].
The structure of UI layout, themes and styles of animations, rich text, localization text and
configurations are represented by XML. The biggest advantage of using XML for these purposes is
that by separating design and configuration from logic code, the opportunities to reuse code increase
significantly. Simply referring to the same XML resource in Java code, the redundancy of Java code
reduces. The link between them is established by Android Developer Tools automatically. Thus the
programmers could concentrate on the logic of program rather than the common data exchange.
Moreover, XML is relatively easier to understand and modify than Java code.
Through the embedded WebKit(an open-sourced web browser engine used by Google Chrome)
engine, Android can recruit all the current popular web technology into native application
development. Application can invoke the JavaScript functions and incorporate HTML/CSS text
seamlessly. Furthermore, HTML actions and JavaScript can influence the native Android application
if the security manager allows. This ability to bi-directional communicate breaks the wall between
web and local resources, which are proven to be very useful in Rich Internet Application(RIA)
development.
5.2.2 Activities, Intents and Others
Activity is the core element for most of the Android applications[8]. It can be seen as one view of
screen from user perspective. So as that, the life cycle of activity has a close relationship to the UI
17
Figure 14: 'dex' File Anatomy
interaction. One activity may contain various widgets from simple as buttons and text input to
complex as interactive web elements and 3D objects. It can also have menus, pop-up dialogues or
background thread if needed. Several activities can be group together to form an application. Two
unique features made activities stand out from traditional containers in other application framework.
One is that activity can return value when it finishes. It makes two-way navigation through activity
stack possible. The other is that the activity can be invoked outside the application if permission
allows. So one application can employ an activity in another application to fulfil the intended
feature.
If activities are the discrete nodes of application, intents are the tunnels which carry the messages
between the nodes. Like dictionary, messages in an intent are key-to-value pairs. Intent can be
explicitly send to certain activity or implicitly broadcast. The latter usage can solve the problem
when the system has multiple applications installed with the similar feature. Intents are used in
almost every part of Android systems from transferring information to starting new activity or
service. If declared, intents can be captured and filtered by activities to answer feature request.
There are many other components in Android system. Content provider acts as the generic data
storage for all kinds of local and remote resources, and even databases. Services run off screen to
perform the job without UI interaction such as background music playing. Furthermore, these
components can be extended by adding the existing numerous Java libraries. Thanks to bytecode
compatibility, most of the libraries can be used without re-compiling from source code.
5.3 Project Specific Design
5.3.1 Open and Controllable
Open means the code of the application will be open-sourced. The biggest benefit of being open-
sourced is that it could prolong the lifetime of the project, which in turn could maintain a longer
influence on the public. Normally the influence of an application is likely to diminish once the
development stops. However, source code publicly available provides the opportunity for external
developers to continue the development of the project even if the author stops. Therefore, the
lifetime of the project prolongs.
18
Controllable means the version control system (VCS) will be used to monitor the development of
the project. There are three reasons to employ VCS in this project. First online VCS provides a secure
remote backup of local work files. In case of unpredictable file damage or data corruption, it would
be easier to recover to the normal situation. Second VCS keeps tracks of all the changes made. The
VCS creates revert points when modification of the project directory were committed. If a problem
occurs, the source code and resource can revert to any previous parts of where things were working
correctly. Thus the developers can safely make changes to the project without worrying about
destroying the whole project. These revert points can also be tagged and branched to reflect the
millstones of the development. Along with Project Management software, progress should fall into a
controllable schedule. Last but not least, VCS provides a solution to collaborative development. With
built-in Tree Conflict and Merge tools, the changes made by different developers can be seamlessly
integrated. It is considered to be essential for an open-sourced project because there is always the
chance that two developers working on the same files.
5.3.2 Consistent but Lighter
In order to increase the usability the consistency principle is followed in the UI design, one of the
ten usability heuristics developed by Nielsen[1]. It includes two parts: First, the style and theme
colour should stay consistent with the one used on university portal web page. The distinctive blue
and white text will be used to represent the titles of individual modules as the web site does; Second,
the same terminology and order of them will be employed to describe the identical function. For
instance, the name and order of the material type used in the library catalogue search page will
remain identical in the mobile version.
Though trying to be consistent with the desktop Portal, the limited power of mobile devices
requires the application to be lightweight. For this particular application, it suggests that three rules
should be considered. First, unnecessary effects and graphics should be avoided on interfaces. As
previously stated, the amount of effects and graphics relies on the purpose of the application. For a
life style or utility application such as this project, fancy graphic details may distort the primary
usage and consume more space on precious internal storage. Second, if possible, the application
should reuse the services provided by existing applications rather than developing a new one.
Sometimes this rule is referred as “Do not reinvent the wheel”. For instance, if there is a PDF viewer
available, the application should know how to use the viewer rather than to develop its own PDF
viewer. Android Intent broadcasting and receiving systems provide the fundamental support for this
19
kind of resource reuse. Third, only the most common used operations should be implemented. For
instance, the ability to access the E-resource database and render the material is a reasonable feature
which suites the requirement of mobile office, but the survey indicates a small user group. So this
feature was excluded from the application to keep it lightweight.
5.3.3 Device compatibility
Unlike devices from some mobile manufacturers who control both the software and hardware,
Android devices are extremely diverse. The Android operating system has been reported to run on
various devices with different screen sizes, from 2.8 inch mobile to 10 inch tablet PCs[10]. To ensure
the consistent UI experience across different screen sizes, the rule-based layout is used to describe
the UI. Unlike traditional pixel based UI design, the position of components are determined by the
rules with other components and their parent container. With carefully designed rules, the rule-
based layout can ensure the UI would be automatically scalable on all devices now and future.
The Android OS is evolving rapidly. At the time this report was written, there are three versions
of Android OS officially available on devices: 1.6, 2.1 and 2.2[22]. There are no problems for most of
the functions the application intended to provide because of the downward compatibility. But for the
map function, the system version matters. Early research suggests that there are three ways to
deliver the university map to an Android mobile device. The first is Google Maps, which is available
across all versions. The second is a PDF map downloaded from university, which only has free
viewers on 2.1 and above. Though for Android 1.6 there are paid viewers available, it would be
unwise to prompt a user to purchase those viewers if they haven't. The third is an interactive map
based on Flash technology, which provides the best user experience for campus navigation but only
available on Android 2.2 devices. So when implementing the map feature there should be a method
to cope with various system versions.
5.3.4 Rich documentation
Detailed documentation is generally important for a project to stand long. It covers the comments in
code files, various Wiki pages, issue tracker on the website and the most important, embedded help.
For this particular project, it could benefit the developer, the end user and the future maintainer. For
the developer, these non-code words help to maintain an understandable style across the project. For
the end user, they could get familiar with application without consulting a manual. For the
maintainer, these comments and notes will make future improvement and bug tracing more
20
efficiently.
5.3.5 Internationalize
With the growing international reputation of University of Leeds, international students are a
significant portion of the target group. This presents two problems for this application. First it
requires the application could run on Android devices with other languages. Second the application
should be relative easy to localize in different languages if required. Thanks to XML, these problems
could be solved by separating text resource from the representative code.
5.4 Summary
The design principles and approaches for the application has been stated from the generic mobile
application level, to Android platform level and project specific guidelines. The actuarial
development of the application could begin.
21
Chapter 6: Implementation
6.1 Overview
First of all, “LeedsGo” was picked as the application name. It was selected because the word “Go”
could explicitly tell the mobile nature of this application.
Second, the Logo of the application must be picked. In the beginning, the university logo was
used. Though it represented well, it was changed to another logo created from one of the author's
photographs on Parkinson Building by the request from legal advisor of the marketing department in
the university(See Figure 15).
Then following the style of object-oriented modularization, five modules are proposed to be
implemented as showed in Drawing 1:
This implementation approach was chosen based on two reasons: Firstly the four features
identified from the user requirements have no overlap on resources nor methods between each other.
The benefit of unified or layer implementation approach would not be obvious in this case. Secondly,
the modularize approach makes it easier for other potential developers to derive, branch or replace a
particular feature without breaking the whole application. It also facilitates the maintenance work by
forcing a developer to concentrate on one feature at a time.
22
Drawing 1: Modules in LeedsGo
Email Setup Helper
Campus Navigation Map
RSS Setup Helper
Library Catalogue QueryPortal
Figure 15: LeedsGo on Android desktop
6.2 Tools
Several tools were selected based on the design principles listed in the previous chapter.
The Eclipse Integrated Development Environment (IDE) along with the Android Development
Toolkit (ADT) and Subclipse Team Provider were employed to develop the application. Eclipse
IDE(See Figure 16) was chosen as the main development platform because it provides better
cooperation with ADT. ADT, distributed by Android Open Source Project, provides essential tools to
compile, debug, pack and deploy the application. Subclipse Team Provider is used to connect the
local workplace in Eclipse with the remote VCS via subversion. Java SE 6 compatible OpenJDK 6
provides the fundamental Java tool chain for the developing platform and application.
GNU Image Manipulation Programme (GIMP) is used to create the logo of the application. Other
icons are adopted from various graphic designers under non-commercial licences.
Two Firefox add-ons assisted the development, too. 'ColorZilla' was used to pick up the colours
used on university website, which are crucial to create consistent UI style. 'Firebug' helped the
author to analysis the communication between client and library catalogue in a structural and
systematic aspect.
23
Figure 16: Eclipse IDE with OpenJDK 6 tool chain
Google Code was selected to be the remote project and code hosting site because of its intuitive
bug tracker and Wiki editor(See Appendix D: Links to online resources). Furthermore, it is
convenient to link the project page with the planned distribution channel, the Google hosted
Android Market, by one account.
All the development tools ran on the author's laptop, powered by Fedora 13 i686.
6.3 Modules
Though the four features were implemented modularly, there are some elements shared across
the whole application. First, the structure of UI remains consistent among modules. For each activity,
there is a top bar which represents the title, followed by an interactive and display area in the middle
and a bottom bar with functional buttons(See Figure 17). The middle area is scalable and anchored to
avoid overlapping with the toolbars. This element reflects the consistency principle discussed in the
previous chapter. Second, the messages within and between modules are carried by explicit intents,
in order to avoid using the resource intensive Content Provider(on page 17). This element helps the
application achieve the goal of being lightweight.
6.3.1 Portal
As the entrance of the application, the Portal should do more than emphasise the main UI style,
especially for the interactive area in the middle. The first impression of the middle area is likely to be
a simple list view. To the contrary, the middle area, which presents the list of current implemented
features of the application, is actually a scrollable linear view with customised separating lines.
Compared to the relatively simple list view approach, the linear view benefits the Portal module in
two ways: First it retains the layout for the top and bottom bar, which are essential to represent the
UI theme; Second it grants the developer the freedom to group the individual items. Since the
separating line is just a two pixels wide grey view, it could be placed any where without dealing
with complex sub-lists. However, the customised view also makes it impossible to use some of the
default widget resources, such as visual click feedback.
24
To provide feedback when clicking the individual item in the list, three solutions were considered.
The first one was to create customised clicking animation resources and attaching them to the list
items. Though this approach could provide the best visual effects, it was not favoured due to
additional graphics and prolonging response time. The second was to replace the text on items with
the standard clickable widget. It was dumped immediately because the server distortion to
appearance. The third approach, which came in the later stage of development, is vibrating for a
short time while clicking. Since nearly all the Android mobiles have vibrators, it is safe to assume
that vibration could provide acceptable clicking feedback to most of the users, therefore this was
selected for implementation.
The three “About...” buttons on the bottom bars explain the layout rules for small touch screen UI
principles. By aligning the button to the parental container, the three buttons will be positioned on
the bottom left, bottom centre and bottom right respectively in both landscape and portrait views
and at any screen resolution.
In the Portal activity, each button was bound to a semi-transparent dialogue which displays the
related information retrieved from XML resource and a close button. The information area is
scalable in case of long text(See Figure 18).
25
Figure 17: Portal UI
6.3.2 Library
Being the most required feature from the survey, the development of library module was placed as
the core feature of the application. Hence it came through three stages in the process.
Initially, the library module was supposed to be a completely native client for the library
catalogue, proposed to solve the problem of slow performance on a search page. Using native
Android widgets to display these search options and result was supposed to be faster than using web
browser. Additionally, SOAP(Simple Object Access Protocol) and REST(Representational State
Transfer) methods were assessed to perform client-server communication. REST was preferred for
two reasons at this stage: First it is more lightweight than SOAP for a performance limited mobile
device; Second there is a REST compatible Http client embedded in Android system. Unfortunately,
the native client-server approach proved to be hard to implement within the time schedule and
available resources due to the lack of an API on the library side.
Next the AirPAC interface of the library catalogue was analysed as an alternative. AirPAC is a
legacy interface to the library catalogue for mobile devices. Since the html page returned via the
AirPAC interface is much simpler than normal catalogue returns, it could be possible to use an html
parser to extract the information and present it in a native Android application. However, after
careful examination and various experiments, this approach was dropped because of the following
reasons: First, although the html page returned from AirPAC is relatively simple, it lacks the
Document Object Model (DOM) for efficient html parsing. Second, the existing text parsers were
reported to be slow on Android devices for unclear reasons. Further tests confirmed that the process
of parsing html as text and extracting the information resulted in an irresponsive thread. Third and
the most important is that the actions which the library catalogue service would accept are in an
26
Figure 18: 'About Uni' Dialogue
undocumented area. Though nine of nineteen actions were reverse-engineered, it was still be too
risky for the whole communication to rely on an unclear method. Later in this stage, the AirPAC
embedded in a WebKit view was prompted to be a temporary solution. Development of library
module was forced to pause and implementation moved on to next module.
The final stage started after implementing the Email module. The author started to realize the
power of combining Android application and Web technology and decided to try a new approach to
solve the library issues. As before, the search page was replaced by natively rendered Android
activity which supplies all the advanced options. But this time when clicking the 'Search' button, a
WebKit view will be launched to render the search result instead of parsing received html page in
the background and then rendering to foreground. Experiments suggested that rendering pure html
text in WebKit is actually faster than parsing html pages then rendering in native widgets. So
eventually the library module became a hybrid of a native Android application, which is faster on
rendering complex widgets such as search operations, and a WebKit view, which is faster on
rendering html text. This approach not only provides the fastest speed among all the attempts to
query the library catalogue on a mobile platform, but also reflects the idea of separating control and
representative parts.
The bottom bar in the library module is designed to ease searching action with and without
advanced operations. When the user enters the library module, the 'Keywords' input area will be in
focus while a soft keyboard is ready to accept input. Unlike the default Android application menu
which will be overlaid by the soft keyboard, the bottom bar will be pushed upward and displayed
between input area and soft keyboard(See Figure 19). Hence when user finishes typing keywords,
they can click the 'Search' button on bottom bar to start querying the catalogue. If the users want to
add extra criteria to the query, they can press BACK button to close the soft keyboard as in other
Android applications. The bottom bar will fall downward to the bottom and leave space for other
advanced options(See Figure 20). Because all the advanced operations are rendered with native
widgets, modifying them does not require Internet connection as in web browser. In all, the floating
design of bottom bar makes the switching between common search and advance search simple and
efficient.
The buttons on bottom bar also provide an early checking mechanism to prevent meaningless
querying. If the 'Search' button was pressed with the 'Keywords' field empty, a notification will pop
up to prompt text input rather than performing a useless query. Moreover, if a mistake happened
during either input or adding advanced options, the 'Clear' button will restore all the texts and
27
options to default values.
In the query result page displayed by WebKit view, three small tweaks were conducted to
enhance the browsing experience(See Figure 21). First, in addition to the 'Back' button, the 'Forward'
button is also provided on bottom bar to allow two-way history navigating in a browsing session.
Though the 'Forward' operation may not be used as often as the 'Back' operation when browsing
other web pages, it is a quite common operation when exploring the library catalogue. Second, the
action of 'BACK' (the hard button on the mobile, see Appendix E: HTC Tattoo) button was
overridden to move back in the browser history until it reached the end since the Android standard
web browser does the same. Again, it was performed to keep consistency and avoid confusion for
end users. Last but not the least, the 'Home' button was placed on bottom bar for quick returning to
search activity. It was added on bottom bar since the 'Home' link on the result page is a bit small to
click on the mobile screen.
Several further improvements extended the combination of native widgets and WebKit to
enhance usability. The 'Home' link on the result page was captured and overridden to return to
Android widgets. 'Up' link was dealt with in a similar way. If the link to the E-resource or other
websites is clicked, a dialogue appears to warn that website is unreadable and bandwidth consuming
on the mobile device(See Figure 22). All these overridden actions were implemented to be
lightweight and free from complex pages.
28
Figure 19: Library (soft keyboard open)
Figure 20: Library(soft keyboard closed)
6.3.3 Email
At first, the email helper was planned to be configured for the popular open-source K-9 Mail client.
Once entering the username and password of university email in the helper, K-9 Mail would be
ready to send and receive email without more manual configuration. However, this approach
appeared to be impossible since the K-9 Mail client has not claimed to respond this kind of action in
intent yet, nor have any of the other known email clients. The email helper therefore has to be
helpful in another way.
After examining several mail providers, many of them provide step-by-step guides to help the
users to configure various email clients. For instance, GMail provides individual guides for nine
desktop email client and eight mobile devices and some of them have images attached to explain. In
contrast, there is only one brief guide explaining the technical information of university mail
without a word on mobile devices. Additional computer-science experience is required to set up
email client with this guide. But apparently not all users can be assumed to be at this level. Thus the
goal of email client helper became providing individual step-by-step guides for Android devices.
When entering the helper, the user will be asked to enter their username and choose one of three
most common email clients: Android Email, K-9 Mail and HTC Mail(See Figure 23). By clicking the
'See Guide' button on the bottom bar, a step-by-step guide for the selected email client will be
presented in a WebKit view. As in the Library module, the 'Help' button lay on the bottom left.
29
Figure 21: WebKit view in Library module
Figure 22: Clicking on the link to an external site
At the beginning of each guide, the user will be informed to use the multitasking ability of
Android to switch between email client and the guide. Unlike some other mobile operating systems,
Android allows users to flip between different applications without losing the running status. Hence
the user could return to the guide at any time during the configuration process in email client and go
back.
Instead of using the place holder in the context of guide to refer to user personal informations,
JavaScript was employed to dynamically personalise the guide. A JavaScript function will be invoked
to insert the real username, actual email address and personal server address to the guide by using
the username acquired previously(See Figure 24). It also demonstrates the ability of binding
JavaScript method with Java code on an Android system.
Furthermore, the 'Email' button, 'Username' button and 'IMAP' button on the bottom bar will
copy personal information to the clipboard so that the user can paste them to the relevant fields in
configuration process without typing. For every button clicking, a tip will be displayed to inform the
user which personal information has been copied to clipboard.
30
Figure 23: First impression of Email module
6.3.4 RSS
During the analysis phase of the user requirements, an RSS module was intended to be an
experiment of integrating an existing open-sourced Java RSS library into Android. It was considered
from the observation of RSS reader available in Android Market at that time, when most of them are
using online RSS parsers to process news feeds. When the development of the RSS module started,
the situation changed. Several experimental projects had been established to test the possibility of
processing RSS feeds locally on Android devices and their results seemed to be in a usable shape.
According to the lightweight design principle, the purpose of the RSS module transformed to a
helper with an existing RSS reader.
After careful examination, OI News Reader was selected to be the first RSS reader to support due
to its device compatibility and zero-fee. The remaining problem was the proper way to prompt the
installation. In most of the cases, sending an intent to Market application could accomplish the job of
installation, but only on the devices with Google certification. Hence rather than throwing an
exception and restarting, a notification will be displayed when trying to calling Market application
on non Google devices(See Figure 25). Here it reflects the consideration of device compatibility.
31
Figure 24: Personalized email configuration guide
Since the OI News Reader can add subscriptions from the clipboard, the function of RSS module is
not complex: copying the selected RSS feed address to the clipboard. Currently there are two RSS
feeds available: university news and library news. The actual feed parsing and news reading are
handled by OI News Reader.
Currently there are two news feeds listed in RSS module. This list can be extended easily once
more university RSS were discovered.
6.3.5 Map
The most difficult part in implementing Map module is to deal with different system versions and
different map resources. As stated in the previous chapter, three viewers have different system
version requirements. So when clicking the installation button of the viewers, the system will be
checked to ensure the device has met the minimum requirements. If not, a notification will be
popped up to warn the user(See Figure 26). This should be better than directing a user to the Android
Market and then being denied access due to a lower version.
32
Figure 25: Clicking on a device without Android Market
For the Google Map and Flash-based map, constructing proper intents is sufficient to direct the
user to start navigation on campus. But for the PDF map some extra checking should be done before
launching the installed PDF viewer. When the user starts the PDF map for the first time, it should
download the PDF document from the university web site. From that moment the downloaded
document should be opened when the PDF map is selected. If for some reason the user deleted the
downloaded map, it should get another copy through the Internet automatically. To achieve this
function, a check of file existing and permission will be performed each time. If the check reports
fail, the user would be prompted to download the PDF. Otherwise, it will try to open the local copy
of the map. These methods were used to avoid creating duplicate map copies on storage.
6.4 Documentations
Much effort was dedicated to maintain the documentation work of the project. Inside the
application, the 'Help' button and various pop-up dialogues were created to provide necessary
assistance and feedback as much as possible(See Figure 27). Outside the application, several Wiki
pages were created on the project hosting site to reflect the development status. For instance,
'Release Note' page keeps the records of each updating from the first public release(See Appendix D:
Links to online resources). Every code commit using Subclipse were attached with rich comments to
address fixed bugs and implemented features. All these were done in the hope of making easy for
both end users and future developers.
33
Figure 26: When the system requirement is not met
6.5 Testing
For each code commit during the development, the application should pass several tests. First is the
test on Android Emulators. The Android Emulator is the virtualization of Android devices
distributed with ADT. It is the quickest and most common way to see how the code work during
development. However, these emulators cannot access the Android Market. So as suggested by the
Android Developer Guide, the author's HTC Tattoo(See Appendix E: HTC Tattoo) was used to
perform the second test. It is a Google certified Android 1.6 mobile with QVGA screen. Later it was
flashed to Android 2.1 manually since the platform version monitor indicates that nearly sixty
percent of Android devices run 2.1 version[22].
Additionally, the application was tested on Android x86 LiveCD[29] before hitting the code
frozen phase(See Appendix F: Screenshots on Android x86 devices). It helped the author to address a
handful minor problems when running on a non Google device with WVGA screen. Due the limited
resource, it is currently the best to emulate the application running on a Tablet PC.
6.6 Variations to the PlanDue to the various changes adopted and difficulties encountered, the project plan for implementation
phase was nor strictly followed. However, these variations are considered to be minor on the
following concerns: First, the methodology for implementation phase permits the exists of the
variations. Second, the overall schedule of implementation phase remains unaltered. Therefore, the
evaluation can still be proceeded based on the initial plan.
34
Figure 27: Help in Map module
Chapter 7: Evaluation
7.1 OverviewThis section assesses two of the intend deliverables of this project besides this report.
• A mobile application which fits the specified needs according to the analysis.
1. Whether the marketing value created from this application overpassed the known
competitor.
2. Whether the application delivered better university information service to mobile
device than the existing system.
3. Whether the application achieved the usability goals set up in software design.
• A project which could be used as the foundation of mobile strategy for the university in a
long term.
1. Whether the project received acceptance from the related university departments.
2. Whether the project attracted external developers or online comments.
7.2 Mobile Marketing Value CreatedSimilar to the assessment on UC San Diego(See 3.2.2 Case study: UC San Diego Mobile), the five
mobile values(See Figure 1 on page 5) discussed in 3.1 Mobile Marketing were used to evaluate the
marketing value. The results can be seen in Table 3:
Features Entertainment needs
Spontaneous needs
Efficiency ambitions
Time-critical arrangements
Mobility-related needs
Library S S
Email S
RSS S
Maps S
Table 3: Mobile value evaluation on LeedsGo
Compared to the needs satisfied by UC San Diego Mobile(See 3.2.2 Case study: UC San Diego
Mobile), more time-critical needs are satisfied by “LeedsGo”, which in turn will generate better
result to the marketing strategy than other satisfactions. Also, the personalised email guide provided
by “LeedsGo” can also be an additional benefits to marketing value according to the discussion on
page 7.
35
7.3 Comparison to the Existing SystemsThe improvement of the application can be seen from comparison with existing systems in terms of
readability and easiness. Readability was assessed by the presentation. Easiness was assessed by the
difficulty to achieve a certain task. This comparison was performed on a mobile with the most
common 320*480 resolution. Images were scaled as 50% of original sizes.
The existing AirPAC interface of the university library is barely readable for its small font
size(See Figure 28) whereas the entry information in “LeedsGo” was zoomed to a comfortable size for
reading(See Figure 29):
At the time of writing, the library has deployed a new mobile-optimised interface for catalogue
querying (See Figure 30).Though it is far better than ordinary view and old AirPAC, it lacks the
advanced options as seen in LeedsGo(Figure 31) and there is no way to switch back to desktop view
with advanced options.
36
Figure 28: Old AirPAC entry view
Figure 29: LeedsGo entry view
As stated in 6.3.3 Email, the current guide on email setup is too simple for average users to
configure the email client. Even worse, it has to be accessed from a desktop PC. In contrast, LeedsGo
delivers step-by-step personalized guides to configure the mobile email client(See Figure 34).
Although configuring an email client require more steps than using email website directly, once
configured, the user can access the university email box on a higher level of readability as shown in
Figure 32 than as in Figure 33. Additionally, email push feature provided by email client can be very
helpful in a time-critical situation.
There is no guide for how to use RSS news feed on mobiles from the university. If the user
proceeded the same way as on a desktop, he/she will get a page full of meaningless XML(See Figure
35). With the guide in LeedsGo(See Figure 36), he/she will have a comfortable view of the university
37
Figure 34: Step-by-step email setup guide in LeedsGo
Figure 30: New AirPAC query view
Figure 31: LeedsGo query view
Figure 32: Standard email client on Android
Figure 33: Email in standard Portal site
news(See Figure 37) and alert when something new was published.
So far the campus map of the university can only be accessed by site search or going down two
levels of navigation(Click “Campus Life” on the university index page and select Campus map). It
would direct user to an interactive screen which is only viewable on high-end Android mobile. Users
with other mobile or low-end Android mobile will see nothing but an empty page(See Figure 39)
with no link to other alternatives. However, LeedsGo provides three kinds of maps for different
needs and systems in one view and an understandable error message when the system version is
lower than required(See Figure 38).
38
Figure 35: RSS feed without proper configuration
Figure 36: RSS configuration helper in LeedsGo
Figure 37: RSS news feed in configured reader
Figure 39: Interactive map on a mobile without Flash
Figure 38: Maps provided in LeedsGo
From the comparison above, the LeedsGo proved to be a better system on the level of readability
and easiness. It delivers a better university information service to mobile devices than the existing
system.
7.4 Usability Test
7.4.1 Method and Task List
To scientifically collect feedback from end user tests, a method and a task list were derived from
heuristics evaluation. Heuristics evaluation was developed by Nielsen[11] as an “usability
engineering method for finding the usability problems in a user interface design”. It was derived but
not implemented directly because a normal heuristics evaluation involve several evaluators, which is
unlikely to be achieved in this project.
The usability test lists contains five pages, one page of operating guide and one task list for each
module(See Appendix H: Usability Test). The email module was made as an optional test due to
privacy concerns. It might be inappropriate to require every participant to set up her private email
account on a test machine. In the operating guide, the aim and method of the test is declared with a
list of common actions of Android operating system and a short exercise to practise those actions.
Moreover, as suggested in heuristics evaluation, the participants are informed on how to use the
built-in 'Help' button and seek help from the evaluator during the task. The task list of each module
contains four parts: 1) the starting time and the finishing time; 2) module specific guidelines; 3) the
step-by-step task and 4) six five-level self-report questions(See Table 4) as criteria derived from ten
usability heuristics suggested by Nielsen[1].
Initial plan was to examine the existing system and “LeedsGo” parallel in the usability test. It was
discarded later due to the lack of corresponding equivalents in the existing system. Except library
service, the existing system only has functional equivalents to “LeedsGo” but not user interface
equivalents. Examining the functional equivalents in a user interface usability test might not be
appropriate. Moreover, those functional equivalents were compared in 7.3 Comparison to the
Existing Systems with advantages showed by 'LeedsGo'.
7.4.2 Subject and Practise
Participant recruiting was accomplished by attaching posters(See Appendix G: Poster) on the public
notice board in Brotherton Library, Edward Boyle Library, Health Science Library, Self-access Area
in the Language Centre and the Reception of Language Centre(See Figure 40). Brief description of
the application and the contact method of the author were included in the poster.
39
In all, the author got seven replies. The time and the place of the test were arranged with each
individuals. During the test, HTC Tattoo(See Appendix E: HTC Tattoo) with Android 2.1 was handed
to the participant as the test machine, along with the task papers and essential stationary(See Figure
41).
7.4.3 Result
Given an application on this scale, seven participants should be enough to identify any major UI
interface problems. The result can been seen in Table 4.
40
Figure 41: A photo of the usability test
Figure 40: One of the posters in Edward Boyle Library
Mean of Agreeableness(5: Most Agree)
Library Email* RSS Map
The feature is useful. 4.43 5 4.57 4.71
The system is fast. 4.14 4.5 4.29 4.43
The application is easy to use. 4.86 3 4.86 4.86
The feedback is sufficient. 4.57 4.5 4.43 4.57
The help message is understandable. 4.71 3 4.57 4.86
The interface is well organized. 4.57 4.5 4.71 4.71
Table 4: Result of usability test
* 2 of 7 participants chose to complete the email test.
The table above suggests a generally positive feedback of the application. However, email
modules seemed to lack a bit from other modules in terms of easiness of use and understandability of
help message. After discussed with the participants, a new dialogue with further detailed help
information was added to email module. Another release was issued and published to the Android
Market immediately.
7.5 Related University Departments: Library and ISSSadly, ISS showed no interest to evaluate nor accept this project as an Android client of the
university. However, the author was told that the ISS is planning to recruit the external company
who developed UC San Diego Mobile to develop an iPhone application for university. Therefore the
advantages of “LeedsGo” over UC San Diego Mobile on 7.2 Mobile Marketing Value Created may
also be applied to the system which ISS is going to employ.
Though one of the system administrators in the library showed great interested and provided
help during the development of “LeedsGo”, the time constrains in summer vacation prohibits the
staff from performing a formal evaluation on this project. However, the staff personally ensured the
author that the AirPAC interface will be kept maintaining as long as “LeedsGo” is using.
7.6 Comments and Issues from OnlineTo prompt this application online, the author has been posting every release to all known social
network websites related to the university. From the information provided by Android Developer
Console, there are 34 users who had browsed the application and 12 of them actually installed and
are currently using it. Unfortunately, there has been no comment on Android Market. Hence the
online attitude towards this application is unclear.
Though project drew a few attentions within the open-sourced Android application community,
41
so far there has been no external developer or tester involving. The bug tracker on Google Code
remains empty.
7.7 SummaryFor the application, the feedback from the evaluation was generally positive. First it overpassed the
UC San Diego Mobile(a representative of the future iPhone application deployed by ISS) in terms of
the marketing value generation. Second it showed significant advantage on the level of readability
and easiness over the existing system. Last but not the least the usability test from end users can be
considered as successful.
The evaluation of the project is not as optimistic as the application. Despite the efforts, the project
received little interests from related departments. Online external developers and testers are basically
non-exist.
42
Chapter 8: Conclusion
8.1 LimitationsThere are some limitations in this project which are worth to be discussed here.
• Effect of marketing value in reality
Thought the marketing effect of the application was generally positive the effect of the added
marketing values from a mobile strategy might take a long time to appear. The expected
effects in reality includes but is not limited to increasing user numbers, external application
developers, higher satisfaction towards the university services and better reputation and
famousness of the university. Due to the time scope of the project, these measures can hardly
be examined at the current phase.
• Support from related departments
The project was developed independently from the related university departments. Previous
research suggests that the integrated support from the organization is important to the
success of the mobile strategy[9]. Hence stronger interaction among various departments
should be established to ensure the employment of the solution.
8.2 Future ImprovementsSome improvements can be done in the future for the application and the project.
• Web-based services integration
In the late stage of the project, the author noticed a mobile project carried by another student
in the university but in a different approach[21]. In that project, REST-based service was
employed to get the information of the clusters and building views on a Symbian S60 system.
The result seems to be quite positive. Though these features are not highly required
according to the user survey, they could be good complementaries to the existing “LeedsGo”
features if more technical details on those REST-based service are exposed.
• Accurate navigation using WLAN
During the project design phase, the author was informed an idea to provide precise campus
navigation service. Though the idea was dropped in the current design due to the inaccuracy
of GPS system and constrained project schedule, it could an area for the future maintainer to
implemented by using WLAN. By pairing the unique hardware address of a wireless router
43
with its geographical locations, a map could be established. The location of the mobile
devices can be positioned by triangulating the distances of the nearest wireless access routers.
Besides the improved accuracy in campus navigation, another advantage of this WLAN
based positioning is that it can be used indoor, suggested by other literature[2]. However, the
process to establish the map would be extremely complex and involve lots of cross-
department cooperation.
8.3 SummaryIn conclusion, by following the principles on investigating unknown marketing field, the project has
delivered an analysis about the mobile marketing. Then an Android mobile application was
developed to solve the particular defects identified from the analysis. Generally positive feedback
was credited to the application but there is still a long way to strength the open-sourced project.
44
Bibliography[1] 10 Heuristics for User Interface Design.
http://www.useit.com/papers/heuristic/heuristic_list.html. Accessed: 08-04-2010.[2] Aittola, M. et al. 2003. SmartLibrary - Location-Aware Mobile Library Service. Human-
Computer Interaction with Mobile Devices and Services. 411-416.[3] Anckar, B. and D'Incau, D. 2002. Value creation in mobile commerce: Findings from a
consumer survey. The Journal of Information Technology Theory and Application (JITTA). 4, 1 (2002), 43–64.
[4] Apple WWDC liveblog: new iPhones and software - and the rest | Technology | guardian.co.uk. http://www.guardian.co.uk/technology/2010/jun/07/apple-wwdc-iphone-announcement. Accessed: 06-15-2010.
[5] BlackBerry - BlackBerry 6. http://na.blackberry.com/developers/blackberry6/. Accessed: 08-20-2010.
[6] Bocij, P. et al. 2008. Business Information Systems: Technology, Development and Management for the E-Business. Financial Times/ Prentice Hall.
[7] Bornstein, D. 2008. Google I/O 2008 - Dalvik Virtual Machine Internals.[8] Burnette, E. 2009. Hello, Android: Introducing Google's Mobile Development Platform. Pragmatic
Bookshelf.[9] Corlett, D. et al. 2005. Evaluation of a mobile learning organiser for university students.
Journal of Computer Assisted Learning. 21, 3 (2005), 162–170.[10] Dell roadmap shows 'Sparta,' 'Athens' Android netbooks amid smartphones | Android Central.
http://www.androidcentral.com/dell-roadmap-shows-sparta-athens-android-netbooks-alongside-smartphones. Accessed: 08-26-2010.
[11] How to Conduct a Heuristic Evaluation: http://www.useit.com/papers/heuristic/heuristic_evaluation.html. Accessed: 08-22-2010.
[12] HP's Palm purchase: the analysis | Technology | guardian.co.uk. http://www.guardian.co.uk/technology/2010/apr/29/hp-buys-palm-analysis. Accessed: 06-15-2010.
[13] Intel and Nokia look together to post-PC world | Technology | guardian.co.uk. http://www.guardian.co.uk/technology/blog/2010/feb/15/intel-nokia. Accessed: 06-15-2010.
[14] Java ME - the Most Ubiquitous Application Platform for Mobile Devices. http://www.oracle.com/technetwork/java/javame/overview/index.html. Accessed: 08-20-2010.
[15] Kaplan, E. and Hegarty, C. 2006. Understanding GPS: Principles and Applications Second Edition. Artech House. (2006).
[16] Katsianis, D. et al. 2001. The financial perspective of the mobile networks in Europe. IEEE Personal Communications. 8, 6 (2001), 58–64.
[17] Kotler, P. 2008. Principles of Marketing. FT/Prentice Hall.[18] Mahatanankoon, P. et al. 2005. Consumer-based m-commerce: exploring consumer perception
of mobile applications. Computer Standards & Interfaces. 27, 4 (Apr. 2005), 347-357.[19] Mobile Phones | Choose the Best Phone for You | Windows Mobile.
http://www.microsoft.com/Windowsmobile/en-us/default.mspx. Accessed: 08-20-2010.[20] Murphy, M. 2010. Beginning Android 2. APRESS.[21] Norman, C. 2010. University of Leeds Web-Based Services Mobile Phone Application. University
of Leeds, School of Computing Studies.[22] Platform Versions | Android Developers.
http://developer.android.com/resources/dashboard/platform-versions.html. Accessed: 08-26-2010.[23] Riivari, J. 2005. Mobile banking: A powerful new marketing and CRM tool for financial services
companies all over Europe. Journal of Financial Services Marketing. 10, 1 (2005), 11-20.[24] Salmre, I. 2005. Writing Mobile Code: Essential Software Engineering for Building Mobile
45
Applications. Addison-Wesley.[25] School of Computing. http://www.engineering.leeds.ac.uk/comp/. Accessed: 08-18-2010.[26] Symbian makes its smartphone software open source | Technology | guardian.co.uk.
http://www.guardian.co.uk/business/2010/feb/04/symbian-smartphone-software-open-source. Accessed: 06-15-2010.
[27] UC San Diego Mobile Home Page. http://mobile.ucsd.edu/. Accessed: 08-18-2010.[28] Walton, G. et al. 2005. Using mobile technologies to give health students access to learning
resources in the UK community setting. Health Information & Libraries Journal. 22, s2 (2005), 51-65.
[29] Welcome to Androidx86. http://www.androidx86.org/. Accessed: 08-26-2010.[30] What is Android? | Android Developers. http://developer.android.com/guide/basics/what-is-
android.html. Accessed: 08-20-2010.[31] Windows Phone 7 Series is official, and Microsoft is playing to win -- Engadget.
http://www.engadget.com/2010/02/15/windows-phone-7-series-is-official-and-microsoft-is-playing-to/. Accessed: 08-20-2010.
46
Appendix A: Personal ReflectionThis project was the biggest work the author have taken during the MSc course. It gave the author
the opportunity to understand the rapidly growing mobile industry from the big marketing overview
to the small single application development. There are some experiences the author would like to
share with the future researchers:
• Work as an open-sourced project, not a close-door application
Though the author has been actively involving with various open-sourced project for years,
this project was the first the author has owned. During this process, the author learnt much
more than just writing application code. Monitoring the tracker system, examining the
branches, maintaining documentations are some of the exciting experiences which are not
easily achieved in a close-door development process. There is no doubt that those experiences
will be inevitable useful in future computing related working environment.
• Get in touch with related departments early
Even for a project which only has reliance on university departments, there is a necessity to
get in touch with as early as possible. It is suggested to explain every detail and leave
sufficient time to them, especially involving university proprieties. In this case, the project
was paused for a while by the marketing department due to the usage of the university logo.
Many of the text and graphic had to been replaced, which causes enormous unnecessary
work. To avoid this turbulence in future development related to the university, the author
suggests to discuss every detail with related departments before start.
• Choose a project with meaningfully challenge
The author himself has quite enjoyed the development process of the project. The enjoyment
of creating something valuable has been the major motivation to power the every day
coding, documenting and writing. This feeling origins from the choice of project. First the
Android application development is techniques the author had been willing to learn for a
long time. Second the skill required roots on the known knowledge of Java, but has
significant difference, which in turns to be an achievable goal once sufficient efforts were
devoted.
Hopefully, these experiences would be helpful for future attempts on this area.
47
Appendix B: Gantt Chart
48
49
50
Appendix C: Interview to UC San Diego
What motivated UC San Diego to employ a mobile strategy?
Which are the factors that led to maintaining two native applications(iPhone and BlackBerry) and mobile web?
Does it target the general population in university or some specific groups? Like teaching fellows, prospective student, current students or research academics et al.
Why was bespoke development the choice for UC San Diego? What about in-house or on-shelf approaches?
What is the most difficult part in the whole process of deploying mobile strategy?
What are the benefits gained from mobile strategy?
How would you evaluate the mobile strategy on UC San Diego on a scale of 1-5 (5 is the best)? What about the future plan on this?
51
Appendix D: Links to online resources
• Public user requirement survey: https://spreadsheets.google.com/viewform?formkey=dE1Ga3pXd2JkSFRkWTJGMDRfWVRFSlE6MA
• Google Code Project Host: http://code.google.com/p/leedsgo/
• Public accessible code tree: http://code.google.com/p/leedsgo/source/browse/
• Release Notes: http://code.google.com/p/leedsgo/wiki/ReleaseNotes
• Brief description with screenshots: http://code.google.com/p/leedsgo/wiki/Screenshots
• Application binary download: http://leedsgo.googlecode.com/files/LeedsGo.apk
52
Figure 42: QRCode to LeedsGo binary download
Appendix E: HTC TattooDownload from: http://www.htc.com/www/product/tattoo/gallery.html
53
Appendix F: Screenshots on Android x86 devices
54
Figure 43: 'LeedsGo Portal' on Android x86
Figure 44: 'LeedsGo LibrarySearch' on Android x86
55
Figure 45: 'LeedsGo LibraryWeb' on Android x86
Figure 46: 'LeedsGo EmailGuide' on Android x86
Appendix G: Poster
56
Appendix H: Usability Test
Thank you for participate the usability test for 'LeedsGo'. It aims to assess the usability of this Android application developed for University of Leeds. Hence none of your personal information will be asked or recorded.
HERE are some Android mobile operations you might use during the test:
• Rotate mobile to switch between Landscape and Portrait view.
• Press HOME button to return to home screen (desktop).
• Long press HOME button to switch between launched applications.
• Press BACK button to return to previous screen or web page. It can close the soft keyboard, too.
• All the applications you would need were placed on desktop. They can be accessed at any time when pressing HOME button.
BEFORE starting the tasks, please follow the instructions to get familiar with Android operating system. ASK IF HAVE ANY PROBLEMS:
1. Tap 'LeedsGo' icon on desktop to launch 'LeedsGo'.
2. Rotate mobile to switch between Landscape and Portrait view.
3. Press HOME button to return to desktop.
4. Tap 'Email' icon on desktop to launch 'Email'
5. Type “Hello” in email address with the soft keyboard.
6. Press BACK button to close the soft keyboard.
7. Long press HOME button.
8. Select 'LeedsGo' from popped up application switcher.
9. Click 'About Me' to see version information.
10. Click 'Close' or use BACK button to close the dialogue.
11. Long press HOME button again.
12. Select 'Email' from popped up application switcher.
13. Check whether “Hello” is still there.
14. Press BACK three times to close the applications and return to desktop.
Three features in 'LeedsGo' are going to be tested with one optional. Follow the instructions and use the 'Help' button inside the application to complete the tasks. Please give rate to each features BEFORE proceeding to the next one.
Turn to the next page for the first test when you are ready.
57
Uni Library
Time on start:
READ BEFORE START:• Press BACK button to close soft keyboard.
• To open soft keyboard, click the text input area or long press MENU button.
• Select 'Uni Library' in 'Portal' of 'LeedsGo' to begin the task.
Task 1:1. Try to find a book called 'The Adventure of English'
2. Find the information about its availability and location in library.
Task 2:1. Get ready to start another search.
2. This time, please try to find all the public materials between 1900 to 2009 on the topic of 'Java'. Sort the results by the relevance.
Time on finish:
1 Strongly Disagree / 5 Strongly Agree
The feature is useful. 1 2 3 4 5
The system is fast. 1 2 3 4 5
The application is easy to use. 1 2 3 4 5
The feedback is sufficient. 1 2 3 4 5
The help message is understandable. 1 2 3 4 5
The interface is well organized. 1 2 3 4 5
Turn to the next page for the second test when you are ready.
58
Email Helper (Optional)If you have never used Outlook, Thunderbird, Apple Mail or any other email clients before, you can safely skip this task. ASK if I confused you. ;-)
Time on start:
READ BEFORE START:• Now you are going to configure the an email client to send and receive email using
university account.
• Make full use of multitasking: Long Press HOME button.
• The 'Email', A.K.A 'Android Email Client', is on the desktop.
• Feel safe to use your own email account in the test. Nothing is going to lose. After the task, your login detail will be completely removed from this mobile whereas all your email will remain untouched on remote email server. ASK if you have any concern.
• To paste, long pressing text input area and select 'Paste' from pop-up.
• Select 'Email Helper' in 'Portal' of 'LeedsGo' to begin the task.
Task:1. Type your ISS username in 'Username'
2. Select 'Android Email Client' and then click 'See Guide'.
3. Press HOME button to return to desktop.
4. Tap 'Email' icon to launch.
5. Long pressing HOME button to switch back to 'LeedsGo'.
6. Follow the guide to complete the configuration.
Time on finish:
1 Strongly Disagree / 5 Strongly Agree
The feature is useful. 1 2 3 4 5
The system is fast. 1 2 3 4 5
The application is easy to use. 1 2 3 4 5
The feedback is sufficient. 1 2 3 4 5
The help message is understandable. 1 2 3 4 5
The interface is well organized. 1 2 3 4 5
Turn to the next page for the third test when you are ready.
59
RSS News Feed
Time on start:
READ BEFORE START:• Now you are going to add the university RSS news feed to the 'OI News Reader' application
to keep in touch with anything new in university.
• 'OI News Reader' is installed and it's on the desktop.
• Nothing needs to be changed when you add the subscription to the 'OI News Reader'.
• ASK for help if you have any problem in the 'OI News Reader'.
• Select 'RSS News Feed' in 'Portal' of 'LeedsGo' to begin the task.
Task:1. Select 'Library News' and click 'Add Subscription'.
2. Press HOME to return to desktop and tap 'OI News Reader'.
3. Click 'Add feed'.
4. Click 'Add clipboard feed'.
5. Press BACK to close keyboard and click 'Save'.
6. Press BACK again.
7. Check whether you could see the 'Latest News'.
Time on finish:
1 Strongly Disagree / 5 Strongly Agree
The feature is useful. 1 2 3 4 5
The system is fast. 1 2 3 4 5
The application is easy to use. 1 2 3 4 5
The feedback is sufficient. 1 2 3 4 5
The help message is understandable. 1 2 3 4 5
The interface is well organized. 1 2 3 4 5
Turn to the next page for the fourth test when you are ready.
60
Campus Map
Time on start:
READ ALL BEFORE START:• Now you are going to view the campus map in two ways.
• 'Google Maps' and 'Adobe Reader' are installed and the latter one is on the desktop.
• ASK for help if you have any problem in the 'Google Maps' or 'Adobe Reader'.
• Select 'Campus Map' in 'Portal' of 'LeedsGo' to begin the task.
Task:1. Select 'Online Map' and click 'View Map'.
2. Check whether you can see the map. Press BACK to return.
3. Select 'PDF Map' and click 'View Map'.
4. Be patient while downloading. Tap to open it with PDF reader.
5. Check whether you can see the map. Fully close all the application by pressing BACK button several times until reaching the desktop.
6. Re-launch 'LeedsGo' and try to view 'PDF Map' using similar steps.
7. There should be no need to download and the map should be ready to view directly this time.
Time on finish:
1 Strongly Disagree / 5 Strongly Agree
The feature is useful. 1 2 3 4 5
The system is fast. 1 2 3 4 5
The application is easy to use. 1 2 3 4 5
The feedback is sufficient. 1 2 3 4 5
The help message is understandable. 1 2 3 4 5
The interface is well organized. 1 2 3 4 5
This is the final test! Thank you for your participation.
Please feel free to tell the author if you have any thoughts on this test, application or mobile for Leeds University.
61
Supervisor's comments on the Interim Report
Assessor's comments on the Interim Report
Introduction
Implement Technology in Marketing Activities of UniversitiesMarketing plays an important role in the development of all kinds of organizations, no exception
for University of Leeds. In the scope of marketing, university provides not only education service to thousands of students and but also a joint research platform to industrials. Generally, the implementation of technology could benefit the service provider in three ways. First, to compete in the field of service providers, it it generally crucial to “send the right signal about the service quality”[1]. In the case of Faculty of Engineering, the integration of front line technology into teaching and researching activities would be that signal for prospective students and potential industrial partners to present the intangible service quality in a tangible way. Second, technologies can facilitate the management of service quality. Previous study in top services organizations suggests that the deployment of self-service technologies has positive relationship with customers' satisfaction [1] . From that aspect, easy access to common activities in a self-serviced way on campus is likely to increase satisfaction of both students and the staff. Last but not the least, technologies can enhance the productivity of service providers[1]. For instance, the groupware in large organizationals are suggested to break the boundary of traditional discrete work and lead to changes of collaboration in an infrastructure level[2].
As non-profit providers of service, technologies means more for university marketing than general ones discussed above: it can solve some of the conflict between multiple publics, which is very common in non-profit education institutions. The appliance of 'Desktop Anywhere' is a good example to explain the usefulness of modern technologies. Increasing students demand more computers in clusters to access faculty specific software. Though it could be solved by simply purchasing more computers and opening a new cluster, these actions require large number of budgets and extra maintenance cost. Also, it would a significant overhead if the students number dropped. Most important, these money could have better use on improving existing or purchasing new research equipments and materials. By liberating remote desktop and virtualization powered 'Desktop Anywhere', the budgets of purchasing new computers for cluster can be saved for the upgrading research equipments while students can access faculty specific software from their own computers legally. Both students and academics are satisfied.
Universities Adoption of Mobile TechnologiesMobile devices, as a representative of fast-growing technology, could be a prefect candidate for
the university who wants to integrate the modern technology to its marketing activities. By implementing mobile technology, first it demonstrates the awareness of the latest technology, which would attract students who seek to learn growingly practical technology. The public image in the eyes of industrial partners would enhance, too. Second, it constructs a new channel for self-service and teamwork. Students and staff could be free from the computers in the clusters or office when the learning and research resource are accessible over the air. Eventually it should lead to higher satisfaction and better production. Third, it could be a complement for the existing 'Desktop Anywhere', which further relieves the light usage demands for cluster computers.
Most of the successful cases on the adoption of mobile technologies are in north American universities. However, research on questionnaires from health students in Northumbria University indicates the high awareness of the mobile technology and high demands for the implementation among students in UK[3]. They reveals two fields where mobile technologies were proved to benefit the universities: library service and general utilities. Extending the boundary of library service is probably the major reason for university to implement mobile technology. Athabasca University in Canada has been conducted a well-designed project to offer library service for students who enrolled in national distance education programmes. First they re-engineered their library catalogue website
so that it could automatically select between small-screen optimized page for mobile devices and default page for desktop computers[4]. Then they conducted a series of experiments to deliver access-restricted PDF journal articles and multimedia materials to PDA as a part of digital reading room programme[5]. Beyond general success, the project in Athabasca University also reveals a common problem in the process of implementing mobile technology: lack of standards. Extra tweaking and testing should be done to ensure the consistent experience across all mobile devices, in their cases, Pocket PC and Palm Pilot. Though huge advancement take place in mobile industrials since the time of mobile project in Canada, this problem still can not be ignored in our project and will be further discussed later. In the field of general utilities, mobile devices can be used a learning organizer and university portal. In 2004, University of Birmingham evaluated the affect of mobile learning organizer on a group of undergraduates[6]. They comprised pre-installed calendar and messenger and 3rd party concept mapping applications to provide time management, communication and content access services on their handled computers. The result indicates the demand of mobile appliance support from institutions. Five years later, University of San Diego went further to deliver university services over the air [7]. Created by paid mobile application design company, about 7800 students there can performed variety of activity from their smart phone, including registration, GPS navigation and library catalogue etc. After receiving positive response from students, the university is planning to move more relative departments like union and school bookshop to the mobile platform.
Problems and AimsDespite the moving trend and successfully cases, there are some choices which worth to be ask
before implementing mobile technology in university. First, are we going to create a small-screen optimized website or native mobile applications? Small-screen optimized website is relatively easy to maintain and distribute. Because the web browser is the only requirement for using this service, virtually any phone within the last three years could view the website in mobile layout. However, due to the chaos of mobile browser market and general ignorance of web design standards, the consistency of user experience and performance are not guaranteed[8]. Quite a large amount of modification are also required to apply on currently running website. In the other hand, native applications have the advantage of fast performance and better GUI while users have to manually install and upgrade. The downside of this approach is that only recent smartphones have the capability to run those customized applications. The users with featured phones can not benefit from them. Second, which mobile platform are we going to enter? For many featured mobile devices, their on-stock browsers have limited support over JavaScript and CSS, which means popular website interaction-boosting technology AJAX(Asynchronism JavaScript and XML) can not function. Choice has to be made between compatibility and user experience if we go to the road of small-screen optimized website. Unfortunately, the market of smartphones is even more fragmented. With six completely different smartphones operating systems competing and zero application level compatibility, choice has to be made between Symbian Foundation S60[9], Apple iOS[10], Google Android, HP/Palm WebOS[11], Microsoft WM6/7, and Intel/Nokia MeeGo[12].
After thoughtful consideration, we aimed to create an Android mobile application in our project to explore the affect of mobile application on Leeds University marketing activities. Native application approach was chosen to avoid the turbulence of main web service and enhance user experience. Android platform was focused due to the following three reasons. First, Android is a fast growing platform which targets all kinds of mobile devices from smartphones to Tablet PCs. It means users with diverse handled computers could have same experience of our application. Second, unlike other smartphone operating systems which can only be seen on high-end mobiles, the price of Android-based devices covers a wide range, from around £130 to more than £400. Users have plenty of options according to their demands and economic status, in other word, our application could benefit people with different backgrounds. Third, development process of Android is much friendly than others. Its SDK is operating system neutral and distributing application in Android
Market does not require months of verification. Moreover, our in-house developed application would like to examine fields of both library service and general utilities. User survey and structural interviews will be conducted to collect responses from end users and related departments.
Analysis and Design
User requirement specificationOnline survey was conducted to see investigate requirement specification. Results shows that
library catalogue is the most demanding feature on mobile, followed by campus navigation. However, due to the lack of the necessary information and accuracy limitation on direction in a relatively small area, campus navigation is not practical to implement in current situation. Though Email account and University news RSS feed were not ranked high from user requirement, they were picked as the experiments for general utilities after discussion.
Software design
Development MethodologyThe development methodology contains three phases. The first phase focus on general
requirement assessment and application framework. In this phase, sequential steps will be taken to understand user requirement and initialize framework from the information. Next phase contains three relatively individualized components. The approaches to achieve module functioning will be slightly different based on the certainty[14]. For library module, it will be waterfall-like with a series of steps undertaken one by one. For email module and RSS client module, rapid prototype method will be used to maximize the usability and functionality. Testing will be conducted at the end of each module. The final phase aims to link three modules to the main portal. The stability as an application will be assessed at the end of this phase.
PlanningSee Appendix 1
Implementation
CodingThe application would be comprised by five components: main portal, library catalogue, email client helper, RSS feed helper and .
Main portal will present a screen with icons which directs users to other three components. It should leave space for adding further components.
To establish communication with library database in catalogue component, three approaches were assessed. First one is SOAP based. Though it is feature rich and close with new Encore interface of the library, it is dumped because SOAP is highly resource intensive, which is not suitable for mobile devices with limited power and battery. Second and third way both deal with HTML like syntax. The difference lies on using WML(Wireless Makeup Language), which is a derivation of HTML for mobile, or standard HTML. After carefully examining the return document, WML one was discard because of the missing 'Comment' attribute in book description.
Email client helper involves interaction with the most popular email client K9Mail. First the helper will ask the user for her ISS username and password. Then it will construct the correct IMAP and SMTP server configuration and forward to K9Mail. After that, the university email should be ready to use in K9Mail. It diminishes hassles to figure out unnecessary technical details like encryption method and port numbers for average users.
Unfortunately, Android platform does not include a RSS client on stock. Hence news RSS feed retrievers simulate RSS feeding in two way: native RSS parser or RSS reader in cloud. After browsing thoroughly on Android Market, most of them calls Google Reader, one of the most popular RSS reader in cloud as parser. If not using the service in cloud, they are mostly propriety ones, which are unlikely to be cooperated due to isolated sandbox design of Android platform[13]. Google Code hosts a experimental project to create a native RSS client. We will examine the possibility to use both approaches to provide university news feeds.
Testing and FeedbackComments from beta testers.
Evaluation from relative departments (library)
Structural interview with some testers.
Discussion
Result and Feedback
Limitation and Future improvement
Limitation
Plenty of room to feature extension
Some influence on marketing will take time to emerge
Improvement
Lightweight REST-based bi-directional communication with library catalogue: Much efficient and standardised than current implementation
CalDAV: open and cross-devices calendar and time management sync OTA, perfect solution for time management
Conclusion
Reference[1] Principles of Marketing, Harlow: FT/Prentice Hall, 2008.[2] J. Grudin and L. Palen, “Why groupware succeeds: discretion or mandate?,” Proceedings of the
fourth conference on European Conference on Computer-Supported Cooperative Work, Stockholm, Sweden: Kluwer Academic Publishers, 1995, pp. 263-278.
[3] G. Walton, S. Childs, and E. Blenkinsopp, “Using mobile technologies to give health students access to learning resources in the UK community setting,” Health Information & Libraries Journal, vol. 22, 2005, pp. 51-65.
[4] Y. Cao, T. Tin, R. McGreal, M. Ally, and S. Coffey, “The Athabasca University mobile library project: increasing the boundaries of anytime and anywhere learning for students,” Proceedings of the 2006 international conference on Wireless communications and mobile computing, Vancouver, British Columbia, Canada: ACM, 2006, pp. 1289-1294.
[5] R. McGreal, T. Tin, B. Cheung, and S. Schafer, “The Athabasca University digital reading room: library resources for mobile students,” Proceedings of the MLearn 2005 Conference. Qawra, Malta: IADIS, 2005.
[6] D. Corlett, M. Sharples, S. Bull, and T. Chan, “Evaluation of a mobile learning organiser for university students,” Journal of Computer Assisted Learning, vol. 21, 2005, pp. 162–170.
[7] C. Harnick, “Universities need to embrace mobile: University of San Diego,” Mobile Marketer, Sep. 2009.
[8] G.L.R. Frederick, Beginning Smartphone Web Development: Developing Applications for iPhone, Android, Palm Pre, BlackBerry, Windows Mobile and Nokia S60, APRESS, 2010.
[9] “Symbian makes its smartphone software open source | Technology | guardian.co.uk,” Feb. 2010.[10] “Apple WWDC liveblog: new iPhones and software - and the rest | Technology |
guardian.co.uk,” Jun. 2010.[11] “HP's Palm purchase: the analysis | Technology | guardian.co.uk,” Apr. 2010.[12] “Intel and Nokia look together to post-PC world | Technology | guardian.co.uk,” Feb. 2010.[13] E. Burnette, Hello, Android: Introducing Google's Mobile Development Platform, Pragmatic
Bookshelf, 2009.[14] I. Sommerville, Software Engineering, Harlow: Addison-Wesley, 2007.