We will develop material related to our work aimed at hands-on workshops and tutorials. Our first presentation will be at TechFest NW in August, 2015.
cunningham
I had the opportunity to show Catherine a visualization that is derivative of work I did a year or two ago that explored the use of force-directed motion as a supplement to (not the focus to) visualization. I thought I would develop a class around this idea and use two previously published example codes as case studies.
Both visualizations compute a proper location for the dots but then let collision avoidance and force-directed motion find the closest approximation within the visual constraint of not piling dots on top of each other.
I found that both of these programs took more experimentation than I would have expected. Since then I have learned more about how to approach d3 visualizations but don't consider myself a total expert. I'd like to communicate this one idea, attraction/repulsion as another kind of paint, and convey some confidence to approach this kind of programming. I don't want to talk about d3 at a deeper level, but medium competence will be required for any success.
zimmerman
I like the idea around getting people hacking. I'd suggest two techniques for scaffolding their learning, drawing them into action, and making it a really useful and engaging workshop:
1. Create an activity that has them reading the code and answering questions about how it works. In a speaker-led code-along, give them a tour of the code's structure and one or two of the details, then lead them to one or two areas they would have the most fun changing. Then pair/team them up and turn them loose with some questions. You can use a tool like Socrative to anonymously collect the answers in real time. It gives them a chance to talk to one another about what they're learning and help each other explore the code. Be watching the results, you get real time feedback on what they're picking up and what they're missing. You can finish the exercise with clarification on stuff they're not picking up.
2. Next, when you invite experimentation, prime the pump with one or two experiments of your own, using the appropriate tool chain and demonstrating the hypothesis-change-observation cycle. Then give them one or two pre-defined experiments to try before encouraging them to try their own experiments. Again, pairs or small teams encourage fun collaboration. Walk around as they work and identify one or two participant experiments that might make good demos for the crowd. Have them do short presentations of their work but limit and guide them so they don't wander. (Are you thinking that they should fork the repo as they experiment? Then the people doing demos could publish their own repo URL. Depending on how git-savvy people are, they could submit pull requests with their experiments and observations and you could later re-incorporate their work on examples branches. Just a thought.) Finally, do a semi-improvised wrap-up at the end that reiterates the main learning points and allows you to give feedback on what you observed and learned. This models the behavior of attendees reflecting on their own experience. And, I also really like the idea of using the repo (maybe the wiki?) as a place for people to continue the interaction.