State of the Application

8/13/2019 State of the Application

1/12

State of Flocktracker, February 2014

Introduction

Flocktracker has evolved substantially from its original Mexico City build, back in May of 2013. From user

interface to overall functionality, the application has completely rebuilt the original design. The new

system is far more stable, accurate, and versatile than it has ever been. To learn more and understand

how we have advanced each component of the application, please read further.

Flocktracking Concept

Flocktracking is a concept that aims to advance survey methodology, making data collection simpler,faster, and more robust. A group of well-trained volunteers, or Flock, are dispatched in a strategic

manner to perform surveys targeted at understanding information in a dynamic manner. That is, they are

dispersed in a manner intended to capture elements that might not be measurable in a static

environment. For example, if one were to compare transit routes, as we did, volunteers would be

dispatched on multiple buses, strategically through the day so as to capture peak and off-peak riders,

and maintain a consistent presence and rotation of coverage over the linear distance of the ride.

Data Generation Technique

The application then converts this spatial coverage into a powerful, data-based, accrual of information

that is dynamically arrayed by time and space. That is, in the current application, an individualsgeospatial coordinates, the number of riders in the vehicle, the volume of riders distributed according

to gender, the speed, and the time can all be combined into a packet and uploaded at 30 second

intervals, enabling a high-resolution mapping of the total course of the trip. Surveys are uploaded and

conjoined with this point specific data, allowing for robust data sets specific to a plethora of

environmental factors.

This application is flexible and is intended for use in a variety of formats. For example, the application is

currently being used to perform a sociodemographic analysis on poverty and household living situations

in the south of Mexico City, as well as tested for use in counting bicyclists by type in urban areas within

the city. More on this work can be found by visiting www.flocktracker.tumblr.com.

Structure of Report

The intent of the report will be to show what previous elements of the application were an issue, explain

that in depth, and then show how we have sought to remedy the issue with the new application. This

section will occur after a brief overview of the current functions of the application. The next section of

the report will be to take any remaining issue components and elaborate on how we seek to address

these moving forward. Finally, we will include and new issues that have come up, as well as planned new

features and conclusions.

1 of 12


2/12

Current Application Features

The current application has 5 key components:

1. Hub Page

2. Counter

3. Statistics Page

4. Survey Compositor

5. Survey

The hub page is simply that. The page acts as a central screen which bridges to the other components

of the application. Currently, the counter, which enabled riders to count the number of persons in the

vehicle by gender, and add or reduce the number given live boardings, is placed on the bottom of the

hub page This could change, moving forward. Particularly, as we engage test users of the application,

we can begin to see what unique case uses occur and use those case uses to begin to inform various

potential reconfiguration options for the user interface.

2 of 12


3/12

Above Left: Screenshot of the current applications hub page. Above Right: Statistics page screenshot. As can be

seen from the screenshot, there is still a slight formatting issue with the name.

The hub page is versatile and performs a number of functions. An image of the screen is located, for

reference, below. The trip start button is located prominently as a large, green gear. The survey link

button is the white gear on the right with the pencil icon, and the statistics link button is the gear on the

right, with the head icon. Tapping either of these options shifts you to the their corresponding

application functions. The male and female ridership counter is present along the bottom half of the

available screen space and arrows up and down allow dynamic addition and removal of riders in the bus.

The third component of the application is the statistics page. This page includes various aspects of the

rider, from current ride time, current distance travelled, surveys completed on the phone, rides or trips

completed on the phone, total distance ridden on the phone, and the present address (using location

sharing with the GPS function within Android).

The fourth component of the application is the survey compositor. This is provided upon starting up theapplication and pulls a JSON file by finding its title in the central Fusion Tables document. It takes that

associated JSON file (the user only has to type in its name, Research_Project, for example) and

reconfigured the application according to the parsed JSON file. This enables the same application to be

used for multiple survey initiatives, thus reducing the difficulty for syncing the application on the

volunteers end.

The survey itself is the product of this configuration effort and is accessed either from the hub screen

or the sidebar menu. Components and types of survey questions possible will be explained further, later.

User InterfaceThe new User Interface is based in Googles Android UX guidelines, which makes the navigation around

the app intuitive for users with experience using Android OS. It implements the Navigation Drawer as the

principal navigation aid to move around the main functions of the app and around the chapters of the

survey.

All the functions were placed with a user with little to none experience in AVL system controlling or even

lacking Android general knowledge besides making phone calls. There are various elements for ensuring

that users can reach their goals with the app, such as dialogs for informing users about the non

reversible nature of the survey uploads and the tracking process to avoid accidental uploads or stops

of tracking and checks to see if the Android device where the app is running has GPS and location

services turned on, prompting the user to the settings menu to turn it on, so the app uploads data with

correct geotagging.

3 of 12


4/12

Above: Navigation Drawer open showing shorcuts to the Hub Page and survey Chapters.

Completed Development Goals on Base Application Model

The next list covers the features that were on the last document we produced to set goals for the

development of the application. These goals were designed in September of 2013.

1. Improving survey question-type options

a. open questions

b. multiple-choice, list-based questions

c. multiple-choice questions with an other open option

d. multiple-choice questions with autocomplete

e. forked questions

f. jump questions

g. check box questions

2. A smart forking system

a. fork surveys based on the answer of a particular question

b. enable navigation options to be contextually sensitive to forking answers

3. Text autocomplete

4. Improve adaptability for different screen sizes and resolutions

5. Inclusion of elevation with the latitude and longitude data

6. Overall improvement on efficiency and reliability of the app.

7. A cache system

a. stabilize data upload methodology

b. enable data procurement without constant data service

c. enable delayed data upload for large data sets

4 of 12


5/12

Above Left: Open question survey screenshot, in this case a number question that brings up the number keyboard.

Above Center: Multiple choice question with an other option. Above Right: Check box-style question screenshot.

The primary goal in revising the application was to make the application more stable, and enable more

complex question sets into the phone. Thus, these are the primary components that have been

completed in the application. The cache system enable the application to function without any cellular

data service or wireless internet connection. Now, the application can cache all locational data and run

upload processes in the background. These combine to make the app both far more stable and far moreaccurate. Accuracy of locations and data points is discussed in the following section.

Another powerful new function of the caching mechanism is that the phone could be run until the

battery runs out, or the application crashes, and the surveys are still stored inside of the phone. Then,

when the phone it turned on - even if no data connection is present - the user simply needs to find a

wireless internet location and the phone will automatically upload all the data points and survey

responses. This could happen hours, or even days, later. The phone is capable of storing thousands of

data points and surveys in such a manner.

The revised applications improved stability was documented extensively in January 2014s Pereferico

Operations report. This can be viewed online at flocktracker.tumblr.com for more information, orrequested by contacting us.

5 of 12


6/12

Additional Development Accomplishments

The following list explains new features that were placed into the application that were not present at

the time of the initial planning and brainstorming back in September of 2013.

1. Photo questions

a. enabling photo documentation to be built into the survey structure

2. Ordered list questions

a. including an animation-based drag function to enable users to actively create dynamic,

ordered lists

3. Capability for handling surveys of great size and complexity

a. the current UNAM Geography Institute project has more than 200 questions

b. the app can handle and navigate through surveys with multiple chapters and forked

survey paths depending on the answers of the person being surveyed

Above Left: Photography survey question build. Above Center: Ordered list question screenshot. Above Right:

Ordered List being manipulated by a user screenshot.

Photo questions were one of the most significant new developments that occurred outside the original

planned grocery list of application improvements. Additionally, the ordered list option allows for theapplication to incorporate animated components that will simply make the experience more engaging.

Such functionalities were clearly observed as increasing user interest and overall, in-vehicle

participation. Thus, introduction of such elements will surely serve to help make the application more

user friendly in the long run. Furthermore, it makes the interface for ordered lists far les cumbersome

than previous, numbered-based prototypes.

The sidebar addition to the application served to help deal with the more linear nature of the new

6 of 12


7/12

application design for the survey portion. Remedying this and getting an interface that is more hub-like

as was seen in the older model may be a direction we want to look at in the future. That said, currently

the chapter bracketing option that is possible from the slide in the sidebar menu helps to reduce the

systems linearity and also makes performing massive, 200+ question surveys easily navigable.

Summary of Pereferico Report

While the full context of the Pereferico research can be found by, again, reading the actual report; the

technical observation of the new applications accomplishments have been transcribed for

convenience. Route accuracy was extremely high and the ability for the application to cache data, as

well as move most upload tasks to the background, meant no crashes, no lost data, and extremely high

resolution results. Because geolocation was an optimized background task, with the ability to cache

location in instances of low or no signal environments, the application both ran smoothly, as well as was

able to, mostly, capture all locations and all moments along the trip.

Above: Single day route data points (totaling 4,955 data point uploads). For comparison, if we had used this

application instead of the older model during the Summer 2014 research initiative, we would have generated

roughly 50,000 data points on our trips. Instead, due to the technical l imitations of the previous application, we

generated almost 11,000 data points. Accuracy is so high from this applications output, that, along Avenida

Tlahuac on the left portion of the map, data points clearly illustrate the northern and southern side of the road for

the inbound and outbound trips, reflecting the separate lanes for the different sides of the road.

7 of 12


8/12

Above: An up close screen capture of data point location along Avenida Tlahuac. Points, in general, stick to their

side of the avenue and most lie, reasonably, within the limit of the roadway, with some deviation still present.

Above: Here, a screen capture of the same length of road is again presented, this time only showing outbound

routes, traveling east on the southern side of the avenue. As can be seen, in comparison with the previous image,

most points for this portion are able to stay locked to the southern side of the road, demonstrating the level of

accuracy achieved with the smartphone application.

By comparison, as can be seen in the below image, the previous model of the application regularly lost

signal and, as a result, did not have locational data throughout the route at anywhere near the level of

consistency. Furthermore, because it lacked the triangulation capabilities of the current application, its

accuracy was poor, at best. Thus, analyses performed on that data functioned at a resolution of 200

meters. The current application allows for accuracy within 5 meters or less. In examining the data from

the current Pereferico Oriente run, only three outliers were found from a full day of testing with three

individuals for around 8 hours. That is to say, three outliers occurred within a 24-hour span of use. We are

confident in the quality of this output, given these results. Furthermore, because of the robust degree of

data output, far more accurate performance measures can be made in regards to speed.

8 of 12


9/12

Above: Similar route data output from a single days effort along a portion of road emanating from Ciudad Azteca,

when using the previous application. Route data was far less consistently uploaded, impeded by the poor

functionality of the application and inability to handle multiple tasks, from data uploads to survey compiling,

simultaneously, as well as the new version. While the data is still useful for more general measurements and

conceptual elements such as perception, the increased accuracy of the current application will enable far more

targeted locational analysis.

Because of the consistency of uploads, speed can easily be understood by the clustering of uploads. In

areas with more dense uploads, one might interpret that the vehicle covered less ground between

upload instances. In creating a heat map, areas with the greatest clustering also corresponded with the

areas of the slowest speeds. Thus, it can be seen that Avenida Tlahuac exhibits the greatest level of

congestion, over all, in the following image. These areas of congestion are highlighted in red on the heat

map.

The bottom right portion of the trip, which features the least intense coverage, also indicates a route

differentiation from the standard observed path. On one inbound and one outbound trip, a driverhappened to diverge from the typical path, instead heading south from the drop point and turning onto

Avenida Tlahuac farther east than the rest of the trips. This application helps in understanding route

divergence and, with the increased accuracy of this application, makes the specific nuances of each

trip and each route far more legible than in previous iterations of the technology.

9 of 12


10/12

Above: Heat map of upload point intensity along the route. Areas of red have more upload point activity.

From a numbers perspective in terms of surveys, the results also extremely positive. Before going into

detail on this trips performance, a brief description of the data statistics from the research last summer

are to be presented, in order to attain some perspective. Last summer, six volunteers would operate at

two stations per shift, with pairs operating on the ground at the CETRAM, in the route operating within

the CETRAM, and in the route operating without the CETRAM. The total survey output was over 1,500,

with roughly 1,000 of those being from in-vehicle surveying. Thus, over 7 days, 1,000 surveys were

performed. This averages to roughly 72 surveys performed per day, per site within the vehicles, with four

volunteers over a period of two three-hour shifts. This averages to 36 surveys per shift.

Results from the Pereferico Oriente study, which used only three volunteers and only three full round trip

rides, on a trip that was 5 kilometers, which is roughly one-third the distance of the previous CETRAM

study trips, and averaged 30-40 minutes of ride time, generated 122 total surveys for the day, or roughly

61 surveys per shift. This is an output increase of roughly 70% over similar statistics from the summers

effort. While these numbers are not perfectly comparable, given the different environments and time of

year, the application and its ability of catalog processes and run background tasks had a clear role in

enabling the productivity of each volunteer to rise significantly.

The ability for the application to function as a very quick and effective measure of dynamic data, while

providing descriptive statistics on the go, should increase the effectiveness of such efforts

substantially. While more surveying would be needed for further site analysis and a real incorporation of

the multi-variate analysis performed from the summer research and analysis, the potential should be

highlighted and clear through this report. Furthermore, the efficiency and ease of deployment should

make such an initiative and the use of the application attractive, we hope, as an option in future such

efforts. Thank you again for reading and if you have any further questions, please do not hesitate to

contact Kuan Butts at [email protected].

Pending Developments from September

The next list covers the features that were on the last document and were not added since September

2014 and a discussion on why they were not added.

1. Live map

a. including a monitoring option to see where other participant volunteers are in the field at

any time, from within the application

2. A phone contact list connected with the live map

3. A panic button

4. Direct access to a manual for surveying

5. Autocomplete function

The live map was not added simply because it is an extremely complex mechanism that is also a

significant power drain the application. Thus, this component has been shelved for the time being but

will be considered for far more elaborate future builds of the software. A phone contact list is an

important next step in the development of the application. Such a device would allow an operator who

was managing a research effort to call users who were riding off route or in any way performing in a

manner that caused the operator to need to contact that person. The application would simply bring up

the associated phone number with that rider, and this section could be incorporated in the future with

10 of 12


11/12


12/12

a. values of the information stored at the beginning of the tracking process can be

changed during said process so the information dynamically collected

b. behavior of this type of questions would be the same as the passenger counter

function thats already built in in the app

2. UTF-8 compliance for surveys

a. to build from there support to languages with non Latin based character sets.

3. Add support for more languages

a. first for languages that members of the team can understand (Chinese, French)

b. next step would be to then reach out to find help of foreign translators.

Bigger platform

These are features aside from the app that would help developing the platform and making it more

useful and easy to use for a more broad audience.

1. Web dashboard- This feature should allow the flock deployer, flock members and the public to

interact with the information being collected in real time and also for information stored on the

database. It should work on the same way that the original dashboard works, but with theaddition of easily jump between projects.

2. Survey creation interface- Although flexible, the JSON code for generating the surveys could

be a barrier for newcomers to the platform to start building their own projects. Because of that,

a simple web interface that would allow users to create their projects with the ability to

graphically edit and modify the contents and structure of a new survey project for uploading to

the platform.

3. Sharing/Viewing previous projects interface- In addition to the dashboard, a creation, sharing

and commenting platform is needed to develop more community engagement and to publicize

the projects capabilities and research findings.

4. Closed project features- For the private usage scheme. The app would be able to connect

with private databases in different communication and database standards, all with the securityof the information as a priority.

About the Research

Flocktracker is an application being funded through research under Professor Christopher Zegras

Mobility Futures Collaborative at MIT in Boston, Massachusetts within the Department of Urban Studies

and Planning. Current research at Pereferico and the development of the new application Flocktracker

is being lead by Kuan Butts, in collaboration with Daniel Palencia, Arturo Cadena, and Jose Manuel of

Urban Launchpad MX and Danny Chiao, a current undergraduate computer science student (and coder

extraordinaire) at MIT. This research builds off of work from the Summer of 2013, during a research

initiative lead by Kuan and funded through MISTI and MIT Mexico in partnership with local travel analytics

firm Urban Travel Logistics. Team members with Kuan for that project included Arturo Cadena, Liqun

Chen, Gabriel Hernandez, Bin Jung, Daniel Palencia, and Clara Suh. Please feel free to contact Kuan Butts

([email protected]), Arturo Cadena ([email protected]), or Daniel Palencia ([email protected]) with

any further questions regarding the application or research.

12 of 12

State of the Application

Documents

Transcript of State of the Application