Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blog: registration: Post on registration management #734

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/blog/2022-10-17-future-of-teaching.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ is the "start page" of the series):
* Teams
* [Hybrid courses vs reverse-hybrid courses](@/blog/2022-11-07-reverse-hybrid.md)
* Open source courses
* Registration and learner management
* [Registration and learner management](@/blog/2022-12-05-registration.md)
* [Livestream courses](@/blog/2022-11-14-livestreaming-courses.md)
* Collaboration in organizing
* [Publishing videos supports more learning styles](@/blog/2022-11-08-video-publishing.md)
Expand Down
89 changes: 89 additions & 0 deletions content/blog/2022-12-05-registration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
+++
title = 'Registration and learner management'
slug = "2022/12/05/registration"
description = "Large courses are more demanding on registration than you'd expect, but we have some ideas."

[extra]
authors = "Richard Darst"
+++

*Part of a series on the [Future of
Teaching](@/blog/2022-10-17-future-of-teaching.md)*

Registration and managing learners can be hard when there are hundreds
of them, but if you plan out a course well, it's manageable.

In a small course, you register and people come, and everything else
gets figured out from there. When you have more than a hundred people
coming, there are pre-made [teams](TODO:LINK), and you don't have "sit
rkdarst marked this conversation as resolved.
Show resolved Hide resolved
an empty table", registration can be much, much harder. Luckily, if
rkdarst marked this conversation as resolved.
Show resolved Hide resolved
you plan the course considering that registration will be a major
task, it can work out OK.

## Basic registration strategies

**Basic registration** would be easy: you let people sign up, they can
get emails. Since we
[livestream](@/blog/2022-11-14-livestreaming-courses.md), people can
even attend without registering, which we think is important (providing
personal data is not necessary to attend - this is by design).
Registering allows someone to receive emails, and it's relatively easy
to send different emails to different groups if desired (for example,
those from our university get information on our local
online/in-person exercise sessions).

At Aalto University, this is what we have done for most online
courses, and it works well.

## Registration including teams

If we want to provide [teams](TODO:LINK) as a service, things get more
involved. The man idea of registering including teams is that we want
rkdarst marked this conversation as resolved.
Show resolved Hide resolved
to make them pre-arranged and the same day-after-day. We want to
rkdarst marked this conversation as resolved.
Show resolved Hide resolved
provide an exercise leader for each team (the same one each day).
rkdarst marked this conversation as resolved.
Show resolved Hide resolved
The in-person equivalent is "sit at a table with at group, that group
rkdarst marked this conversation as resolved.
Show resolved Hide resolved
is yoru team". Our online version is much harder than this, since we
rkdarst marked this conversation as resolved.
Show resolved Hide resolved
pre-plan a lot more. We *could* emulate this by randomly assigning
rkdarst marked this conversation as resolved.
Show resolved Hide resolved
Zoom breakout rooms on day 1, and then ask people to join the same one
each day. But, we think that part of the benefit is assigning similar
teams (if you know someone, you are with them) and having it clear
that rooms *will* stay the same day-after-day.


So, to do this teams online, our registration system needs to:
* Accept the normal registration
* Know a little bit about people to assign them to suitable teams (if
desired).
* Provide a way for people to indicate pre-made teams.
* Provide a way for us to see the information above easily and assign
the teams ...
* ... and then send everyone a customized email with their team's room
number
* And be able to quickly update this information based on last-minute
changes, send people new info, and not get overwhelmed with this
job.

This, especially the last one, turns out to be exceptionally hard. We
are working on ways to make this better:
- point1
- point2
- point3

## Distributed registration

The livestream and [reverse
hybrid](@/blog/2022-11-07-reverse-hybrid.md) approaches allow another
option: **distributed registration**. With this idea, we don't need a
central registration (or if we do, it can be only for general
information), and we let each local partner run a registration that
includes the teams - and let them deal with that locally in a smaller
and more manageable form.


## Summary

We did a lot of great things with [teams](TODO:LINK), but it was a lot
of work back then, and is still a lot of work now. Anyone running a
large course (that goes beyond "infodump to an audience") should
carefully consider how to make this manageable.