Seating (was: Re: Gradebook development)

[Roger Dingledine <arma@mit.edu>]

In message <364FA118.A797E091@chemsun.chem.umn.edu>, 
 wilson@chemsun.chem.umn.edu writes:
>3. Seating charts
>
>Here's something that doesn't seem like a big deal, but it would be
>handy. Some gradebook programs will allow you to reorder your seating
>charts randomly, but I'd like to be able to do so according to
>parameters that I define. Specifically, I use tables in my classroom, so
>I'd like to be able to mix gender and ability automatically in my
>seating charts. It would also be nice to be able to specify certain
>students that should always or never be seated together (or even near
>each other). I should also be able to fix the position of certain
>students. For example, I have a student in a wheel chair who must be in
>a specific location in my room. Bottom line: if I have to go through and
>fix the seating chart by hand after it's created, then I would have no
>reason to use the software.
>
>6. Small-group generator
>
>This is rather like the seating chart program. I use small-groups
>frequently in my classroom for labs and in-class activities. It would be
>great if I could automatically generate the groups instead of doing so
>by "numbering off" at the beginning of class. Just like with the seating
>charts, I'd want to be able to mix gender and ability and prevent
>certain students from being in groups together. Saving the groups with
>my daily lesson plan would allow me to go back and see who was working
>with whom on a certain day.

I gave some thoughts to this, and the real stumbling block is in
defining what a 'seat' is and how it relates to the other seats in
the room. The general case is where you've got seats anywhere in the room;
the concept of a table complicates things further. One solution is to build
an adjacency matrix for each seat, that specifies which seats are 'nearby'
it. This isn't something any sane teacher wants to write down by hand.

A more correct solution is to have a GUI that displays the room, and
allows you to click to create chairs, create tables, resize tables, etc.
This allows a teacher to either describe the current room layout, or
experiment with new room layouts without having to shove all the tables
and chairs around physically to see if it would work out.
To save time, it would have a set of 'standard' layout types ("horseshoe",
"clusters of 4", etc) -- you could specify "I want clusters of 4" and
it would generate a room layout for you, based on your list of students
and your constraints (eg student attributes and likes/dislikes).

So there are three 'parts' to this:

* somebody needs to write the gui to interface with the user. This
  means making stuff that will go on the screen, and then turning
  it into lists of students/attributes/whatever.
* the database format. The lists need to be stored in a convenient
  way, ideally one that other programs in the suite can use directly.
  This shouldn't be that bad -- we can use the same database format/ideas
  as other subprojects on here use.
* The actual constraint-solving stuff: taking in all the student names
  and constraints, and solving who should go where based on proximity
  of each seat to each other seat, etc.

I'd be willing to do #3 if somebody wants to do #1 and #2. (#2 will
probably get mostly solved by the gradebook people. If we're smart,
we'll even share their database.)

--Roger