Bérénice Batut

github email twitter linkedin orcid

When I am giving a training using Galaxy (e.g. ref-based RNA-seq), I usually give a 10-20 min introduction to RNA, RNA-seq using the slides that in the transcriptomics topic.

Then I switch to the tutorial. I show the participants where to find the tutorial on the training material website. I introduce the tutorial story: explain that we want to reproduce an analysis from a paper, introduce this paper, talk about the datasets/samples we will use.

After that, I open Galaxy and I go step by step through the analysis with them:

• introduce the step: give an idea why we need this step
• talk a bit about the “theory” of this step
  • using the schemas in the tutorial to explain for example RNA-seq mapping
  • using legos to explain mapping (and let them try to map lego reads on a reference genome)
• open the tools in Galaxy and going through the parameters with them, explaining the main parameters and their potential effect
• run the tool
• inspect the generated output with them, insist on each new format
• ask the questions that are in the question boxes and/or to do an extra step (identify a new tool, identify and use different parameters, etc)

At some point, I introduce the step and explain the purpose of the step, but let them do it by themselves.

At the end of the tutorial, I spent some time to go through again each step, asking them again why this step, what were the inputs/outputs and in which format, repeating again :smile:

Here is the way I usually give a data analysis training using Galaxy. What is your way?

Mo Heydarian

github email orcid

I prefer to have workshop attendees interacting with Galaxy as much as possible during a workshop. I begin workshops with an overview of the agenda and some brief background on the Galaxy Project. I quickly move attendees over to the Galaxy instance and interactively walk through the Galaxy interface and have them register accounts. From this point on, the workshop is hands-on and attendees are working through vetted exercises. Before executing an exercise, I like to go back to the slides to show some type of schematic representing the exercise and adding some biological context (i.e. showing overlapping intervals if working with ChIPseq peaks and promoters). I like using example data I am familiar with so that I can finish each exercise with some biological insight that was gained from the exercise. I like to end workshops by introducing relevant sub-communities of Galaxy (GTN, Galaxy Biostars) and highlighting Galaxy events (GCC) that enable engagement with the Galaxy Community beyond the workshop.

Things to do before the workshop

• Set up a registration system (Google Forms works fine)
• Figure out the wifi, projector, seating capacity situation.
• Test compute resources, hands-on exercises in advance
• Pre-load sample data, if possible
• Email outreach@galaxyproject.org to have your workshop added to the Galaxy Events Calendar. Tweet about your workshop using the #useGalaxy hashtag

Things to do the day of the workshop

• Show up early
  • Test wifi and arrange tables/chairs so you can easily move around the room to assist workshop attendees
  • Write the web address to the Galaxy instance(s) on a board somewhere, include web address to slides if applicable
• Have workshop attendees complete a feedback form after workshop

Additional considerations

• Slow down and speak up - Speak slow and loud so everyone hears and understands what you are saying.
• Two is better than one - I prefer to have two people conducting a workshop. One person is guiding attendees through exercises, while the other is floating among the audience, helping anyone who has fallen behind.
• Leave no one behind - I have noticed that if a person falls behind the pace of the group, especially the presenter, even a little, they have a difficult time re-engaging. I try to prevent this by frequently verbally repeating exactly what I am clicking on while presenting the hands-on exercises.

Saskia Hiltemann

github email linkedin orcid

First off, I really like this idea of collecting different instructor’s experiences, and love hearing about other people’s styles, I am still trying to find what works best in which situations and this is great!

I have a similar philosophy, I like to start off with introductory slides, but not too long, I prefer the focus to be on the hands-on part. How exactly I do the hands-on part (whether I perform each step centrally and have students follow along, or if I have them work through the manual at their own pace and walk around for some 1-on-1 questions/discussions- depends heavily on the audience and topic. Some considerations:

• I often have groups of very mixed backgrounds, e.g. bioinformatics postdocs together with seasoned biology professors/PIs and medical clinicians (who aren’t quite as computer savvy), together with university teachers looking to incorporate Galaxy into their curricula; and they typically go at vastly different paces. If I do things centrally, some will struggle to keep up and feel lost, and others may feel like things are going too slowly/be bored. In these cases I tend to prefer to let people go at their own pace, I think it is better if some people only make it halfway through the tutorial but at least understand that half well, rather than pulling them through too fast and leave them feeling like Galaxy is too complex for them. This also enables people to focus on/play around with the aspects that are interesting to them, some people want to understand every detail of the file formats, others just want to get a global picture of the topic and then explore unrelated aspects of Galaxy when they have time left over, or have a discussion with one of the instructors. Everybody gets something different from the workshop and that’s ok!
• Doing everything centrally has downside that not everybody feels comfortable asking their questions in front of the class, but letting participants go at their own pace and answering questions one-on-one can be nicer for them (feasibility of this also depends on ratio of trainers-to-trainees, you want to be able to spend enough time chatting with everybody). This also gives opportunity for participants to ask questions that are specific to their research/situation etc.
• Working centrally does help pull people along if time is tight or if motivation is a concern (i.e. the researchers I teach are usually intrinsically motivated or they wouldn’t be there in the first place, but teaching e.g. bachelor students who are only there because they have to be, was a very different experience ;))
• I usually end up doing something in the middle, most tutorials are naturally divided into substeps (e.g. QC/analysis/visualization/interpretation). After introductory slides, I introduce first hands-on subpart, ask them to work through manual themselves until they reach part X (say 30 minutes), walk around helping people when they get stuck or have questions, then do a quick recap centrally of what we did and why, ask them some questions to test their understanding, and then introduce the next section (often switching back to a few slides) and repeat.

Other random points:

• I like to walk around the room continually when not doing anything centrally, a lot of people are much more inclined to ask a question when you are standing right there next to them than when they have to get your attention from across the room.
• Repeat, repeat, repeat. You really can’t explain things often enough, so mention things in the introductory slides, then repeat them during the hands-on session, then again during a wrap-up at end.
• I like to encourage people to work in pairs, it forces them to discuss things with each other, and on the practical side: if they bring their own laptops or are in a computer room that doesn’t have dual monitors, having the manual open on one screen and Galaxy on the other is a nice way to work (split screen is not always very practical on small screens)
• I show up early to prepare the room, makes sure there is power for everybody, the wifi works etc, familiarize myself with the systems for presenting slides etc, chitchat with participants as they trickle in, make yourself approachable
• I like to prepare some organizational slides containing all other links the participants will need, the schedule, the materials, location of lunch etc, and make this into a tinyurl so that it is easy for participants to remember; one link to rule them all (for example https://tinyurl.com/GalaxyWorkshop from my last course, I just change content of slides for every new workshop)
• Before they leave, make sure participants have everything they need to keep learning; the tutorials and slides, but also ensure they know where to ask questions and engage with the community; biostars, gitter, github, mailing lists, events calendar etc.
• I keep a running list of issues we run into during the course, and can use this to improve the training materials later, or read through when preparing the next course, but I usually forget most of these points if I don’t write them down as they occur.
• Have fun! If the workshop is enjoyable for you that will rub off on the students, so find the style that feels best for you! :)

EDIT: I just wanted to add that this is just a list of things I try to do and stick to, but in reality I often forget to do several of these things or things don’t work out as intended/hoped or are complicated by circumstances of the day. And I am still continually revising this list and updating how I do things based on feedback from participants and tips I pick up from watching others teach etc

Helena Rasche

github orcid

Love this idea! Y’all’s posts were really helpful in the past days to give me some ideas and inspiration and maybe? a bit more confidence for holding my section of a workshop tuesday. It’s been… a couple of years since I gave a training, so I feel incredibly unqualified to post next to y’all since y’all do this way more regularly.

But I gave a sysadmin-focused training yesterday and it was somewhat different to most of the stories here, so I’m writing this in case other admin trainers can find something useful.

Some philosophy things

• Like @shiltemann I really prefer the at-your-own-pace. For really complex admin tasks + different skill levels, I find it a good fit. Everyone has their own gaps in knowledge due to specialisation, or their own issues due to their compute environment. Being able to help debug one-on-one with the particular problems of users is efficient for allowing everyone to continue making progress, no matter what their pace. Similarly people have different interests, sometimes you can spark them by linking to the “detailed capabilities” pages, so like the full list of things ansible can do out of the box, or everything terraform can manage. Maybe they can get inspiration from this list for how to apply the tool to their setup.
• Doing everything centrally can also work if everyone is on a standard environment. Here you can explain things in detail and have more opportunities for asking questions to the audience to check understanding which you miss out on in the one-on-ones
• Put everyone on the same, standardised environment. Provide some cloud VM with a web based file browser/editor/etc (e.g. Jupyterlab/Cloud9). If possible, provide a URL for the already running machines to the trainees; sometimes they forget to download the VM+setup virtualbox ahead of time.
• Before teaching any training module for the first time, run through it with a less experienced colleague. Administration topics often include large silent assumptions about prior knowledge. Running through the training with them will let you identify these issues and then you include any missing background knowledge in collapsible boxes or tips boxes.
• In a similar vein, be extremely specific in instructions. Where should each command be executed (maybe include terminal prompt, user@laptop vs user@cloud), exactly which URL people should be at for other tasks.
• Not everyone will be proactive in asking questions/putting their stickers up; it is good to walk around and talk to people often and ask how they’re progress or finding things even if they seem to be doing ok. In my experience they’ll often have issues that you can answer briefly or questions related to the use of the material in their own projects
• If possible, find common ground amongst participants (everyone needs to … build reproducible environments, everyone needs to ___) and from this, provide them with motivation for learning the tool you are teaching. In some trainings this is easier to do than others, and it depends on your audience and the topic.
• Have backup plans for your backup plans. If something out of your control goes wrong, at least knowing you have a plan can be reassuring as a trainer

Things I wish someone had reminded me of before hand

• To reiterate @MoHeydarian, especially if you’re a native speaker, talk slowly, clearly, loudly, and with as little slang/jargon as possible.
• From @shiltemann to me: “don’t be too hard on yourself. It’s tough, nothing will go perfectly smoothly”

Other

• @shiltemann’s tip about a tinyurl with all of the links was really useful, everyone could find the documentation without too much trouble!! Loved that.

Tomas Klingström

github email twitter orcid

I have been working in three very different training environments.

1. Lecturing with a biology students in an applied bioinformatics course.
2. Classroom training with biobank experts working to create a more comprehensive service for users.
3. One of one with system administrators expanding into the technical part of bioinformatics support.

I agree with everything said above so I will try to add some more specialised flavour. I would also like to add that I think the Galaxy Training resources are absolutely fantastic and if I get the opportunity to hold a more comprehensive course (ie more than half a day) I will structure it so that we have one quick joint introduction and then conduct a number of interactive tutorials using the training portal.

Case 1 students

• For students context is king. I think almost everyone how many open resources there are available in the world and this is especially true for students. Knowing what is available for download and/or through the “Get data” tab of Galaxy is therefore a valuable exercise in itself, likewise informing the students about key resources such as the GTN, Biostars and Stack Overflow is very important.
• Students often spend so much time writing/clicking commands that they forget about the biological context. As a teacher I think it therefore is very important to help students take a step back and ask themselves why they do a step. For example, after doing the steps to assembly RNA-seq reads it is good to break the work, show an assembly of an mRNA and help them remember what we have done and then explain how the next steps are to map it to the genome so that we can identify it in an unambiguous manner before doing the statistics.

Case 2 experts

• Catching the attention of experts (in another field than bioinformatics) is often a bit of a challenge. Not due to a lack of interest but because their focus is often on a narrow but very well defined area. Meaning that it is often very valuable to pre-plan exercises to be directly applicable within their own research. Ideally I would like to work give a training in such a situation that even the “get data step” is based on their local environment but that is unlikely to be possible in most cases.

Case 3 system administrators During our set up in Gambia I had a very positive experience regarding using the Dockerized Galaxy set up. Configuring environmental variables and then just running the docker run command gives a very good insight in how to adapt the system for a local environment without running the risk of ruining your environments. At SLU I am now working to take this a step further with a Nextcloud implementation that provide us with a back end for handling FTP data to and from the docker FTP server.

Anthony Bretaudeau

github email twitter orcid

My turn!

I mostly do training sessions for Conda and Galaxy tool dev, and some of the tutorials from GTN, mainly assembly and annotation until now.

The last time we did the Conda/tool dev one, some people wanted a tool dev training, some others wanted a Conda training. So we made it in 2 (small) days: 1 for conda, then 1 for tool dev. It worked great like this, people could come to Conda only or both Conda + tool dev.

For data analysis trainings, we usually focus on one topic, for half a day, or a full day.

For all these trainings, we have well-equiped training rooms with 1 PC for 1 or 2 people. Often people come with their own laptop. We leave them free to use it: if it’s for data analysis, it should just work with a modern web browser (and it’s good to work in their familiar environment). For dev, they just use a ready to use virtualbox image (we have it on usb stick if needed).

A few principles I try to adopt:

• Be simple: we try to keep it as informal as possible, with no registration fees, and invite (local) people to join just by sending us an email. I think it allows people to feel more free to come (they dont have to ask their boss for money). The little downside is of course that some of them can be less motivated, and can cancel at the last moment. But it’s ok for us.
• Make it a fun moment: I love making bad jokes and silly puns (and I’m not ashamed). The good thing is that it makes the atmosphere more relaxed, and people are usually more prone to discussion when they’re relaxed (they have no risk to be more ridiculous than I am). I feel that if a training session is very boring, people will disconnect after a moment, they will not come back to another session, and I will not be willing to do it another time as a trainer. So, have fun.
• Adapt to the audience: if a participant needs to focus on a specific question/kind of data/whatever, try to integrate it in the training. In our case, we usually propose a training after someone asks us to do it, so it’s easy to discuss it beforehand and try to adapt to their need.
• Keep contact with people: I hate it when a trainer is just reciting the slides, not even looking at people. So I try to keep contact with attendees, asking questions, trying to detect when someone gets lost, reexplaining when I see that something is not clear.
• Be honest: don’t try to hide when you don’t know an answer or if there’s an unexpected result. It’s a good opportunity to look for the answer or understand what’s going on together.
• Don’t be alone: I prefer to be at least 2 trainers. It allows to answer questions more quickly, and to reexplain things differently if needed. (and it is more fun too)

We also do a full week of bioinformatics training for biology students (I don’t participate to all the sessions though). Most of them have never manipulated a fastq file, but they have a good biology background. Each day we begin with slides to introduce the topic (2~3 hours), and the rest of the day they run the hands-on. The first day is an introduction: why computing matters in biology? what is a computing cluster? what is Galaxy? Then they run the Galaxy 101/peaks2genes tutorials. Second day is for genome assembly and annotation, third day is RNASeq analysis, and then they have some snp calling and metagenomic. The program might look scary, but we don’t try to make them experts of each kind analysis, we just try to give them a concetre overview of what it looks like to do real data analysis.

For the hand-on we (2 trainers) usually give them access to the tutorial, give them a brief overview of the goal, and then just let them work. We keep on circulating, checking that no one is blocked, answering questions. When we get 2 or 3 times the same question, or if we see they have difficulties, we stop everyone and clarify the problem.

• I’m always amazed how quickly they understand how to use Galaxy
• Tutorials are well suited to this audience, they just follow it and that’s it
• The downside is that if you don’t discuss with the students, they can just follow the tutorial, get their result, even if they have not understood anything. As they’re shy and forced to be here, they won’t necessarily ask for help…
• As they’re shy and forced to be here, we get few questions during the slides too.
• To fight this, and as we are evils, we hide some answers to the questions in the tutorial (we give them a pdf), and we ask them to write them in a report. We also add a few questions on the slides too, to make sure they listen. We don’t really care if they cheat, and we help them if they’re blocked. It’s just a way to force them to think about what they do. Not completely satisfied with this system, maybe we’ll change it next year…

That’s it for me.