Visualization goal
We started this project aligning our goals of what we wanted the visualization to focus on, before moving to making design and visual encoding decisions.

Through this dataset of Fire Calls that happen within Seattle, we wanted to have a better understanding of the city's safety level. We wanted to allow viewers to freely explore the data through an interactive map to either raise their awareness of the neighborhoods they are living in, communities that they are interested in, or to gain a better sense of safety levels. This knowledge can either be used to prepare or prevent fires or to potentially look at suitable areas for living in the (near) future.

Selector for consecutive months
We considered 2 options when creating a time selector to view this set of data - (1) filtering to view data across selected individual months or (2) to view data for a selected range of months. We decided that it was more valuable for viewers to compare how trends of fire calls change over a range of months, rather than comparing between an arbitrary selection of months, so we decided to go with the second option.

Zoomed in vs zoomed out view
When analyzing the dataset, a problem that we first encountered is the huge number of fire calls that happen within a year (more than 100,000 calls). If we made a call to plot each individual point across the entire city of Seattle, not only will the map become too dense to observe or interact with properly, but also the visualization will take a significant amount of time to load the data. This slow loading of the webpage will negatively affect the experience for viewers.

As a result, we decided to create an aggregated dataset for a default view (an overview of the fire calls that occur in Seattle) which will take a significantly shorter amount of time to load, yet provide substantial information for viewers. While the viewers view the entire map of Seattle, the individual dataset is then loaded in the backend. When the viewers continue to click on neighborhoods, the datasets with the individual fire calls would have been filtered and be ready for viewing. In this zoomed in neighborhood view, we are also able to display more information for the respective data points due to the increased real estate (neighborhood area to screen ratio).

For the default zoomed out view, as the data needed to be loaded before making the map visible, creating an aggregated dataset increased our web's performance by 50x since the number of data rows were reduced from 103,000 rows to over 2000 rows. Before checking for the location and plot on the map, we also added a filtering step, which also helped to reduce the number of data points and thus accelerated the plotting time tremendously (instead of processing data for the whole 53 neighborhoods to do plotting, we are now processing 1 neighborhood, which improves the performance by a further 50x).

Tooltips
We chose to display a tooltip when viewers hover over the neighborhoods (rather than displaying all the names of neighborhoods at once) to (1) avoid too much information displayed (fighting with the color coding of aggregated data), and (2) to encourage interaction from users to explore the map.

Input by Users
All the interactions that are available to users (besides hovering and clicking on the map itself) is placed on the right of the screen so that the attention of viewers are focused on one area (rather than jumping around the screen). We also chose to keep the interactions available to the users to a minimum - (1) selection of date range, (2) multi-selection filter of fire calls, (3) hovering to see more details, and (4) clicking to zoom into specific neighborhoods. These interactions are also kept consistent across both views (zoomed in and zoomed out).

Color Coding Fire Calls
In the zoomed in view, fire calls are color coded based on their respective types so that viewers can get a big picture understanding of the distribution of fire calls before exploring each of them separately.

Zoomed out Legend
We decided to have a legend to help our viewers better understand the color coding of our zoomed-out view, which is essentially a density heat map. In our development process, we discovered that the density of fire calls for different areas do not span evenly on a linear scale: most of areas have a density below or around 20 fire calls per 100 people, while a few areas (e.g. downtown, SODO), have a much higher density (e.g. close to 100 fire calls per 100 people). Therefore, we choose to skew our color scale in a way so that a difference between two relatively low-density areas can still be visible to our viewers even when they choose to filter out some dates or types of fire calls. Therefore, we have our legend skewed toward the colors representing low density to reflect such considerations.

Information box for individual instances
Even though we do have a neighborhood label to show location information, we do have a time selector to specify range of time, and we do have a filter of fire calls type to select particular types of fire calls, these information are (1) scattering at different places within the visualization and (2) not giving enough detail information. We would want to help users to extract all relevant information of a particular datapoint as fast and convenient as possible, and a box that contains all of relevant information (fire call type, date occured, and address of the call) seems to be a good decision to condense all of these information in one place. In fact, by creating that detailed information box, we enable our users to instantly extract all information of any particular datapoint just by simply hovering their cursor into that point, which would improve user experience of using our visualization.

All of us were involved in the discussions of how to use the dataset, what features/interactions we wanted in the visualization, and the question that eventually guided the direction of our project.

Yadi and Thai preprocessed and transformed the data to make it more usable, and wrote much of the baseline visualization code as well; Aspen's designed the page layout and interaction patterns, and wrote most of the HTML and CSS; Damien wrote the code to display tooltips, color coding for the macro and micro views, and more. We did confine ourselves to work only within these roles. We also actively provided feedback to each other at each step of the way, but this is roughly how we divided the work. The bulk of our individual work was naturally split based on the strengths that we brought to the team.

The assignment took us approximately 40 person-hours collectively. The most time consuming parts were adding the color encoding on the zoomed-out view and displaying the outlines of the neighborhoods. But mostly it was just a series of moderately time consuming tasks. Another significant chunk of time was also spent figuring out the syntax for D3 (and how it works with HTML/CSS), which was a lot more challenging for Aspen, who doesn't write code regularly.

This project was developed in Google Chrome and Firefox, and will be best viewed in either of these browsers.

References
http://bl.ocks.org/almccon/a53831a573911d0a875821c5f9fac6be
https://github.com/ivan-ha/d3-hk-map
https://bl.ocks.org/mbostock/2206590
[data source] https://data.seattle.gov/Public-Safety/Seattle-Real-Time-Fire-911-Calls/kzjm-xkqj