state of the application
TRANSCRIPT
-
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
-
8/13/2019 State of the Application
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
-
8/13/2019 State of the Application
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
-
8/13/2019 State of the Application
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
-
8/13/2019 State of the Application
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
-
8/13/2019 State of the Application
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
-
8/13/2019 State of the Application
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/13/2019 State of the Application
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
-
8/13/2019 State of the Application
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
-
8/13/2019 State of the Application
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
-
8/13/2019 State of the Application
11/12
-
8/13/2019 State of the Application
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