As a professor at a small liberal arts college, most of my research gets done with a fresh group of 2-4 undergraduate students over the course of 10 weeks each summer. These students have to quickly ramp up on part of my research and make a contribution all before August vacation. This summer I wanted to develop a workflow that would enable students to get onboarded as quickly as possible, get help when they needed it (while leaving me some time to get my own stuff done), and also document their work for me and the next round of students that join in the future. I decided to conduct an experiment where my students and I used a combination of the instant messaging service Slack and the collaborative notetaking web app Roam Research to conduct our research. I found the combination of real time messaging in Slack with the capability to record meeting notes and workflows in Roam to be a great combination that was easy for students to use and helpful for their planning and reflection if set up appropriately.

Why Slack and Roam

I decided to use Slack because it enables real-time communication via both personal messaging (for private conversations) and public channels (so everyone knows what is going on and messages don’t have to be repeated). While there are many other services that do this as well, my students all already know how to use Slack and it is free for teams with limited messages, so it seemed like a good choice.

However, Slack doesn’t address things like documenting workflows, so I wanted another tool. In the past I used a research group wiki / knowledge base with documentation about how to get set up with different parts of the project, and project pages for each student. However, no one (even including myself) really used the knowledge base, and it felt like a chore to keep updated. I’ve been using Roam a lot lately, and feel that it is so much easier to start writing in, so I decided to try Roam out mostly as a glorified wiki and for daily/weekly stand ups.

Implementation

My implementation in Roam focused on sticking to the basics as much as possible. I relied heavily on roam/templates that students just needed to apply on the daily notes page or their personal page. I kept on immutable blocks, which means that users can only edit their own blocks unless someone places a child block under one of your own blocks. Block references were included in many of the templates, but students were not expected to make their own block references (though I did show them how to do it once). Students were also taught the basics of indentation, especially about indenting under the blocks generated by the templates shown below.

There were four components of the implementation this summer:

  1. Onboarding
  2. Daily and weekly check ins
  3. Mid-summer check in
  4. Offboarding

Onboarding

I onboarded my students by welcoming them in a Zoom meeting and adding them to the Slack server. I set up a dedicated channel for summer research. Next, I added them to Roam1 and a shared Google Drive folder. I showed the students how to create a Roam account and then sign in and open our shared graph. Pinned in the left sidebar was a page called “START HERE.” Inside that page was a brief introduction to Roam, along with instructions to create their own daily page.

I set up an onboarding template that included items like setting their display name, setting up software we use like Zotero, instructions to prepare a research proposal, etc. Each of these tasks linked to a dedicated page in the graph as needed. I also had students practice making their first daily standup page during the onboarding template and checked in to make sure each student understood how to use the basics. I included some “Tips & Tricks” on the getting started page, and explained what the students should do each day and week.

Daily and Weekly Check ins

At the beginning of each day and week, students completed daily and weekly check in templates. The daily check in templates were completed on the daily notes page and the weekly check ins were on each student’s personal pages. The daily check looked like this:

  • [[Name]]
    • [[Daily Stand Up]]
      • What did you accomplish yesterday?
      • What are your plans for today and the coming week?
      • Is there anything you are stuck on?
      • Do you need anything from the team?

I reviewed the student check ins each morning on my way to work and sent a message to the summer research channel in Slack saying good morning and responding to anything of note. I intentionally messaged the whole channel most of the time so students could see what other people had questions about or were working on.

The weekly meeting agenda looked like this (items in (()) were shown as comments in Roam hidden by a little astrolabe symbol):

  • [[One on One Meeting Agenda]]
    • Follow up from last week: ((Insert action items from last week (if applicable), list their current status, and reflect on how the week went.))
      • [[Review]]
        • What were the goals from last week?
        • What was completed?
        • What was not completed?
      • [[Retrospective]]
        • What went well during the sprint / what is going well so far?
        • What could be improved?
        • What resources do you need moving forward?
    • Goals for this week:((insert plans for this week here))
    • Upcoming Deadlines: ((Insert specific upcoming deadlines (as needed).))
    • Goals for Meeting: ((Insert the desired outcomes for the meeting, including specific topics to be discussed and decisions made.))
    • Agenda: ((insert the meeting agenda here))
    • Notes: ((Insert notes from meeting here.))
    • Action Items: ((Insert action items, grouped by person, to be completed in the following week after the meeting.))

I reviewed the meeting agenda quickly at the beginning of each meeting, and then let the student run the meeting itself. We both recorded action items for moving forward after the project.

Mid-summer Check In

Half way through the summer I had students complete a mid-summer check in. This check in included the review and retrospective sections like in a weekly review, and also included a self-assessment about research adapted from a University of Colorado Boulder assessment about student assessment of learning gains from summer research. I used the Roam slider feature to allow students to score their learning gains from 1 to 10. We had extended one on ones that week and discussed their responses and what to focus on in the rest of the summer.

Offboarding

At the end of the ninth of ten weeks, I created and shared an offboarding template with the students. This contained instructions in the same vein as the onboarding template, including expectations for a final research report, where to put important files, and an exit questionnaire about their experience with summer research and their experience using Roam.

How it Went

Overall, I think Slack and Roam were a great combination. Slack allowed for conversation, with Roam dedicated to check ins and meeting notes. I think it would have been more confusing for everyone if we had tried to have any real conversations in Roam itself. But, since we were working a mix of in person and remote, it was not a problem to discuss over Slack or meet up in person or on Zoom.

Roam was much easier and more fun to use than a traditional wiki. Students said that writing on the daily notes page helped them stay organized and prioritize what to get done each day, and it was helpful for me to see what each student was working on and be able to answer quick questions based on their check in. The weekly template allowed for us to quickly get on the same page about what to discuss during the meeting, and what the action items were after the meeting.

It was also very useful to be able to document workflows. There were some pages that I created for onboarding purposes that we updated throughout the summer as needed, and students created their own pages to document workflows for the group in the future. One student noted that it was nice to be able to open up different pages in Roam without having to open multiple tabs like with Google Docs.

Ultimately we did not document everything in Roam; sometimes we still used Google Docs for writeups that involved a lot of images and formatting, or when multiple people needed to edit the document at the same time as immutable blocks make collaboration on a page very difficult.

One student commented that a downside of Roam was the lack of folders, and that pages were hard to find in the graph. I think the opacity of the graph database is something that can be hard to get used to with Roam in general, but I do think I could have made things easier to find by teaching students how to use queries and/or setting up specific tags for us to use when we created new pages. Right now the number of pages is small enough that one can simply look for the page on the all pages list, but as the graph grows more organization will be needed. I will probably use index pages instead of queries to make the graph more user friendly.

Takeaways

My major takeaway from this experience is that a team of undergraduate students can work productively in Roam with the appropriate scaffolding through templates. Students were readily able to pick up things like formatting text, but we did not explore more advanced topics such as block references or queries. At this basic level, Roam is good for coordinating and checking in on projects, but not for something more complex like group sense-making through e.g. zettelkasten. Still, even for professional teams a simple workflow like this one could be a good way to start, only introducing complexity as the size of the database grows and individual users become more comfortable with the tool.

Notes

  1. While Roam is not free if one is not on the Roam scholars plan, I was the only one who needed to have a paid Roam account; the students could join my graph for free. ↩