This blog post describes the cRaggy event  at the June 2, 2018 Cascadia R Conf, its design, the logic behind its design, feedback from participants and reflections on how such an event might be better in the future.

Here’s the pith of the how we learn R: The R ecosystem is a marvel made up of a global cloud of people, their connections, their know-how, and their tools.  Learning in this ecosystem involves choosing between specific pathways: a place and time, with certain people, using specific boundary objects — in some reasonable sequence of steps.  The best instructional, event, or conference design results in increased excitement, inspiration, enjoyment, personal connections, and know-how.  In a way, the event pieces that we string together to make up a conference are just like a bunch of R statements that aren’t useful till we put them together with human intention, skill, and passion.

Down on the ground cRaggy started with not much more than the half-baked idea depicted in this drawing:

From the beginning I was thinking of cRaggy as a sequence of steps strung together to structure individual and collective experience, along the lines of liberating structures, with learning objective as the main goal.

The cRaggy design process was itself a string of collaborations with the conference organizing committee.  They helped by validating the original idea and by building on it to produce the final event. Chester Ismay and Ted Laderas, in particular, had lots of of specific suggestions for datasets, which was a key element of the design.  Chester mentioned that Andrew Bray’s students were doing a lot with local, civic data; and one of Andrew’s suggestions was the BIKETOWN dataset which was the one we ended up using. Chester also put me in touch with Thomas Mock, who’s been running the Tidy Tuesday events.  We borrowed a lot of ideas from Tidy Tuesday and email exchanges with Thomas were very helpful in evolving the final design.  Ted has written up some reflections about the overall conference design.

This year’s cRaggy event

We announced the cRaggy event in January, without very many specifics.  As the conference approached, we published a set of instructions for participants, calling it the cRaggy gRaphics show-and-tell.  Here is the super-simple form that people completed when they submitted their entry on the day of the conference:

cRaggy entries were all posted in one corner of the 360 person capacity room where the conference was held.  The beer and food were served in the same corner at the end of the day. People could stand around discussing the entries during the whole day.

The three entries that received the most votes gave a 5 minute lighting talk at the end of the day:

• Pierrette Lo,  Locations and numbers of rides ending outside a BIKETOWN hub
• Charlotte Wickham, When do rides start?
• Kevin Watanabe-Smith, AVERAGE BIKETOWN TRIPS; Median trajectory of weekday trips (2016-2018)

Design  to Balance Opposing Factors

During the design phase and on the conference day, I was aware that “design with social learning in mind” meant balancing two opposing forces.  This table to suggests how those forces alternated, more or less in chronological order, as a kind of learning peristalsis.

Overall feedback from conference participants

In the conference feedback questionnaire, several people said that cRaggy was their favorite part of the conference.  Some said that the lighting talks they liked most were the cRaggy talks. One said, “I didn’t participate in cRaggy this year, BUT I LOVED IT! Please do it again!”

Feedback from cRaggy participants

I wrote to the twelve people who submitted an entry and got really thoughtful and interesting feedback from many of them.

Participants agreed that cRaggy was really fun.  Sample comments were:

 “It was a fun, no-pressure way to feel a bit more involved in the conference and see how other people approached the dataset.”

 “I can’t think of anything more fun than exploring data and creating visualizations.”

Participants especially liked the BIKETOWN dataset because:

 “[it] struck a wonderful balance of being interesting, big-but-not-too-big, in pretty good shape tidy-wise (but not perfect) and fun to explore.”

They liked the fact that the dataset had both dates and geolocation features, which made it “really easy to join up with other sets.”

Part of cRaggy’s value was that the dataset forced people to work outside of their usual professional domain.  For example, two different respondents said,

 “I work in anthropology, specifically archaeology, and so it was really fun to branch out to a very different kind of dataset that has time stamps in the minutes and not in the tens or hundreds of years.”

 “I am a transportation professional and found myself overthinking what to do with the data set a lot [and that was good].”

One participant summarized it,

 “… a big value in the event is exposing people to ideas beyond those directly relating to R code they might not come across otherwise.”

cRaggy was a way to encourage people to dive into the R ecosystem.  One participant was impressed with

 “… how helpful and active the R community is in Stack Overflow, GitHub, CRAN, Reddit, etc. In essence, I am super grateful of R’s passionate developers and user base (in real life and online).“

As a bit of an #rstats glutton, I was struck that one very interesting cRaggy entry was from someone who admitted that they weren’t even on Twitter!  Talk about diversity!

Suggestions for next time

The original idea was to share and think about graphics, but clearly participants thought it could go further.  They thought that cRaggy focused “more on presentation and communication than on coding and data analysis.”  Ed Borasky put his finger on the fact that voting missed thoughtful examination of data problems that weren’t as recognizable as flashy graphics.  He said

 “I spent a *lot* of time cleaning the data. See http://rpubs.com/znmeb/biketown.”

Other suggestions included:

 “It would be cool to easily see links to github repos from the other entrants.”

 “Switch to a virtual format – the “paste on the wall” thing really doesn’t cut it.”

Charlotte Wickham had several interesting suggestions:

 “It might also be nice to somehow celebrate the learning side of the event, i.e. each entrant must also provide a sentence describing something new they learnt or tried in the process of entering, that could be displayed independently of the actual entries.”

 “I’d love to see some more support for those who might be on the edge of entering.  I’m not sure what this might look like, but maybe a pre-conference hack event, a online forum (Slack or something), or just a few more people posting starts they’ve made or questions they’d like to answer.  I’d imagine the primary focus would be on encouraging people to post something on the day regardless of where they get to.”

 How can we keep the event approachable and comfortable for people across all sorts of skill levels?

We wanted cRaggy to result in the selection of people who would give a lighting talk, but participants thought that the voting could be improved.

 “I would suggest that voting NOT be publicly presented via stickers. I would use a ballot box or online kind of voting system that’s anonymous to the voters and participants. As a social network analyst, I would posit that there seemed to be a preferential attachment (i.e. “rich get richer”) effect with the stickers.”

 “Have more categories of winners, such as most creative, most artistic visual / graph, most last-minute (maybe), etc.”

I had thought of having different categories of votes, but never quite figured out the logistics.  In the heat of the conference (after all I was a participant first and an organizer second!) I even forgot to record the number votes that each entry received.  Next time I would display the entry form in advance so that people would expect to provide additional information such as

• How much time did you spend?
• What was your question?
• What packages did you use?
• What did you learn?
• What would you have done with more time?

Beyond that, the cRaggy idea could evolve by somehow mapping the steps people go through as participants to a model of the steps in a data analysis project, either Hadley Wickham’s model from R for Data Science or something along the lines of John Tukey’s (1982) “Introduction to styles of data analysis techniques” ( PDF) that proposes stringing data analysis steps together along the lines of: