dereklieu / d3-mapping Goto Github PK

Thoughts for how we might outline the presentation.

Hour 1: Exercises to get the brain moving

1. Introduce ourselves and outline the talk that we will be giving.
2. Quick survey of the class: Who has done d3? How much js do you know? Have you done mapping?
3. Talk about data binding in slides. Show data binding exercise, walk through code. Manipulate in console to illustrate live data binding.
4. Talk about SVG in slides. Show svg exercise, walk through code.
5. Talk about mapping. Show mapping exercise, walk through code.

@jueyang feel free to add on here - I've started the SVG exercises, but we could do one more after the mapping one if the mapping one is quick.

Hour 2: Mapping theory 101

1. In slides, talk about the trade-offs and benefits of all the mapping stacks out there. How can you make a map to fit your needs? Does it need to be interactive? Can it be flat? What level of administrative detail do you need to show?
2. After we walk through the options, introduce our stack: leaflet, mapbox, d3. Explain why we settled on this stack.
3. Talk about how each works in tandem. What part of the stack ecosystem does each fulfill? This is a good chance to introduce Woodstock, demo the map, and show specific segments of the code.
4. Discuss some of the parts of the d3 api we are using with Woodstock - quintiles, etc.

This part feels a little dry but the pizza will help.

Hour 3: Demo

1. This part is probably closer to a half hour, since we want to leave time for Q/A at the end, and since other stuff always runs over. But we should do some sort of walk-through that gets them a working map hosted on Mapbox by the end of this. TBD. @jueyang what was the leaflet tutorial you had mentioned?

The schedule has us starting at 7:15 and going until 8:45, with a half hour Q&A. Here are my thoughts for how we could lay out this hour.

Mapping on the Internet (30 min)

1. Introductions and saying hi. We are here to make maps, but we are also here to understand how everyone makes all the maps on the internet, because there really aren't that many ways.
2. It'll also help us make better decisions about what kind of map suites our data. This will help us avoid killer map-related stress. Once we know about all the maps, we will deep dive into how we made Woodstock.
3. First, there were raster maps. A lot of interactive maps on the web were raster maps. Explain what they are, how you can make them, and what their shortfalls are. Tilemill -> Mapbox -> Leaflet (client). Shortfall: once you make your map, it can take some time to go back and change your map. Benefit: The tech stack is mature and laid-out for you. Once you get familiar, you can generate lots of complex maps without worrying about too much about servers, etc.
4. This is when we should discuss Tilemill, Mapbox, and Leaflet. Mapbox is the server, leaflet is the positioning and interaction layer.
5. Then, people started using vectors. Google maps, Tilemill 2, d3. Vectors can be a lot more complicated, because you're the one doing the nitty-gritty work. They can also be more lightweight than raster maps, and they allow you more flexibility to change variables on the fly. Finally, you can create more complex interactives with vectors (not necessarily good!), and offer different mash-ups of data (sometimes hard!).
6. Quick intro to d3, but they should be familiar already.
7. Discuss how vectors can both take the place of, and complement, map tiles. Some cases require slippy raster maps, in others, you can get away with a good vector map. Some other cases require vectors on top of rasters. Give some real-world examples of each, drawing on maps that people already use.

This will be a good segway into talking about Woodstock...

Mapping Lots of Data

// TODO for Derek

cc @jueyang