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 individuals geospatial 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

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

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 the application 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 Interface The 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

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 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 Text autocomplete Improve adaptability for different screen sizes and resolutions Inclusion of elevation with the latitude and longitude data Overall improvement on efficiency and reliability of the app. 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

2.

3. 4. 5. 6. 7.

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 more accurate. 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, or requested by contacting us.

5 of 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. 2. Photo questions a. enabling photo documentation to be built into the survey structure Ordered list questions a. including an animation-based drag function to enable users to actively create dynamic, ordered lists 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

3.

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 the application 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

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 limitations 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

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

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 driver happened 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

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 kuanb@mit.edu.

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 A phone contact list connected with the live map A panic button Direct access to a manual for surveying Autocomplete function

2. 3. 4. 5.

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

the live map. Similar to the phone, a panic button could bring up a warning on the dashboard and thus broadcast if an issue were to occur with a rider to all those monitoring the effort, as well as all volunteers in the vicinity. A manual for how to survey is in the process of being completed and will be paired with the application for a complete release, ideally on Google Play. The autocomplete function is intended to become more robust. That is, the application is to be modified in order to enable the user to attain greater functionality. Essentially, anything that makes the software easier to use on a hectic and packed bus will make the application operate better, thereby improving accuracy and user output, or productivity, and thus will be pursued.

Upcoming Initiatives The UNAMs Geography Institute project will be this new platforms first test run in a full-sized project. This project will be an excellent opportunity to test the applications features, as well as its reliability and robustness in handling such large scale projects. We are also working on creating a workshop with students from the City Planning students from UAM (Universidad Autnoma Metropolitana), in this workshop we can explore more about different use cases and we can have direct contact with possible flock deployers to know more about their needs and issues they find in the app. In addition to fixing all the bugs we can identify in those experiences, the listed features below are scheduled to be added before the initial release of the app on Google Play Store. 1. Different menu icons for complete versus versus incomplete chapters 2. An about menu with licensing information and links to How To guides and support pages. 3. Include a return option to the configuration screen so the app can exit and switch users and projects a. this needs to automatically end the existing trip so it does not run indefinitely 4. Text overflow adjustments a. make ellipses happen instead of unsightly formatting errors

Proposed Features in the Short Term 1. Explore adding speed as a function a. determine if the accuracy can be improved to a reasonable amount via the accelerometer 2. Add distance covered to the log and survey data 3. The gender and crowding data needs to be re-added to log and survey data a. it was accidentally removed in a previous iteration

Proposed Graphical Adjustments in the Short Term 1. Fix the three bars in the top right that lead to the sidebar; they are too large 2. Remedy the layout issue arising from the formating of the text in the statistics page

Proposed Features in the Short Term 1. Include the ability to adjust trip descriptors during tracking
11 of 12

2. 3.

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 UTF-8 compliance for surveys a. to build from there support to languages with non Latin based character sets. 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.

a.

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 the addition 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 security of 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 (kuanb@mit.edu), Arturo Cadena (a.cadhe@gmail.com), or Daniel Palencia (buzoherbert@gmail.com) with any further questions regarding the application or research.

12 of 12