Page 149 of 201
Although neither the EpiCollect nor FormEntry options were satisfactory for the project, the feedback and development issues were valuable steps in defining the restrictions and
functional attributes for this app. Many of the principles outlined in the final part of this chapter were established during this phase.
The final step in the prototype development process was to move away from attempting to modify existing off-the-shelf products to a customised product development project.
10.3.3 Custom application
We approached a commercial provider of app and web development services nowcommsgroup.com and freshweb.com.au with experience on applications developed for
Australian livestock industries, including development of the Stocktake Plus app stocktakeplus.com.au for MLA.
A design brief was developed that defined development of: A server app running on a linux system that could function as a stand-alone installation
on a laptop or as a web-available application if internet services were available. An Android app running on hand-held devices for data collection with key functions
including: o
ability to import lists of livestock at load-out based on loading plan for individually identified animals cattle or mob-identified animals sheep.
o recording of events and conditions during the voyage, including sickness, deaths,
sea conditions, and pendeckship conditions. o
attaching of notes and photos and audio files to any event record. o
able to synchronise with the server app with two-way data flow. o
optimized for small screens with fast and simple user interface. o
support for scanning of animal RFID tags. This brief included a discussion of the previously identified constraints and requirements
created by the need to provide a reliable and easy to use service in a harsh environment. Discussion with the developer indicated that likely costs for completion of a fully functional
system with both server and hand-held components would exceed 50,000. This was well above available funding allocated within the existing project budget.
A negotiated approach was then agreed to restrict developer activities to specification of table structure and development of partially functional demonstration modules that showed
how specific data entry fields may be managed. Any outputs from this work were intended to inform specification and recommendations for future development of an application for this
purpose.
A brief description is provided here of the layout of example screens of the demonstration modules developed in this prototype system.
Figure 32 shows a diagrammatic representation of the opening screen for a custom developed application.
Page 150 of 201
a. b.
Figure 32: Diagrammatic layout of opening screen shown in a. and screen for entering a new voyage shown in b.
The system is developed specifically for display on small screens and for use on touch- enabled devices.
Options are triggered by pressing symbols with a finger or stylus device. The plus symbol is used to trigger adding a new record or entry.
A down-arrow symbol is used to trigger a drop-down list which is displayed in a pop-up
dialog box, allowing the user to scroll through options and select an option by pressing it with a finger. The field will then be populated with that option. Figure 33 shows an example drop-
down list showing pre-entered options for PORT.
Figure 33: Example drop-down list produced by pressing the arrow beside PORT as displayed in Figure 32 b.
Page 151 of 201
The entries available for selection in a drop down box can be managed through separate screens or a new entry can be recorded by manually typing in a new port name.
A sideways facing symbol will open a new screen with additional details for that
variable.
The small circle symbol containing three horizontal bars will produce a main menu of
available options to choose from, that includes data entry and reporting options. This is an emerging standard for menus on mobile devices.
At any point the user can go straight to a main menu list of major options through the menu symbol in the upper left of the screen, or can save newly entered data by pressing
the save button at the bottom of the screen, or can go back one screen by pressing the return button.
Figure 34 shows example screen-layouts for adding a new vessel to the system.
a. b.
c.
Figure 34: Example screen layouts for adding a new vessel to the system with a. defining the new vessel, b. defining the number of decks and c. defining the rows for each deck.
The system is designed to allow a vessel to be defined with multiple levels of detail down to the number of pens on each deck. The intention is that static ship information would be pre-
entered, so that a user chooses the vessel name and then all the details for that vessel are already available for selection and recording.
Page 152 of 201
Figure 35 shows example screen-layouts for selecting an animal breed.
a. b.
Figure 35: Example screenshots showing options for selecting animal breed in a. and class in b. and showing the fields where new breeds can be added in b.
Page 153 of 201
Figure 36 shows example screenshots showing a list of summary headings or choice- options a and a main user-interface screen during an active voyage where a user may
choose between specific options most relevant while a voyage is under way.
a. b.
Figure 36: Example screenshots showing a list of summary headings in a. drawing on data from multiple voyages and b. a main navigation screen active during a voyage where a user
may choose between a small number of routine data entry and reporting activities.
From a design perspective the prototype development process reinforced the importance of simplicity, restriction of the amount of information displayed on screen at any point in time,
use of simple, intuitive symbols for navigation and key functions, and use of drop down boxes and other aids to limit the amount of new data or information that might have to be
manually entered. All of these points contributed to a simple, easy to use interface.
Page 154 of 201
10.4 Database table structure
