Team Members: Derek Coley, Chadi Moussi, Justin Kotalik, Cody Ohlsen
Explore Data
Filter by factors:
Filter by date:
FromScale by metric:
Information:
Design Rationale
In this project, we decided to use a map to visually encode each of the collisions in Seattle. A map is a logical choice, as collisions occur at specific locations. Initially when loaded, the map will center above Seattle. The user may move around the
map, looking at where collisions occurred over the last year, which are represented by circles. The may also zoom in by pressing the plus and minus buttons on the map. On the right of the map, we have a list of filters to narrow
down the data presented on screen. For example, a user may specify that they only want to see accidents that involved alcohol. They may also specify multiple filters at the same time. Just below that, we have a specifier that changes
the size of circles based on counts. When selecting the injuries tab, the map will only display collisions that had injured people, where the size of each circle corresponds to the number of injuries.
Presenting the user with filters and specifiers allows them to make conclusions about trends in Seattle Collisions. We could conclude that there is a high correlation between speeding and it being dark outside, and a low correlation
between speeding and wet roads. Another interesting conclusion that we drew is that almost all accidents on New Year's Eve happen when it's dark outside. Though these are logical conclusions, our visual encoding conveys this information
effectively and clearly.
On the bottom of the screen, there is a slider to change the date range shown on the map. We found this channel significantly easier to use than typing in the date, allowing the users to purely
use the mouse/trackpad.
Finally, when hovering over a circle on the map, the circle will be highlighted pink and the user can see information about the accident on the right side of the page. This includes number of injuries,
fatalities, people involved, and the date.
Most of our interaction techniques we selected were based on previous knowledge and intuitive design. Once we decided to make a map, we asked the question: What makes a good
map? We based our design heavily on online examples, where eventually we narrowed down on using Leaflet for our map. We wanted a minimal map, one which had only roads.
There were many design decision and components that
we eventually scrapped. We originally had a component that looked like the car sales line graph example shown in class, but we decided to push it back for our final project. We also considered using data outside of the last year,
however the load times on our map were too high and it would be too much data for a user to handle.
Development Process
Initially, we all got together to discuss design and datasets that we would use for our interactive visualization. Though our group is focused on traffic data, it is known that collisions are a main cause for high traffic. We then focused on getting the
map working with points on it, as that was a major component that needed to work. We then got the performance better of zooming and loading the map, and then finalized any style components that needed to be finished.
Most of our work was done through pair programming, either with 2-4 of us there. Once the design was mostly fleshed out, we then broke the project off into individual tasks. The hardest tasks in our project were using Leaflet to
display the map and fixing the zoom animation. We initially had our design using updates for points on our map, rather than enter and exit. It took a significant amount of time to refactor the code to use enter and exit. We each
worked around 15 hours on this project, in total around 60 hours.
Justin: Helped significantly with initial planning, figuring out what to visualize. Helped with using leaflet for our map, finding d3 examples to base our implementation on, and writing the design rationale. Implemented
many small things, cleaning up many bugs. He also added in the filter logic, which allowed for some cool conclusions to be made. Helpled with last minute fixes to finalize our project. Also suggested the to use sizes for showing
the severity of different events on the map.
Besides the stuff we worked together on as a team, Chadi helped work on porting our leaflet logic to better use d3's enter/exit/update pattern (instead of always reloading all points), and making use of GeoJSON and SVG
paths. He helped with modifying leaflet's code (with Justin) to send the redraw callback so we can animate during their zoom animation. Other things include when mousing-over a point, a stroke is applied and a sidebar displays
icons and stats about the collision, and a change in our date picker from manually entering dates to a Date Slider that can scrub through arbitrary date ranges.
Derek helped with initial planning and getting the frameworks hooked up like d3 and Leaflet. He spent a significant amount of time getting everything to work together, finding the right tile server, and dealing with HTTPS
certificate issues to ensure our project would work correctly when deployed to Github pages. Derek then helped to implement the initial filtering / rendering of data and implemented many key UI / UX elements of our visualization
like the "explore data" menu. Lastly, he helped to clean up and document our code while fixing a few miscellaneous bugs.
Cody spent a significant amount of time trying to solve some of the problems we ran into initially, such as cleaning up the csv data, and using better rendering techniques when we had 'too much data' on the screen. Cody
built a parrallel coordinates visualization that we might use later in the final project, but we ended up not using it for the prototype. Besides that, a few various fixes and bugs.