-
Notifications
You must be signed in to change notification settings - Fork 23
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
blog: registration: Post on registration management
- History of registration, difficulties of doing it with teams, why this appears online but not in-preson, distributed registration as a strategy. - It does *not* include our latest practices and what we raret trying to do in the future - others can fill that in. - Please add yourself to authors when you add more.
- Loading branch information
Showing
2 changed files
with
90 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 | ||
an empty table", registration can be much, much harder. Luckily, if | ||
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 | ||
to make them pre-arranged and the same day-after-day. We want to | ||
provide an exercise leader for each team (the same one each day). | ||
The in-person equivalent is "sit at a table with at group, that group | ||
is yoru team". Our online version is much harder than this, since we | ||
pre-plan a lot more. We *could* emulate this by randomly assigning | ||
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. | ||
|