Computer Science Honours Final Paper

2016

Title: Developing an Android Application for Agricultural Information Dissemination Author: Jeremy Bishop Project Abbreviation: FarmAid Supervisor(s): Aslam Safla

Category Min Max Chosen Requirement Analysis and Design 0 20 20 Theoretical Analysis 0 25 0 Experiment Design and Execution 0 20 0 System Development and Implementation 0 15 15 Results, Findings and Conclusion 10 20 10 Aim Formulation and Background Work 10 15 15 Quality of Paper Writing and Presentation 10 10 Quality of Deliverables 10 10 Overall General Project Evaluation (this section allowed only with motivation letter from supervisor)

0 10

Total marks 80 80

DEPARTMENT OF COMPUTER SCIENCE

Developing an Android Application for Agricultural InformationDissemination

Jeremy BishopUniversity of Cape TownCape Town, South Africabshjer001@myuct.ac.za

ABSTRACTA signi�cant portion of South Africans are involved in agriculturalwork. Current means of agricultural information dissemination suf-fer from lack of adequate resources and national government haslaid out goals to improve upon this. Considering the high rate ofmobile penetration nationally, and existing projects that e�ectivelyuse mobile phones and multimedia as channels for communicat-ing agricultural information, this paper outlines the process bywhich an initial Android mobile application prototype (FarmAid)was developed in order to aid South African farmers in accessingagricultural information. 1

CCS CONCEPTS• Software and its engineering → Software design engineer-ing; • Human-centered computing → User interface program-ming;

KEYWORDSAndroid application development, agricultural extension

1 INTRODUCTION AND BACKGROUND1.1 South African Agricultural Information

DisseminationMany of South African (SA) households are engaged in agriculturalactivities. The portion by province ranges from 5.2% in the WesternCape to 35.4% in the Eastern Cape [7]. The main existing means ofinformation dissemination for farmers and communities in ruralareas relies on face-to-face interactions with government-employedextension o�cers [10].

In the last few decades there have been three notable trends inthe way in which SA’s agricultural extension and advisory serviceshave changed: the realization of the role of extension as more thanjust the transfer of technology to farmers; interest in collabora-tion between public and private stakeholders; and the change inunderlying rationale towards more participatory approaches [15].

Echoing these trends, as part of its outlined goals for 2030, SA’sNational Development Plan [2] made several recommendationsaimed at aiding small-scale farmers: the implementation of im-proved communication infrastructure to aid in assessing marketconditions; pursuing innovative means of agricultural extensionin partnership with private interests; and improving upon and ex-tending existing skills development systems, while encouragingfarmer-to-farmer skills transfer.1 This report was completed as part of a Bachelor of Business Science Honours degreein Computer Science at the University of Cape Town in 2017. For further informationon FarmAid, as well as additional material, please visit: http://pubs.cs.uct.ac.za/

1.2 Project AimsIt is against this background of changes in agricultural extension inSA and the need for new approaches to information disseminationwithin it that this paper outlines the development process of anAndroid mobile application prototype that would function as aninformation dissemination tool between two parties taking on ateacher-learner relationship. This relationship could be betweenan extension o�cer and one of the farmers they aid, or between ateacher at a school and a student, for example.

The intention is that this FarmAid prototype would be the �rststep in the development of a fully-featured mobile app and accom-panying database with its own server that could aid learners, aswell as small-scale and subsistence farmers in accessing agriculturalinformation in a convenient, timely manner.

Originally the scope was for a mobile application to be usedby low-literate rural farmers within the Western Cape. However,following the literature review and consultation with members ofthe UCT Centre in ICT for Development (UCT4D) and other UCTlecturers, we decided to work within the time and resources avail-able to us and pursued the development of an initial prototype tobe used in future development iterations. Due to the short timeperiod assigned for this project and having no prior connectionswith those in the agricultural industry in the Western Cape, wewere advised not to involve extension o�cers and their associatedcommunities in our user studies, but rather to consult with urbanfarmers and hobbyists who were not a�liated to any public organi-zation so as to avoid lengthy ethical clearance and governmentalbureaucratic processes.

Throughout the project we treated our supervisor Aslam Sa�aas the product owner. Regular meetings were held that shaped thedesign decisions to be in line with his vision of the application. Theintention being that the prototype app could then be developed andtested with community garden volunteers, hobbyists, or anyoneinvolved in agriculture within our immediate surroundings in thebeginning developmental stages. Because of this, the necessity ofcatering for low-literate users was removed, and the focus wasbroadened to developing an application that would work betweentwo parties in a ’teacher’ and ’learners’ role, rather than speci�callyan ’extension o�cer’ and a ’farmer’ role. The core functionality ofthe app remained unchanged however.

2 LITERATURE REVIEWThe literature was consulted in order to assess existing and pre-vious educational interventions making use of Information andCommunication Technologies (ICTs) and their suitability to the SAagricultural context.

2.1 Mobile App SuitabilityUse of digital media in information dissemination has a few ad-vantages over traditional extension methods: they can be cateredspeci�cally for the language of the targeted community, there areno barriers de�ned by literacy, they can use a level of terminologythat suits the expertise of the community, are practical at a grassroots level, and are highly accessible [4].

Because of this, technologies that utilized audiovisual means ofcommunication were prioritized for consideration in this project.However, several technologies were not considered. Firstly, thepossibility of using web pages was discarded due to less than 10% ofthe SA population having access to �xed line internet connections[3]. TV and radio were not considered as they o�er a one-waycommunication that allows for little to no interaction, with contentthat is often too general to be helpful [5] as well as programmingtimes that could be inconvenient to farmers [22]. Additionally, useof phone calls was also not considered as a primary disseminationmethod as it is already currently used for direct communicationbetween farmers and extension workers, although it is not preferredby the former [10].

98% of South Africans live in areas withmobile cellular signal and92% of the population are subscribed to mobile services [20], and inrecent years there has been unprecedented growth in the adoptionof Internet-capable mobile devices within SA [1]. With such highmobile penetration levels, and the multimedia capabilities of mobilephones, it was considered worthwhile using mobile phones as ameans of information dissemination in the South African agricul-tural sector.

While face-to-face interactions may be preferred by rural SouthAfrican communities [10], it is apparent that there may not beenough extension o�cers to allow for regular visits [15]. A mobileapp service may have the potential to allow for a reduction in thenumber of visits desired by farmers, if it can be e�ectively usedby both extension o�cers and farmers in communicating relevantinformation. Thus, the number of visits that extension o�cers arerequired to make could be reduced, allowing for greater focus onunique or urgent issues experienced by farmers or their communi-ties that require a personal visit, while allowing for common issuesto be addressed by using the technology.

Additionally, ICTs have the potential to address farmers’ needsthat are not necessarily addressed by extension services. Beyondextension, farmers often rely on non-governmental organizationsor producer organisations to access information relating to "inno-vations in crop varieties, pest management, soil fertility, weatherforecasting and irrigation among others" [15]. General informationthat may not need to be catered for a particular farmer could easilybe communicated using ICTs in a more cost-e�ective manner.

The Android application approach is however not without itsobstacles. Poorer populations in South Africa feel most the burdenof high data costs and although SA may have high coverage rates,there is still unequal coverage in more rural areas [6]. These prob-lems were considered in the designing of the application, outlinedbelow.

2.2 Previous and Existing E�orts2.2.1 Digital Green. Digital Green was a research project con-

ducted in India that looked into the e�ectiveness of informationdissemination in small and marginal farming communities throughuse of digital video [5]. They made use of a participatory contentproduction process, inviting members of each community to partic-ipate in creation of video content through recording their descrip-tions and demonstrations of methods they used in their farmingpractices, with the database of videos thus being locally-generated.Farmers in the community would then meet to watch these videos,and were able to see their peers appear in videos during sessionswhich were mediated by community members. This approach tookadvantage of existing social networks, linking farmers to experts,and ensuring that language, education, and age barriers are reduced(or even nulli�ed).

During their 13-month trial assessing 16 di�erent villages, (witheight control and eight experimental villages), Digital Green saw asevenfold increase in the adoption of certain agricultural practicesover classical extension approaches, and was also shown to be tentimes more e�ective per dollar spent than the classical system. Thisstudy gives evidence of how multimedia can be used by ICTs toe�ectively educate those involved in agriculture.

2.2.2 Wainaina’s Kenyan Study. Wainaina [22] researched thee�ectiveness of using a mobile app to deliver pre-harvest informa-tion to horticultural farmers in Kenya. The app ran o� the Androidoperating system and made use of videos and images in order to aidunderstanding of concepts related to the cultivation of strawberryand mushroom crops. Following the design and user evaluationprocesses, it was found that farmers were highly receptive of themobile app, with 100% of participants responding positively to its in-troduction, a majority indicating that they would make use of sucha mobile app, and found it e�ective in disseminating information.

2.2.3 M-Farm. Another mobile application in Kenya that allowsfarmers access to relevant information is M-Farm [8]. M-Farm of-fers market insights to its users by giving retail price informationof various crops, along with prices and suppliers of farm inputs(which can be directly purchased), as well as o�ering an onlinemarketplace in which they can �nd buyers for their produce [22]. Itseeks to eradicate information asymmetries in agricultural marketsby allowing users to see prices in di�erent cities across Kenya. Theservice operates both as an application on the Android operatingsystem, but also as a Short Message Service (SMS) in which userscan access information through SMSing pre-de�ned requests whichare answered by an automated system using daily pricing data fromindependent collectors.

3 SYSTEM DESIGN3.1 System OverviewThe architecture of the FarmAid system can be broadly divided intothree categories (see Figure 1):

3.1.1 Android Mobile App. The Android app is intended to beused by learners in accessing information that is uploaded to theserver by teachers via the web app. Learners login and can run anupdate to check for any new information that has been added to

2

Figure 1: System Overview

their institution’s database since their last update, and downloadif applicable. Users can then navigate through the di�erent cropsthat are available and view the tutorials (guides on how to conductvarious aspects of crop growth) that have been uploaded for them.Additionally, the app o�ers the user the ability to message theirteacher through in-app messaging. This sends text messages whichare viewable by the teacher in the web app.

3.1.2 Web App. The web app functions as a means of uploadinginformation for teachers. Users can register with an associatedinstitute, and from there images and text relating to crops and theirassociated tutorials can be uploaded. Messages from students canbe viewed and responded to.

3.1.3 Database Server. The database server functions as thecentral repository for all information used by both the web andmobile app. Running Ruby on Rails, details about institutes, theirteachers and learners are stored, along with the associated �lesrelating to crops and tutorials uploaded by the teacher throughthe web app. The server’s logic handles all queries from both apps’clients: HTML �les used by the web app, and responding to HTTPrequests from the mobile app.

3.2 Technology UsedAll programming of the Android app was conducted in Intellij IDEAwith use of the Android support plugin in order to make use of theAndroid SDK. All the coding was done in Java and XML, whichproved to be a sensible choice due to previous familiarity with Java,and the large amount of documentation available to aid in learningXML. During digital prototyping two Samsung Galaxy Pockets withAndroid version 4.0.4 with API 14 (Ice Cream Sandwich) were usedin testing and development (supplied by the University of CapeTown’s UCT4D Centre), while an emulation of a Google’s PixelXL was used within Android Studio throughout the course of theproject for development.

Android was chosen as the platform for development due toAndroid smartphones generally being cheaper, as well as being themost prevalent smartphones in SA [13]. E�ort was made to ensurethat the app could function fully on low Android API versions toallow for a greater user base.

3.3 FeaturesThe core function of the app is to allow communication of agricul-tural information between two parties in a learner-teacher relation-ship. As such, there are three main mechanisms to allow for thiswhich were the focus of this app:

3.3.1 Crop Information Access. Teachers are able to upload in-formation pertaining to various crops on the FarmAid web page(https://farmaid.cs.uct.ac.za), which users can then download ontotheir device, store in internal memory, and then access within theapp.

This information is arranged in a hierarchical set of activities:displaying all available crops; displaying general information andavailable tutorials for a chosen crop; and �nally displaying the stepsinvolved in the chosen tutorial (see Screens 2, 3, and 4 in AppendixA.3).

3.3.2 Messaging. The app’s messaging functionality functionsin a fashion typical of other SMS and instant messaging services andapplications. The user makes use of their phone’s native keyboardto enter in messages which are sent to the server and received bythe teacher in their pro�le on the FarmAid website, where they canrespond.

The mobile app’s messaging service only checks for new mes-sages upon opening the ChatActivity window. This was done inorder to reduce data consumption, considering that the app may beused by those who are less well-o�, or live in areas with reducedmobile coverage.

The app’s connection to the server is achieved through the HTTPprototcol, by using several HttpUrlConnection objects and sendingPOST requests containing the user’s email in the body. The serverreacts appropriately and sends back a text message that serveseither as con�rmation of the mobile app sending a message, or as aseries of messages for the mobile app to display, with each messagebeing composed of a series of key - value pairs with keys ’Message’,’Time’, and ’Sent from’. These key value pairs are used in a�ectinghow the mobile app displays the individual message.

Appropriate checks are in place for network connectivity toensure the correct functioning of the messaging service. Users arenoti�ed if there is no data connection, as well as if a server-sideerror takes place.

3.3.3 Updating. The app’s update functionality retrieves allavailable data on the server database that has not yet been down-loaded to the phone. This is achieved by �rst connecting via theuse of a HttpUrlConnection object, then sending a POST requestwhich receives a text block representing the path on the server forall the individual �les the app needs to download.

For each of these paths, the mobile app makes use of image-Downloader and textDownloader objects depending on the �letype (whether it is a .txt �le, or an image). These objects serve ashelper classes that handle the process of requesting a resource viaHTTP POST requests through to writing it to local storage. Stor-ing resources to local storage was opted for as it would make thefunctionality available regardless of whether or not the user hasexternal storage connected (i.e. an SD card).

As with messaging above, checking and notifying users of net-work connection issues are included.

3

4 METHODOLOGIES USED4.1 Project ManagementThe project followed a rough Agile methodology approach through-out. The focus was on an iterative cycle of gathering user require-ments, planning for development, designing, developing, releasing,and then monitoring. In this context, the user for the gathering ofrequirements, release, and testing of the project (both the mobileand web app) was the product owner and supervisor, Aslam Sa�a.

Due to the size of the team (two members), many Agile ap-proaches were not appropriate and so the SCRUM methodology[19] was used as a template that was adapted to the needs of theteam. This gave the project high visibility of progress, a predictablework rhythm (especially needed while doing other course work), aself-organising team, adaptability, low bureaucratic overhead, andan emphasis on face-to-face communication. All of these charac-teristics allowed for better teamwork, faster software development,and ease of code changes.

The team met once a week with the product owner to createa sprint backlog (a list of features to be worked on that week)with tasks appropriate to each member’s scope, that were thenworked on throughout that week. At eachmeeting factors that couldbe improved were identi�ed for the next week. A daily SCRUMmeeting is usual, but due to high coursework requirements dailycommunication of progress was preferred within the team.

4.2 User InvolvementEntering the project, we had hoped to adopt a co-design approach[21] since the end users have a very di�erent lifestyle to the teammembers. This would have required the applications to be devel-oped alongside farmers and extension workers. Unfortunately timeand and resource constraints made this near-impossible, and so anapproach closer to participation design was followed. Participationdesign provided the user (the product owner, Aslam Sa�a) with avoice in the process of design, evaluation and implementation ofthe system [21] through conducting meetings. Additionally, proto-type testing sessions were held with users to inform user interfacedesign decisions (outlined below).

Early code development was conducted alongside paper proto-typing, so that a lot of the app’s logic could be implemented. Fol-lowing paper prototyping, the insights garnered from there wereused to inform some user interface design decisions in the digitalprototype.

5 INITIAL REQUIREMENTS GATHERINGIn the �rst stages of the project the team conducted a literature re-view (with some features of it outlined above) in order to assess thescope for the project. The results of this review informed the initialproject proposal, which was presented to a group of University ofCape Town Computer Science Department lecturers. Issues withthe project (including scope and logistical issues such as access toextension o�cers and low-literate farmers as well as a clear separa-tion of roles and responsibilities within the group) were identi�edwhich informed a reassessment of the project’s scope.

A meeting was held between the acting director of the UCTCentre in ICT for Development (UCT4D), Melissa Densmore, and

the project team (including the product owner Aslam Sa�a). Fromthis meeting, the team was advised to approach local NGOs ratherthan governmental organisations. Following this advice severalorganisations were contacted, of which very few responded enthu-siastically. A meeting was scheduled with one urban farming groupin Cape Town’s City Bowl area, however due to miscommunicationthe team were not received by anyone, and subsequent plans andproposals from the team were not responded to, despite the farminggroup’s initial enthusiasm.

After these initial stages, artefact development began in earnest,with additional user requirements gathering being conducted through-out by way of consultation with the product owner (Aslam Sa�a),as well as through the prototyping phases outlined below.

6 PAPER PROTOTYPE6.1 RationaleA low-�delity paper prototype was chosen as the initial means ofassessing the user interface (UI) for the mobile app. This was chosendue to the ease of implementation, how early it allows for testingUI ideas with users, the fast iterations it allows, and allowing for abroader range of ideas to be tested early on [18].

Fourteen University of Cape Town Computer Science honoursstudents were chosen as users for testing. This approach may havemade prototype evaluation and design less e�ective in terms ofits end goal of achieving an e�ective interface for farmers, butwas considered the best approach to achieving insight into userinterface issues given the circumstances. To ease the mismatchbetween users involved in testing and our end users, we asked testusers background questions concerning any farming experiencethey or any of their close family may have (in order to prioritiseresponses), as well as features they would expect from such anapplication before beginning the user test.

Five participants in the study had some form of farming ex-perience through a close relative and nine participants reportedthat they had no farming experience. The responses from the �veparticipants with farming experience were highlighted as they rep-resent personas [17] close to our end users, farmers. Nonetheless,no usability recommendations were discarded.

At the time of conducting the paper prototype, the focus of theproject was still on catering for low-literate users, and hence manyof the features explored in this prototype were related to commu-nicating information without text. While scope change removedthe need for the implementation of these features, the feedbackfrom the paper prototype still in�uenced UI design decisions andgave insight into the appropriateness of the hierarchical, drill-downapproach [14] to presenting the information.

6.2 MethodA Wizard of Oz (WOZ) study [16] was conducted on fourteen par-ticipants: users were guided through cognitive walkthroughs ofthe prototype by one team member, while the other took noteswithout interacting with users. A qualitative approach (rather thanquantitative) was chosen, as it was thought best to �gure out whatlayout design was more user-friendly (to eventual end users) be-fore attempting to implement the actual software. The Wizard of

4

Oz style of evaluation was helpful in this as several features andimprovements came with little design.

To evaluate usability participants were asked to complete tasksthat: help the farmer extract farming information through the app;use features on the app that help in navigation to this information;and observed how easily this could be done. Pictures of the paperprototype’s screens can be viewed in Appendix A.1, as well as thefull list of questions used in Appendix A.2.

Since the app’s core functionality is to disseminate agriculturalinformation to farmers, �guring out how intuitive the design wasto an untrained user was a priority. To that end, some participantswere given simple identities (a farmer who just downloaded theapp) and were asked to perform high level tasks (for example, "Sinceyou are a potato farmer, can you �gure out how to sow your potatoseeds?" or "Assume you are interested in farming some maize, whatpesticides should you look out for?"). Other participants were giventasks relative to the screen they were currently on, for example, onthe home screen: "Assume you want to know more about your crops,what would you do?".

6.3 Findings and Analysis6.3.1 On Opening for First Time. The feedback from participants

indicated a need to have a learning mechanism for �rst time usersof the app. This may have been because of the highly visual natureof the app and the low quality of drawings in the prototype. Aninteresting suggestion was to disable other buttons and require theuser to click on a certain button so that the user may know whatthat button does. We noted this suggestion but another participantpointed out that this could imply that the app is broken somehowand may cause confusion in some users with low e-literacy.

6.3.2 Audio Prompts. The speaker button on each tile plays anaudio �le telling the user what that tile is for (an "about" button). Tohave an idea whether target users would be able to understand thisfunctionality we asked users "How would you �nd out what eachpicture represents?", or "How would you �nd out what this screen isabout?".

A recurring comment was that the symbol chosen for the promptwas not intuitive. Suggestions were made to turn that into the com-mon "i" (information) symbol. Two participants suggested high-lighting the speaker buttons when clicked, to make it obvious tousers which tile the audio playing is for. Most participants were notsuccessful in completing tasks associated with using this feature.This further justi�ed the idea behind a tutorial for �rst time users.

6.3.3 Navigation to Information. The prototype takes a drilldown approach [14] to navigating through the information it con-tains, thus users have to navigate through various screens to accessthe information they seek. For instance, if a user was interestedin sowing apples then the user was expected to follow tiles fromcrops/livestock to crops, to apple, to pressing play on the sowingtile.

To evaluate this layout’s appropriateness, participants wereasked to perform high level tasks (as previously stated). For in-stance, retrieving information on apple pests. Mixed results wereobserved as some users navigated down incorrect paths, whilstothers followed perfectly. However, all users were able to complete

a similar task ("Get information about how to plant apples") aftergoing through the navigation once. This di�erence in comprehen-sibility and performance was attributed to misleading drawings onthe paper prototype, following feedback from users and discussionamongst group members.

Some participants felt like they had lost a source of referenceas to where they were on the app. They subsequently suggestedhaving some kind of title that gives context to each screen. Picturesof the previous tile selected were used to give users context onwhich screen they were on.

6.3.4 Miscellaneous features. A dashboard or pro�le page foreach farmer was added to allow for quick navigation to speci�ccrops chosen by farmers. Navigation to this was easily spotted bymost users due to its visibility at the bottom of the screen. However,the users that failed to accomplish the task were confused by thetask given, for instance, when asking users to "Add information oncarrots to your pro�le" when they were on the crop screen (Screen3 in appendix A.1). Some users were able to add this informationthrough the plus sign but were not sure what happened as therewas no response by the app after adding. After explaining that theadded crops go to your pro�le a participant suggested we showthis as an animation or indicate it with a +1 on the pro�le icon.The pro�le tab itself was a source of confusion for most users. Thiswas because our drawing skills could not represent small iconswell enough. It was also because the test participants were notfarmers and did not understand the process of sowing, fertilizing,harvesting, and storing.

We also asked users to contact the extension worker from thehome screen. Those who were not on the homescreen when giventhis task forgot that there was a tile with the extension worker’spicture (poorly drawn). Some clicked on the caller icon on thebottom of the screen. Thus the icon was intuitive but not universally.All users that were given this task whilst on the home screen didnot face any di�culty completing it.

7 DIGITAL PROTOTYPEThe digital prototype continued from the design of the �rst paperprototype. It was felt that much of the paper prototype’s issuesinvolved visual aspects, such as issues with the drawings of iconsand button representation. The digital prototype allowed us to getcloser to the �nal visual representation of the application and thusget richer feedback from users testing it.

7.1 RationaleThe digital prototype was used as a �nal stage in gaining feedbackfrom users. Having completed the bulk of the logic required bythe application, it was easy to modify and test the interactive func-tionality of the application without requiring the backend to beadjusted dramatically.

The digital prototype was tested on six people from di�erentbackgrounds staying within Cape Town. None of the six was cur-rently involved in farming, however this was not considered anissue as at this stage the prototyping was to assess the UI at a highlevel. There were however several users who had previous agricul-tural experience, ranging from having worked on a farm to growingtheir own vegetables and herbs at home.

5

7.2 MethodEach test session started with a brief explanation of what the projectwas about, what the Android app’s role within it is, and who its endusers were intended to be. Users were then asked if they had anybackground in farming, or experience growing their own ediblegoods, before being asked to complete tasks in the same way inwhich the paper prototype was conducted. These test sessionsranged in length from 20min to one hour, largely determined bythe degree of feedback from the user, as well as discussions aboutpossible additional features and considerations that they broughtup.

This qualitative approachmeant the design was being challengedby users who were not just being told what to do at each stage, butrather being given a task to complete and had to �gure out how theinterface works in order to complete said task. As far as possible,the users were left to grapple with issues that they voiced in orderto see if they could remedy their problems without guidance. Whenno solution could be found, they would then be prompted, althoughthis only ever occurred with a few users who were not familiarwith the Samsung Galaxy Pocket and thus did not know how tonavigate back within the app.

7.3 Findings and AnalysisThe prototype had a rudimentary UI design, having been designedvery shortly after functionality had been completed. The bene�tfrom this was that users in testing were very quick to identify issueswith layout and navigation and make suggestions for alternativeswhich could be explored without having invested too much timeinto UI design. Some of the key issues are outlined below:

7.3.1 On Opening for the First Time. Many of the users felt con-fusion regarding several visual elements in the prototype’s homepage (see Screen 1 in Appendix A.3). The rationale for arrangingthe three key app features (entering the crop information display,messaging, and updating) in a horizontal arrangement in the centreof the screen was purely aesthetic: it was an attempt at followingthe Rule of Thirds [9]. However, many users found this arrange-ment confusing. Several thought the bar suggested being able tohorizontally scroll, and one thought the �rst button was purelyfor decorational purposes. Additionally, the link between the textexplaining the actions that could be performed in that context andtheir corresponding buttons was not clear for the majority of users.

7.3.2 Conveying "Clickability". One piece of feedback that camefrom several users was that it often was not clear what images wereintended as buttons and which were not. One user was surprisedwhen they clicked on a Planting tutorial’s thumbnail and theywere navigated to its corresponding view (see Screens 3 and 4 inAppendix A.3). Similarly, many users would tap the text ratherthan the image when trying to navigate to a tutorial (see Screen 3),which would result in no change.

7.3.3 Updating. Many users expected real-time updates of mes-saging, a feature that was opted out of in order to reduce data con-sumption. Similarly, when users were prompted that their teacherhad messaged them to inform them of new information being avail-able to them, several immediately navigated from their chat (Screen

5) to see their available crops (Screen 2) without thinking that theymay need to take any action to update the app.

Beyond knowing when and why to update, the existing mecha-nism presented some confusion to users. One user upon �rst open-ing the app immediately started tapping on multiple UI items andnavigating throughout the app. However, when he �rst hit the up-date button and there was not an immediate response, he continuedtapping it repeatedly for a few seconds, despite a Toast messageappearing brie�y informing him of the �les the app was download-ing.

7.3.4 Miscellaneous features. All of the users were not familiarwith the Samsung Galaxy Pockets that were used during testing,and this made some in-app navigation di�cult, particular movingback to a previous activity as the prototype relied on the phone’shardware button for this, rather than o�ering any sort of ’back’button in the UI.

One issue that many users felt was that images and icons usedwere not always clear in their meaning. While the icons for ’home’and ’messaging’ (both shown in the toolbar in Screen 2 in AppendixA.3) were understood clearly by all users, the icon used for updating,and the image of a vegetable basket in the home page (Screen 1)were not as easily understood, with no user being completely certainof what the update button’s functionality was.

The one feature which every user was comfortable with wasthe in-app messaging. This would largely be in part because of thefamiliar and established approaches used in messaging in mobileapplications that were followed in the prototype.

All of the users found that once they had interacted with theinterface for a few minutes they had a better understanding of howit worked and were able to ful�l tasks immediately. Despite theissues outlined above, there is reason to believe that the app is veryeasy to learn, perhaps largely due to its small set of features.

8 FINAL PROTOTYPEFollowing user feedback from digital prototyping, several featureswere altered or added to the prototype, which then became the�nal artefact for this project. Beyond the changes made to thehome screen and the addition of the Login Page outlined below,the clickability of horizontal tiles was added after having observedmany users tapping text rather than the ImageButton when tryingto navigate.

8.1 Home ScreenThe home screen’s horizontal arrangement of three icons (seeScreen 1 in Appendix A.3) was replaced with a vertical arrange-ment of the three options (Screen 1 in Appendix A.4), with thedescriptive text for each option placed next to its respective icon.Following feedback from a few users about the inconsistent use oficons and photos in the digital prototype, all the buttons make useof icons (rather than images), which suggest interactivity ratherthan decoration, and make use of a green colour scheme to �t inwith the app’s agricultural theme.

The "Welcome to FarmAid" message was moved into the activ-ity’s title following one user’s comment that having "FarmAid"in the title as well as displaying this message seemed unneces-sary. This also freed up space in the activity, and lent to a cleaner,

6

more streamlined interface. Additionally, the messaging icon wasremoved from the toolbar, so that there was no longer two routesto accessing messaging from the Home Page.

8.2 Login ScreenA simple login page was added to the app to allow users to login totheir account when �rst opening the app. This page was adaptedfrom Android studio’s login page template. Users are prompted toenter in a valid email and password (with validity determined bythe app’s logic through assessing the strings inputted).

9 ETHICAL, PROFESSIONAL, AND LEGALISSUES

Ethical clearance for user testing was acquired through UCT’sFaculty of Science Research Ethics Committee (FSREC), and all datawas recorded with identifying information removed.

All code that had been adapted for the purposes of this mobileapplication were made publicly available for commercial or pri-vate use, and thus no licensing fees are required in the use of thisprototype.

The images used during prototyping were taken from GoogleImages and have di�erent forms of copyright applied. This was notconsidered an issue as at this point in the development process thatapp is not available to the public.

10 CONCLUSIONSThe current South African Agricultural Extension system su�ersfrom a lack of resources, and those farmers that dependent upon itlose out on bene�ts from information access, as well as experiencedisadvantages due to information asymmetries in markets. Thanksto the wide spread of Android devices in South Africa, there isthe potential for a mobile application to act as an e�ective tool inimproving existing extension services, and allowing farmers greateraccess to relevant, timely information. This service is capable ofbeing generalised outside of extension services to be applicable toany two parties in a teacher-learner relationship.

10.1 FarmAid SystemThe implemented system is composed of three components: anAndroid application used by learners, a web application used byteachers, and the database server which handles storage as wellas all communication between the two applications. The Androidapplication’s features include core communication functionality:remote retrieval, and local storage of institute-speci�c resourcesuploaded by a learner’s teacher; as well as in-app messaging be-tween the mobile and web app. Seeing as the bulk of the projectinvolved setting up infrastructure for the system, as well as a steeplearning curve for both members, it is possible that adding featuresin the future may be conducted with a degree of ease.

10.2 Paper PrototypingPaper prototypingwas an e�ectivemeans of quicklymaking changesto the user interface and allowed for user participation in the designprocess. The low requirements in terms of time for preparing the

prototype allowed for great insight into user’s expectations of theapp early on in the project’s lifecycle.

10.3 Digital PrototypingDigital prototyping was an e�ective means of observing a user’sbehaviour while using the app. Comments and discussions duringthese sessions greatly informed the work to be done on the interface,as well as some considerations for the app’s functionality.

10.4 Final PrototypeThe �nal prototype addresses many of the issues brought up duringthe two testing phases outlined above. The app ful�ls its core func-tionality, and based o� user testing there is qualitative evidencethat the interface is easy to learn, and intuitive for users.

11 LIMITATIONSWhile the project achieved its goals, there were two factors thatlimited the amount of functionality that was implemented.

11.1 Team Member’s ExperienceBoth team members had not undertaken any development workof this sort before, and therefore the time and e�ort involved inlearning relevant frameworks and approaches was extensive. Ad-ditionally, during integration of the web and mobile app’s therewere periods where one partner was unable to continue work untilthe other had implemented a feature. While all core functionalitywas implemented, there were several additional features that werehoped to be added that time constraints did not allow for.

11.2 Logistical IssuesDuring the project several personal and inter-personal issues stuntedthe rate of development. Team member illness, as well as a housebreak-in which resulted in the theft of one of the Samsung GalaxyPockets held back the project. Additionally, loss of communicationwith the urban farming organisation that the project had plannedto conduct user testing with hampered the prototyping phases.

12 FUTUREWORKIn order for the mobile app to fully meet its potential as an e�ectiveinformation disseminator in SA, the following areas of work willneed to be explored moving forward:

12.1 SecurityThe FarmAid mobile app exchanges and stores user information ona remote server, and these processes will require greater security inorder to prevent security breaches, and ensure user trust. Sensitiveinformation such as app users’ emails and passwords as well asinstitutions’ media and knowledge (whatever form it may take)would need to be adequately protected.

12.2 In-depth User TestingIn order for the app to be nationally usable in the existing SAAgricultural Extension system, and thus aid in extension e�orts,sessions would need to be conducted in the �eld with these partiesto greater inform design decisions.

7

12.3 User Interface Re�nementCurrently the FarmAid prototype has its core functionality, and avery simplistic user interface (UI). While the design of this interfacehas been conductedwith consideration to variousHumanComputerInteraction (HCI) interface design principles, and feedback fromusers in testing, the appropriateness of the design would need tobe continually assessed with end users (as outlined above), andfurther re�ned so that it is as easy as possible to use. In particular,symbols and language choices would need to be appropriate withinthe culture of the end users.

12.4 Additional FunctionalityThere is the potential for other features to be added to the app toallow for greater utility for users.

12.4.1 Data-free Updating. The ability to update the app over aconnection that does not consume mobile data (such as Bluetooth,or over USB) would be bene�cial to those users for whom data costsare prohibitive. Indeed, a 2015 research study of South Africanmobile data usage suggests that users will often try to "employvarious strategies to optimize mobile data usage such as activelydisconnecting from the mobile Internet to save data" [12].

Currently, USB transfer of data from a computer to a user’sAndroid device can be achieved, but would require having accessto a package of all the relevant institute’s resources appropriatelyorganized. This feature could be added on the web app, while in-apptransfer of data between phones via Bluetooth could be added inthe future.

12.4.2 Market Information. Market information is critical tosmall-scale commercial farmers in order to allow them to makeinformed business decisions [11]. By allowing for greater and moretimely insight, uncertainties in transactions can be reduced as farm-ers can �nd information on prices on agricultural inputs and out-puts, thus reducing information asymmetries [15]. Providing mar-ket information in the FarmAid app could prove very useful movingforward, as apps such as M-farm [8] have shown.

12.4.3 Weather Forecast. Having an in-app weather forecastwidget that is speci�c to the user’s location could be useful inassessing weather conditions and thereby informing practices.

12.4.4 Crop Tracking. It may be worthwhile exploring the pos-sibility of adding a feature that allows a user to track the lifecycleof a crop, allowing them to receive reminders when they should beundertaking time-sensitive activities (such as fertilising, watering,harvesting, for example). This would also allow the user a quickerway to look at the speci�c crops they are involved in, rather than allthose available on the institute’s database. this feature was exploredin the initial paper prototype, but was removed from scope duringthe project.

12.4.5 Text-to-speech and Multimedia. Currently the FarmAidapp utilises text and images to communicate information. In orderto make the app accessible to more people with low levels of literacy,it would be worthwhile taking advantage of multimedia and text-to-speech functionality.

8

   

 Screen   1:   Home   Page 

 Screen   2:   Crops/Livestock 

   

 Screen   3:   Crops 

 Screen   4:   Crop 

   

A APPENDICESA.1 Paper Prototype

9

   

 Screen   5:   Pests 

 Screen   6:   Profile 

   

 Screen   7:   Extension   Officer 

 Screen   8:   Weather 

 

10

   1. Do   you   have   any   farming   experience? 2. Assume   you   are   a   farmer,   what   information   would   you   like   to   know   about   your 

crops/livestock? 3. [Home   screen   ­   Screen   1] 

a. Can   you   guess   what   each   picture/icon   stands   for? b. How   would   you   find   out   what   each   picture   stands   for? c. Assume   you   want   to   know   more   about   your   livestock   or   crops,   what   would 

you   do? 4. [Crop/Livestock   ­   Screen   2] 

a. Assume   you   want   to   know   more   about   your   crops,   what   would   you   do? 5. [Crops   ­   Screen   3] 

a. Where   are   the   avocadoes? b. You   are   interested   in   apples,   click   on   a   button   that   helps   you   find   out 

information   on   apples. 6. [Crop   (Apple)   ­   Screen   4] 

a. What   is   this   screen   about,   how   would   you   find   out? b. What   apple   pests   should   you   be   looking   out   for,   how   can   you   find   this   out? 

7. [Pests   Screen   ­   Screen   5] a. Get   the   information   on   pests   and   how   to   protect   against   them b. Add   this   information   to   your   profile c. Add   information   on   carrots   to   your   profile d. View   your   profile 

8. [Profile   screen   ­   Screen   6] a. What   is   this   page   look   like   it’s   about? b. Add   information   on   onions   to   your   profile c. You   know   that   you   need   to   put   some   fertilizer   for   apples   this   week,   remember 

fertilizer   doesn’t   work   if   it   is   about   to   rain   as   it   could   be   washed   off,   can   you figure   out   on   which   day   the   weather   is   most   conducive   for   applying   fertilizer? 

9. [Weather   ­   Screen   8] a. So   you’ve   found   your   day   but   not   necessarily   sure   if   you   should   go   ahead   and 

apply   your   fertilizer,   can   you   contact   your   extension   worker   to   ask   if   this   day   is suitable? 

10. [Home   screen   ­   Screen   1] a. Find   out   how   to   sow   your   apples   (Helper   question   if   stuck:   Find   out   what   each 

of   these   sections   do) b. Play   audio   telling   you   what   weather   conditions   are   suitable   for   your   apples c. Add   apples   to   your   profile 

11. [Profile   ­   Screen   6] a. Contact   extension   worker   (If   they   have   not   used   speaker   yet   ask   them   how 

they   would   find   out   information   about   a   tile).   

A.2 Paper Prototype Questions

11

 

 

 

 

 

 

Screen   1:   Home   Page 

 

Screen   2:   Crops 

 

Screen   3:   Crop   View 

 

 

 

Screen   4:   Tutorial   View 

 

Screen   5:   Messaging 

 

 

 

 

A.3 Digital Prototype

12

 

 

 

 

 

 

 

 

 

 

 

Screen   1:   Home   Page 

 

Screen   2:   Login   Page 

 

 

 

 

 

 

 

 

 

 

A.4 Final Prototype

13

ACKNOWLEDGMENTSI would like to thank my project partner Barak Setton for makingworking on this project as enjoyable and stress-free as possible, andfor the valuable contributions he made.

I would also like to thank my project supervisor Aslam Sa�a forhis guidance, support, and understanding, as well as the project’ssecond reader Lighton Phiri for the valuable insights and advice hegave over the course of the project.

Lastly, I would like to thank Amreesh Phokeer from UCT’sUCT4D centre for allowing the use of two Android phones thatwere used in development and testing, as well as the centre’s actingdirector Melissa Densmore for her valuable advice and insights intothe processes involved in user testing.

REFERENCES[1] GSM Association et al. 2015. The mobile economy Sub-Saharan Africa 2015.

GSMA Intelligence. Regional report https://gsmaintelligence. com/research (2015).[2] National Planning Commission et al. 2013. National development plan vision

2030. (2013).[3] Christian Fuchs and Eva Horak. 2008. Africa and the digital divide. Telematics

and informatics 25, 2 (2008), 99–116.[4] Mucemi Gakuru, Kristen Winters, and Francois Stepman. 2009. Inventory of

innovative farmer advisory services using ICTs. Forum for Agricultural Researchin Africa (FARA), Accra, GH.

[5] Rikin Gandhi, Rajesh Veeraraghavan, Kentaro Toyama, and Vanaja Ramprasad.2007. Digital green: Participatory video for agricultural extension. In Informationand Communication Technologies and Development, 2007. ICTD 2007. InternationalConference on. IEEE, 1–10.

[6] Alison Gillwald, Mpho Moyo, and Christoph Stork. 2012. Understanding whatis happening in ICT in South Africa: A supply-and demand-side analysis of theICT sector. Evidence for ICT Policy Action. Policy Paper 7 (2012).

[7] Pali Lehohla. 2011. Census 2011 Agricultural Households Key Highlights. TechnicalReport. Report.

[8] M-farm. 2017. M-farm. (2017). Retrieved 25 September 2017 from https://www.mfarm.co.ke/

[9] Long Mai, Hoang Le, Yuzhen Niu, and Feng Liu. 2011. Rule of thirds detectionfrom photograph. In Multimedia (ISM), 2011 IEEE International Symposium on.IEEE, 91–96.

[10] S Maoba. 2016. Farmers’ perception of agricultural extension service deliveryin Germiston Region, Gauteng Province, South Africa. South African Journal ofAgricultural Extension 44, 2 (2016), 167–173.

[11] BMasuka, TMatenda, J Chipomho, NMapope, S Mupeti, S Tatsvarei, andWNgez-imana. 2016. Mobile phone use by small-scale farmers: a potential to transformproduction and marketing in Zimbabwe. South African Journal of AgriculturalExtension 44, 2 (2016), 121–135.

[12] Arunesh Mathur, Brent Schlotfeldt, and Marshini Chetty. 2015. A mixed-methodsstudy of mobile users’ data usage practices in South Africa. In Proceedings of the2015 ACM International Joint Conference on Pervasive and Ubiquitous Computing.ACM, 1209–1220.

[13] MyBroadband. 2017. Android vs iPhone in South AfricaâĂŞ The winner is clear. (2017). Retrieved 26 Septem-ber 2017 from https://mybroadband.co.za/news/smartphones/197747-android-vs-iphone-in-south-africa-the-winner-is-clear-2.html

[14] Theresa Neil. 2014. Mobile design pattern gallery: UI patterns for smartphone apps." O’Reilly Media, Inc.".

[15] OI Oladele. 2015. E�ect of Information Communication Technology (ICT) onagricultural information access among extension o�cers in North West ProvinceSouth Africa. South African Journal of Agricultural Extension 43, 2 (2015), 30–41.

[16] Tim Paek. 2001. Empirical methods for evaluating dialog systems. In Proceedingsof the workshop on Evaluation for Language and Dialogue Systems-Volume 9.Association for Computational Linguistics, 2.

[17] John Pruitt and Jonathan Grudin. 2003. Personas: practice and theory. In Proceed-ings of the 2003 conference on Designing for user experiences. ACM, 1–15.

[18] Marc Rettig. 1994. Prototyping for tiny �ngers. Commun. ACM 37, 4 (1994),21–27.

[19] Ken Schwaber. 1997. Scrum development process. In Business object design andimplementation. Springer, 117–134.

[20] AP Simpson and AP Calitz. 2014. The use of mobile technologies amongst SouthAfrican commercial farmers. South African Journal of Agricultural Extension 42,1 (2014), 98–107.

[21] Marc Steen, Lottie Kuijt-Evers, and Jente Klok. 2007. Early user involvement inresearch and design projects–A review of methods and practices. In 23rd EGOS

Colloquium (European Group for Organizational Studies). 5–7.[22] Joyce Wangui Wainaina. 2013. Horticultural Crops Information Dissemination

in Kenya Using Mobile Application. (2013).

14